SSE instruction emulation issues

SSE instruction emulation issues

[Andrew Cooper]

(breaking this thread away from the hijacked emulation cleanup and fixes
thread)

On 09/07/15 20:32, Zhi Wang wrote:
> Hi Gurus:
>     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

Then, you will want to investigate the implementation in
xen/arch/x86/x86_emulate/x86_emulate.c around line 4245.

~Andrew

Re: SSE instruction emulation issues

[Jan Beulich]

>>> 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.

Jan

Re: SSE instruction emulation issues

[Fabio Fantoni]

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.

Re: SSE instruction emulation issues

[Paul Durrant]

> -----Original Message-----
> From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz]
> Sent: 15 July 2015 14:56
> To: Jan Beulich
> Cc: Andrew Cooper; Paul Durrant; Zhi Wang; 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@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.

Ok. I suggest you start with the handle_mmio() function in Xen (xen/arch/x86/hvm/io.c). This is where the code you're interested in is entered. Indeed the reason you see:

(XEN) MMIO emulation failed: d7v1 64bit @ 0010:fffff8000294e273 -> 66

is because handle_mmio() has called hvm_dump_emulation_state() because its call to hvm_emulate_one() has returned HVMEMUL_UNHANDLEABLE. The question is why?

What you need to do is pick strategic points in the code executed by hvm_emulate_one() and add suitable printk() calls to figure what is happening. Your printk() messages will appear on the xen console (and hence in xl dmesg) so they will be quite noticeable :-).

  Paul

> 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.

Re: SSE instruction emulation issues

[Razvan Cojocaru]

On 07/15/2015 04:55 PM, Fabio Fantoni wrote:
> 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.

MOVAPS emulation is at line 4001 in the x86_emulate.c from staging:

4001     case 0x28: /* {,v}movap{s,d} xmm/m128,xmm */
4002                /* vmovap{s,d} ymm/m256,ymm */

I found this by looking up MOVAPS, getting the opcode (from e.g. here:
http://x86.renejeschke.de/html/file_module_x86_id_180.html) and
searching for 0x28 in the file.

> 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?

You don't have to do a full rebuild (i.e. make dist), you can just build
the hypervisor (change the current directory to xen/ and just run make
&& make install there, then reboot).

> 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?

https://docs.oracle.com/cd/E18752_01/html/817-5477/epmpv.html
http://softpixel.com/~cwright/programming/simd/sse2.php


Hope this helps,
Razvan

Re: SSE instruction emulation issues

[Andrew Cooper]

On 15/07/15 15:13, Paul Durrant wrote:
>> -----Original Message-----
>> From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz]
>> Sent: 15 July 2015 14:56
>> To: Jan Beulich
>> Cc: Andrew Cooper; Paul Durrant; Zhi Wang; 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@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.
> Ok. I suggest you start with the handle_mmio() function in Xen (xen/arch/x86/hvm/io.c). This is where the code you're interested in is entered. Indeed the reason you see:
>
> (XEN) MMIO emulation failed: d7v1 64bit @ 0010:fffff8000294e273 -> 66
>
> is because handle_mmio() has called hvm_dump_emulation_state() because its call to hvm_emulate_one() has returned HVMEMUL_UNHANDLEABLE. The question is why?

For this, I can help somewhat.  66 is a prefix (specifically, operand
size override).  The lack of any further bytes printed by
hvm_dump_emulation_state() indicates that Xen failed to fetch them, when
obeying instruction fetch semantics while walking the pagetables.

As the instruction pointer is not on a page boundary, the most likely
reason for this in a plain VM is that some other vcpu has modifying the
paging structure under the feet of the emulator.

First of all, start debugging with a single vcpu domain.  Then you want
to find the conditions under which ops->insn_fetch() fails in
insn_fetch_bytes() in x86_emulate.c

~Andrew

Re: SSE instruction emulation issues

[Wang, Zhi A]

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

-----Original Message-----
From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz] 
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@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.

Re: SSE instruction emulation issues

[Fabio Fantoni]

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@m2r.biz]
> 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@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.

Re: SSE instruction emulation issues

[Wang, Zhi A]

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.

-----Original Message-----
From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz] 
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@m2r.biz]
> 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@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.

