[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.