Re: [Xen-devel] [PATCH] x86emul: VEX.B is ignored in compatibility mode

2017-01-16 Thread Andrew Cooper 
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 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86emul: VEX.B is ignored in compatibility mode

2017-01-13 Thread Jan Beulich 
>>> On 12.01.17 at 18:29,  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

Re: [Xen-devel] [PATCH] x86emul: VEX.B is ignored in compatibility mode

2017-01-12 Thread Andrew Cooper 
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