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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 22/04/16 11:30, Jan Beulich wrote:
>>>> 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).

#GP(sel) or #SS(sel) also occur for a memory access which causes a
segment limit violation.  (SDM Vol 3, 5.3 "Limit Checking")

It is not clear whether invlpg falls into this category; it does take a
memory operand, but doesn't use it in the usual manor.

~Andrew

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