[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 6/6] x86emul: support MOVDIR{I,64B} insns
On 01/07/2019 12:58, Jan Beulich wrote: > Note that the ISA extensions document revision 035 doesn't specify > exception behavior for ModRM.mod != 0b11; assuming #UD here. This has moved into the main SDM now. These instructions don't make sense with reg/reg encodings, so I expect that encoding space will be reused as a new group at some point in the future. > > Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> > > --- a/xen/arch/x86/x86_emulate/x86_emulate.c > +++ b/xen/arch/x86/x86_emulate/x86_emulate.c > @@ -548,6 +548,8 @@ static const struct ext0f38_table { > [0xf1] = { .to_mem = 1, .two_op = 1 }, > [0xf2 ... 0xf3] = {}, > [0xf5 ... 0xf7] = {}, > + [0xf8] = { .simd_size = simd_other }, > + [0xf9] = { .to_mem = 1 }, > }; > > /* Shift values between src and dst sizes of pmov{s,z}x{b,w,d}{w,d,q}. */ > @@ -1902,6 +1904,8 @@ in_protmode( > #define vcpu_has_avx512_bitalg() (ctxt->cpuid->feat.avx512_bitalg) > #define vcpu_has_avx512_vpopcntdq() (ctxt->cpuid->feat.avx512_vpopcntdq) > #define vcpu_has_rdpid() (ctxt->cpuid->feat.rdpid) > +#define vcpu_has_movdiri() (ctxt->cpuid->feat.movdiri) > +#define vcpu_has_movdir64b() (ctxt->cpuid->feat.movdir64b) > #define vcpu_has_avx512_4vnniw() (ctxt->cpuid->feat.avx512_4vnniw) > #define vcpu_has_avx512_4fmaps() (ctxt->cpuid->feat.avx512_4fmaps) > > @@ -2693,10 +2697,12 @@ x86_decode_0f38( > { > case 0x00 ... 0xef: > case 0xf2 ... 0xf5: > - case 0xf7 ... 0xff: > + case 0xf7 ... 0xf8: > + case 0xfa ... 0xff: > op_bytes = 0; > /* fall through */ > case 0xf6: /* adcx / adox */ > + case 0xf9: /* movdiri */ > ctxt->opcode |= MASK_INSR(vex.pfx, X86EMUL_OPC_PFX_MASK); > break; > > @@ -9896,6 +9902,32 @@ x86_emulate( > : "0" ((uint32_t)src.val), "rm" (_regs.edx) ); > break; > > + case X86EMUL_OPC_66(0x0f38, 0xf8): /* movdir64b r,m512 */ > + vcpu_must_have(movdir64b); > + generate_exception_if(ea.type != OP_MEM, EXC_UD); > + src.val = truncate_ea(*dst.reg); > + generate_exception_if(!is_aligned(x86_seg_es, src.val, 64, ctxt, > ops), > + EXC_GP, 0); > + /* Ignore the non-temporal behavior for now. */ > + fail_if(!ops->write); > + BUILD_BUG_ON(sizeof(*mmvalp) < 64); > + if ( (rc = ops->read(ea.mem.seg, ea.mem.off, mmvalp, 64, > + ctxt)) != X86EMUL_OKAY || > + (rc = ops->write(x86_seg_es, src.val, mmvalp, 64, > + ctxt)) != X86EMUL_OKAY ) > + goto done; > + state->simd_size = simd_none; > + sfence = true; > + break; > + > + case X86EMUL_OPC(0x0f38, 0xf9): /* movdiri mem,r */ > + vcpu_must_have(movdiri); > + generate_exception_if(dst.type != OP_MEM, EXC_UD); > + /* Ignore the non-temporal behavior for now. */ > + dst.val = src.val; > + sfence = true; > + break; I'm not certain this gives the required atomicity. AFAICT, it degrades into ops->write(), which can end up with bytewise writes. I think we need to map the destination and issue an explicit mov instruction. > --- a/tools/tests/x86_emulator/x86-emulate.c > +++ b/tools/tests/x86_emulator/x86-emulate.c > @@ -76,6 +76,8 @@ bool emul_test_init(void) > cp.feat.adx = true; > cp.feat.avx512pf = cp.feat.avx512f; > cp.feat.rdpid = true; > + cp.feat.movdiri = true; > + cp.feat.movdir64b = true; > cp.extd.clzero = true; > > if ( cpu_has_xsave ) > @@ -137,15 +139,15 @@ int emul_test_cpuid( > res->c |= 1U << 22; > > /* > - * The emulator doesn't itself use ADCX/ADOX/RDPID nor the S/G prefetch > - * insns, so we can always run the respective tests. > + * The emulator doesn't itself use ADCX/ADOX/RDPID/MOVDIR* nor the S/G > + * prefetch insns, so we can always run the respective tests. > */ > if ( leaf == 7 && subleaf == 0 ) > { > res->b |= (1U << 10) | (1U << 19); > if ( res->b & (1U << 16) ) > res->b |= 1U << 26; > - res->c |= 1U << 22; > + res->c |= (1U << 22) | (1U << 27) | (1U << 28); I've just noticed, but we shouldn't be having both the named variables and these unnamed ones. Is their presence a rebasing issue around patches into the test suite? ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |