Re: [Xen-devel] 4.2 TODO update

[Tim Deegan <tim@xxxxxxx>]

At 08:47 -0800 on 14 Feb (1329209245), Andres Lagar-Cavilla wrote:
> > On Tue, Feb 14, Andres Lagar-Cavilla wrote:
> >
> >> Why? Because it's really really hard to guarantee we'll go to sleep in
> >> an
> >> atomic context. The main use for wait queues (imho) is in hvm_copy, and
> >> there's a zillion paths going into hvm_copy (copy_from/to_user!) with
> >> all
> >> ways of bumping the preemption count.
> >
> > If the guests pagetable is paged out this code path will trigger, then
> > one of the hypercalls returns an error and the guest runs into a BUG().
> > I think it was decrease_reservation, or similar.
> 
> Unlikely to be something specific about decrease_reservation. If the guest
> page table is paged out, then copy_from_user for any hypercall, or,
> "virtual address to gfn" for any emulation will run into this.
> 
> Now, even an innocent-looking rcu lock anywhere in this code path will
> crash the host if we go into a wait queue. Hence my concern.

OK, so the current code breaks the guest and you're worried about it
crashing the host instead.   That seems fair.

Maybe we can arrange that instead of bugging out if the cpu is
in_atomic() it gdprintk()s a big ol' warning and crashes the guest?  It
seems no worse than the current failure modes.

> > What other way exist to make paging 100% transparent to the guest?
> 
> Don't page out page table pages? I know you were not expecting that...

Sadly, it's not possible to reliably detect which pages are pagetables
(or the shadow pagetable code would be more straightforward!).

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel