Date: Wed, 25 Jan 2017 14:20:55 +0300 From: Alexander Nusov <alexander.nusov@nfvexpress.com> To: "Akshay Jaggi" <jaggi@freebsd.org> Cc: =?UTF-8?Q?=22Roger_Pau_Monn=C3=A9=22?= <roger.pau@citrix.com>, "FreeBSD-Xen" <freebsd-xen@freebsd.org> Subject: Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb) Message-ID: <159d55b6b65.dc9b3b1720453.5847395326743424395@nfvexpress.com> In-Reply-To: <CAAeUNV=j5-Sz00PQCvC6rX7QeiEpbhD9uRCFSnqKP-dUFxjB-g@mail.gmail.com> References: <A80956E3-F5A1-46BC-86C7-17BBF3DA8FB4@nfvexpress.com> <20170124114444.xdl3qj35lwebkso7@dhcp-3-221.uk.xensource.com> <159d0f04b55.10bbf935114648.7927688075504705395@nfvexpress.com> <20170124165621.iidjypfoyp4ccysi@dhcp-3-221.uk.xensource.com> <CAAeUNV=j5-Sz00PQCvC6rX7QeiEpbhD9uRCFSnqKP-dUFxjB-g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Got it, thanks.
I found a workaround to avoid XENBUS delay in Linux DomUs by adding xen_pla=
tform_pci =3D 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 wi=
th QCOW2 overlay images)
Can you tell me please what is the disadvantage of not using /dev/xen/vbd d=
evices and drivers in guests? like slow I/O?=20
May it lead to data corruption?
--
Alex
---- On Wed, 25 Jan 2017 12:35:14 +0300 Akshay Jaggi <jaggi@freebsd.org&=
gt; wrote ----
Hi Alex and Roger,
Without the patch and FreeBSD 12, qcow2 doesn't actually work. We were thin=
king of adding code to warn against this, but then thought gntdev implement=
ation is in process anyway.
With the patch, the crash needs to be investigated (because I did run one o=
f the gntdev based image, most probably qcow2, iirc).
Sadly, I'm still searching for housing in Dublin, and hence won't be able t=
o look at this immediately. Two weeks, to find and then move in, if I'm luc=
ky. Meanwhile, I'll start hunting for a development machine in office.
Regards,
Akshay
On Jan 24, 2017 16:56, Roger Pau Monn=C3=A9 <roger.pau@citrix.com> wr=
ote:
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 f=
rom the ports tree (head)
>
>
>
> It seems there is an issue with xen pci devices, since booting from QC=
OW2 images actually works (even on FreeBSD 11.0-RELEASE branch) except comm=
unication 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=3D0x807463c00) at hw/block/xen_disk.c:862
862 rp =3D 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=3D0x807463c00) at hw/block/xen_disk.c:862
#1 0x00000000005f9dcd in blk_bh (opaque=3D0x807463c00) at hw/block/xen_dis=
k.c:918
#2 0x000000000080ba69 in aio_bh_call (bh=3D0x80780d810) at async.c:87
#3 0x000000000080bb10 in aio_bh_poll (ctx=3D0x8074a0680) at async.c:115
#4 0x000000000081c099 in aio_dispatch (ctx=3D0x8074a0680) at aio-posix.c:3=
03
#5 0x000000000080c2cd in aio_ctx_dispatch (source=3D0x8074a0680, callback=
=3D0, user_data=3D0x0)
at async.c:254
#6 0x0000000802e3903b in g_main_context_dispatch () from /usr/local/lib/li=
bglib-2.0.so.0
#7 0x000000000081a34c in glib_pollfds_poll () at main-loop.c:259
#8 0x0000000000819dc5 in os_host_main_loop_wait (timeout=3D0) at main-loop=
.c:306
#9 0x0000000000819c29 in main_loop_wait (nonblocking=3D0) at main-loop.c:5=
56
#10 0x0000000000588ed7 in main_loop () at vl.c:1966
#11 0x0000000000583b59 in main (argc=3D38, argv=3D0x7fffffffe750, envp=3D0x=
7fffffffe888) 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?159d55b6b65.dc9b3b1720453.5847395326743424395>