Re: SSE instruction emulation issues

[Fabio Fantoni]

[-- Attachment #1: Type: text/plain, Size: 9652 bytes --]

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@m2r.biz]
> 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@m2r.biz]
>> 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@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.


[-- Attachment #2: X-gdb.log --]
[-- Type: text/plain, Size: 16408 bytes --]

Full backtrace:
#0  sse2_blt (src_bits=<optimized out>, dst_bits=<optimized out>, src_stride=<optimized out>, dst_stride=<optimized out>, src_bpp=<optimized out>, src_x=<optimized out>, src_y=0, dest_x=0, dest_y=0, width=1024, height=<optimized out>, dst_bpp=<optimized out>, imp=<optimized out>) at ../../pixman/pixman-sse2.c:4770
        w = 4160
        s = 0x7f39f0abefc0 <error: Cannot access memory at address 0x7f39f0abefc0>
        d = 0x7f39fe80a000 <error: Cannot access memory at address 0x7f39fe80a000>
        src_bytes = 0x7f39f0abe000 <error: Cannot access memory at address 0x7f39f0abe000>
        dst_bytes = <optimized out>
        byte_width = 4096
#1  0x00007f39fc399a39 in sse2_blt (height=768, width=1024, dest_y=0, dest_x=<optimized out>, src_y=<optimized out>, src_x=<optimized out>, dst_bpp=<optimized out>, src_bpp=<optimized out>, dst_stride=<optimized out>, src_stride=<optimized out>, dst_bits=<optimized out>, src_bits=<optimized out>, imp=<optimized out>) at ../../pixman/pixman-sse2.c:4822
No locals.
#2  sse2_composite_copy_area (imp=<optimized out>, info=<optimized out>) at ../../pixman/pixman-sse2.c:4815
        op = <optimized out>
        src_image = <optimized out>
        mask_image = <optimized out>
        dest_image = <optimized out>
        src_x = <optimized out>
        src_y = <optimized out>
        mask_x = <optimized out>
        mask_y = <optimized out>
        dest_x = <optimized out>
        dest_y = 0
        width = 1024
        height = 768
#3  0x00007f39fc311711 in pixman_image_composite32 (op=op@entry=PIXMAN_OP_SRC, src=<optimized out>, mask=mask@entry=0x0, dest=<optimized out>, src_x=src_x@entry=0, src_y=src_y@entry=0, mask_x=0, mask_y=0, dest_x=0, dest_y=0, width=1024, height=768) at ../../pixman/pixman.c:707
        src_format = <optimized out>
        mask_format = 0
        dest_format = PIXMAN_a8r8g8b8
        region = {extents = {x1 = 0, y1 = 0, x2 = 1024, y2 = 768}, data = 0x0}
        extents = {x1 = 0, y1 = 0, x2 = 1024, y2 = 768}
        imp = 0x7f39fdddb8a0
        func = 0x7f39fc3999d0 <sse2_composite_copy_area>
        info = {op = PIXMAN_OP_SRC, src_image = 0x7f39fe1910b0, mask_image = 0x0, dest_image = 0x7f39fe1911c0, src_x = 0, src_y = 0, mask_x = 0, mask_y = 0, dest_x = 0, dest_y = 0, width = 1024, height = 768, src_flags = 42420863, mask_flags = 8194, dest_flags = 34032255}
        pbox = 0x7ffdbbb1cca0
        n = 0
#4  0x00007f39fc3117e3 in pixman_image_composite (op=op@entry=PIXMAN_OP_SRC, src=<optimized out>, mask=mask@entry=0x0, dest=<optimized out>, src_x=src_x@entry=0, src_y=src_y@entry=0, mask_x=<optimized out>, mask_y=<optimized out>, dest_x=<optimized out>, dest_y=<optimized out>, width=<optimized out>, height=<optimized out>) at ../../pixman/pixman.c:730
No locals.
#5  0x00007f39f710bca8 in download_box_no_update (surface=0x7f39fe190ff0, surface=0x7f39fe190ff0, y2=<optimized out>, x2=<optimized out>, y1=0, x1=0) at ../../src/qxl_surface.c:133
No locals.
#6  qxl_download_box (surface=0x7f39fe190ff0, x1=0, y1=0, x2=<optimized out>, y2=<optimized out>) at ../../src/qxl_surface.c:150
No locals.
#7  0x00007f39f710bdaf in qxl_surface_prepare_access (surface=0x7f39fe190ff0, pixmap=0x7f39fe18d830, region=0x7ffdbbb1cdd0, access=<optimized out>) at ../../src/qxl_surface.c:183
        n_boxes = <optimized out>
        boxes = 0x7ffdbbb1cdd0
        pScreen = 0x7f39fde00a20
        pScrn = <optimized out>
        new = {extents = {x1 = 0, y1 = 0, x2 = 1024, y2 = 768}, data = 0x0}
#8  0x00007f39f7116d6d in uxa_prepare_access (pDrawable=0x7f39fe18d830, region=0x7ffdbbb1ce40, region@entry=0x0, access=access@entry=UXA_ACCESS_RO) at ../../../src/uxa/uxa.c:172
        pScreen = <optimized out>
        xoff = 0
        yoff = 0
        pPixmap = 0x7f39fe18d830
        box = {x1 = 0, y1 = 0, x2 = <optimized out>, y2 = <optimized out>}
        region_rec = {extents = {x1 = 0, y1 = 0, x2 = 1024, y2 = 768}, data = 0x0}
        result = 1
#9  0x00007f39f71170f0 in uxa_prepare_access_window (pWin=0x7f39fde5f530) at ../../../src/uxa/uxa.c:310
No locals.
#10 0x00007f39f7117187 in uxa_change_window_attributes (pWin=0x7f39fde5f530, mask=1) at ../../../src/uxa/uxa.c:343
        ret = <optimized out>
        need_access = 1
#11 0x00007f39fd3de6fd in compChangeWindowAttributes (pWin=0x7f39fde5f530, mask=1) at ../../composite/compinit.c:117
        pScreen = 0x7f39fde00a20
        ret = <optimized out>
#12 0x00007f39fd37fef4 in ChangeWindowAttributes (pWin=0x7f39fde5f530, vmask=<optimized out>, vlist=vlist@entry=0x7f39fe18f304, client=client@entry=0x7f39fe18cf90) at ../../dix/window.c:1460
        pVlist = 0x7f39fe18f308
        pPixmap = 0x7f39fe18d830
        pixID = <optimized out>
        pCursor = 0x0
        pOldCursor = <optimized out>
        cursorID = <optimized out>
        pChild = <optimized out>
        cmap = <optimized out>
        pCmap = 0x2040000000
        xE = {u = {u = {type = 144 '\220', detail = 207 '\317', sequenceNumber = 65048}, keyButtonPointer = {pad00 = 4263038864, time = 32569, root = 390, event = 0, child = 3148992480, rootX = 32765, rootY = 0, eventX = 26524, eventY = -715, state = 32569, sameScreen = 0 '\000', pad1 = 0 '\000'}, enterLeave = {pad00 = 4263038864, time = 32569, root = 390, event = 0, child = 3148992480, rootX = 32765, rootY = 0, eventX = 26524, eventY = -715, state = 32569, mode = 0 '\000', flags = 0 '\000'}, focus = {pad00 = 4263038864, window = 32569, mode = 134 '\206', pad1 = 1 '\001', pad2 = 0 '\000', pad3 = 0 '\000'}, expose = {pad00 = 4263038864, window = 32569, x = 390, y = 0, width = 0, height = 0, count = 53216, pad2 = 48049}, graphicsExposure = {pad00 = 4263038864, drawable = 32569, x = 390, y = 0, width = 0, height = 0, minorEvent = 53216, count = 48049, majorEvent = 253 '\375', pad1 = 127 '\177', pad2 = 0 '\000', pad3 = 0 '\000'}, noExposure = {pad00 = 4263038864, drawable = 32569, minorEvent = 390, majorEvent = 0 '\000', bpad = 0 '\000'}, visibility = {pad00 = 4263038864, window = 32569, state = 134 '\206', pad1 = 1 '\001', pad2 = 0 '\000', pad3 = 0 '\000'}, createNotify = {pad00 = 4263038864, parent = 32569, window = 390, x = 0, y = 0, width = 53216, height = 48049, borderWidth = 32765, override = 0 '\000', bpad = 0 '\000'}, destroyNotify = {pad00 = 4263038864, event = 32569, window = 390}, unmapNotify = {pad00 = 4263038864, event = 32569, window = 390, fromConfigure = 0 '\000', pad1 = 0 '\000', pad2 = 0 '\000', pad3 = 0 '\000'}, mapNotify = {pad00 = 4263038864, event = 32569, window = 390, override = 0 '\000', pad1 = 0 '\000', pad2 = 0 '\000', pad3 = 0 '\000'}, mapRequest = {pad00 = 4263038864, parent = 32569, window = 390}, reparent = {pad00 = 4263038864, event = 32569, window = 390, parent = 0, x = -12320, y = -17487, override = 253 '\375', pad1 = 127 '\177', pad2 = 0 '\000', pad3 = 0 '\000'}, configureNotify = {pad00 = 4263038864, event = 32569, window = 390, aboveSibling = 0, x = -12320, y = -17487, width = 32765, height = 0, borderWidth = 26524, override = 53 '5', bpad = 253 '\375'}, configureRequest = {pad00 = 4263038864, parent = 32569, window = 390, sibling = 0, x = -12320, y = -17487, width = 32765, height = 0, borderWidth = 26524, valueMask = 64821, pad1 = 32569}, gravity = {pad00 = 4263038864, event = 32569, window = 390, x = 0, y = 0, pad1 = 3148992480, pad2 = 32765, pad3 = 4248135580, pad4 = 32569}, resizeRequest = {pad00 = 4263038864, window = 32569, width = 390, height = 0}, circulate = {pad00 = 4263038864, event = 32569, window = 390, parent = 0, place = 224 '\340', pad1 = 207 '\317', pad2 = 177 '\261', pad3 = 187 '\273'}, property = {pad00 = 4263038864, window = 32569, atom = 390, time = 0, state = 224 '\340', pad1 = 207 '\317', pad2 = 48049}, selectionClear = {pad00 = 4263038864, time = 32569, window = 390, atom = 0}, selectionRequest = {pad00 = 4263038864, time = 32569, owner = 390, requestor = 0, selection = 3148992480, target = 32765, property = 4248135580}, selectionNotify = {pad00 = 4263038864, time = 32569, requestor = 390, selection = 0, target = 3148992480, property = 32765}, colormap = {pad00 = 4263038864, window = 32569, colormap = 390, new = 0 '\000', state = 0 '\000', pad1 = 0 '\000', pad2 = 0 '\000'}, mappingNotify = {pad00 = 4263038864, request = 57 '9', firstKeyCode = 127 '\177', count = 0 '\000', pad1 = 0 '\000'}, clientMessage = {pad00 = 4263038864, window = 32569, u = {l = {type = 390, longs0 = 0, longs1 = -1145974816, longs2 = 32765, longs3 = -46831716, longs4 = 32569}, s = {type = 390, shorts0 = 0, shorts1 = 0, shorts2 = -12320, shorts3 = -17487, shorts4 = 32765, shorts5 = 0, shorts6 = 26524, shorts7 = -715, shorts8 = 32569, shorts9 = 0}, b = {type = 390, bytes = "\000\000\000\000\340ϱ\273\375\177\000\000\234g5\375\071\177\000"}}}}}
        error = <optimized out>
        rc = <optimized out>
        pScreen = 0x7f39fde00a20
        index2 = 1
        tmask = <optimized out>
        vmaskCopy = <optimized out>
        val = <optimized out>
        checkOptional = 0
        borderRelative = 0
#13 0x00007f39fd34c2f6 in ProcChangeWindowAttributes (client=0x7f39fe18cf90) at ../../dix/dispatch.c:679
        pWin = 0x7f39fde5f530
        stuff = 0x7f39fe18f2f8
        len = 1
        rc = <optimized out>
        access_mode = <optimized out>
#14 0x00007f39fd352117 in Dispatch () at ../../dix/dispatch.c:432
        clientReady = 0x7f39fe1e8f70
        result = <optimized out>
        client = 0x7f39fe18cf90
        nready = 0
        icheck = 0x7f39fd748bf0 <checkForInput>
        start_tick = 45
#15 0x00007f39fd35629b in dix_main (argc=7, argv=0x7ffdbbb1d1c8, envp=<optimized out>) at ../../dix/main.c:298
        i = <optimized out>
        alwaysCheckForInput = {0, 1}
#16 0x00007f39fb21ab45 in __libc_start_main (main=0x7f39fd340660 <main>, argc=7, argv=0x7ffdbbb1d1c8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffdbbb1d1b8) at libc-start.c:287
        result = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, 413568259572484160, 139887037908581, 140727752446400, 0, 0, -412574937688979392, -302096973215053760}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x7f39fd4bdd90 <__libc_csu_init>, 0x7ffdbbb1d1c8}, data = {prev = 0x0, cleanup = 0x0, canceltype = -45359728}}}
        not_first_call = <optimized out>
