>>> On 12.01.17 at 18:29, <andrew.coop...@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(
>> - 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).
Xen-devel mailing list