Re: [Xen-devel] [PATCH v2 04/16] x86emul: complete decoding of two-byte instructions

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.09.16 at 19:22, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 28/09/16 09:08, Jan Beulich wrote:
>> @@ -1651,6 +1668,34 @@ x86_decode_onebyte(
>>  }
>>  
>>  static int
>> +x86_decode_twobyte(
>> +    struct x86_emulate_state *state,
>> +    struct x86_emulate_ctxt *ctxt,
>> +    const struct x86_emulate_ops *ops)
>> +{
>> +    int rc = X86EMUL_OKAY;
>> +
>> +    switch ( state->opcode )
>> +    {
>> +    case 0x78:
> 
> It occurs to me (after spending far too long attempting to locate these
> instructions in the manual), that we should consider where the cpuid
> checks should go.
> 
> This opcode is particularly awkward.  Without a prefix, it is Intel's
> VMREAD instruction, but with 66 or f2, it becomes part of AMD's SSE4A. 
> (I guess this answers why the VT-x instructions strictly may not be
> encoded with legacy prefixes.)
> 
> On real hardware, the cpuid check would logically be here, as it
> indicates an inability of the pipeline to understand an instruction. 
> OTOH, there is an argument to be made about sizing instructions which
> are understood, but shouldn't be successfully emulated.

True - if only there weren't these exceptions of certain opcodes
being known to #UD yet also decoding e.g. a ModRM byte before
they actually do.

Furthermore, the decoding would get more complicated: We'd have
to check both CPUID bits here, while having them in the execution
phase allows them to sit cleanly in different case statements. Plus if
we were to not fetch further bytes upon recognizing an insn that
is to #UD, putting the check here would even be too late (except
for the exceptions mentioned above): We'd have to put the check
before fetching the ModRM or immediate operand bytes.

Jan


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