From owner-freebsd-current@FreeBSD.ORG Tue Dec 24 15:51:14 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73E98DB9; Tue, 24 Dec 2013 15:51:14 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 49C8E1AD4; Tue, 24 Dec 2013 15:51:14 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 359C1B968; Tue, 24 Dec 2013 10:51:13 -0500 (EST) From: John Baldwin To: Roger Pau Monne Subject: Re: [PATCH v7 14/19] xen: introduce a dummy pvcpu device Date: Tue, 24 Dec 2013 10:35:18 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <1387479296-33389-1-git-send-email-roger.pau@citrix.com> <1387479296-33389-15-git-send-email-roger.pau@citrix.com> In-Reply-To: <1387479296-33389-15-git-send-email-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201312241035.18783.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 24 Dec 2013 10:51:13 -0500 (EST) Cc: xen-devel@lists.xen.org, julien.grall@citrix.com, freebsd-xen@freebsd.org, freebsd-current@freebsd.org, kib@freebsd.org, gibbs@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2013 15:51:14 -0000 On Thursday, December 19, 2013 1:54:51 pm Roger Pau Monne wrote: > Since Xen PVH guests doesn't have ACPI, we need to create a dummy > pvcpu device that will be used to fill the pcpu->pc_device field. Rather than have this hang directly off of nexus0, it might be better to create some sort of 'xenov0' device that takes the place of acpi0 and have the CPUs hang off of that. This is how the non-ACPI case works in the native case where the default nexus creates a 'legacy0' device that sits at the same spot in the device tree as acpi0. In sys/x86/legacy.c we create CPU devices that are a child of legacy0. In general the way the native code handes ACPI vs non-ACPI is to have a different nexus (as you've adopted) create a specific child bus (acpi0 vs legacy0). Drivers that want to only attach in one of the cases at the top- level then attach as children of those rather than children of 'nexus0'. This just adds an extra layer of protection to avoid the possibility of a top-level driver that is ACPI or non-ACPI specific being probed in the "wrong" case. Right now, all drivers that attach to 'nexus' aside from the top-level busses (acpi0 vs legacy0) are intended to work on any machine. I think the CPU driver itself looks fine, I would just encourage you to consider a xenpv0 device and to move anything PV specific to hang off of that rather than directly attaching to nexus0. -- John Baldwin