[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] 4.2 TODO update

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:

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

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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.