From owner-freebsd-current@FreeBSD.ORG Mon Jan 6 09:47:52 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E871D49; Mon, 6 Jan 2014 09:47:52 +0000 (UTC) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E2A341819; Mon, 6 Jan 2014 09:47:34 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.95,611,1384300800"; d="scan'208";a="87823046" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 06 Jan 2014 09:46:52 +0000 Received: from [IPv6:::1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id 14.2.342.4; Mon, 6 Jan 2014 04:46:56 -0500 Message-ID: <52CA7B8F.9060402@citrix.com> Date: Mon, 6 Jan 2014 10:46:55 +0100 From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Julien Grall , , , , , , , Subject: Re: [Xen-devel] [PATCH v9 14/19] xen: introduce xenpv bus and a dummy pvcpu device References: <1388677433-49525-1-git-send-email-roger.pau@citrix.com> <1388677433-49525-15-git-send-email-roger.pau@citrix.com> <52C9D432.3040409@linaro.org> In-Reply-To: <52C9D432.3040409@linaro.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-DLP: MIA2 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: Mon, 06 Jan 2014 09:47:52 -0000 On 05/01/14 22:52, Julien Grall wrote: > > > On 01/02/2014 03:43 PM, Roger Pau Monne wrote: >> Since Xen PVH guests doesn't have ACPI, we need to create a dummy >> bus so top level Xen devices can attach to it (instead of >> attaching directly to the nexus) and a pvcpu device that will be used >> to fill the pcpu->pc_device field. >> --- >> sys/conf/files.amd64 | 1 + >> sys/conf/files.i386 | 1 + >> sys/x86/xen/xenpv.c | 155 >> ++++++++++++++++++++++++++++++++++++++++++++++++++ > > I think it makes more sense to have 2 files: one for xenpv bus and one > for a dummy pvcpu device. It would allow us to move xenpv bus to common > code (sys/xen or sys/dev/xen). Ack. I wasn't thinking other arches will probably use the xenpv bus but not the dummy cpu device. Would you agree to leave xenpv bus inside x86/xen for now and move the dummy PV cpu device to dev/xen/pvcpu/? > > [..] > >> + >> +static int >> +xenpv_probe(device_t dev) >> +{ >> + >> + device_set_desc(dev, "Xen PV bus"); >> + device_quiet(dev); >> + return (0); > > As I understand, 0 means I can "handle" the current device, in this case > if a device is probing, because it doesn't have yet a driver, we will > use xenpv and end up with 2 (or even more) xenpv buses. > > As we only want to probe xenpv bus once, when the bus was added > manually, returning BUS_PROBE_NO_WILDCARD would suit better. > > [..] > >> +static int >> +xenpvcpu_probe(device_t dev) >> +{ >> + >> + device_set_desc(dev, "Xen PV CPU"); >> + return (0); > > Same here: BUS_PROBE_NOWILDCARD. Ack for both, will change it to BUS_PROBE_NOWILDCARD. While at it, we should also change xenstore probe function to return BUS_PROBE_NOWILDCARD.