From owner-freebsd-xen@freebsd.org Tue Jan 24 16:56:45 2017 Return-Path: Delivered-To: freebsd-xen@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E82ACCBF065 for ; Tue, 24 Jan 2017 16:56:45 +0000 (UTC) (envelope-from prvs=19068b32a=roger.pau@citrix.com) Received: from SMTP.EU.CITRIX.COM (smtp.ctxuk.citrix.com [185.25.65.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "DigiCert SHA2 Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F089972; Tue, 24 Jan 2017 16:56:44 +0000 (UTC) (envelope-from prvs=19068b32a=roger.pau@citrix.com) X-IronPort-AV: E=Sophos;i="5.33,278,1477958400"; d="scan'208";a="39293574" Date: Tue, 24 Jan 2017 16:56:21 +0000 From: =?iso-8859-1?Q?=22Roger_Pau_Monn=E9=22?= To: Alexander Nusov CC: , Subject: Re: Xen on FreeBSD 11: Cannot boot from QCOW2 properly (waiting for XENBUS, xenbusb_nop_confighook_cb) Message-ID: <20170124165621.iidjypfoyp4ccysi@dhcp-3-221.uk.xensource.com> References: <20170124114444.xdl3qj35lwebkso7@dhcp-3-221.uk.xensource.com> <159d0f04b55.10bbf935114648.7927688075504705395@nfvexpress.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <159d0f04b55.10bbf935114648.7927688075504705395@nfvexpress.com> User-Agent: NeoMutt/20170113 (1.7.2) X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 16:56:46 -0000 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/)] [New Thread 807418800 (LWP 100945/)] [New Thread 807418300 (LWP 100944/)] [New Thread 807417e00 (LWP 100943/)] [New Thread 807417900 (LWP 100942/)] [New Thread 807417400 (LWP 100941/)] [New Thread 807416a00 (LWP 100940/)] [New Thread 807416500 (LWP 100939/)] [New Thread 807416000 (LWP 100091/)] (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.