>>> 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( >> 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