Re: [Xen-devel] [DRAFT C] PVH CPU hotplug design document

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.01.17 at 18:12, <roger.pau@xxxxxxxxxx> wrote:
> On Mon, Jan 23, 2017 at 09:55:19AM -0700, Jan Beulich wrote:
>> >>> On 23.01.17 at 17:42, <roger.pau@xxxxxxxxxx> wrote:
>> > On Mon, Jan 23, 2017 at 09:30:30AM -0700, Jan Beulich wrote:
>> >> >>> On 17.01.17 at 18:14, <roger.pau@xxxxxxxxxx> 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).

Right.

> 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.

As you've said during some earlier discussion, it won't hurt to give
this a try.

Jan


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