Bug in x86 instruction emulator?

Bug in x86 instruction emulator?

[wogiz]

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

Re: Bug in x86 instruction emulator?

[Mihai Donțu]

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

Re: Bug in x86 instruction emulator?

[Mihai Donțu]

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

Re: Bug in x86 instruction emulator?

[wogiz]

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

Re: Bug in x86 instruction emulator?

[wogiz]

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

Re: Bug in x86 instruction emulator?

[Andrew Cooper]

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

Re: Bug in x86 instruction emulator?

[wogiz]

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

Re: Bug in x86 instruction emulator?

[Jan Beulich]

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

Re: Bug in x86 instruction emulator?

[wogiz]

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

Re: Bug in x86 instruction emulator?

[wogiz]

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

Re: Bug in x86 instruction emulator?

[Andrew Cooper]

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

Re: Bug in x86 instruction emulator?

[wogiz]

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

Re: Bug in x86 instruction emulator?

[Jan Beulich]

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

Re: Bug in x86 instruction emulator?

[Wei Liu]

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

Re: Bug in x86 instruction emulator?

[Andrew Cooper]

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

Re: Bug in x86 instruction emulator?

[William Z.]

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

Re: Bug in x86 instruction emulator?

[Andrew Cooper]

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

Re: Bug in x86 instruction emulator?

[Jan Beulich]

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

Re: Bug in x86 instruction emulator?

[William Z.]

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