#17 0x00007f39fd34068e in _start ()
No symbol table info available.


Registers:
rax            0x7f39fe4e9a80	139887056427648
rbx            0x7f39f0abe000	139886827659264
rcx            0x7f39f0abf000	139886827663360
rdx            0x1000	4096
rsi            0x7f39fe80a040	139887059705920
rdi            0x7f39f0abf000	139886827663360
rbp            0x1000	0x1000
rsp            0x7ffdbbb1cbc8	0x7ffdbbb1cbc8
r8             0x1000	4096
r9             0x7f39fe4e9a80	139887056427648
r10            0x300	768
r11            0x1000	4096
r12            0xfffffffffffff000	-4096
r13            0x0	0
r14            0x0	0
r15            0x0	0
rip            0x7f39fc3998df	0x7f39fc3998df <sse2_blt+447>
eflags         0x10202	[ IF RF ]
cs             0x33	51
ss             0x2b	43
ds             0x0	0
es             0x0	0
fs             0x0	0
gs             0x0	0


Current instructions:
=> 0x7f39fc3998df <sse2_blt+447>:	movaps %xmm3,-0x40(%rsi)
   0x7f39fc3998e3 <sse2_blt+451>:	movaps %xmm2,-0x30(%rsi)
   0x7f39fc3998e7 <sse2_blt+455>:	movaps %xmm1,-0x20(%rsi)
   0x7f39fc3998eb <sse2_blt+459>:	movaps %xmm0,-0x10(%rsi)
   0x7f39fc3998ef <sse2_blt+463>:	cmp    $0x3f,%r8d
   0x7f39fc3998f3 <sse2_blt+467>:	jg     0x7f39fc3998c0 <sse2_blt+416>
   0x7f39fc3998f5 <sse2_blt+469>:	sub    $0x40,%edx
   0x7f39fc3998f8 <sse2_blt+472>:	mov    %edx,%esi
   0x7f39fc3998fa <sse2_blt+474>:	shr    $0x6,%esi
   0x7f39fc3998fd <sse2_blt+477>:	mov    %esi,%ecx
   0x7f39fc3998ff <sse2_blt+479>:	shl    $0x6,%esi
   0x7f39fc399902 <sse2_blt+482>:	add    $0x1,%rcx
   0x7f39fc399906 <sse2_blt+486>:	sub    %esi,%edx
   0x7f39fc399908 <sse2_blt+488>:	shl    $0x6,%rcx
   0x7f39fc39990c <sse2_blt+492>:	add    %rcx,%rdi
   0x7f39fc39990f <sse2_blt+495>:	add    %rcx,%rax


