Re: [Xen-devel] [PATCH 09/15] x86/emul: Avoid raising faults behind the emulators back

[Tim Deegan <tim@xxxxxxx>]

At 16:40 +0000 on 23 Nov (1479919254), Andrew Cooper wrote:
> On 23/11/16 16:31, Tim Deegan wrote:
> > At 15:38 +0000 on 23 Nov (1479915532), Andrew Cooper wrote:
> >> Introduce a new x86_emul_pagefault() similar to x86_emul_hw_exception(), 
> >> and
> >> use this instead of hvm_inject_page_fault() from emulation codepaths.
> >>
> >> Replace one hvm_inject_hw_exception() in the shadow emulation codepaths.
> >>
> >> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> >> NOTE: this is a functional change for the shadow code, as a #PF previously
> >> raised properly with the guest will now cause X86EMUL_UNHANDLABLE. It is my
> >> understanding after a discusion with Tim that this is ok, but I haven't 
> >> done
> >> extenstive testing yet.
> > Do you plan to?  I think this is indeed OK, but there may be some edge
> > case, e.g. an instruction that writes to both the current top-level
> > pagetable (which can't be unshadowed) and an unmapped virtual address.
> > That ought to raise #PF in the guest but might now spin retrying?
> 
> That is a devious corner case.  I take it you have been there before?

In similar situations, yes. :)

> The more I think about these changes, the more I think that the shadow
> code would be better by selectively looking a pending event, injecting
> pagefaults, but rejecting and retrying if any other event shows up.

That sounds like a good idea, and seems like the smallest deviation
from the current behaviour.  It might also be OK to inject any event
that the emulator raises.  That's a bigger change but maybe a more
coherent end result?

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel