| Message ID | 596347B7020000780016A1AC@prv-mh.provo.novell.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
>>> On 10.07.17 at 09:24, <JBeulich@suse.com> wrote: > Going though the XED commits from the last couple of months made me > notice that VPINSRD, other than VPEXTRD, does not clear VEX.W for non- > 64-bit modes, leading to an insertion of stray 32-bits of zero in case > the original instruction had the bit set. > > Also remove a pointless fall-through in VPEXTRW handling, bringing > things in line with VPINSRW. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> Together with this one also x86emul: correct VEX.L handling for VCVT{,T}S{S,D}2SI x86emul: correct EVEX register extension bit handling for non-64-bit modes (not to speak of the AVX etc series sent even longer ago) Jan > --- > Correcting this made me further notice that the SDM states that > VPEXTR{B,W} and VPINSR{B,W} require VEX.W to be clear in other than > their EVEX encodings (which we don't support so far). XED and reality > disagree, so things are being left unchanged there. > > --- a/xen/arch/x86/x86_emulate/x86_emulate.c > +++ b/xen/arch/x86/x86_emulate/x86_emulate.c > @@ -6730,10 +6730,9 @@ x86_emulate( > ea.type = OP_MEM; > goto simd_0f_int_imm8; > > + CASE_SIMD_PACKED_INT(0x0f, 0xc5): /* pextrw $imm8,{,x}mm,reg */ > case X86EMUL_OPC_VEX_66(0x0f, 0xc5): /* vpextrw $imm8,xmm,reg */ > generate_exception_if(vex.l, EXC_UD); > - /* fall through */ > - CASE_SIMD_PACKED_INT(0x0f, 0xc5): /* pextrw $imm8,{,x}mm,reg */ > opc = init_prefixes(stub); > opc[0] = b; > /* Convert GPR destination to %rAX. */ > @@ -7512,6 +7511,8 @@ x86_emulate( > case X86EMUL_OPC_VEX_66(0x0f3a, 0x20): /* vpinsrb $imm8,r32/m8,xmm,xmm > */ > case X86EMUL_OPC_VEX_66(0x0f3a, 0x22): /* vpinsr{d,q} $imm8,r/m,xmm,xmm > */ > generate_exception_if(vex.l, EXC_UD); > + if ( !mode_64bit() ) > + vex.w = 0; > memcpy(mmvalp, &src.val, op_bytes); > ea.type = OP_MEM; > op_bytes = src.bytes; > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel
On 10/07/17 08:24, Jan Beulich wrote: > Going though the XED commits from the last couple of months made me > notice that VPINSRD, other than VPEXTRD, does not clear VEX.W for non- > 64-bit modes, leading to an insertion of stray 32-bits of zero in case > the original instruction had the bit set. > > Also remove a pointless fall-through in VPEXTRW handling, bringing > things in line with VPINSRW. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
--- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -6730,10 +6730,9 @@ x86_emulate( ea.type = OP_MEM; goto simd_0f_int_imm8; + CASE_SIMD_PACKED_INT(0x0f, 0xc5): /* pextrw $imm8,{,x}mm,reg */ case X86EMUL_OPC_VEX_66(0x0f, 0xc5): /* vpextrw $imm8,xmm,reg */ generate_exception_if(vex.l, EXC_UD); - /* fall through */ - CASE_SIMD_PACKED_INT(0x0f, 0xc5): /* pextrw $imm8,{,x}mm,reg */ opc = init_prefixes(stub); opc[0] = b; /* Convert GPR destination to %rAX. */ @@ -7512,6 +7511,8 @@ x86_emulate( case X86EMUL_OPC_VEX_66(0x0f3a, 0x20): /* vpinsrb $imm8,r32/m8,xmm,xmm */ case X86EMUL_OPC_VEX_66(0x0f3a, 0x22): /* vpinsr{d,q} $imm8,r/m,xmm,xmm */ generate_exception_if(vex.l, EXC_UD); + if ( !mode_64bit() ) + vex.w = 0; memcpy(mmvalp, &src.val, op_bytes); ea.type = OP_MEM; op_bytes = src.bytes;
Going though the XED commits from the last couple of months made me notice that VPINSRD, other than VPEXTRD, does not clear VEX.W for non- 64-bit modes, leading to an insertion of stray 32-bits of zero in case the original instruction had the bit set. Also remove a pointless fall-through in VPEXTRW handling, bringing things in line with VPINSRW. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- Correcting this made me further notice that the SDM states that VPEXTR{B,W} and VPINSR{B,W} require VEX.W to be clear in other than their EVEX encodings (which we don't support so far). XED and reality disagree, so things are being left unchanged there.