Re: [Xen-devel] SSE instruction emulation issues

[Fabio Fantoni <fabio.fantoni@xxxxxxx>]

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.
>
> > Thanks,
> > Zhi.
> >
> > -----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
> > > > > > 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.

Attachment: X-gdb.log
Description: Text document

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