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

Re: [Xen-devel] [PATCH] x86emul: honor MXCSR.MM



On 14/10/16 07:20, Jan Beulich wrote:
>>>> On 13.10.16 at 15:26, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 13/10/16 13:57, Jan Beulich wrote:
>>> Commit 6dc9ac9f52 ("x86emul: check alignment of SSE and AVX memory
>>> operands") didn't consider a specific AMD mode: Mis-alignment #GP
>>> faults can be masked on some of their hardware.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> This highlights that the following CPUID dependency change is also required
>>
>> diff --git a/xen/tools/gen-cpuid.py b/xen/tools/gen-cpuid.py
>> index 33e68eb..e803654 100755
>> --- a/xen/tools/gen-cpuid.py
>> +++ b/xen/tools/gen-cpuid.py
>> @@ -185,8 +185,9 @@ def crunch_numbers(state):
>>          # the first place.
>>          APIC: [X2APIC],
>>  
>> -        # AMD built MMXExtentions and 3DNow as extentions to MMX.
>> -        MMX: [MMXEXT, _3DNOW],
>> +        # AMD built MMXExtentions, 3DNow and SSE Misalignment as
>> extensions to
>> +        # MMX.
>> +        MMX: [MMXEXT, _3DNOW, MISALIGNSSE],
>>  
>>          # The FXSAVE/FXRSTOR instructions were introduced into hardware
>> before
>>          # SSE, which is why they behave differently based on
>> %CR4.OSFXSAVE and
> Hmm, for one this is an orthogonal change, so doesn't belong in this
> patch. And then - why is this an extension to MMX (which doesn't
> have any alignment requirements anyway) rather than SSE?

Sorry - I have no idea why I suggested MMX.  It should have been SSE.

>
>>> @@ -4675,7 +4679,13 @@ x86_emulate(
>>>              ea.bytes = vex.pfx & VEX_PREFIX_DOUBLE_MASK ? 8 : 4;
>>>          if ( ea.type == OP_MEM )
>>>          {
>>> -            generate_exception_if((b >= 0x28) &&
>>> +            uint32_t mxcsr = 0;
>>> +
>>> +            if ( b < 0x28 )
>>> +                mxcsr = MXCSR_MM;
>>> +            else if ( vcpu_has_misalignsse() )
>>> +                asm ( "stmxcsr %0" : "=m" (mxcsr) );
>>> +            generate_exception_if(!(mxcsr & MXCSR_MM) &&
>>>                                    !is_aligned(ea.mem.seg, ea.mem.off, 
>>> ea.bytes,
>>>                                                ctxt, ops),
>>>                                    EXC_GP, 0);
>>> @@ -4955,7 +4965,13 @@ x86_emulate(
>>>          }
>>>          if ( ea.type == OP_MEM )
>>>          {
>>> -            generate_exception_if((vex.pfx == vex_66) &&
>>> +            uint32_t mxcsr = 0;
>>> +
>>> +            if ( vex.pfx != vex_66 )
>>> +                mxcsr = MXCSR_MM;
>>> +            else if ( vcpu_has_misalignsse() )
>>> +                asm ( "stmxcsr %0" : "=m" (mxcsr) );
>>> +            generate_exception_if(!(mxcsr & MXCSR_MM) &&
>>>                                    !is_aligned(ea.mem.seg, ea.mem.off, 
>>> ea.bytes,
>>>                                                ctxt, ops),
>>>                                    EXC_GP, 0);
>> According to the docs, we should also be possibly raising #AC here.
> Well, you've said the same in a different context not so long ago,
> and my answer is then also the same: As long as we don't do any
> #AC generation, I see no reason why we would want to create an
> exception here.

Ah yes.  I had managed to let that slip my mind.

Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

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

 


Rackspace

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