Re: [DRAFT C] PVH CPU hotplug design document

From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Graeme Gregory <graeme.gregory@linaro.org>,
	Al Stone <al.stone@linaro.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Anshul Makkar <anshul.makkar@citrix.com>,
	JulienGrall <julien.grall@arm.com>,
	Paul Durrant <paul.durrant@citrix.com>,
	xen-devel@lists.xenproject.org,
	BorisOstrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [DRAFT C] PVH CPU hotplug design document
Date: Mon, 23 Jan 2017 17:12:17 +0000	[thread overview]
Message-ID: <20170123171217.khxa4bamrggfefgi@dhcp-3-221.uk.xensource.com> (raw)
In-Reply-To: <588643870200007800133031@prv-mh.provo.novell.com>

On Mon, Jan 23, 2017 at 09:55:19AM -0700, Jan Beulich wrote:
> >>> On 23.01.17 at 17:42, <roger.pau@citrix.com> wrote:
> > On Mon, Jan 23, 2017 at 09:30:30AM -0700, Jan Beulich wrote:
> >> >>> On 17.01.17 at 18:14, <roger.pau@citrix.com> wrote:
> >> > This can be solved by using a different ACPI name in order to describe vCPUs in
> >> > the ACPI namespace. Most hardware vendors tend to use CPU or PR prefixes for
> >> > the processor objects, so using a 'VP' (ie: Virtual Processor) prefix should
> >> > prevent clashes.
> >> 
> >> I continue to think that this is insufficient, without seeing a nice
> >> clean way to solve the issue properly.
> > 
> > But in this document the namespace path for processor objects will be
> > _SB.XEN0.VPXX, which should prevent any namespace clashes. Maybe I should have
> > updated the wording here, every Xen-related ACPI bit will be inside the
> > _SB.XEN0 namespace.
> 
> Well, if we want to introduce our own parent name space, why the
> special naming convention then? Any name not colliding with other
> things in _SB.XEN0 should do then, so the only remaining risk would
> then be that the firmware also has _SB.XEN0.

Right, that's why I say that I should have reworded this. We can then use PXXX,
CXXX or whatever we want.

Yes, the only remaining risk is some vendor using _SB.XEN0, and AFAICT there's
no way to reserve anything in there (mostly because it's assumed that ACPI
tables will be created by a single entity I guess).

I think that the chance of this happening is 0%, and that there's no single
system out there with a _SB.XEN0 node. I've been wondering whether I should try
to post this to the ACPI working group, and try to get some feedback there.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel