From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH for-4.5 2/2] x86/hvm: Improve "Emulation
 failed @" error messages
Date: Fri, 26 Sep 2014 13:53:37 +0100
Message-ID: <542561D1.2080201@citrix.com>
References: <1411726207-2689-1-git-send-email-andrew.cooper3@citrix.com>
	<1411726207-2689-3-git-send-email-andrew.cooper3@citrix.com>
	<54256C9C0200007800039985@mail.emea.novell.com>
	<54255646.6030402@citrix.com>
	<542579F40200007800039A62@mail.emea.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <542579F40200007800039A62@mail.emea.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: Kevin Tian <kevin.tian@intel.com>, Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>, Eddie Dong <eddie.dong@intel.com>, Xen-devel <xen-devel@lists.xen.org>, Jun Nakajima <jun.nakajima@intel.com>
List-Id: xen-devel@lists.xenproject.org

On 26/09/14 13:36, Jan Beulich wrote:
>>>> On 26.09.14 at 14:04, <andrew.cooper3@citrix.com> wrote:
>> On 26/09/14 12:39, Jan Beulich wrote:
>>>>>> On 26.09.14 at 12:10, <andrew.cooper3@citrix.com> wrote:
>>>> @@ -1449,6 +1441,37 @@ struct segment_register *hvmemul_get_seg_reg(
>>>>      return &hvmemul_ctxt->seg_reg[seg];
>>>>  }
>>>>  
>>>> +static const char *guest_x86_mode_to_str(int mode)
>>>> +{
>>>> +    switch ( mode )
>>>> +    {
>>>> +    case 0:
>>>> +        return "Real";
>>>> +    case 1:
>>>> +        return "v8086";
>>>> +    case 2:
>>> return "16bit";
>> case 2 is 32bit mode code in a 16bit segment.  Therefore, 32bit is still
>> the correct text when aiding decode of the instruction.
> It's specifically not: Operand and address size (and respective
> prefixes) have different meaning. You really don't care about
> the mode the CPU as a whole is in, but the kind of instructions
> it executes.
>
>> What I want to avoid is the confusing statement of "16bit mode" which is
>> easily confused as "Real mode" and a set of bytes which should be
>> decoded as 32bit instructions.
> But instructions in a 16-bit segment should be decoded as 16-bit
> instructions, not 32-bit ones. Yes, OS/2 and 16-bit Windows are
> long gone, but this hasn't changed.

I am indeed getting confused.

>
>>>> +    printk("%s emulation failed: %pv %s mode, %u bytes @ %04x:%lx: %*ph\n",
>>>> +           prefix, curr, mode_str, hvmemul_ctxt->insn_buf_bytes,
>>> Do you really need to print the byte count as a number when the
>>> new formatting will suitably limit output anyway?
>> I considered that, but thought that "@ xxxx:xxxx:\n" might be a little
>> obscure.  On the other hand, it might be ok.  I am happy dropping the
>> "%u bytes" if that is considered ok.
> Just make it "%04x:%08lx -> %*ph"? (Intentionally not using %lx
> as you did - I'd really dislike seeing addresses like 0000:12, while I'd
> be much less concerned for digit counts between 8 and 16 to vary.)

Looks better - I shall go with that.

~Andrew