>>> On 14.09.16 at 19:05, <andrew.coop...@citrix.com> wrote:
> On 08/09/16 14:12, Jan Beulich wrote:
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -336,6 +336,27 @@ union vex {
>> ptr[1] = rex | REX_PREFIX; \
>> } while (0)
>>
>> +union evex {
>> + uint8_t raw[3];
>> + struct {
>> + uint8_t opcx:2;
>> + uint8_t :2;
>
> Is this legal syntax? I am guessing it compiles for you, so is it
> perhaps a GCCism?
Unnamed bitfields are standard C afaik.
>> @@ -1852,6 +1876,14 @@ x86_decode(
>> op_bytes = 8;
>> }
>> }
>> + if ( b == 0x62 )
>> + {
>> + evex.raw[0] = vex.raw[0];
>> + evex.raw[1] = vex.raw[1];
>> + evex.raw[2] = insn_fetch_type(uint8_t);
>> +
>> + vex.opcx = evex.opcx;
>
> What is the meaning of opcx? The manuals list these as the mm fields.
Well, we're already using opcx instead of mmmmm for VEX, so it seems
natural to also do so for EVEX. I'm in particular of the opinion that field
names like mmmmm or vvvv are rather meaningless.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
