Re: [Xen-devel] [PATCH for-4.7] x86/hvm: Correct emulation of invlpg instruction

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.04.16 at 12:16, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 22/04/16 10:57, Jan Beulich wrote:
>>>>> On 22.04.16 at 11:48, <Paul.Durrant@xxxxxxxxxx> wrote:
>>>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>>>> Sent: 22 April 2016 10:31
>>>>>>> On 22.04.16 at 10:59, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>>> --- a/xen/arch/x86/hvm/emulate.c
>>>>> +++ b/xen/arch/x86/hvm/emulate.c
>>>>> @@ -1598,8 +1598,27 @@ static int hvmemul_invlpg(
>>>>>      rc = hvmemul_virtual_to_linear(
>>>>>          seg, offset, 1, &reps, hvm_access_none, hvmemul_ctxt, &addr);
>>>>>
>>>>> -    if ( rc == X86EMUL_OKAY )
>>>>> +    switch ( rc )
>>>>> +    {
>>>>> +    case X86EMUL_OKAY:
>>>>>          hvm_funcs.invlpg_intercept(addr);
>>>>> +        break;
>>>>> +
>>>>> +    case X86EMUL_EXCEPTION:
>>>>> +        ASSERT(hvmemul_ctxt->trap.vector == TRAP_gp_fault);
>>>>> +        /*
>>>>> +         * `invlpg` and `invlpga` are specified to be NOPs when issued 
>>>>> on a
>>>>> +         * non-canonical address.  hvmemul_virtual_to_linear() latches a 
>>>>> #GP
>>>>> +         * which is the useful behaviour for most of its callers.
>>>> Here and in the description I'd prefer you to not exclusively refer
>>>> to non-canonical addresses - segment limit violations in 32-bit or
>>>> compatibility modes are affected as much.
>>> ...in which case squashing the #GP would be incorrect, right?
>> No, not according to the SDM.
> 
> I should check and only squash a #GP(0)
> 
> #GP(sel) or #SS(sel) should not be squashed.

Which also can't happen here (these only occur when selectors
get loaded via some the various mechanisms allowing that).

Jan


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