[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [DRAFT C] PVH CPU hotplug design document
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |