All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fabio Fantoni <fabio.fantoni@m2r.biz>
To: "Wang, Zhi A" <zhi.a.wang@intel.com>, 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>
Subject: Re: SSE instruction emulation issues
Date: Thu, 16 Jul 2015 17:38:04 +0200	[thread overview]
Message-ID: <55A7CFDC.1060206@m2r.biz> (raw)
In-Reply-To: <F3B0350DF4CB6849A642218320DE483D0E9CB27F@SHSMSX101.ccr.corp.intel.com>

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

      reply	other threads:[~2015-07-16 15:38 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
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 [this message]

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=55A7CFDC.1060206@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.