Re: [Xen-devel] [PATCH 5/8] x86emul: support TBM insns

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.01.17 at 15:52, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 16/01/17 11:36, Jan Beulich wrote:
>>>>> On 13.01.17 at 19:48, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 13/01/17 15:32, Jan Beulich wrote:
>>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>>> @@ -1355,6 +1355,7 @@ static bool vcpu_has(
>>>>  #define vcpu_has_cr8_legacy()  vcpu_has(0x80000001, ECX,  4, ctxt, ops)
>>>>  #define vcpu_has_lzcnt()       vcpu_has(0x80000001, ECX,  5, ctxt, ops)
>>>>  #define vcpu_has_misalignsse() vcpu_has(0x80000001, ECX,  7, ctxt, ops)
>>>> +#define vcpu_has_tbm()         vcpu_has(0x80000001, ECX, 21, ctxt, ops)
>>>>  #define vcpu_has_bmi1()        vcpu_has(         7, EBX,  3, ctxt, ops)
>>>>  #define vcpu_has_hle()         vcpu_has(         7, EBX,  4, ctxt, ops)
>>>>  #define vcpu_has_bmi2()        vcpu_has(         7, EBX,  8, ctxt, ops)
>>>> @@ -6014,6 +6015,85 @@ x86_emulate(
>>>>              asm ( "rorl %b1,%k0" : "=g" (dst.val) : "c" (imm1), "0" 
>>>> (src.val) );
>>>>          break;
>>>>  
>>>> +    case X86EMUL_OPC(0x8f09, 0x01): /* XOP Grp1 */
>>> Surely this calls for the introduction of X86EMUL_OPC_XOP_* to match
>>> their VEX/EVEX counterparts?
>> Do really you think
>>
>>     case X86EMUL_OPC_XOP(09, 0x01): /* XOP Grp1 */
>>
>> or
>>
>>     case X86EMUL_OPC_XOP09(0x01): /* XOP Grp1 */
>>
>> are any better?
> 
> Either would be better, as it avoids the 0x8f magic prefix.

Well, okay then.

>> Iirc you had asked this same question already
>> when the opcode canonicalization patch was under review. The
>> situation hasn't changed: The nothing/VEX/EVEX distinction is
>> needed because the same base opcode may have (slightly or
>> significantly) different meaning depending on which of the three
>> (or four, if we also considered MVEX) encodings are being used.
> 
> MVEX is the precursor to EVEX, and as far as I can tell, was only
> implemented on the Knights-Corner co-processor, now superseded by
> Knights-Landing processor which uses EVEX.
> 
> There are a number of other reasons why Xen doesn't currently boot on
> Knights-Corner (whereas its functions fine on Kights-Landing), so unless
> someone has a specific usecase in mind and is willing to spend the
> effort, I don't think it is worth our effort at the moment.

I fully agree.

>> There's no such duplicate meaning for XOP encodings.
> 
> How have you come to this conclusion?  The XOP map spaces are separate
> to the main encodings, so the same primary opcode byte does have
> different meanings depending on whether it is XOP encoded or not.

That's not the duplicate meaning I was referring to. What I've tried
to point at is that e.g. ADDPS and VADDPS share their encoding, and
are distinguished only by non-VEX, VEX, or EVEX. There's nothing
equivalent for XOP.

Jan


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