[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86emul: support {RD,WR}{F,G}SBASE
>>> On 14.12.16 at 14:28, <andrew.cooper3@xxxxxxxxxx> wrote: > On 14/12/16 13:18, Jan Beulich wrote: >>>>> On 14.12.16 at 13:36, <andrew.cooper3@xxxxxxxxxx> wrote: >>> On 14/12/16 09:37, Jan Beulich wrote: >>>> @@ -5205,6 +5206,44 @@ x86_emulate( >>>> } >>>> break; >>>> >>>> + case X86EMUL_OPC_F3(0x0f, 0xae): /* Grp15 */ >>>> + { >>>> + unsigned long cr4; >>>> + >>>> + fail_if(modrm_mod != 3); >>> This should surely be an explicit #UD? The only issue is that we don't >>> yet implement Grp15/F3 instructions with memory operands (as there are >>> none yet defined)? >> If there weren't any, I probably would have used #UD here. But >> there are - ptwrite is even in the normal SDM already (but it looks >> to be missing from the opcode map). > > I find that the opcode maps are consistently out of date. > > However, I don't understand why you have chosen to avoid the #UD. #UD > is the appropriate action for an opcode which isn't implemented. I don't think we should raise #UD knowingly for the wrong reason. Hence my plan was to go through all fail_if()-s once we are at a point where we consider the emulator complete enough, but keep using fail_if() vs #UD to distinguish cases where we know of gaps vs an encoding being undefined in up-to-date docs. While I guess we don't always match this model at present, that was at least what I have been trying to follow in all my recent work. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |