Keir Fraser wrote:
> On 12/02/2010 09:25, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:
>>> I'd be a bit more comfortable if we had the cover of lots of other
>>> modern systems putting their processor objects under \_SB, but
>>> actually I've never seen one. Then again I haven't been looking at
>>> high-end systems supporting CPU hotplug and the like.
>> Yes. I only saw \_SB definition in system supporting CPU hotplug. In
>> fact, in that system, the processor is defined under an container
>> object in \_SB. As currently all system in our lab is shutdown for
>> CNY, I can't find more system to check. And I suspect that we need
>> care \_PR soluation, legacy OS support is an important usage model
>> for virtualization.
>> One thing I noticed in my system is, there is a ACPI version option
>> in my desktop system, and I remember I saw that option in other
>> system also. So one possible solution is, place all processor
>> definition under a seperated SSDT file. An option is provided so
>> that build.c can select different SSDT based on user's input. But
>> that make thing tricky still.
> You can see that xen-unstable tip can do this now. But I don't want
> to start dumping in loads of alternative DSDTs, as each one is a fair
> size. What I'm hoping is that this Linux regression is fixed fairly
> swiftly, and we can hence ignore it. :-) If not, we can think about
> what to do.
> -- Keir
Yes, we hope so :)
Compared with linux 2.6.30, 2.6.32 change a lot at processor_hotplug path, but
still not clean to support \_PR processor, while both versions seems work well
for \_SB processor. Win2k8 is similar situation.
Xen-devel mailing list