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

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 26/09/14 14:06, Jan Beulich wrote:
>>>> On 26.09.14 at 14:57, <andrew.cooper3@citrix.com> 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" ?

The question is whether we want to provide more or less context.

For now, I will move to just 16/32/64bit as it is the simpler course of
action.  More context can easily be added in the future, as extending
???_guest_x86_mode() will be quite invasive and we are currently in a
code freeze.

~Andrew