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

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



On 22/04/16 12:47, Jan Beulich wrote:
>>>> On 22.04.16 at 13:18, <andrew.cooper3@xxxxxxxxxx> wrote:
>> 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")
> I can't find any mention of error codes in this section at all. Not
> sure which version of it you're looking at, mine is 057US. And
> even if it said so, I'd be 99.999% certain this is in error, as all
> instruction pages always say #GP(0) and #SS(0) for limit
> violations.

Hmm - Section 6.15 is rather more clear, and does state  #GP(0) and
#SS(0) for limit violations.

In which case I am going to have to untangle hvmemul_virtual_to_linear()
and hvm_virtual_to_linear_addr() to distinguish the two cases, and also
to raise #SS for %ss limit violations.

~Andrew

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

 


Rackspace

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