From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH for-4.5 2/2] x86/hvm: Improve "Emulation failed @" error messages Date: Fri, 26 Sep 2014 14:16:51 +0100 Message-ID: <54256743.7050808@citrix.com> References: <1411726207-2689-1-git-send-email-andrew.cooper3@citrix.com> <1411726207-2689-3-git-send-email-andrew.cooper3@citrix.com> <20140926120545.GB35563@deinos.phlegethon.org> <54255774.20109@citrix.com> <20140926124156.GC35563@deinos.phlegethon.org> <542562A5.8050903@citrix.com> <542580E20200007800039AC0@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <542580E20200007800039AC0@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Kevin Tian , Keir Fraser , Tim Deegan , Eddie Dong , Xen-devel , Jun Nakajima List-Id: xen-devel@lists.xenproject.org On 26/09/14 14:06, Jan Beulich wrote: >>>> On 26.09.14 at 14:57, 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