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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

> 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.

> 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.

~Andrew

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