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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 23/11/16 16:50, Tim Deegan wrote:
> 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?

Well - now this isn't hidden in a security fix, I am less averse to
functional changes.

My only concern is that the previous lack of the ->inject_hw_exception()
hook cut off large chunks of functionality from the shadow and PV PT
emulation paths, and I am not sure opening this up in general is a good
idea.

Longterm the plan is to fully split the decode and emulate calls even
for external callers, at which point the the pagetable code could check
that the instruction is write which matches %cr2 before proceeding with
emulation.  Even then however, I am not sure it would be a good idea to
follow anything other than a pagefault which surfaces from emulation.

~Andrew

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