From owner-freebsd-xen@freebsd.org Thu Dec 22 10:14:18 2016 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 833AEC8A776 for ; Thu, 22 Dec 2016 10:14:18 +0000 (UTC) (envelope-from prvs=1579c2c41=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 C21B818A4; Thu, 22 Dec 2016 10:14:17 +0000 (UTC) (envelope-from prvs=1579c2c41=roger.pau@citrix.com) X-IronPort-AV: E=Sophos;i="5.33,387,1477958400"; d="scan'208";a="37291649" Date: Thu, 22 Dec 2016 10:13:44 +0000 From: Roger Pau =?iso-8859-1?Q?Monn=E9?= To: Colin Percival CC: FreeBSD Lists , John Baldwin Subject: Re: svn commit: r310177 - in head/sys: amd64/conf i386/conf Message-ID: <20161222101344.swlw37j2of7iiwm5@dhcp-3-221.uk.xensource.com> References: <201612162110.uBGLAbG3091898@repo.freebsd.org> <0100015923b8e2f4-689d4cb8-61d4-4634-8165-5a2c7bf537dd-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <0100015923b8e2f4-689d4cb8-61d4-4634-8165-5a2c7bf537dd-000000@email.amazonses.com> User-Agent: NeoMutt/20161126 (1.7.1) 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: Thu, 22 Dec 2016 10:14:18 -0000 On Wed, Dec 21, 2016 at 11:30:36PM +0000, Colin Percival wrote: > This commit breaks the Xen boot: > > panic: NULL pcpu device_t > > > cpuid = 0 > > > KDB: stack backtrace: > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff82233a20 > > > vpanic() at vpanic+0x186/frame 0xffffffff82233aa0 > > > kassert_panic() at kassert_panic+0x126/frame 0xffffffff82233b10 > > > xen_setup_cpus() at xen_setup_cpus+0x5b/frame 0xffffffff82233b50 > > > mi_startup() at mi_startup+0x118/frame 0xffffffff82233b70 > > > btext() at btext+0x2c > > > I'm assuming this means xenpvcpu_attach isn't running early enough; does > anyone have time to track this down and fix it? xen_intr_alloc_and_bind_ipi requires a non-NULL device_t, and with the changes to the AP startup code now xen_cpu_ipi_init gets called before the dummy pcpu devices are attached. I will try to find some time this afternoon/tomorrow in order to rework the ipi bind function so that it no longer requires a device_t (it seems kind of pointless anyway, since IPIs by definition always belong to the CPU package). Roger.