Re: [PATCH 3/8] x86emul: support BMI1 insns

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 16/01/17 12:57, Jan Beulich wrote:
>>>> On 16.01.17 at 13:43, <JBeulich@suse.com> wrote:
>>>>> On 16.01.17 at 12:59, <andrew.cooper3@citrix.com> wrote:
>>> On 16/01/17 11:19, Jan Beulich wrote:
>>>>>>> On 13.01.17 at 18:40, <andrew.cooper3@citrix.com> wrote:
>>>>> On 13/01/17 15:31, Jan Beulich wrote:
>>>>>> @@ -5866,6 +5879,67 @@ x86_emulate(
>>>>>>          break;
>>>>>>  #endif
>>>>>>  
>>>>>> +    case X86EMUL_OPC_VEX(0x0f38, 0xf2):    /* andn r/m,r,r */
>>>>>> +    case X86EMUL_OPC_VEX(0x0f38, 0xf7):    /* bextr r,r/m,r */
>>>>>> +    {
>>>>>> +        uint8_t *buf = get_stub(stub);
>>>>>> +        typeof(vex) *pvex = container_of(buf + 1, typeof(vex), raw[0]);
>>>>>> +
>>>>>> +        host_and_vcpu_must_have(bmi1);
>>>>>> +        generate_exception_if(vex.l, EXC_UD);
>>>>> The manual also states #UD if VEX.W is set.
>>>> This is very clearly a doc error: For one, is doesn't _also_ state this,
>>>> but says nothing about VEX.L. And the instruction encodings list .W1
>>>> variants (as expected) to encode 64-bit operations.
>>> VEX.L != 0 is called out, but only in the text, not the exception list.
>>>
>>> The exact text is:
>>>
>>> "This instruction is not supported in real mode and virtual-8086 mode.
>>> The operand size is always 32 bits if not in 64-bit mode. In 64-bit mode
>>> operand size 64 requires VEX.W1. VEX.W1 is ignored in non-64-bit modes.
>>> An attempt to execute this instruction with VEX.L not equal to 0 will
>>> cause #UD."
>>>
>>> with:
>>>
>>> "#UD If VEX.W = 1"
>>>
>>> in the exception list.
>>>
>>> I am confused about the references to VEX.W1 in the text, because it
>>> doesn't match any described VEX fields.  At a guess, I'd say it should
>>> be referring to VEX.B which control operand size, while VEX.W is an
>>> opcode extention.
>> VEX.W1 means VEX.W set to 1 (VEX.W0 similarly means VEX.W set to
>> zero). And there's no VEX.B afaik.
> Oops, of course there is, just that it has nothing to do with operand
> size (it rather provide the top bit of the (base) register number.

Right.  What happens in reality is this:

--- Xen Test Framework ---
Environment: HVM 32bit (No paging)
Test VEX.W matching mode:
  andn cccca5a5, ff00ff00 = 00cc00a5
Test VEX.W opposite to mode:
  andn cccca5a5, ff00ff00 = 00cc00a5
Test result: SUCCESS

--- Xen Test Framework ---
Environment: HVM 64bit (Long mode 4 levels)
Test VEX.W matching mode:
  andn cccca5a5cccca5a5, ff00ff00ff00ff00 = 00cc00a500cc00a5
Test VEX.W opposite to mode:
  andn cccca5a5cccca5a5, ff00ff00ff00ff00 = 0000000000cc00a5
Test result: SUCCESS

So VEX.W is ignored in 32bit (i.e. doesn't raise #UD), and *does* cause
64bit mode to operate on 32bit operands, contrary to the manual.

~Andrew

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