* Bug in x86 instruction emulator?
@ 2016-04-05 23:38 wogiz
2016-04-05 23:57 ` Mihai Donțu
` (2 more replies)
0 siblings, 3 replies; 19+ messages in thread
From: wogiz @ 2016-04-05 23:38 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/plain, Size: 412 bytes --]
I'm running Xen 4.6.1 with Alpine Linux 3.3.3 in dom0. In a HVM domU
with vga="qxl", Xorg will segfault instantly if tried started. Multiple
Linux distros have been tested and Xorg segfaults in all.
Attached are a full backtrace from domU generated by Xorg, and a
assembler dump of function 'sse2_blt'.
According to Xen IRC channel, the cause could be a bug in the x86
instruction emulator related to SSE.
[-- Attachment #2: xorg-full-backtrace.txt --]
[-- Type: text/plain, Size: 10816 bytes --]
Core was generated by `/usr/bin/X -nolisten tcp :0 -auth /tmp/serverauth.J8ecNHkUxO'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007fc65c3d5626 in _mm_store_si128 (__B=..., __P=0xf1fe000001e000) at /usr/lib/gcc/x86_64-alpine-linux-musl/5.3.0/include/emmintrin.h:710
710 *__P = __B;
[Current thread is 1 (LWP 2296)]
(gdb) bt full
#0 0x00007fc65c3d5626 in _mm_store_si128 (__B=..., __P=0xf1fe000001e000) at /usr/lib/gcc/x86_64-alpine-linux-musl/5.3.0/include/emmintrin.h:710
No locals.
#1 save_128_aligned (data=..., dst=0xf1fe000001e000) at pixman-sse2.c:391
No locals.
#2 sse2_blt (imp=0x7fc65b3ee420, src_bits=0x7fc650541000, dst_bits=0x7fc64ff41020, src_stride=-4096, dst_stride=4096, src_bpp=32, dst_bpp=32, src_x=22, src_y=4, dest_x=22, dest_y=4,
width=9, height=8) at pixman-sse2.c:4782
w = 28
s = 0x7fc65053d060 <error: Cannot access memory at address 0x7fc65053d060>
d = 0x7fc64ff45080 ""
src_bytes = 0x7fc65053c058 <error: Cannot access memory at address 0x7fc65053c058>
dst_bytes = 0x7fc64ff46078 ""
byte_width = 36
#3 0x00007fc65c3d57d2 in sse2_composite_copy_area (imp=0x7fc65b3ee420, info=0x7ffcad040e00) at pixman-sse2.c:4815
op = PIXMAN_OP_SRC
src_image = 0x55dff8418e00
mask_image = 0x0
dest_image = 0x55dff8418f20
src_x = 22
src_y = 4
mask_x = 0
mask_y = 0
dest_x = 22
dest_y = 4
width = 9
height = 9
#4 0x00007fc65c102b62 in pixman_image_composite32 (op=PIXMAN_OP_SRC, src=0x55dff8418e00, mask=0x0, dest=0x55dff8418f20, src_x=22, src_y=4, mask_x=0, mask_y=0, dest_x=22, dest_y=4,
width=9, height=9) at pixman.c:700
src_format = PIXMAN_a8r8g8b8
mask_format = 0
dest_format = PIXMAN_a8r8g8b8
region = {extents = {x1 = 22, y1 = 4, x2 = 31, y2 = 13}, data = 0x0}
extents = {x1 = 0, y1 = 0, x2 = 9, y2 = 9}
imp = 0x7fc65b3ee420
func = 0x7fc65c3d56b7 <sse2_composite_copy_area>
info = {op = PIXMAN_OP_SRC, src_image = 0x55dff8418e00, mask_image = 0x0, dest_image = 0x55dff8418f20, src_x = 22, src_y = 4, mask_x = 0, mask_y = 0, dest_x = 22, dest_y = 4,
width = 9, height = 9, src_flags = 42420863, mask_flags = 8194, dest_flags = 34032255}
pbox = 0x7ffcad040de0
n = 0
#5 0x00007fc65c102c71 in pixman_image_composite (op=PIXMAN_OP_SRC, src=0x55dff8418e00, mask=0x0, dest=0x55dff8418f20, src_x=22, src_y=4, mask_x=0, mask_y=0, dest_x=22, dest_y=4, width=9,
height=9) at pixman.c:723
No locals.
#6 0x00007fc655c6f25b in download_box_no_update (surface=0x55dff8418d20, x1=22, y1=4, x2=31, y2=13) at qxl_surface.c:133
No locals.
#7 0x00007fc655c6f315 in qxl_download_box (surface=0x55dff8418d20, x1=22, y1=4, x2=31, y2=13) at qxl_surface.c:150
__func__ = "qxl_download_box"
#8 0x00007fc655c6f43b in qxl_surface_prepare_access (surface=0x55dff8418d20, pixmap=0x55dff8419040, region=0x7ffcad040fd0, access=UXA_ACCESS_RW) at qxl_surface.c:183
n_boxes = 0
boxes = 0x7ffcad040fd0
pScreen = 0x55dff82d6b20
pScrn = 0x55dff82ccfa0
new = {extents = {x1 = 22, y1 = 4, x2 = 31, y2 = 13}, data = 0x0}
#9 0x00007fc655c7aa1a in qxl_prepare_access (pixmap=0x55dff8419040, region=0x7ffcad041100, access=UXA_ACCESS_RW) at qxl_uxa.c:49
No locals.
#10 0x00007fc655c828f7 in uxa_prepare_access (pDrawable=0x55dff8419040, region=0x7ffcad041100, access=UXA_ACCESS_RW) at uxa.c:172
pScreen = 0x55dff82d6b20
uxa_screen = 0x55dff82d8600
xoff = 0
yoff = 0
pPixmap = 0x55dff8419040
box = {x1 = 2912, y1 = 21994, x2 = 32710, y2 = 0}
region_rec = {extents = {x1 = 0, y1 = 0, x2 = 0, y2 = 0}, data = 0x16}
result = 1
#11 0x00007fc655c92b51 in uxa_check_composite (op=3 '\003', pSrc=0x55dff85a53c0, pMask=0x55dff85a5640, pDst=0x55dff85a4d20, xSrc=-1, ySrc=-9, xMask=0, yMask=0, xDst=22, yDst=4, width=9,
height=9) at uxa-unaccel.c:439
screen = 0x55dff82d6b20
region = {extents = {x1 = 22, y1 = 4, x2 = 31, y2 = 13}, data = 0x0}
__FUNCTION__ = "uxa_check_composite"
#12 0x00007fc655c90725 in uxa_composite (op=3 '\003', pSrc=0x55dff85a53c0, pMask=0x55dff85a5640, pDst=0x55dff85a4d20, xSrc=-1, ySrc=-9, xMask=0, yMask=0, xDst=22, yDst=4, width=9, height=9)
at uxa-render.c:1694
uxa_screen = 0x55dff82d8600
ret = -1
saveSrcRepeat = 1
saveMaskRepeat = 0
region = {extents = {x1 = 19744, y1 = -1958, x2 = 21983, y2 = 0}, data = 0xfffffffffffffff0}
tx = 0
ty = 0
#13 0x000055dff7098e30 in damageComposite (op=<optimized out>, pSrc=0x55dff85a53c0, pMask=0x55dff85a5640, pDst=0x55dff85a4d20, xSrc=<optimized out>, ySrc=<optimized out>, xMask=0, yMask=0,
xDst=22, yDst=4, width=9, height=9) at damage.c:503
pScreen = <optimized out>
ps = 0x55dff82d80c0
pScrPriv = 0x55dff82d8820
#14 0x00007fc655c89675 in uxa_check_glyphs (op=3 '\003', src=0x55dff85a53c0, dst=0x55dff85a4d20, maskFormat=0x55dff82d74c8, xSrc=0, ySrc=0, nlist=-1, list=0x7ffcad041650,
glyphs=0x7ffcad041a50) at uxa-glyphs.c:528
pScreen = 0x55dff82d6b20
image = 0x55dff85a54a0
scratch = 0x55dff85a4a60
mask = 0x55dff85a5640
width = 9
height = 9
x = 22
y = 4
n = -1
xDst = 23
yDst = 13
extents = {x1 = 22, y1 = 4, x2 = 31, y2 = 13}
#15 0x00007fc655c8b1bb in uxa_glyphs (op=3 '\003', pSrc=0x55dff85a53c0, pDst=0x55dff85a4d20, maskFormat=0x55dff82d74c8, xSrc=0, ySrc=0, nlist=1, list=0x7ffcad041640, glyphs=0x7ffcad041a48)
at uxa-glyphs.c:1054
screen = 0x55dff82d6b20
uxa_screen = 0x55dff82d8600
xDst = 23
yDst = 13
extents = {x1 = 0, y1 = 0, x2 = 0, y2 = 0}
have_extents = 0
width = 1564158436
height = 32710
ret = 32
localDst = 0x55dff85a4d20
#16 0x000055dff709918f in damageGlyphs (op=<optimized out>, pSrc=0x55dff85a53c0, pDst=0x55dff85a4d20, maskFormat=0x55dff82d74c8, xSrc=<optimized out>, ySrc=<optimized out>, nlist=1,
list=0x7ffcad041640, glyphs=0x7ffcad041a48) at damage.c:569
pScreen = <optimized out>
ps = 0x55dff82d80c0
pScrPriv = 0x55dff82d8820
#17 0x000055dff7091143 in ProcRenderCompositeGlyphs (client=0x55dff85e6de0) at render.c:1390
glyphSet = 0x55dff85a46c0
ps = 0x55dff82d80c0
pScrPriv = 0x55dff82d8820
#17 0x000055dff7091143 in ProcRenderCompositeGlyphs (client=0x55dff85e6de0) at render.c:1390
glyphSet = 0x55dff85a46c0
gs = 0
pSrc = 0x55dff85a53c0
pDst = 0x55dff85a4d20
pFormat = 0x55dff82d74c8
listsLocal = {{xOff = 23, yOff = 13, len = 1 '\001', format = 0x55dff82d74c8}, {xOff = 0, yOff = 0, len = 0 '\000', format = 0x0} <repeats 63 times>}
lists = <optimized out>
listsBase = 0x7ffcad041640
glyphsLocal = {0x55dff85a4ae0, 0x0 <repeats 118 times>, 0x4412c00000000000, 0x7fc65d14d744 <alloc_fwd+167>, 0x0, 0x0, 0x0, 0x55dff85a4d70, 0x55dff8419040, 0x60, 0x55dff85a2dfc,
0x0, 0x55dff85a4d10, 0x7fc65d14d83c <free+143>, 0x60, 0x4, 0x7fc65d3b2a2c <mal+108>, 0x7fc65d15e580 <ioctl+58>, 0x7fc65d3b2a28 <mal+104>, 0x55dff85c9420, 0x55dff8419040,
0x55dff85c94a0, 0x55dff85a2dfc, 0x55dff85d1440, 0x55dff737ee48 <dispatchException>, 0x7fc655c7ef8f <qxl_bo_decref+254>, 0x55dff85d1f60, 0x55dff82cdea0, 0x0, 0x100000001, 0x0,
0x7ffcad042220, 0x55dff85d1f60, 0x7fc65c327dcd <pixman_region_init_rects+119>, 0x55dff85a2dfc, 0x155c7f276, 0x7ffcad041f80, 0x7ffcad042220, 0x44090000f82cdea0,
0x7fc65d14d744 <alloc_fwd+167>, 0x1, 0x55dff85a4d20, 0x100000000, 0x55dff85a54f0, 0x55dff85e6de0, 0x60, 0x55dff85e6de0, 0x0, 0x4409c000f85a5490, 0x7fc65d14d83c <free+143>, 0x60,
0x30, 0x7fc65d3b2e4c <mal+1164>, 0x7fc65d15e580 <ioctl+58>, 0x55dff85a4d20, 0x55dff85a2e48, 0x55dff85e6de0, 0x0, 0x55dff85e6de0, 0x55dff85d1440,
0x55dff737ee48 <dispatchException>, 0x7fc655c7ef8f <qxl_bo_decref+254>, 0x55dff85a4f80, 0x55dff82cdea0, 0x7fc655ea0b40 <uxa_pixmap_index>, 0x7fc65c6d9113 <drmIoctl+30>,
0x55dff82cdea0, 0x55dff85a2e48, 0x55dff85a4f80, 0x9958196311bf3cc9, 0x55dff85e6de0, 0x7fc655c7f276 <qxl_bo_write_command+389>, 0x55dff85a4fe0, 0x55dff85a54a0, 0x1f82cdea0,
0x55dff82cdea0, 0x1, 0x55dff85a54a0, 0x100000000, 0x7ffcad042070, 0x55dff85a5508, 0x55dff82ce838, 0xb700000001, 0x55df00000001, 0x55dff82cdea0, 0x9958196311bf3cc9, 0x400000020,
0x7fc655c6f0d1 <push_drawable+48>, 0x55dff85a54a0, 0x55dff82cdea0, 0x55dff85a54a0, 0x7fc655c6f1c0 <submit_fill+233>, 0xffbbbbbbffffffff, 0x7ffcad042140, 0x55dff85a4fe0,
0x55dff82cdea0, 0x55dff85a54a0, 0x55dff85a5500, 0x7fc655ea0b40 <uxa_pixmap_index>, 0x7fc655c6fe03 <qxl_surface_solid+127>, 0x7fc655ea0b40 <uxa_pixmap_index>, 0x100000001, 0x0,
0x55dff85a4fe0, 0xffbbbbbb55ea0b40, 0x55dff82cdea0, 0x0, 0x100000001, 0x0, 0x9958196311bf3cc9, 0xbb0055eaffff, 0x7fc655c7abcd <qxl_solid+68>, 0x3ffffffff, 0x100000001, 0x0,
0x7ffcad042220, 0x55dff85a5300, 0x7fc655c8e88b <uxa_solid_rects+1482>, 0x55dff85a2e5c, 0x55dff85a2e54, 0x55dff85a53c0, 0x9958190100000001, 0x55dff85a53c0, 0x0, 0x55dfffffffff,
0xf85e6de0, 0x7ffcad042248, 0x0, 0x55dff85e6de0, 0x55dff85d1440, 0x1, 0x7fc65d17e3d5 <__clock_gettime+22>, 0xffffffff, 0x55dff7388cf0 <checkForInput>, 0x55dff85e6f40,
0x55dff70f89d3 <ReadRequestFromClient+46>, 0x55dff85a2e48, 0x55dff707359e <XaceHookDispatch+152>, 0x55dff85e6de0}
glyph = <optimized out>
glyphs = 0x7ffcad041a50
glyphsBase = 0x7ffcad041a48
elt = <optimized out>
buffer = 0x55dff85a2e8c "\212\a\002"
end = 0x55dff85a2e8c "\212\a\002"
nglyph = <optimized out>
nlist = 1
space = <optimized out>
size = 1
rc = <optimized out>
n = <optimized out>
stuff = <optimized out>
#18 0x000055dff6fe816b in Dispatch () at dispatch.c:430
clientReady = <optimized out>
result = <optimized out>
client = 0x55dff85e6de0
nready = 0
icheck = 0x55dff7388cf0 <checkForInput>
start_tick = 5
#19 0x000055dff6feb4f6 in dix_main (argc=6, argv=0x7ffcad0423a8, envp=<optimized out>) at main.c:300
i = <optimized out>
alwaysCheckForInput = {0, 1}
#20 0x00007fc65d14772f in __libc_start_main (main=0x55dff6fd941c <main>, argc=6, argv=0x7ffcad0423a8) at src/env/__libc_start_main.c:74
envp = 0x7ffcad0423e0
#21 0x000055dff6fd945c in _start_c (p=<optimized out>) at crt/crt1.c:17
argc = <optimized out>
argv = <optimized out>
#22 0x000055dff6fd9437 in _start ()
No symbol table info available.
[-- Attachment #3: sse2_blt-assembler-dump.txt --]
[-- Type: text/plain, Size: 14470 bytes --]
(gdb) disass
Dump of assembler code for function sse2_blt:
0x00007fc65c3d519f <+0>: sub $0x170,%rsp
0x00007fc65c3d51a6 <+7>: mov %rdi,-0x50(%rsp)
0x00007fc65c3d51ab <+12>: mov %rsi,-0x58(%rsp)
0x00007fc65c3d51b0 <+17>: mov %rdx,-0x60(%rsp)
0x00007fc65c3d51b5 <+22>: mov %ecx,-0x64(%rsp)
0x00007fc65c3d51b9 <+26>: mov %r8d,-0x68(%rsp)
0x00007fc65c3d51be <+31>: mov %r9d,-0x6c(%rsp)
0x00007fc65c3d51c3 <+36>: mov -0x6c(%rsp),%eax
0x00007fc65c3d51c7 <+40>: cmp 0x178(%rsp),%eax
0x00007fc65c3d51ce <+47>: je 0x7fc65c3d51da <sse2_blt+59>
0x00007fc65c3d51d0 <+49>: mov $0x0,%eax
0x00007fc65c3d51d5 <+54>: jmpq 0x7fc65c3d56af <sse2_blt+1296>
0x00007fc65c3d51da <+59>: cmpl $0x10,-0x6c(%rsp)
0x00007fc65c3d51df <+64>: jne 0x7fc65c3d527f <sse2_blt+224>
0x00007fc65c3d51e5 <+70>: mov -0x64(%rsp),%eax
0x00007fc65c3d51e9 <+74>: shl $0x2,%eax
0x00007fc65c3d51ec <+77>: mov %eax,%edx
0x00007fc65c3d51ee <+79>: shr $0x1f,%edx
0x00007fc65c3d51f1 <+82>: add %edx,%eax
0x00007fc65c3d51f3 <+84>: sar %eax
0x00007fc65c3d51f5 <+86>: mov %eax,-0x64(%rsp)
0x00007fc65c3d51f9 <+90>: mov -0x68(%rsp),%eax
0x00007fc65c3d51fd <+94>: shl $0x2,%eax
0x00007fc65c3d5200 <+97>: mov %eax,%edx
0x00007fc65c3d5202 <+99>: shr $0x1f,%edx
0x00007fc65c3d5205 <+102>: add %edx,%eax
0x00007fc65c3d5207 <+104>: sar %eax
0x00007fc65c3d5209 <+106>: mov %eax,-0x68(%rsp)
0x00007fc65c3d520d <+110>: mov -0x64(%rsp),%eax
0x00007fc65c3d5211 <+114>: imul 0x188(%rsp),%eax
0x00007fc65c3d5219 <+122>: movslq %eax,%rdx
0x00007fc65c3d521c <+125>: mov 0x180(%rsp),%eax
0x00007fc65c3d5223 <+132>: cltq
0x00007fc65c3d5225 <+134>: add %rdx,%rax
0x00007fc65c3d5228 <+137>: lea (%rax,%rax,1),%rdx
0x00007fc65c3d522c <+141>: mov -0x58(%rsp),%rax
0x00007fc65c3d5231 <+146>: add %rdx,%rax
0x00007fc65c3d5234 <+149>: mov %rax,-0x38(%rsp)
0x00007fc65c3d5239 <+154>: mov -0x68(%rsp),%eax
0x00007fc65c3d523d <+158>: imul 0x198(%rsp),%eax
0x00007fc65c3d5245 <+166>: movslq %eax,%rdx
0x00007fc65c3d5248 <+169>: mov 0x190(%rsp),%eax
0x00007fc65c3d524f <+176>: cltq
0x00007fc65c3d5251 <+178>: add %rdx,%rax
0x00007fc65c3d5254 <+181>: lea (%rax,%rax,1),%rdx
0x00007fc65c3d5258 <+185>: mov -0x60(%rsp),%rax
0x00007fc65c3d525d <+190>: add %rdx,%rax
0x00007fc65c3d5260 <+193>: mov %rax,-0x30(%rsp)
0x00007fc65c3d5265 <+198>: mov 0x1a0(%rsp),%eax
0x00007fc65c3d526c <+205>: add %eax,%eax
0x00007fc65c3d526e <+207>: mov %eax,-0x40(%rsp)
0x00007fc65c3d5272 <+211>: shll -0x64(%rsp)
0x00007fc65c3d5276 <+215>: shll -0x68(%rsp)
0x00007fc65c3d527a <+219>: jmpq 0x7fc65c3d5691 <sse2_blt+1266>
0x00007fc65c3d527f <+224>: cmpl $0x20,-0x6c(%rsp)
0x00007fc65c3d5284 <+229>: jne 0x7fc65c3d5333 <sse2_blt+404>
0x00007fc65c3d528a <+235>: mov -0x64(%rsp),%eax
0x00007fc65c3d528e <+239>: shl $0x2,%eax
0x00007fc65c3d5291 <+242>: lea 0x3(%rax),%edx
0x00007fc65c3d5294 <+245>: test %eax,%eax
0x00007fc65c3d5296 <+247>: cmovs %edx,%eax
0x00007fc65c3d5299 <+250>: sar $0x2,%eax
0x00007fc65c3d529c <+253>: mov %eax,-0x64(%rsp)
0x00007fc65c3d52a0 <+257>: mov -0x68(%rsp),%eax
0x00007fc65c3d52a4 <+261>: shl $0x2,%eax
0x00007fc65c3d52a7 <+264>: lea 0x3(%rax),%edx
0x00007fc65c3d52aa <+267>: test %eax,%eax
0x00007fc65c3d52ac <+269>: cmovs %edx,%eax
0x00007fc65c3d52af <+272>: sar $0x2,%eax
0x00007fc65c3d52b2 <+275>: mov %eax,-0x68(%rsp)
0x00007fc65c3d52b6 <+279>: mov -0x64(%rsp),%eax
0x00007fc65c3d52ba <+283>: imul 0x188(%rsp),%eax
0x00007fc65c3d52c2 <+291>: movslq %eax,%rdx
0x00007fc65c3d52c5 <+294>: mov 0x180(%rsp),%eax
0x00007fc65c3d52cc <+301>: cltq
0x00007fc65c3d52ce <+303>: add %rdx,%rax
0x00007fc65c3d52d1 <+306>: lea 0x0(,%rax,4),%rdx
0x00007fc65c3d52d9 <+314>: mov -0x58(%rsp),%rax
0x00007fc65c3d52de <+319>: add %rdx,%rax
0x00007fc65c3d52e1 <+322>: mov %rax,-0x38(%rsp)
0x00007fc65c3d52e6 <+327>: mov -0x68(%rsp),%eax
0x00007fc65c3d52ea <+331>: imul 0x198(%rsp),%eax
0x00007fc65c3d52f2 <+339>: movslq %eax,%rdx
0x00007fc65c3d52f5 <+342>: mov 0x190(%rsp),%eax
0x00007fc65c3d52fc <+349>: cltq
0x00007fc65c3d52fe <+351>: add %rdx,%rax
0x00007fc65c3d5301 <+354>: lea 0x0(,%rax,4),%rdx
0x00007fc65c3d5309 <+362>: mov -0x60(%rsp),%rax
0x00007fc65c3d530e <+367>: add %rdx,%rax
0x00007fc65c3d5311 <+370>: mov %rax,-0x30(%rsp)
0x00007fc65c3d5316 <+375>: mov 0x1a0(%rsp),%eax
0x00007fc65c3d531d <+382>: shl $0x2,%eax
0x00007fc65c3d5320 <+385>: mov %eax,-0x40(%rsp)
0x00007fc65c3d5324 <+389>: shll $0x2,-0x64(%rsp)
0x00007fc65c3d5329 <+394>: shll $0x2,-0x68(%rsp)
0x00007fc65c3d532e <+399>: jmpq 0x7fc65c3d5691 <sse2_blt+1266>
0x00007fc65c3d5333 <+404>: mov $0x0,%eax
0x00007fc65c3d5338 <+409>: jmpq 0x7fc65c3d56af <sse2_blt+1296>
0x00007fc65c3d533d <+414>: mov -0x38(%rsp),%rax
0x00007fc65c3d5342 <+419>: mov %rax,-0x28(%rsp)
0x00007fc65c3d5347 <+424>: mov -0x30(%rsp),%rax
0x00007fc65c3d534c <+429>: mov %rax,-0x20(%rsp)
0x00007fc65c3d5351 <+434>: mov -0x64(%rsp),%eax
0x00007fc65c3d5355 <+438>: cltq
0x00007fc65c3d5357 <+440>: add %rax,-0x38(%rsp)
0x00007fc65c3d535c <+445>: mov -0x68(%rsp),%eax
0x00007fc65c3d5360 <+449>: cltq
0x00007fc65c3d5362 <+451>: add %rax,-0x30(%rsp)
0x00007fc65c3d5367 <+456>: mov -0x40(%rsp),%eax
0x00007fc65c3d536b <+460>: mov %eax,-0x3c(%rsp)
0x00007fc65c3d536f <+464>: jmp 0x7fc65c3d5392 <sse2_blt+499>
0x00007fc65c3d5371 <+466>: mov -0x28(%rsp),%rax
0x00007fc65c3d5376 <+471>: movzwl (%rax),%edx
0x00007fc65c3d5379 <+474>: mov -0x20(%rsp),%rax
0x00007fc65c3d537e <+479>: mov %dx,(%rax)
0x00007fc65c3d5381 <+482>: subl $0x2,-0x3c(%rsp)
0x00007fc65c3d5386 <+487>: addq $0x2,-0x28(%rsp)
0x00007fc65c3d538c <+493>: addq $0x2,-0x20(%rsp)
0x00007fc65c3d5392 <+499>: cmpl $0x1,-0x3c(%rsp)
0x00007fc65c3d5397 <+504>: jle 0x7fc65c3d53c7 <sse2_blt+552>
0x00007fc65c3d5399 <+506>: mov -0x20(%rsp),%rax
0x00007fc65c3d539e <+511>: and $0x3,%eax
0x00007fc65c3d53a1 <+514>: test %rax,%rax
0x00007fc65c3d53a4 <+517>: jne 0x7fc65c3d5371 <sse2_blt+466>
0x00007fc65c3d53a6 <+519>: jmp 0x7fc65c3d53c7 <sse2_blt+552>
0x00007fc65c3d53a8 <+521>: mov -0x28(%rsp),%rax
0x00007fc65c3d53ad <+526>: mov (%rax),%edx
0x00007fc65c3d53af <+528>: mov -0x20(%rsp),%rax
0x00007fc65c3d53b4 <+533>: mov %edx,(%rax)
0x00007fc65c3d53b6 <+535>: subl $0x4,-0x3c(%rsp)
0x00007fc65c3d53bb <+540>: addq $0x4,-0x28(%rsp)
0x00007fc65c3d53c1 <+546>: addq $0x4,-0x20(%rsp)
0x00007fc65c3d53c7 <+552>: cmpl $0x3,-0x3c(%rsp)
0x00007fc65c3d53cc <+557>: jle 0x7fc65c3d55bb <sse2_blt+1052>
0x00007fc65c3d53d2 <+563>: mov -0x20(%rsp),%rax
0x00007fc65c3d53d7 <+568>: and $0xf,%eax
0x00007fc65c3d53da <+571>: test %rax,%rax
0x00007fc65c3d53dd <+574>: jne 0x7fc65c3d53a8 <sse2_blt+521>
0x00007fc65c3d53df <+576>: jmpq 0x7fc65c3d55bb <sse2_blt+1052>
0x00007fc65c3d53e4 <+581>: mov -0x28(%rsp),%rax
0x00007fc65c3d53e9 <+586>: mov %rax,-0x10(%rsp)
0x00007fc65c3d53ee <+591>: mov -0x10(%rsp),%rax
0x00007fc65c3d53f3 <+596>: mov %rax,0x70(%rsp)
0x00007fc65c3d53f8 <+601>: mov 0x70(%rsp),%rax
0x00007fc65c3d53fd <+606>: movdqu (%rax),%xmm0
0x00007fc65c3d5401 <+610>: movaps %xmm0,0x88(%rsp)
0x00007fc65c3d5409 <+618>: mov -0x28(%rsp),%rax
0x00007fc65c3d540e <+623>: add $0x10,%rax
0x00007fc65c3d5412 <+627>: mov %rax,-0x8(%rsp)
0x00007fc65c3d5417 <+632>: mov -0x8(%rsp),%rax
0x00007fc65c3d541c <+637>: mov %rax,0x68(%rsp)
0x00007fc65c3d5421 <+642>: mov 0x68(%rsp),%rax
0x00007fc65c3d5426 <+647>: movdqu (%rax),%xmm0
0x00007fc65c3d542a <+651>: movaps %xmm0,0x98(%rsp)
0x00007fc65c3d5432 <+659>: mov -0x28(%rsp),%rax
0x00007fc65c3d5437 <+664>: add $0x20,%rax
0x00007fc65c3d543b <+668>: mov %rax,(%rsp)
0x00007fc65c3d543f <+672>: mov (%rsp),%rax
0x00007fc65c3d5443 <+676>: mov %rax,0x60(%rsp)
0x00007fc65c3d5448 <+681>: mov 0x60(%rsp),%rax
0x00007fc65c3d544d <+686>: movdqu (%rax),%xmm0
0x00007fc65c3d5451 <+690>: movaps %xmm0,0xa8(%rsp)
0x00007fc65c3d5459 <+698>: mov -0x28(%rsp),%rax
0x00007fc65c3d545e <+703>: add $0x30,%rax
0x00007fc65c3d5462 <+707>: mov %rax,0x8(%rsp)
0x00007fc65c3d5467 <+712>: mov 0x8(%rsp),%rax
0x00007fc65c3d546c <+717>: mov %rax,0x58(%rsp)
0x00007fc65c3d5471 <+722>: mov 0x58(%rsp),%rax
0x00007fc65c3d5476 <+727>: movdqu (%rax),%xmm0
0x00007fc65c3d547a <+731>: movaps %xmm0,0xb8(%rsp)
0x00007fc65c3d5482 <+739>: mov -0x20(%rsp),%rax
0x00007fc65c3d5487 <+744>: mov %rax,0x10(%rsp)
0x00007fc65c3d548c <+749>: movdqa 0x88(%rsp),%xmm0
0x00007fc65c3d5495 <+758>: movaps %xmm0,0x128(%rsp)
0x00007fc65c3d549d <+766>: mov 0x10(%rsp),%rax
0x00007fc65c3d54a2 <+771>: mov %rax,0x50(%rsp)
0x00007fc65c3d54a7 <+776>: movdqa 0x128(%rsp),%xmm0
0x00007fc65c3d54b0 <+785>: movaps %xmm0,0x138(%rsp)
0x00007fc65c3d54b8 <+793>: mov 0x50(%rsp),%rax
0x00007fc65c3d54bd <+798>: movdqa 0x138(%rsp),%xmm0
0x00007fc65c3d54c6 <+807>: movaps %xmm0,(%rax)
0x00007fc65c3d54c9 <+810>: mov -0x20(%rsp),%rax
0x00007fc65c3d54ce <+815>: add $0x10,%rax
0x00007fc65c3d54d2 <+819>: mov %rax,0x18(%rsp)
0x00007fc65c3d54d7 <+824>: movdqa 0x98(%rsp),%xmm0
0x00007fc65c3d54e0 <+833>: movaps %xmm0,0x108(%rsp)
0x00007fc65c3d54e8 <+841>: mov 0x18(%rsp),%rax
0x00007fc65c3d54ed <+846>: mov %rax,0x48(%rsp)
0x00007fc65c3d54f2 <+851>: movdqa 0x108(%rsp),%xmm0
0x00007fc65c3d54fb <+860>: movaps %xmm0,0x118(%rsp)
0x00007fc65c3d5503 <+868>: mov 0x48(%rsp),%rax
0x00007fc65c3d5508 <+873>: movdqa 0x118(%rsp),%xmm0
0x00007fc65c3d5511 <+882>: movaps %xmm0,(%rax)
0x00007fc65c3d5514 <+885>: mov -0x20(%rsp),%rax
0x00007fc65c3d5519 <+890>: add $0x20,%rax
0x00007fc65c3d551d <+894>: mov %rax,0x20(%rsp)
0x00007fc65c3d5522 <+899>: movdqa 0xa8(%rsp),%xmm0
0x00007fc65c3d552b <+908>: movaps %xmm0,0xe8(%rsp)
0x00007fc65c3d5533 <+916>: mov 0x20(%rsp),%rax
0x00007fc65c3d5538 <+921>: mov %rax,0x40(%rsp)
0x00007fc65c3d553d <+926>: movdqa 0xe8(%rsp),%xmm0
0x00007fc65c3d5546 <+935>: movaps %xmm0,0xf8(%rsp)
0x00007fc65c3d554e <+943>: mov 0x40(%rsp),%rax
0x00007fc65c3d5553 <+948>: movdqa 0xf8(%rsp),%xmm0
0x00007fc65c3d555c <+957>: movaps %xmm0,(%rax)
0x00007fc65c3d555f <+960>: mov -0x20(%rsp),%rax
0x00007fc65c3d5564 <+965>: add $0x30,%rax
0x00007fc65c3d5568 <+969>: mov %rax,0x30(%rsp)
0x00007fc65c3d556d <+974>: movdqa 0xb8(%rsp),%xmm0
0x00007fc65c3d5576 <+983>: movaps %xmm0,0xc8(%rsp)
0x00007fc65c3d557e <+991>: mov 0x30(%rsp),%rax
0x00007fc65c3d5583 <+996>: mov %rax,0x38(%rsp)
0x00007fc65c3d5588 <+1001>: movdqa 0xc8(%rsp),%xmm0
0x00007fc65c3d5591 <+1010>: movaps %xmm0,0xd8(%rsp)
0x00007fc65c3d5599 <+1018>: mov 0x38(%rsp),%rax
0x00007fc65c3d559e <+1023>: movdqa 0xd8(%rsp),%xmm0
0x00007fc65c3d55a7 <+1032>: movaps %xmm0,(%rax)
0x00007fc65c3d55aa <+1035>: addq $0x40,-0x28(%rsp)
0x00007fc65c3d55b0 <+1041>: addq $0x40,-0x20(%rsp)
0x00007fc65c3d55b6 <+1047>: subl $0x40,-0x3c(%rsp)
0x00007fc65c3d55bb <+1052>: cmpl $0x3f,-0x3c(%rsp)
0x00007fc65c3d55c0 <+1057>: jg 0x7fc65c3d53e4 <sse2_blt+581>
0x00007fc65c3d55c6 <+1063>: jmp 0x7fc65c3d563a <sse2_blt+1179>
0x00007fc65c3d55c8 <+1065>: mov -0x28(%rsp),%rax
0x00007fc65c3d55cd <+1070>: mov %rax,0x28(%rsp)
0x00007fc65c3d55d2 <+1075>: mov 0x28(%rsp),%rax
0x00007fc65c3d55d7 <+1080>: mov %rax,0x80(%rsp)
0x00007fc65c3d55df <+1088>: mov 0x80(%rsp),%rax
0x00007fc65c3d55e7 <+1096>: movdqu (%rax),%xmm0
0x00007fc65c3d55eb <+1100>: mov -0x20(%rsp),%rax
0x00007fc65c3d55f0 <+1105>: mov %rax,-0x18(%rsp)
0x00007fc65c3d55f5 <+1110>: movaps %xmm0,0x148(%rsp)
0x00007fc65c3d55fd <+1118>: mov -0x18(%rsp),%rax
0x00007fc65c3d5602 <+1123>: mov %rax,0x78(%rsp)
0x00007fc65c3d5607 <+1128>: movdqa 0x148(%rsp),%xmm0
0x00007fc65c3d5610 <+1137>: movaps %xmm0,0x158(%rsp)
0x00007fc65c3d5618 <+1145>: mov 0x78(%rsp),%rax
0x00007fc65c3d561d <+1150>: movdqa 0x158(%rsp),%xmm0
=> 0x00007fc65c3d5626 <+1159>: movaps %xmm0,(%rax)
0x00007fc65c3d5629 <+1162>: subl $0x10,-0x3c(%rsp)
0x00007fc65c3d562e <+1167>: addq $0x10,-0x20(%rsp)
0x00007fc65c3d5634 <+1173>: addq $0x10,-0x28(%rsp)
0x00007fc65c3d563a <+1179>: cmpl $0xf,-0x3c(%rsp)
0x00007fc65c3d563f <+1184>: jg 0x7fc65c3d55c8 <sse2_blt+1065>
0x00007fc65c3d5641 <+1186>: jmp 0x7fc65c3d5662 <sse2_blt+1219>
0x00007fc65c3d5643 <+1188>: mov -0x28(%rsp),%rax
0x00007fc65c3d5648 <+1193>: mov (%rax),%edx
0x00007fc65c3d564a <+1195>: mov -0x20(%rsp),%rax
0x00007fc65c3d564f <+1200>: mov %edx,(%rax)
0x00007fc65c3d5651 <+1202>: subl $0x4,-0x3c(%rsp)
0x00007fc65c3d5656 <+1207>: addq $0x4,-0x28(%rsp)
0x00007fc65c3d565c <+1213>: addq $0x4,-0x20(%rsp)
0x00007fc65c3d5662 <+1219>: cmpl $0x3,-0x3c(%rsp)
0x00007fc65c3d5667 <+1224>: jg 0x7fc65c3d5643 <sse2_blt+1188>
0x00007fc65c3d5669 <+1226>: cmpl $0x1,-0x3c(%rsp)
0x00007fc65c3d566e <+1231>: jle 0x7fc65c3d5691 <sse2_blt+1266>
0x00007fc65c3d5670 <+1233>: mov -0x28(%rsp),%rax
0x00007fc65c3d5675 <+1238>: movzwl (%rax),%edx
0x00007fc65c3d5678 <+1241>: mov -0x20(%rsp),%rax
0x00007fc65c3d567d <+1246>: mov %dx,(%rax)
0x00007fc65c3d5680 <+1249>: subl $0x2,-0x3c(%rsp)
0x00007fc65c3d5685 <+1254>: addq $0x2,-0x28(%rsp)
0x00007fc65c3d568b <+1260>: addq $0x2,-0x20(%rsp)
0x00007fc65c3d5691 <+1266>: mov 0x1a8(%rsp),%eax
0x00007fc65c3d5698 <+1273>: lea -0x1(%rax),%edx
0x00007fc65c3d569b <+1276>: mov %edx,0x1a8(%rsp)
0x00007fc65c3d56a2 <+1283>: test %eax,%eax
0x00007fc65c3d56a4 <+1285>: jne 0x7fc65c3d533d <sse2_blt+414>
0x00007fc65c3d56aa <+1291>: mov $0x1,%eax
0x00007fc65c3d56af <+1296>: add $0x170,%rsp
0x00007fc65c3d56b6 <+1303>: retq
End of assembler dump.
[-- Attachment #4: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bug in x86 instruction emulator?
2016-04-05 23:38 Bug in x86 instruction emulator? wogiz
@ 2016-04-05 23:57 ` Mihai Donțu
2016-04-06 0:02 ` Mihai Donțu
` (2 more replies)
2016-05-04 16:02 ` Jan Beulich
2016-05-18 9:12 ` Jan Beulich
2 siblings, 3 replies; 19+ messages in thread
From: Mihai Donțu @ 2016-04-05 23:57 UTC (permalink / raw)
To: wogiz; +Cc: xen-devel
On Wed, 06 Apr 2016 01:38:32 +0200 wogiz@openmailbox.org wrote:
> I'm running Xen 4.6.1 with Alpine Linux 3.3.3 in dom0. In a HVM domU
> with vga="qxl", Xorg will segfault instantly if tried started. Multiple
> Linux distros have been tested and Xorg segfaults in all.
>
> Attached are a full backtrace from domU generated by Xorg, and a
> assembler dump of function 'sse2_blt'.
>
> According to Xen IRC channel, the cause could be a bug in the x86
> instruction emulator related to SSE.
I don't believe the x86 emulator is complete wrt the SSE instruction
set. But I do wonder why, in your case, these instructions need
emulation at all. Unless touching the video RAM requires emulation. Can
you try using a different video driver? I see xorg picked up qxl, maybe
try vesa?
--
Mihai Donțu
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bug in x86 instruction emulator?
2016-04-05 23:57 ` Mihai Donțu
@ 2016-04-06 0:02 ` Mihai Donțu
2016-04-06 1:48 ` wogiz
2016-04-06 1:26 ` wogiz
2016-04-06 8:55 ` Andrew Cooper
2 siblings, 1 reply; 19+ messages in thread
From: Mihai Donțu @ 2016-04-06 0:02 UTC (permalink / raw)
To: wogiz; +Cc: xen-devel
On Wed, 6 Apr 2016 02:57:35 +0300 Mihai Donțu wrote:
> On Wed, 06 Apr 2016 01:38:32 +0200 wogiz@openmailbox.org wrote:
> > I'm running Xen 4.6.1 with Alpine Linux 3.3.3 in dom0. In a HVM domU
> > with vga="qxl", Xorg will segfault instantly if tried started. Multiple
> > Linux distros have been tested and Xorg segfaults in all.
> >
> > Attached are a full backtrace from domU generated by Xorg, and a
> > assembler dump of function 'sse2_blt'.
> >
> > According to Xen IRC channel, the cause could be a bug in the x86
> > instruction emulator related to SSE.
>
> I don't believe the x86 emulator is complete wrt the SSE instruction
> set. But I do wonder why, in your case, these instructions need
> emulation at all. Unless touching the video RAM requires emulation. Can
> you try using a different video driver? I see xorg picked up qxl, maybe
> try vesa?
This would appear to be an old issue with qxl and xen:
http://www.gossamer-threads.com/lists/xen/devel/358125
--
Mihai Donțu
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bug in x86 instruction emulator?
2016-04-06 0:02 ` Mihai Donțu
@ 2016-04-06 1:48 ` wogiz
0 siblings, 0 replies; 19+ messages in thread
From: wogiz @ 2016-04-06 1:48 UTC (permalink / raw)
To: Mihai Donțu; +Cc: xen-devel
On 2016-04-06 02:02, Mihai Donțu wrote:
> On Wed, 6 Apr 2016 02:57:35 +0300 Mihai Donțu wrote:
>> I don't believe the x86 emulator is complete wrt the SSE instruction
>> set. But I do wonder why, in your case, these instructions need
>> emulation at all. Unless touching the video RAM requires emulation.
>> Can
>> you try using a different video driver? I see xorg picked up qxl,
>> maybe
>> try vesa?
>
> This would appear to be an old issue with qxl and xen:
> http://www.gossamer-threads.com/lists/xen/devel/358125
I'm not able to find out what the current status is, or if the issue has
been ignored.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bug in x86 instruction emulator?
2016-04-05 23:57 ` Mihai Donțu
2016-04-06 0:02 ` Mihai Donțu
@ 2016-04-06 1:26 ` wogiz
2016-04-06 8:55 ` Andrew Cooper
2 siblings, 0 replies; 19+ messages in thread
From: wogiz @ 2016-04-06 1:26 UTC (permalink / raw)
To: Mihai Donțu; +Cc: xen-devel
On 2016-04-06 01:57, Mihai Donțu wrote:
> I don't believe the x86 emulator is complete wrt the SSE instruction
> set. But I do wonder why, in your case, these instructions need
> emulation at all. Unless touching the video RAM requires emulation. Can
> you try using a different video driver? I see xorg picked up qxl, maybe
> try vesa?
I'm not able to start Xorg with vesa driver, as manual configuration of
xorg.conf is required. However, I can confirm that both modesetting and
fbdev drivers work without Xorg segfaulting, even though HVM domU is
configured with vga="qxl".
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bug in x86 instruction emulator?
2016-04-05 23:57 ` Mihai Donțu
2016-04-06 0:02 ` Mihai Donțu
2016-04-06 1:26 ` wogiz
@ 2016-04-06 8:55 ` Andrew Cooper
2016-04-07 1:26 ` wogiz
2 siblings, 1 reply; 19+ messages in thread
From: Andrew Cooper @ 2016-04-06 8:55 UTC (permalink / raw)
To: Mihai Donțu, wogiz; +Cc: xen-devel
On 06/04/16 00:57, Mihai Donțu wrote:
> On Wed, 06 Apr 2016 01:38:32 +0200 wogiz@openmailbox.org wrote:
>> I'm running Xen 4.6.1 with Alpine Linux 3.3.3 in dom0. In a HVM domU
>> with vga="qxl", Xorg will segfault instantly if tried started. Multiple
>> Linux distros have been tested and Xorg segfaults in all.
>>
>> Attached are a full backtrace from domU generated by Xorg, and a
>> assembler dump of function 'sse2_blt'.
>>
>> According to Xen IRC channel, the cause could be a bug in the x86
>> instruction emulator related to SSE.
> I don't believe the x86 emulator is complete wrt the SSE instruction
> set. But I do wonder why, in your case, these instructions need
> emulation at all. Unless touching the video RAM requires emulation. Can
> you try using a different video driver? I see xorg picked up qxl, maybe
> try vesa?
>
Now I think about it, even dirty VRAM tracking shouldn't actually
emulate the instructions.
Can you grab the full register state at the point of Xorgs crash? `info
regs` in gdb?
The instruction in use, `movaps` is specified to fault if the memory
operand isn't aligned on a 16byte boundary. Therefore, if %rax in this
case isn't a multiple of 16, this is a code generation bug, rather than
an emulation bug.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bug in x86 instruction emulator?
2016-04-06 8:55 ` Andrew Cooper
@ 2016-04-07 1:26 ` wogiz
2016-04-07 2:04 ` Jan Beulich
0 siblings, 1 reply; 19+ messages in thread
From: wogiz @ 2016-04-07 1:26 UTC (permalink / raw)
To: Andrew Cooper; +Cc: Mihai Donțu, xen-devel
[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]
On 2016-04-06 10:55, Andrew Cooper wrote:
> On 06/04/16 00:57, Mihai Donțu wrote:
>> On Wed, 06 Apr 2016 01:38:32 +0200 wogiz@openmailbox.org wrote:
>>> I'm running Xen 4.6.1 with Alpine Linux 3.3.3 in dom0. In a HVM domU
>>> with vga="qxl", Xorg will segfault instantly if tried started.
>>> Multiple
>>> Linux distros have been tested and Xorg segfaults in all.
>>>
>>> Attached are a full backtrace from domU generated by Xorg, and a
>>> assembler dump of function 'sse2_blt'.
>>>
>>> According to Xen IRC channel, the cause could be a bug in the x86
>>> instruction emulator related to SSE.
>> I don't believe the x86 emulator is complete wrt the SSE instruction
>> set. But I do wonder why, in your case, these instructions need
>> emulation at all. Unless touching the video RAM requires emulation.
>> Can
>> you try using a different video driver? I see xorg picked up qxl,
>> maybe
>> try vesa?
>>
>
> Now I think about it, even dirty VRAM tracking shouldn't actually
> emulate the instructions.
>
> Can you grab the full register state at the point of Xorgs crash?
> `info
> regs` in gdb?
>
> The instruction in use, `movaps` is specified to fault if the memory
> operand isn't aligned on a 16byte boundary. Therefore, if %rax in this
> case isn't a multiple of 16, this is a code generation bug, rather than
> an emulation bug.
>
> ~Andrew
Attached is the full register state.
I'm very interested in getting to the bottom of this, so please let me
know if I can do anything to help.
[-- Attachment #2: register-state.txt --]
[-- Type: text/plain, Size: 800 bytes --]
(gdb) info registers
rax 0xf1fe000001e000 68114745340846080
rbx 0x9 9
rcx 0xfffffc00 4294966272
rdx 0x222222 2236962
rsi 0x7fc650541000 140489727938560
rdi 0x7fc65b3ee420 140489911100448
rbp 0x16 0x16
rsp 0x7ffcad040b58 0x7ffcad040b58
r8 0x400 1024
r9 0x20 32
r10 0x20 32
r11 0x9 9
r12 0x4 4
r13 0xffffffff 4294967295
r14 0x55dff82d8820 94420429801504
r15 0x55dff82d80c0 94420429799616
rip 0x7fc65c3d5626 0x7fc65c3d5626 <sse2_blt+1159>
eflags 0x13206 [ PF IF #12 #13 RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
[-- Attachment #3: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bug in x86 instruction emulator?
2016-04-07 1:26 ` wogiz
@ 2016-04-07 2:04 ` Jan Beulich
2016-04-08 1:43 ` wogiz
2016-04-15 17:33 ` wogiz
0 siblings, 2 replies; 19+ messages in thread
From: Jan Beulich @ 2016-04-07 2:04 UTC (permalink / raw)
To: wogiz; +Cc: andrew.cooper3, mihai.dontu, xen-devel
>>> <wogiz@openmailbox.org> 04/07/16 3:28 AM >>>
>On 2016-04-06 10:55, Andrew Cooper wrote:
>> Can you grab the full register state at the point of Xorgs crash?
>> `info
>> regs` in gdb?
>>
>> The instruction in use, `movaps` is specified to fault if the memory
>> operand isn't aligned on a 16byte boundary. Therefore, if %rax in this
>> case isn't a multiple of 16, this is a code generation bug, rather than
>> an emulation bug.
>
>Attached is the full register state.
So it is even page aligned. Which raises the question whether we're
mishandling something here when the page needs bringing in from
disk by the guest.
>I'm very interested in getting to the bottom of this, so please let me
>know if I can do anything to help.
We'd need to know which exact exception (including error code and,
in the case of #PF, CR2 value) gets raised to the guest by what
specific piece of code in the hypervisor. That'll likely mean some
instrumentation of the hypervisor code.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bug in x86 instruction emulator?
2016-04-07 2:04 ` Jan Beulich
@ 2016-04-08 1:43 ` wogiz
2016-04-15 17:33 ` wogiz
1 sibling, 0 replies; 19+ messages in thread
From: wogiz @ 2016-04-08 1:43 UTC (permalink / raw)
To: Jan Beulich; +Cc: andrew.cooper3, mihai.dontu, xen-devel
On 2016-04-07 04:04, Jan Beulich wrote:
> We'd need to know which exact exception (including error code and,
> in the case of #PF, CR2 value) gets raised to the guest by what
> specific piece of code in the hypervisor. That'll likely mean some
> instrumentation of the hypervisor code.
>
> Jan
No problem with instrumentation as it's not a production system.
I don't have the knowledge to write code, but if a patch can be created
or if only a few lines of code is required, I can edit source files
manually, rebuild, install Xen and collect the required information.
William Z.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bug in x86 instruction emulator?
2016-04-07 2:04 ` Jan Beulich
2016-04-08 1:43 ` wogiz
@ 2016-04-15 17:33 ` wogiz
2016-04-15 17:44 ` Andrew Cooper
1 sibling, 1 reply; 19+ messages in thread
From: wogiz @ 2016-04-15 17:33 UTC (permalink / raw)
To: Jan Beulich; +Cc: andrew.cooper3, mihai.dontu, xen-devel
On 2016-04-07 04:04, Jan Beulich wrote:
> We'd need to know which exact exception (including error code and,
> in the case of #PF, CR2 value) gets raised to the guest by what
> specific piece of code in the hypervisor. That'll likely mean some
> instrumentation of the hypervisor code.
>
> Jan
I want to give it a try, but I'm not sure how the hypervisor code
should be modified.
Can anyone point me to some documentation or anything else that can
help me get started?
William Z.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bug in x86 instruction emulator?
2016-04-15 17:33 ` wogiz
@ 2016-04-15 17:44 ` Andrew Cooper
2016-04-16 4:06 ` wogiz
0 siblings, 1 reply; 19+ messages in thread
From: Andrew Cooper @ 2016-04-15 17:44 UTC (permalink / raw)
To: wogiz, Jan Beulich; +Cc: mihai.dontu, xen-devel
On 15/04/16 18:33, wogiz@openmailbox.org wrote:
> On 2016-04-07 04:04, Jan Beulich wrote:
>> We'd need to know which exact exception (including error code and,
>> in the case of #PF, CR2 value) gets raised to the guest by what
>> specific piece of code in the hypervisor. That'll likely mean some
>> instrumentation of the hypervisor code.
>>
>> Jan
>
> I want to give it a try, but I'm not sure how the hypervisor code
> should be modified.
>
> Can anyone point me to some documentation or anything else that can
> help me get started?
Very sorry - I have been busy with patches intended for the 4.7 code freeze.
What domU are you using? Is the issue reproducible from a LiveCD by any
chance?
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bug in x86 instruction emulator?
2016-04-15 17:44 ` Andrew Cooper
@ 2016-04-16 4:06 ` wogiz
0 siblings, 0 replies; 19+ messages in thread
From: wogiz @ 2016-04-16 4:06 UTC (permalink / raw)
To: Andrew Cooper; +Cc: mihai.dontu, Jan Beulich, xen-devel
On 2016-04-15 19:44, Andrew Cooper wrote:
> On 15/04/16 18:33, wogiz@openmailbox.org wrote:
>> On 2016-04-07 04:04, Jan Beulich wrote:
>>> We'd need to know which exact exception (including error code and,
>>> in the case of #PF, CR2 value) gets raised to the guest by what
>>> specific piece of code in the hypervisor. That'll likely mean some
>>> instrumentation of the hypervisor code.
>>>
>>> Jan
>>
>> I want to give it a try, but I'm not sure how the hypervisor code
>> should be modified.
>>
>> Can anyone point me to some documentation or anything else that can
>> help me get started?
>
> Very sorry - I have been busy with patches intended for the 4.7 code
> freeze.
>
> What domU are you using? Is the issue reproducible from a LiveCD by
> any
> chance?
>
> ~Andrew
No problem. I appreciate your help.
I'm using Alpine Linux 3.3.3 domU, but I have also tested various
versions
of Ubuntu.
The issue is reproducible from LiveCD, both Alpine and Ubuntu.
The only requriements to reproduce the fault is a Linux HVM domU with
vga="qxl"
and qxl driver installed in domU. Xorg will segfault instantly when
started, no
matter what Linux distro or other configuration.
William Z.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bug in x86 instruction emulator?
2016-04-05 23:38 Bug in x86 instruction emulator? wogiz
2016-04-05 23:57 ` Mihai Donțu
@ 2016-05-04 16:02 ` Jan Beulich
2016-05-04 16:04 ` Wei Liu
` (2 more replies)
2016-05-18 9:12 ` Jan Beulich
2 siblings, 3 replies; 19+ messages in thread
From: Jan Beulich @ 2016-05-04 16:02 UTC (permalink / raw)
To: wogiz; +Cc: xen-devel
>>> On 06.04.16 at 01:38, <wogiz@openmailbox.org> wrote:
> I'm running Xen 4.6.1 with Alpine Linux 3.3.3 in dom0. In a HVM domU
> with vga="qxl", Xorg will segfault instantly if tried started. Multiple
> Linux distros have been tested and Xorg segfaults in all.
So I've been wanting to make an attempt to repro this, but qemu
keeps telling me
qemu-system-i386: -device qxl-vga,vram_size_mb=64,ram_size_mb=64: 'qxl-vga' is not a valid device model name
when I pass vga="qxl" upon guest creation. My knowledge on
qemu is limited, so I have no idea what I might be doing wrong.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bug in x86 instruction emulator?
2016-05-04 16:02 ` Jan Beulich
@ 2016-05-04 16:04 ` Wei Liu
2016-05-04 16:06 ` Andrew Cooper
2016-05-17 16:53 ` William Z.
2 siblings, 0 replies; 19+ messages in thread
From: Wei Liu @ 2016-05-04 16:04 UTC (permalink / raw)
To: Jan Beulich; +Cc: wogiz, Wei Liu, xen-devel
On Wed, May 04, 2016 at 10:02:07AM -0600, Jan Beulich wrote:
> >>> On 06.04.16 at 01:38, <wogiz@openmailbox.org> wrote:
> > I'm running Xen 4.6.1 with Alpine Linux 3.3.3 in dom0. In a HVM domU
> > with vga="qxl", Xorg will segfault instantly if tried started. Multiple
> > Linux distros have been tested and Xorg segfaults in all.
>
> So I've been wanting to make an attempt to repro this, but qemu
> keeps telling me
>
> qemu-system-i386: -device qxl-vga,vram_size_mb=64,ram_size_mb=64: 'qxl-vga' is not a valid device model name
>
> when I pass vga="qxl" upon guest creation. My knowledge on
> qemu is limited, so I have no idea what I might be doing wrong.
>
You need to install libspice-dev (or the equivalent in you distro) to
enable spice support.
Wei.
> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bug in x86 instruction emulator?
2016-05-04 16:02 ` Jan Beulich
2016-05-04 16:04 ` Wei Liu
@ 2016-05-04 16:06 ` Andrew Cooper
2016-05-17 16:53 ` William Z.
2 siblings, 0 replies; 19+ messages in thread
From: Andrew Cooper @ 2016-05-04 16:06 UTC (permalink / raw)
To: Jan Beulich, wogiz; +Cc: xen-devel
On 04/05/16 17:02, Jan Beulich wrote:
>>>> On 06.04.16 at 01:38, <wogiz@openmailbox.org> wrote:
>> I'm running Xen 4.6.1 with Alpine Linux 3.3.3 in dom0. In a HVM domU
>> with vga="qxl", Xorg will segfault instantly if tried started. Multiple
>> Linux distros have been tested and Xorg segfaults in all.
> So I've been wanting to make an attempt to repro this, but qemu
> keeps telling me
>
> qemu-system-i386: -device qxl-vga,vram_size_mb=64,ram_size_mb=64: 'qxl-vga' is not a valid device model name
>
> when I pass vga="qxl" upon guest creation. My knowledge on
> qemu is limited, so I have no idea what I might be doing wrong.
I encountered that as well. It means Qemu isn't built with spice support.
You want to pass --with-extra-qemuu-configure-args="--enable-spice" to a
./configure when building the Xen tools. (iirc)
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bug in x86 instruction emulator?
2016-05-04 16:02 ` Jan Beulich
2016-05-04 16:04 ` Wei Liu
2016-05-04 16:06 ` Andrew Cooper
@ 2016-05-17 16:53 ` William Z.
2016-05-17 17:03 ` Andrew Cooper
2 siblings, 1 reply; 19+ messages in thread
From: William Z. @ 2016-05-17 16:53 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel
On 2016-05-04 18:02, Jan Beulich wrote:
>>>> On 06.04.16 at 01:38, <wogiz@openmailbox.org> wrote:
>> I'm running Xen 4.6.1 with Alpine Linux 3.3.3 in dom0. In a HVM domU
>> with vga="qxl", Xorg will segfault instantly if tried started.
>> Multiple
>> Linux distros have been tested and Xorg segfaults in all.
>
> So I've been wanting to make an attempt to repro this, but qemu
> keeps telling me
>
> qemu-system-i386: -device qxl-vga,vram_size_mb=64,ram_size_mb=64:
> 'qxl-vga' is not a valid device model name
>
> when I pass vga="qxl" upon guest creation. My knowledge on
> qemu is limited, so I have no idea what I might be doing wrong.
>
> Jan
When the HVM is able to boot, it should be very easy to repo, but
I can create a LiveCD that will repo, if necessary.
William Z.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bug in x86 instruction emulator?
2016-05-17 16:53 ` William Z.
@ 2016-05-17 17:03 ` Andrew Cooper
0 siblings, 0 replies; 19+ messages in thread
From: Andrew Cooper @ 2016-05-17 17:03 UTC (permalink / raw)
To: William Z., Jan Beulich; +Cc: xen-devel
On 17/05/16 17:53, William Z. wrote:
> On 2016-05-04 18:02, Jan Beulich wrote:
>>>>> On 06.04.16 at 01:38, <wogiz@openmailbox.org> wrote:
>>> I'm running Xen 4.6.1 with Alpine Linux 3.3.3 in dom0. In a HVM domU
>>> with vga="qxl", Xorg will segfault instantly if tried started. Multiple
>>> Linux distros have been tested and Xorg segfaults in all.
>>
>> So I've been wanting to make an attempt to repro this, but qemu
>> keeps telling me
>>
>> qemu-system-i386: -device qxl-vga,vram_size_mb=64,ram_size_mb=64:
>> 'qxl-vga' is not a valid device model name
>>
>> when I pass vga="qxl" upon guest creation. My knowledge on
>> qemu is limited, so I have no idea what I might be doing wrong.
>>
>> Jan
>
> When the HVM is able to boot, it should be very easy to repo, but
> I can create a LiveCD that will repo, if necessary.
I am terribly sorry - I keep on getting diverted onto other things.
A LiveCD with qxl already configured would be fantastically helpful.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bug in x86 instruction emulator?
2016-04-05 23:38 Bug in x86 instruction emulator? wogiz
2016-04-05 23:57 ` Mihai Donțu
2016-05-04 16:02 ` Jan Beulich
@ 2016-05-18 9:12 ` Jan Beulich
2016-05-20 16:44 ` William Z.
2 siblings, 1 reply; 19+ messages in thread
From: Jan Beulich @ 2016-05-18 9:12 UTC (permalink / raw)
To: wogiz; +Cc: Andrew Cooper, xen-devel
>>> On 06.04.16 at 01:38, <wogiz@openmailbox.org> wrote:
> I'm running Xen 4.6.1 with Alpine Linux 3.3.3 in dom0. In a HVM domU
> with vga="qxl", Xorg will segfault instantly if tried started. Multiple
> Linux distros have been tested and Xorg segfaults in all.
>
> Attached are a full backtrace from domU generated by Xorg, and a
> assembler dump of function 'sse2_blt'.
Just FYI: Looks like I can repro this finally, and it also looks like at
least for me it isn't an SSE2 instruction that the issue is with.
Instead I'm getting an #UD in the middle of an instruction a few
lines down from the last SSE2 one, which suggests we're having
an issue with sizing instructions (however odd that may seem).
Now that I can repro it, at least I have something to actually
debug ...
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bug in x86 instruction emulator?
2016-05-18 9:12 ` Jan Beulich
@ 2016-05-20 16:44 ` William Z.
0 siblings, 0 replies; 19+ messages in thread
From: William Z. @ 2016-05-20 16:44 UTC (permalink / raw)
To: Jan Beulich; +Cc: Andrew Cooper, xen-devel
[-- Attachment #1: Type: text/plain, Size: 2232 bytes --]
On 2016-05-18 11:12, Jan Beulich wrote:
>>>> On 06.04.16 at 01:38, <wogiz@openmailbox.org> wrote:
>> I'm running Xen 4.6.1 with Alpine Linux 3.3.3 in dom0. In a HVM domU
>> with vga="qxl", Xorg will segfault instantly if tried started.
>> Multiple
>> Linux distros have been tested and Xorg segfaults in all.
>>
>> Attached are a full backtrace from domU generated by Xorg, and a
>> assembler dump of function 'sse2_blt'.
>
> Just FYI: Looks like I can repro this finally, and it also looks like
> at
> least for me it isn't an SSE2 instruction that the issue is with.
> Instead I'm getting an #UD in the middle of an instruction a few
> lines down from the last SSE2 one, which suggests we're having
> an issue with sizing instructions (however odd that may seem).
> Now that I can repro it, at least I have something to actually
> debug ...
>
> Jan
I have patched Xen 4.6.1 with commit
2bb230972c5ddb1ca823f47750b5d46a9d302d0e
(x86emul: suppress writeback upon unsuccessful MMX/SSE/AVX insn
emulation) and
tested with different Linux distros. I can say with confidence that the
patch
has solved my initial problem as Xorg no longer segfaults when started.
Thanks
to everyone that has helped with this.
However, while testing I have found a new problem. This may not be
related to
my initial problem or even Xen, but I will try to describe it here as
I'm hoping
someone can point me in the right direction.
Various actions will now raise the CPU usage of Xorg to 100% and freeze
the
entire X Window System for some time. E.g.:
Starting xterm in a window manager or directly from .xinitrc and
executing
dmesg. This will print a few lines per second while the Xorg CPU usage
is 100%
and the X Window System is frozen for about 60 seconds until all dmesg
output
has been printed.
I have run 'perf record -g -a sleep 60' while connected via SSH and then
executed dmesg in xterm. I have attached a few lines of 'perf report -g'
with
the first one expanded.
I have also run 'strace -p $(pidof Xorg)' while dmesg was running in
xterm. The
lines I have attached will repeat until all dmesg output has been
printed. File
descriptor 8 is pointing on '/dev/dri/card0'.
Any ideas on what could cause this?
William Z.
[-- Attachment #2: perf_report.txt --]
[-- Type: text/plain, Size: 1485 bytes --]
Samples: 239K of event 'cpu-clock', Event count (approx.): 59992000000
Children Self Command Shared Object Symbol
- 98.63% 98.53% Xorg libpixman-1.so.0.33.6 [.] sse2_blt.part.0
- sse2_blt.part.0
- 0.10% xen_hvm_callback_vector
xen_evtchn_do_upcall
irq_exit
__do_softirq
run_timer_softirq
call_timer_fn
rh_timer_func
- usb_hcd_poll_rh_status
- 0.10% uhci_hub_status_data
_raw_spin_unlock_irqrestore
0.00% mod_timer
- 0.00% retint_user
prepare_exit_to_usermode
exit_to_usermode_loop
schedule
__schedule
finish_task_switch
+ 0.57% 0.00% Xorg [kernel.kallsyms] [k] entry_SYSCALL_64_fastpath
+ 0.51% 0.00% Xorg libc-2.23.so [.] __GI___ioctl
+ 0.51% 0.00% Xorg [kernel.kallsyms] [k] sys_ioctl
+ 0.51% 0.00% swapper [kernel.kallsyms] [k] rest_init
+ 0.51% 0.00% swapper [kernel.kallsyms] [k] start_kernel
+ 0.51% 0.00% swapper [kernel.kallsyms] [k] x86_64_start_reservations
+ 0.51% 0.00% swapper [kernel.kallsyms] [k] x86_64_start_kernel
+ 0.50% 0.00% swapper [kernel.kallsyms] [k] cpu_startup_entry
+ 0.50% 0.00% Xorg [kernel.kallsyms] [k] do_vfs_ioctl
[-- Attachment #3: strace.txt --]
[-- Type: text/plain, Size: 4554 bytes --]
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
rt_sigreturn({mask=[]}) = 140000965392016
ioctl(8, DRM_IOCTL_QXL_ALLOC, 0x7ffce28a6780) = 0
ioctl(8, DRM_IOCTL_QXL_MAP, 0x7ffce28a6780) = 0
mmap(NULL, 13436, PROT_READ|PROT_WRITE, MAP_SHARED, 8, 0x107931000) = 0x7f5489ddb000
ioctl(8, DRM_IOCTL_QXL_ALLOC, 0x7ffce28a6780) = 0
ioctl(8, DRM_IOCTL_QXL_MAP, 0x7ffce28a6780) = 0
mmap(NULL, 48, PROT_READ|PROT_WRITE, MAP_SHARED, 8, 0x107935000) = 0x7f5489dda000
ioctl(8, DRM_IOCTL_QXL_EXECBUFFER, 0x7ffce28a6830) = 0
munmap(0x7f5489ddb000, 13436) = 0
ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffce28a6800) = 0
munmap(0x7f5489dda000, 48) = 0
ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffce28a6860) = 0
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
select(512, [1 3 4 5 6 9], NULL, NULL, {0, 0}) = 0 (Timeout)
setitimer(ITIMER_REAL, {it_interval={0, 5000}, it_value={0, 5000}}, NULL) = 0
clock_gettime(CLOCK_MONOTONIC, {5298, 406984775}) = 0
ioctl(8, DRM_IOCTL_QXL_UPDATE_AREA, 0x7ffce28a6820) = 0
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
rt_sigreturn({mask=[]}) = 140000965411184
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
rt_sigreturn({mask=[]}) = 140000965435536
ioctl(8, DRM_IOCTL_QXL_ALLOC, 0x7ffce28a6780) = 0
ioctl(8, DRM_IOCTL_QXL_MAP, 0x7ffce28a6780) = 0
mmap(NULL, 4700, PROT_READ|PROT_WRITE, MAP_SHARED, 8, 0x107936000) = 0x7f5489ddd000
ioctl(8, DRM_IOCTL_QXL_ALLOC, 0x7ffce28a6780) = 0
ioctl(8, DRM_IOCTL_QXL_MAP, 0x7ffce28a6780) = 0
mmap(NULL, 48, PROT_READ|PROT_WRITE, MAP_SHARED, 8, 0x107938000) = 0x7f5489ddc000
ioctl(8, DRM_IOCTL_QXL_EXECBUFFER, 0x7ffce28a6830) = 0
munmap(0x7f5489ddd000, 4700) = 0
ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffce28a6800) = 0
munmap(0x7f5489ddc000, 48) = 0
ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffce28a6860) = 0
clock_gettime(CLOCK_MONOTONIC, {5298, 419896630}) = 0
ioctl(8, DRM_IOCTL_QXL_UPDATE_AREA, 0x7ffce28a6820) = 0
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
rt_sigreturn({mask=[]}) = 140000965399104
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
rt_sigreturn({mask=[]}) = 140000965415424
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
rt_sigreturn({mask=[]}) = 140000965431744
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
rt_sigreturn({mask=[]}) = 140000965444432
ioctl(8, DRM_IOCTL_QXL_ALLOC, 0x7ffce28a6780) = 0
ioctl(8, DRM_IOCTL_QXL_MAP, 0x7ffce28a6780) = 0
mmap(NULL, 6260, PROT_READ|PROT_WRITE, MAP_SHARED, 8, 0x107939000) = 0x7f5489ddd000
ioctl(8, DRM_IOCTL_QXL_ALLOC, 0x7ffce28a6780) = 0
ioctl(8, DRM_IOCTL_QXL_MAP, 0x7ffce28a6780) = 0
mmap(NULL, 48, PROT_READ|PROT_WRITE, MAP_SHARED, 8, 0x10793b000) = 0x7f5489ddc000
ioctl(8, DRM_IOCTL_QXL_EXECBUFFER, 0x7ffce28a6830) = 0
munmap(0x7f5489ddd000, 6260) = 0
ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffce28a6800) = 0
munmap(0x7f5489ddc000, 48) = 0
ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffce28a6860) = 0
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
select(512, [1 3 4 5 6 9], NULL, NULL, {0, 0}) = 0 (Timeout)
setitimer(ITIMER_REAL, {it_interval={0, 5000}, it_value={0, 5000}}, NULL) = 0
clock_gettime(CLOCK_MONOTONIC, {5298, 437495822}) = 0
ioctl(8, DRM_IOCTL_QXL_UPDATE_AREA, 0x7ffce28a6820) = 0
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
rt_sigreturn({mask=[]}) = 140000965400096
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
rt_sigreturn({mask=[]}) = 140000965408032
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
rt_sigreturn({mask=[]}) = 140000965415904
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
rt_sigreturn({mask=[]}) = 140000965420832
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
rt_sigreturn({mask=[]}) = 140000965428768
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
rt_sigreturn({mask=[]}) = 140000965436640
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
rt_sigreturn({mask=[]}) = 140000965444576
ioctl(8, DRM_IOCTL_QXL_ALLOC, 0x7ffce28a6780) = 0
ioctl(8, DRM_IOCTL_QXL_MAP, 0x7ffce28a6780) = 0
mmap(NULL, 14060, PROT_READ|PROT_WRITE, MAP_SHARED, 8, 0x10793d000) = 0x7f5489ddb000
ioctl(8, DRM_IOCTL_QXL_ALLOC, 0x7ffce28a6780) = 0
ioctl(8, DRM_IOCTL_QXL_MAP, 0x7ffce28a6780) = 0
mmap(NULL, 48, PROT_READ|PROT_WRITE, MAP_SHARED, 8, 0x107941000) = 0x7f5489dda000
ioctl(8, DRM_IOCTL_QXL_EXECBUFFER, 0x7ffce28a6830) = 0
[-- Attachment #4: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2016-05-20 16:44 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-04-05 23:38 Bug in x86 instruction emulator? wogiz
2016-04-05 23:57 ` Mihai Donțu
2016-04-06 0:02 ` Mihai Donțu
2016-04-06 1:48 ` wogiz
2016-04-06 1:26 ` wogiz
2016-04-06 8:55 ` Andrew Cooper
2016-04-07 1:26 ` wogiz
2016-04-07 2:04 ` Jan Beulich
2016-04-08 1:43 ` wogiz
2016-04-15 17:33 ` wogiz
2016-04-15 17:44 ` Andrew Cooper
2016-04-16 4:06 ` wogiz
2016-05-04 16:02 ` Jan Beulich
2016-05-04 16:04 ` Wei Liu
2016-05-04 16:06 ` Andrew Cooper
2016-05-17 16:53 ` William Z.
2016-05-17 17:03 ` Andrew Cooper
2016-05-18 9:12 ` Jan Beulich
2016-05-20 16:44 ` William Z.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).