All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
To: Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Zhi Wang <zhi.a.wang@intel.com>
Subject: Re: SSE instruction emulation issues
Date: Wed, 15 Jul 2015 15:55:35 +0200	[thread overview]
Message-ID: <55A66657.3020306@m2r.biz> (raw)
In-Reply-To: <55A6618C02000078000914A6@mail.emea.novell.com>

Il 15/07/2015 13:35, Jan Beulich ha scritto:
>>>> On 15.07.15 at 13:13, <fabio.fantoni@m2r.biz> wrote:
>> Il 10/07/2015 14:16, Jan Beulich ha scritto:
>>>>>> On 10.07.15 at 14:00, <andrew.cooper3@citrix.com> wrote:
>>>> On 09/07/15 20:32, Zhi Wang wrote:
>>>>>       We found that MOVD instruction are used by some windows driver
>>>>> during developing XenGT, and also we found this one:
>>>>>
>>>>> (XEN) MMIO emulation failed: d7v1 64bit @ 0010:fffff8000294e273 -> 66
>>>>> 0f e7 00 48 83 c0 10 45 3
>>>>> b cb 73 f0 45 85 c9
>>>> Disassembly:
>>>>      0:    66 0f e7 00              movntdq %xmm0,(%rax)
>>>>      4:    48 83 c0 10              add    $0x10,%rax
>>>>      8:    45 3b cb                 cmp    %r11d,%r9d
>>>>      b:    73 f0                    jae    0xfffffffffffffffd
>>>>      d:    45 85 c9                 test   %r9d,%r9d
>>>>
>>>> The x86 instruction emulator does appear to have a decode for this
>>>> instruction.  This failure suggests that the implementation is buggy.
>>>>
>>>> To start with diagnosing, add a test case to
>>>> tools/tests/x86_emulator/test_x86_emulator.c
>>> Considering that we already test MOVDQU, the emulation of which
>>> shares code with MOVNTDQ (which only differs in aspects not of
>>> interest to the emulator) I'm not sure this will turn up anything
>>> interesting. Perhaps an even easier step would be to simply run
>>> the emulator test on the machine where the issue is seen? We're
>>> playing some prefix byte tricks there... Otoh failure to execute
>>> the constructed instruction would bring down the hypervisor.
>> I also have a problem with mmio as I already reported many times but I
> And to be honest, I don't see the value in re-stating this every once
> in a while without providing any new information.
>
>> don't know if it is the same as the one reported by the intel developer
>> about xengt, I have it in linux hvm domUs with qxl.
> Looks different - their's was about MOVD (which we clearly don't
> support right now) while yours looks to be about MOVAPS.
>
>> Today with the latest xen update from git staging (with the addiction of
>> the xengt patch that add support of emulating SSE2 instruction MOVD) I
>> had a different domU's Xorg backtrace containing also a "error: Cannot
>> access memory at address":
> Sadly a gdb backtrace is nothing I can see use extract useful information
> from. Iirc Paul had already asked you to instrument the involved code
> paths (considering that the x86 insn emulator supports MOVAPS as used
> by the failing code) to figure out where in the whole involved stack the
> failure actually originates.
>
> Jan
>

Thanks for your reply, as I wrote the other times I don't know a better 
debug method about particular things like this (x86 instructions 
emulation) and I'm asking what I should do.
If you mean to look at the code involved, search the part about the 
problem, think how can go wrong or unexpected, add debug output if 
needed, try quick changes to it ecc... I can do it with simpler software 
and I did something similar with libxl but I don't know how to do the 
same for code like xen/arch/x86/x86_emulate/x86_emulate.c. I already 
took a look at it but I didn't find "MOVAPS" in comments like many others.
If the problem is located in something like libxl where there are 
instructions that I know or that are intuitive I can imagine what the 
software is supposed to do and I can do quick targeted tests or changes, 
but on thing like x86 emulation I can't (or at least not before knowing 
all instructions and essential data about it).
Is this what you mean and is that the only way to collect useful data or 
to solve the problem?
If so, I suppose that for any change in xen/arch/x86/x86_emulate and 
similar I can't simply make the change, do a make, make install and test 
it immediatly like libxl/xl but I have to rebuild full xen, install it 
and reboot dom0, is it right?
Can you post a link with a quick reference about x86 emulation and/or 
instruction sets like sse2 which can help me learn what to do or an 
extensive knowledge on the subject is required in this case?
What kind of logging instruction for debug can I use? Are they visible 
with xl dmesg or I must do something different and more specific in this 
case?

Thanks for any reply and sorry for my bad english.

  parent reply	other threads:[~2015-07-15 13:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-10 12:00 SSE instruction emulation issues Andrew Cooper
2015-07-10 12:16 ` Jan Beulich
     [not found]   ` <55A64066.5020406@m2r.biz>
     [not found]     ` <55A6618C02000078000914A6@mail.emea.novell.com>
2015-07-15 13:55       ` Fabio Fantoni [this message]
2015-07-15 14:13         ` Paul Durrant
2015-07-15 14:22           ` Andrew Cooper
2015-07-15 14:18         ` Razvan Cojocaru
2015-07-15 14:35         ` Wang, Zhi A
2015-07-16 12:14           ` Fabio Fantoni
2015-07-16 14:54             ` Wang, Zhi A
2015-07-16 15:38               ` Fabio Fantoni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55A66657.3020306@m2r.biz \
    --to=fabio.fantoni@m2r.biz \
    --cc=JBeulich@suse.com \
    --cc=Paul.Durrant@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=xen-devel@lists.xensource.com \
    --cc=zhi.a.wang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.