[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 06/17] x86emul: add EVEX decoding
>>> On 14.09.16 at 19:05, <andrew.cooper3@xxxxxxxxxx> 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@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |