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

Re: [Xen-devel] [PATCH v2 08/19] x86/emul: Rework emulator event injection



On 28/11/16 14:24, Tim Deegan wrote:
> At 12:48 +0000 on 28 Nov (1480337304), Andrew Cooper wrote:
>> On 28/11/16 12:04, Tim Deegan wrote:
>>> At 11:13 +0000 on 28 Nov (1480331605), Andrew Cooper wrote:
>>>> +    /*
>>>>       * NB. We do not unshadow on X86EMUL_EXCEPTION. It's not clear that it
>>>>       * would be a good unshadow hint. If we *do* decide to 
>>>> unshadow-on-fault
>>>>       * then it must be 'failable': we cannot require the unshadow to 
>>>> succeed.
>>>>       */
>>>> -    if ( r == X86EMUL_UNHANDLEABLE )
>>>> +    if ( r == X86EMUL_UNHANDLEABLE || emul_ctxt.ctxt.event_pending )
>>> No thank you.  The comment there explains why we don't want to
>>> unshadow for an injection; please let it stand.  Or if the new
>>> semantics have changed, update the comment.
>> This addition is no functional behavioural change from before, which is
>> the point I was trying to get across.
> I can understand why you want to do it that way but it makes the
> series (and this code!) read quite oddly.  If you keep this, then
> please add a second comment above this line that explains why the code
> temporarily disagrees with the first comment. :)  You can delete that
> comment again in patch #13.
>
> With that, Acked-by: Tim Deegan <tim@xxxxxxx>

How about this?

~Andrew

--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -3374,11 +3374,33 @@ static int sh_page_fault(struct vcpu *v,
     r = x86_emulate(&emul_ctxt.ctxt, emul_ops);
 
     /*
+     * TODO: Make this true:
+     *
+    ASSERT(emul_ctxt.ctxt.event_pending == (rc == X86EMUL_EXCEPTION));
+     *
+     * Some codepaths still raise exceptions behind the back of the
+     * emulator. (i.e. return X86EMUL_EXCEPTION but without event_pending
+     * being set).  In the meantime, use a slightly relaxed check...
+     */
+    if ( emul_ctxt.ctxt.event_pending )
+        ASSERT(r == X86EMUL_EXCEPTION);
+
+    /*
      * NB. We do not unshadow on X86EMUL_EXCEPTION. It's not clear that it
      * would be a good unshadow hint. If we *do* decide to
unshadow-on-fault
      * then it must be 'failable': we cannot require the unshadow to
succeed.
+     *
+     * Note: Despite the above comment, this path has actually been handing
+     * exception circumstances raised by the emulator itself (e.g.
singlestep)
+     * because of the lack of the inject_hw_exception() hook.
+     *
+     * With this change, exceptions raised behind the back of the emulator
+     * still return without setting event_pending, but exceptions raised by
+     * the emulator do.  Force these exceptions back onto the UNHANDLEABLE
+     * path for now, so they are similarly ignored.  A future change
will fix
+     * this properly.
      */
-    if ( r == X86EMUL_UNHANDLEABLE )
+    if ( r == X86EMUL_UNHANDLEABLE || emul_ctxt.ctxt.event_pending )
     {
         perfc_incr(shadow_fault_emulate_failed);



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

 


Rackspace

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