[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 5/8] x86emul: support TBM insns
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |