Re: [Xen-devel] [PATCH 2/4] x86emul: drop RIP-relative special case for TEST

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 15/08/16 16:08, Jan Beulich wrote:
>>>> On 15.08.16 at 16:25, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 15/08/16 09:34, Jan Beulich wrote:
>>> @@ -1851,11 +1911,6 @@ x86_emulate(
>>>                          ((op_bytes == 8) ? 4 : op_bytes);
>>>                  else if ( (d & SrcMask) == SrcImmByte )
>>>                      ea.mem.off += 1;
>>> -                else if ( !ext && ((b & 0xfe) == 0xf6) &&
>>> -                          ((modrm_reg & 7) <= 1) )
>> Do we actually handle these cases correctly?  0xf6 /0 (imm8) and 0xf7 /0
>> (imm) look to work as expected
> I think we do; what makes you think we might not?
>
>> However, 0xf6 /1, 0xf7 /1 are harder to pin down.  We have an
>> implementation of it, but the only other reference I can find to them
>> are in the AMD grp3 opcode map, where they appear equal to their /0
>> variants.  The /1 variants do not appear in the AMD description of the
>> TEST instruction, and do not appear anywhere in the Intel manuals.
>>
>> Suravee: Can you confirm whether the /1 variants are expected to be
>> implemented and copies of the /0 variants?
> I've check on Intel systems that they are aliases (Intel doesn't
> document them), and AMD halfway documenting them as aliases
> makes me assume they indeed are. Other than opcode 82 they're
> also aliases regardless of whether in 64-bit mode (on Intel again,
> that is, I can't get to my AMD boxes right now).

How helpful.  It would be lovely if the documentation matched reality.

Anyway, the change isn't really related to this question, so
Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

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