Re: [Xen-devel] [PATCH for-4.5 2/2] x86/hvm: Improve "Emulation failed @" error messages

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.09.14 at 14:57, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 26/09/14 13:41, Tim Deegan wrote:
>> At 13:09 +0100 on 26 Sep (1411733364), Andrew Cooper wrote:
>>> As identified in the other thread, "16bit" is misleading as the
>>> instruction bytes are actually 32bit code in a 16bit segment.
>>>
>>> I am not sure what the best solution here is.  Perhaps we can trust
>>> anyone capable of interpreting this error to know that "16b" != "Real"
>>> or "v86" when it comes to decoding the instruction.
>> Hmm.  I can see that 16bit is a bit misleading if you don't
>> know/remember that vm86 and real mode would be reported as such.  OTOH
>> that is infomration that's needed for decoding -- the instruction will
>> have 16bit operands and addresses even though it uses 32bit registers
>> and protected segments.
>>
>> Maybe we should report it as '16bit protected' or similar?
> 
> How about following the convention at http://sandpile.org/x86/mode.htm ?
> 
> Currently, we can distinguish between RM16, VM16, (P/C)M{16,32} and
> PM64, which is good enough for decoding the bytes correctly.
> 
> Alternatively, we could extend {vmx,svm}_guest_x86_mode() to provide a
> rather more complete enum of processor modes and cover the other cases?

None of this is relevant for instruction decoding. Even the 16-bit
protected / real / vm86 mode distinction is relevant there, that's
only useful as additional context.

Jan


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