Re: [Xen-devel] 4.2 TODO update

["Andres Lagar-Cavilla" <andres@xxxxxxxxxxxxxxxx>]

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

How about judiciously adding the following

get_gfn_sleep(d, gfn, type)
{
  if (d == current_domain && !in_atomic())
  {
    printk("Naughty");
    crash_domain(d);
    return INVALID_MFN;
  }

retry:
  mfn rval = get_gfn(d, gfn, type)
  if (d == current->domain && type == paging && !mfn_valid(mfn))
  {
    put_gfn(d, gfn);
    go to sleep on wait queue;
    goto retry;
  }

  return rval;
}

Then we could toss it in before vmx_load_pdptrs gets to do evil things,
for example.

Andres

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