On 10/12/2018 11:32, Jan Beulich wrote:
> In commit efe9cba66c ("x86emul: VME and PVI modes require a #GP(0) check
> first thing") I neglected the fact that the retire flags get zapped only
> in x86_decode(), which hasn't been invoked yet at the point of the #GP(0)
> check added.
>
> Ahead of the other explicit return (rather than "goto") path use an
> explicit return here too, to make the flow more obvious.
>
> Signed-off-by: Jan Beulich <[email protected]>
How did you discover this issue? I ask because given the comment, its
quite likely that you'll hit the assert in x86_emul_hw_exception()
Why is the zeroing code in decode rather than emulate? I'm tempted to
suggest that we fix this by requiring that callers pass in a suitably
initialised ctxt.
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -3400,10 +3400,15 @@ x86_emulate(
>
> ASSERT(ops->read);
>
> - generate_exception_if((mode_vif() &&
> - (_regs.eflags & X86_EFLAGS_VIF) &&
> - (_regs.eflags & X86_EFLAGS_VIP)),
> - EXC_GP, 0);
> + if ( unlikely(mode_vif()) &&
> + (_regs.eflags & X86_EFLAGS_VIF) &&
> + (_regs.eflags & X86_EFLAGS_VIP) )
> + {
> + x86_emul_hw_exception(EXC_GP, 0, ctxt);
> + /* x86_decode() was not called yet. */
> + ctxt->retire.raw = 0;
> + return X86EMUL_EXCEPTION;
> + }
>
> rc = x86_decode(&state, ctxt, ops);
> if ( rc != X86EMUL_OKAY )
>
>
>
>
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
