Re: 4.2 TODO update

[Olaf Hering <olaf@aepfle.de>]

On Tue, Feb 14, 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.

The workaround for the guest crash I were seeing:
http://lists.xen.org/archives/html/xen-devel/2010-11/msg01609.html

I once modified xenpaging to keep the pagetables paged out as much as it
could (and still allowed the guest to make at least a little bit
progress) and run into no appearent issue.

> > Another thing reported by Huawei on this list was somewhere in the
> > emulation code where a gfn_to_mfn() failed.
> 
> Can you point to the original report? Is there anything more specific?

It was vmx_load_pdptrs().
http://lists.xen.org/archives/html/xen-devel/2011-09/msg01336.html

> > 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...

How can xenpaging know what gfns are pagetables?

Olaf