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 15:16, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 26/09/14 14:06, Jan Beulich wrote:
>>>>> 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.
> 
> I presume you mean "is irrelevant there" ?

Oops, yes, of course.

Jan


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