* [PATCH] x86emul: VEX.B is ignored in compatibility mode
@ 2017-01-12 16:37 Jan Beulich
2017-01-12 17:29 ` Andrew Cooper
0 siblings, 1 reply; 4+ messages in thread
From: Jan Beulich @ 2017-01-12 16:37 UTC (permalink / raw)
To: xen-devel; +Cc: Andrew Cooper
[-- Attachment #1: Type: text/plain, Size: 1586 bytes --]
While VEX.R and VEX.X are guaranteed to be 1 in compatibility mode,
VEX.B can be encoded as zero, but would be ignored by the processor.
Since we emulate instructions in 64-bit mode, we need to force the
bit to 1 in order to not act on the wrong {X,Y,Z}MM register.
We must not, however, fiddle with the high bit of VEX.VVVV in the
decode phase, as that would undermine the checking of instructions
requiring the field to be all ones independent of mode. This is
being enforced in copy_REX_VEX() instead.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -331,7 +331,11 @@ union vex {
#define copy_REX_VEX(ptr, rex, vex) do { \
if ( (vex).opcx != vex_none ) \
+ { \
+ if ( !mode_64bit() ) \
+ vex.reg |= 8; \
ptr[0] = 0xc4, ptr[1] = (vex).raw[0], ptr[2] = (vex).raw[1]; \
+ } \
else if ( mode_64bit() ) \
ptr[1] = rex | REX_PREFIX; \
} while (0)
@@ -2217,6 +2221,8 @@ x86_decode(
op_bytes = 8;
}
}
+ else
+ vex.b = 1;
switch ( b )
{
case 0x62:
@@ -2235,7 +2241,7 @@ x86_decode(
break;
}
}
- if ( mode_64bit() && !vex.r )
+ if ( !vex.r )
rex_prefix |= REX_R;
ext = vex.opcx;
[-- Attachment #2: x86emul-32bit-VEX-B.patch --]
[-- Type: text/plain, Size: 1631 bytes --]
x86emul: VEX.B is ignored in compatibility mode
While VEX.R and VEX.X are guaranteed to be 1 in compatibility mode,
VEX.B can be encoded as zero, but would be ignored by the processor.
Since we emulate instructions in 64-bit mode, we need to force the
bit to 1 in order to not act on the wrong {X,Y,Z}MM register.
We must not, however, fiddle with the high bit of VEX.VVVV in the
decode phase, as that would undermine the checking of instructions
requiring the field to be all ones independent of mode. This is
being enforced in copy_REX_VEX() instead.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -331,7 +331,11 @@ union vex {
#define copy_REX_VEX(ptr, rex, vex) do { \
if ( (vex).opcx != vex_none ) \
+ { \
+ if ( !mode_64bit() ) \
+ vex.reg |= 8; \
ptr[0] = 0xc4, ptr[1] = (vex).raw[0], ptr[2] = (vex).raw[1]; \
+ } \
else if ( mode_64bit() ) \
ptr[1] = rex | REX_PREFIX; \
} while (0)
@@ -2217,6 +2221,8 @@ x86_decode(
op_bytes = 8;
}
}
+ else
+ vex.b = 1;
switch ( b )
{
case 0x62:
@@ -2235,7 +2241,7 @@ x86_decode(
break;
}
}
- if ( mode_64bit() && !vex.r )
+ if ( !vex.r )
rex_prefix |= REX_R;
ext = vex.opcx;
[-- Attachment #3: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] x86emul: VEX.B is ignored in compatibility mode
2017-01-12 16:37 [PATCH] x86emul: VEX.B is ignored in compatibility mode Jan Beulich
@ 2017-01-12 17:29 ` Andrew Cooper
2017-01-13 13:20 ` Jan Beulich
0 siblings, 1 reply; 4+ messages in thread
From: Andrew Cooper @ 2017-01-12 17:29 UTC (permalink / raw)
To: Jan Beulich, xen-devel
On 12/01/17 16:37, Jan Beulich wrote:
> While VEX.R and VEX.X are guaranteed to be 1 in compatibility mode,
> VEX.B can be encoded as zero, but would be ignored by the processor.
Really? That is unfortunate.
It would have been far more helpful for this to raise #UD, like the
other prohibited VEX encodings.
> @@ -2235,7 +2241,7 @@ x86_decode(
> break;
> }
> }
> - if ( mode_64bit() && !vex.r )
> + if ( !vex.r )
> rex_prefix |= REX_R;
>
> ext = vex.opcx;
>
What is the purpose of this change? I doesn't appear to be related to
the rest of the patch.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] x86emul: VEX.B is ignored in compatibility mode
2017-01-12 17:29 ` Andrew Cooper
@ 2017-01-13 13:20 ` Jan Beulich
2017-01-16 17:23 ` Andrew Cooper
0 siblings, 1 reply; 4+ messages in thread
From: Jan Beulich @ 2017-01-13 13:20 UTC (permalink / raw)
To: Andrew Cooper; +Cc: xen-devel
>>> On 12.01.17 at 18:29, <andrew.cooper3@citrix.com> wrote:
> On 12/01/17 16:37, Jan Beulich wrote:
>> While VEX.R and VEX.X are guaranteed to be 1 in compatibility mode,
>> VEX.B can be encoded as zero, but would be ignored by the processor.
>
> Really? That is unfortunate.
>
> It would have been far more helpful for this to raise #UD, like the
> other prohibited VEX encodings.
It's spelled out that way in the doc, and to be sure I've just again
verified this to be the case in practice.
>> @@ -2235,7 +2241,7 @@ x86_decode(
>> break;
>> }
>> }
>> - if ( mode_64bit() && !vex.r )
>> + if ( !vex.r )
>> rex_prefix |= REX_R;
>>
>> ext = vex.opcx;
>>
>
> What is the purpose of this change? I doesn't appear to be related to
> the rest of the patch.
It is related - see the first half of the first sentence of the description
(still visible above).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] x86emul: VEX.B is ignored in compatibility mode
2017-01-13 13:20 ` Jan Beulich
@ 2017-01-16 17:23 ` Andrew Cooper
0 siblings, 0 replies; 4+ messages in thread
From: Andrew Cooper @ 2017-01-16 17:23 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel
On 13/01/17 13:20, Jan Beulich wrote:
>
>>> @@ -2235,7 +2241,7 @@ x86_decode(
>>> break;
>>> }
>>> }
>>> - if ( mode_64bit() && !vex.r )
>>> + if ( !vex.r )
>>> rex_prefix |= REX_R;
>>>
>>> ext = vex.opcx;
>>>
>> What is the purpose of this change? I doesn't appear to be related to
>> the rest of the patch.
> It is related - see the first half of the first sentence of the description
> (still visible above).
Ah ok, in which case it is simply an optimisation rather than a
functional change.
With that at least mentioned in the commit message, Reviewed-by: Andrew
Cooper <andrew.cooper3@citrix.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-01-16 17:23 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-01-12 16:37 [PATCH] x86emul: VEX.B is ignored in compatibility mode Jan Beulich
2017-01-12 17:29 ` Andrew Cooper
2017-01-13 13:20 ` Jan Beulich
2017-01-16 17:23 ` Andrew Cooper
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.