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

Re: [Xen-devel] 4.2 TODO update

  • To: "Olaf Hering" <olaf@xxxxxxxxx>
  • From: "Andres Lagar-Cavilla" <andres@xxxxxxxxxxxxxxxx>
  • Date: Tue, 14 Feb 2012 09:34:03 -0800
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, tim@xxxxxxx, ian.campbell@xxxxxxxxxx
  • Delivery-date: Tue, 14 Feb 2012 17:34:32 +0000
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; q=dns; s= lagarcavilla.org; b=aSpi3i/+iYIXcMGHm136SciWk/kyyiB4CwiFESb+rx+8 Rp3lWmyyZMwykI/MDyGHIXTWfx8BbUluL64dh7YGQFY9kQBi3xEqVTC7DA5NRjK7 4IDdU2DydDKG8wJhU/O1WP1fGCk9hyaqZi4bPwImPHcvglEmsOPCbjcHd6m2hxg=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

> 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

This makes sense. It's basically what emulation does (X86_EMUL_RETRY). Great!

> 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

I have a patch queued up for cleaning up vmx_load_pdptrs so that it
doesn't crash the host if the cr3 is paged out for a PAE guest.

You can't really do what they propose (mdelay, retry). You're in a
hypervisor context holding locks, nothing is getting scheduled!

One option worth considering is testing the cr3 "early enough", when it's
safe to sleep.

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

There's a bunch of heuristics one can try. It boils down to a lengthy
discussion about what the pager is trying to do. Say, you can
statistically sample cr3's, map candidates and look for page table-like
structures, exploit knowledge about the guest OS.

I'll agree though that the hypervisor support should be good enough that
the pager should not care. But it isn't and it won't get there quickly,
and I don't want us to be cavalier about these wait queues.


> Olaf

Xen-devel mailing list



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