|
[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |