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

[Tim Deegan <tim@xxxxxxx>]

At 13:09 +0100 on 26 Sep (1411733364), Andrew Cooper wrote:
> On 26/09/14 13:05, Tim Deegan wrote:
> > At 11:10 +0100 on 26 Sep (1411726207), Andrew Cooper wrote:
> >> +static const char *guest_x86_mode_to_str(int mode)
> >> +{
> >> +    switch ( mode )
> >> +    {
> >> +    case 0:
> >> +        return "Real";
> >> +    case 1:
> >> +        return "v8086";
> >> +    case 2:
> > return "16bit"?  
> >
> > Otherwise, Reviewed-by: Tim Deegan <tim@xxxxxxx>
> >
> > While you're respinning, could you also shorten all of these strings
> > (e.g. to real/vm86/16b/32b/64b), and trim the rest of the line,
> > something like:
> >
> > (d1) MMIO emulation failed: d1v0 64b @ 0008:ffff82d080102fea: 48 63 8d 40 
> > ff ff ff
> >
> > You can keep the reviewed-by regardless of whatever cosmetic changes.
> >
> > Cheers,
> >
> > Tim.
> 
> 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?

Tim.

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