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?



---- On Wed, 25 Jan 2017 12:35:14 +0300 Akshay Jaggi <> 
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.



On Jan 24, 2017 16:56, Roger Pau Monné <> 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, 

    at async.c:254

#6  0x0000000802e3903b in g_main_context_dispatch () from 

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


_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to