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

[Al Stone <al.stone@xxxxxxxxxx>]

On 02/07/2017 05:21 AM, Roger Pau Monné wrote:
> Hello Al,
> 
> Thanks for your comments, please see below.
> 
> On Mon, Feb 06, 2017 at 04:06:45PM -0700, Al Stone wrote:
>> On 01/24/2017 07:20 AM, Boris Ostrovsky wrote:
[snip....]

>> Then it gets messy :).  The APIC and/or x2APIC subtables of the MADT are not
>> likely to exist on arm64; chances are just about zero, actually.  There are
>> other similar MADT subtables for arm64, but APIC, x2APIC and many more just
>> won't be there.  There is some overlap with ia64, but not entirely.
> 
> ia64 is also out of the picture here, the more that Xen doesn't support it, 
> and
> it doesn't look like anyone is working on it.

Aw.  That's kind of sad.  I worked on Xen/ia64 briefly many, many moons ago.

Yeah, there are arch differences.  Once you have the x86 side going, though, I
think adding in arm64 wouldn't be too bad; they're a little simpler, in some
respects.

>> The other issue is that a separate name space for the added CPUs would have
>> to be very carefully done.  If not, then the processor hierarchy information
>> in the AML either becomes useless, or at the least inconsistent, and OSPMs
>> are just now beginning to use some of that info to make scheduling decisions.
>> It would be possible to just assume the hot plug CPUs are outside of any
>> existing processor hierarchy, but I would then worry that power management
>> decisions made by the OSPM might be wrong; I can imagine a scenario where
>> a CPU is inserted and shares a power rail with an existing CPU, but the
>> existing CPU is idle so it decides to power off since it's the last in the
>> hierarchy, so the power rail isn't needed, and now the power gets turned off
>> to the unit just plugged in because the OSPM doesn't realize it shares power.
> 
> Well, my suggestion was to add the processor objects of the virtual CPUs 
> inside
> an ACPI Module Device that has the _SB.XEN0 namespace. However, AFAIK there's
> no way to reserve the _SB.XEN0 namespace, so a vendor could use that for
> something else. I think the chances of that happening are very low, but it's
> not impossible.
> 
> Is there anyway in ACPI to reserve a namespace for a certain usage? (ie: would
> it be possible to somehow reserve _SB.XEN0 for Xen usage?)

The only really reserved namespace is "_XXX".  The rest is fair game; since one
can only use four characters, I suspect there will be some reluctance to set
aside more.

There are the top-level names (mostly just \_SB these days).  Maybe a top level
\_XEN or \_VRT could work, perhaps with some fairly strict rules on what can be
in that subspace.  I think the issue at that point would be whether or not this
is a solution to a general problem, or if it is something that affects only Xen.

> Or if we want to go more generic, we could reserve _SB.VIRT for generic
> hypervisor usage.

Right.  And this would be one of the key questions from ASWG -- can it be
generalized?

> [snip...] 
> I'm also a member of the ACPI working group, and I was planning to send this
> design document there for further discussion, just haven't found the time yet
> to write a proper mail :(.
> 
> Roger.
> 

No worries.  Getting things started is not too bad; it's the discussion after
that can go on for a while :-).

-- 
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Linaro Enterprise Group
al.stone@xxxxxxxxxx
-----------------------------------

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