Threads backtrace:

Thread 3 (Thread 0x7f39f262b700 (LWP 1902)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f39f60ac463 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
#2  0x00007f39f60abcc7 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
#3  0x00007f39fa9c00a4 in start_thread (arg=0x7f39f262b700) at pthread_create.c:309
#4  0x00007f39fb2df07d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 2 (Thread 0x7f39f2e2c700 (LWP 1901)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f39f60ac463 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
#2  0x00007f39f60abcc7 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
#3  0x00007f39fa9c00a4 in start_thread (arg=0x7f39f2e2c700) at pthread_create.c:309
#4  0x00007f39fb2df07d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 1 (Thread 0x7f39fd6fb980 (LWP 1897)):
#0  sse2_blt (src_bits=<optimized out>, dst_bits=<optimized out>, src_stride=<optimized out>, dst_stride=<optimized out>, src_bpp=<optimized out>, src_x=<optimized out>, src_y=0, dest_x=0, dest_y=0, width=1024, height=<optimized out>, dst_bpp=<optimized out>, imp=<optimized out>) at ../../pixman/pixman-sse2.c:4770
#1  0x00007f39fc399a39 in sse2_blt (height=768, width=1024, dest_y=0, dest_x=<optimized out>, src_y=<optimized out>, src_x=<optimized out>, dst_bpp=<optimized out>, src_bpp=<optimized out>, dst_stride=<optimized out>, src_stride=<optimized out>, dst_bits=<optimized out>, src_bits=<optimized out>, imp=<optimized out>) at ../../pixman/pixman-sse2.c:4822
#2  sse2_composite_copy_area (imp=<optimized out>, info=<optimized out>) at ../../pixman/pixman-sse2.c:4815
#3  0x00007f39fc311711 in pixman_image_composite32 (op=op@entry=PIXMAN_OP_SRC, src=<optimized out>, mask=mask@entry=0x0, dest=<optimized out>, src_x=src_x@entry=0, src_y=src_y@entry=0, mask_x=0, mask_y=0, dest_x=0, dest_y=0, width=1024, height=768) at ../../pixman/pixman.c:707
#4  0x00007f39fc3117e3 in pixman_image_composite (op=op@entry=PIXMAN_OP_SRC, src=<optimized out>, mask=mask@entry=0x0, dest=<optimized out>, src_x=src_x@entry=0, src_y=src_y@entry=0, mask_x=<optimized out>, mask_y=<optimized out>, dest_x=<optimized out>, dest_y=<optimized out>, width=<optimized out>, height=<optimized out>) at ../../pixman/pixman.c:730
#5  0x00007f39f710bca8 in download_box_no_update (surface=0x7f39fe190ff0, surface=0x7f39fe190ff0, y2=<optimized out>, x2=<optimized out>, y1=0, x1=0) at ../../src/qxl_surface.c:133
#6  qxl_download_box (surface=0x7f39fe190ff0, x1=0, y1=0, x2=<optimized out>, y2=<optimized out>) at ../../src/qxl_surface.c:150
#7  0x00007f39f710bdaf in qxl_surface_prepare_access (surface=0x7f39fe190ff0, pixmap=0x7f39fe18d830, region=0x7ffdbbb1cdd0, access=<optimized out>) at ../../src/qxl_surface.c:183
#8  0x00007f39f7116d6d in uxa_prepare_access (pDrawable=0x7f39fe18d830, region=0x7ffdbbb1ce40, region@entry=0x0, access=access@entry=UXA_ACCESS_RO) at ../../../src/uxa/uxa.c:172
#9  0x00007f39f71170f0 in uxa_prepare_access_window (pWin=0x7f39fde5f530) at ../../../src/uxa/uxa.c:310
#10 0x00007f39f7117187 in uxa_change_window_attributes (pWin=0x7f39fde5f530, mask=1) at ../../../src/uxa/uxa.c:343
#11 0x00007f39fd3de6fd in compChangeWindowAttributes (pWin=0x7f39fde5f530, mask=1) at ../../composite/compinit.c:117
#12 0x00007f39fd37fef4 in ChangeWindowAttributes (pWin=0x7f39fde5f530, vmask=<optimized out>, vlist=vlist@entry=0x7f39fe18f304, client=client@entry=0x7f39fe18cf90) at ../../dix/window.c:1460
#13 0x00007f39fd34c2f6 in ProcChangeWindowAttributes (client=0x7f39fe18cf90) at ../../dix/dispatch.c:679
#14 0x00007f39fd352117 in Dispatch () at ../../dix/dispatch.c:432
#15 0x00007f39fd35629b in dix_main (argc=7, argv=0x7ffdbbb1d1c8, envp=<optimized out>) at ../../dix/main.c:298
#16 0x00007f39fb21ab45 in __libc_start_main (main=0x7f39fd340660 <main>, argc=7, argv=0x7ffdbbb1d1c8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffdbbb1d1b8) at libc-start.c:287
#17 0x00007f39fd34068e in _start ()

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

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