[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] SSE instruction emulation issues

Il 16/07/2015 16:54, Wang, Zhi A ha scritto:
Hi Fantoni:
If the emulation is successfully done without problem, maybe the instruction 
emulator in xen inject an incorrect fault into HVM, so that Xorg got killed. 
Can you also show the binary opcode with asm code? It looks only asm code in 
the gdb log.

Thanks for reply, I tried to add some gdprintk on probable fail about movaps, more exactly before these lines:
4005         fail_if(vex.pfx & VEX_PREFIX_SCALAR_MASK);
4037             fail_if((vex.opcx != vex_0f) ||
4050             generate_exception_if((b >= 0x28) &&
But xl dmesg showed nothing.

Gdb data more complete that this (full backtrace, registers, latest instructions and threads backtrace) I not found, see attachment.

This is the command used:
gdb -batch-silent -ex "run" -ex "set logging overwrite on" -ex "set logging file /root/X-gdb.log" -ex "set logging on" -ex "set pagination off" -ex "handle SIG33 pass nostop noprint" -ex "echo Full backtrace:\n" -ex "backtrace full" -ex "echo \n\nRegisters:\n" -ex "info registers" -ex "echo \n\nCurrent instructions:\n" -ex "x/16i \$pc" -ex "echo \n\nThreads backtrace:\n" -ex "thread apply all backtrace" -ex "set logging off" -ex "quit" --args "/usr/bin/X.bak" "$@"

Do you mean that I need something more complete to replace this about instructions? x/16i $pc

Another thing, on fedora 21 (where xorg crash is sid instead) where qemu is a 100% cpu (Xorg of domU) I saw that after long time arrive to view correct login page also with qxl, probably was about 20 minutes instead of 3-4 seconds max, pratically seems working (probably after latest one or more of many x86/hvm patches) but with performance 1/1000 or lesser that normal. Probably is something similar to windows some years ago where before an old Jan Beulich patch performance (based on screen output) was 1/10 or lesser.

Sorry if I had too low knowledge to find exact problem or at least all useful data :(

-----Original Message-----
From: Fabio Fantoni [mailto:fabio.fantoni@xxxxxxx]
Sent: Thursday, July 16, 2015 8:15 PM
To: Wang, Zhi A; Jan Beulich
Cc: Andrew Cooper; Paul Durrant; xen-devel
Subject: Re: SSE instruction emulation issues

Il 15/07/2015 16:35, Wang, Zhi A ha scritto:
You can put the MMIO emulation failed output message in the email like what I 
did, that will help to cook a patch for instruction emulator. Only gdb log is 
not enough as xen-developer has to know the exact opcode. I also found that not 
all forms of one SSE instruction was supported, for example an instruction may 
support move data from xmm register to mem, or move from xmm register to xmm 
registers, maybe only one form is supported in the instruction emulator.
Thanks for your reply, unfortunately don't give directly "MMIO emulation failed" but on 
"better" cases only software crash inside domUs, on other only qemu at 100% cpu and in 
domUs black screen ecc...
There are also many other cases of "strange" low performance probably related 
to MMIO operations.
I started to find it some years ago on hvm desktop domUs, derisory/hardly 
visible on older windows like xp or linux DE with fewer effects and lower 
screen resolution of client used and increasing using newer system, DE and 
bigger resolutions.
Using only thing like rdp inside domU's S.O. the problem is minimized, using 
client for connecting directly to domUs like spice is increased.
Seems increased also using rdp but using softwares that use "more graphic 
operations" (even if not 3D).
Trying similar thing on kvm instead using same qemu upstream version similar 
domU configuration ecc.. is better.
About more specific problem with qxl vga on xen was unable to works at all 
until 2 memory fixes in libxl/qemu did by anthony perard 3-4 years ago is I 
remember good, after on windows domUs was working but with very bad 
performance, after Jan beulich a fix about x86/hvm 2-3 years performances 
became decent and other x86/hvm changes in latest 1-2 years they made the 
performance closer to kvm for most of the vm windows.
About linux domUs qxl seems correctly working on suse as dom0 and domUs as 
reported by a suse developer but I not found the specific suse workaround, may 
be also other cases where is working out-of-box.
Xen is already better for many features and find/solves this problem probably 
make it very good also in all recent desktop necessity (except particular 3d 
acceleration that require phisical vga or similar).

About cases where I taken backtrace of domU's X crash I suppose I must find 
possible fails case without output in xl dmesg and add output to find what is 
the exact case, right?
I should add gdprintk(XENLOG_INFO,"...\n"); in any fail_if() and
generate_exception_if() that can be related to movaps for example based on 
backtrace, or is this wrong or stupid?

Thanks for any reply and sorry for my bad english.


-----Original Message-----
From: Fabio Fantoni [mailto:fabio.fantoni@xxxxxxx]
Sent: Wednesday, July 15, 2015 9:56 PM
To: Jan Beulich
Cc: Andrew Cooper; Paul Durrant; Wang, Zhi A; xen-devel
Subject: Re: SSE instruction emulation issues

Il 15/07/2015 13:35, Jan Beulich ha scritto:
On 15.07.15 at 13:13, <fabio.fantoni@xxxxxxx> wrote:
Il 10/07/2015 14:16, Jan Beulich ha scritto:
On 10.07.15 at 14:00, <andrew.cooper3@xxxxxxxxxx> 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
       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
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
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
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.


Thanks for your reply, as I wrote the other times I don't know a
better debug method about particular things like this (x86
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 
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.

Attachment: X-gdb.log
Description: Text document

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.