Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb)

[Alexander Nusov]

Got it, thanks.



I found a workaround to avoid XENBUS delay in Linux DomUs by adding xen_platform_pci = 0 to the configuration file.

So FreeBSD 11.0 Dom0 can boot Linux guests and Windows Server (FreeBSD DomU still stuck on xenbusb_nop_confighook_cb) from QCOW2 images (also works with QCOW2 overlay images)



Can you tell me please what is the disadvantage of not using /dev/xen/vbd devices and drivers in guests? like slow I/O? 

May it lead to data corruption?


--

Alex




---- On Wed, 25 Jan 2017 12:35:14 +0300 Akshay Jaggi <jaggi at freebsd.org> wrote ----




Hi Alex and Roger,



Without the patch and FreeBSD 12, qcow2 doesn't actually work. We were thinking of adding code to warn against this, but then thought gntdev implementation is in process anyway.

With the patch, the crash needs to be investigated (because I did run one of the gntdev based image, most probably qcow2, iirc).

Sadly, I'm still searching for housing in Dublin, and hence won't be able to look at this immediately. Two weeks, to find and then move in, if I'm lucky. Meanwhile, I'll start hunting for a development machine in office.



Regards,

Akshay






On Jan 24, 2017 16:56, Roger Pau Monné <roger.pau at citrix.com> wrote:






On Tue, Jan 24, 2017 at 05:45:25PM +0300, Alexander Nusov wrote:

> Yes, it was FreeBSD 11.0-STABLE Dom0 with xen-kernel/xen-tools built from the ports tree (head)

>

>

>

> It seems there is an issue with xen pci devices, since booting from QCOW2 images actually works (even on FreeBSD 11.0-RELEASE branch) except communication with /xen/vbd devices from the guest.



Yes, I'm seeing exactly the same. The QEMU process is killed with a

segmentation fault. Akshay, here is the full debug output:



Program terminated with signal 11, Segmentation fault.

[...]

#0  blk_handle_requests (blkdev=0x807463c00) at hw/block/xen_disk.c:862

862         rp = blkdev->rings.common.sring->req_prod;

[New Thread 8087f9000 (LWP 100947/<unknown>)]

[New Thread 807418800 (LWP 100945/<unknown>)]

[New Thread 807418300 (LWP 100944/<unknown>)]

[New Thread 807417e00 (LWP 100943/<unknown>)]

[New Thread 807417900 (LWP 100942/<unknown>)]

[New Thread 807417400 (LWP 100941/<unknown>)]

[New Thread 807416a00 (LWP 100940/<unknown>)]

[New Thread 807416500 (LWP 100939/<unknown>)]

[New Thread 807416000 (LWP 100091/<unknown>)]

(gdb) bt

#0  blk_handle_requests (blkdev=0x807463c00) at hw/block/xen_disk.c:862

#1  0x00000000005f9dcd in blk_bh (opaque=0x807463c00) at hw/block/xen_disk.c:918

#2  0x000000000080ba69 in aio_bh_call (bh=0x80780d810) at async.c:87

#3  0x000000000080bb10 in aio_bh_poll (ctx=0x8074a0680) at async.c:115

#4  0x000000000081c099 in aio_dispatch (ctx=0x8074a0680) at aio-posix.c:303

#5  0x000000000080c2cd in aio_ctx_dispatch (source=0x8074a0680, callback=0, user_data=0x0)

    at async.c:254

#6  0x0000000802e3903b in g_main_context_dispatch () from /usr/local/lib/libglib-2.0.so.0

#7  0x000000000081a34c in glib_pollfds_poll () at main-loop.c:259

#8  0x0000000000819dc5 in os_host_main_loop_wait (timeout=0) at main-loop.c:306

#9  0x0000000000819c29 in main_loop_wait (nonblocking=0) at main-loop.c:556

#10 0x0000000000588ed7 in main_loop () at vl.c:1966

#11 0x0000000000583b59 in main (argc=38, argv=0x7fffffffe750, envp=0x7fffffffe888) at vl.c:4684

Current language:  auto; currently minimal



It seems like the device is not properly mapping the grants, and QEMU gets a

SEGFAULT when trying to access the ring page.



Roger.