<Brown, Len> Wrote: > >So the xen hypervizor is responsible for power management decisions, >but it doesn't know how to talk to the power management >controls in the platform? > >Why is that a good idea? Your question is reasonable. there is also debate here before. People discuss if it is possible to add acpica stuff to xen hypervisor and let xen control the acpi completely. Unfortunately, this will lead dilemma here, i.e. some devices are controlled by dom0 and also need acpi info, e.g. battery, thermal, etc. and pci hotplug in dom0 is another example. Tian Kevin has detail description on this issue in the attached mail. On the other hand, the dom0 acpica approach has other benefit, i.e. current linux acpica stuff is pretty mature and has numerous bug fix. Leveraging acpica in linux kernel is more practical. So I would like to say it is a practical idea rather than a good idea. > >Does somebody expect all this dom0 stuff to really live >in the upstream linux kernel source tree? There are lots of discussion on the dom0 stuff acceptance, and I did not see decision yet. Anyway, I would like to make this patch as clean as possible, so that it can benefit both xen and kernel. > >I'd like the patch better if you > >s/extcntl/xen/ to make it clear why this code exists -- >or is there an expected "external control" other than Xen? > >-Len Ok, I can try this. BTW, besides this naming change, do you have other comment on the code? So that I can make it more clean. Best Regards Ke
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx on behalf of Tian, Kevin [kevin.tian@xxxxxxxxx] Sent: 2009Äê6ÔÂ20ÈÕÐÇÆÚÁù 16:58 To: Eric W. Biederman; Keir Fraser Cc: Jeremy Fitzhardinge; Xen-devel; the arch/x86 maintainers; Linux Kernel Mailing List; Ingo Molnar; Nakajima, Jun; H. Peter Anvin; Thomas Gleixner; Len Brown Subject: RE: [Xen-devel] Re: [PATCH RFC] x86/acpi: don't ignore I/O APICs just because there's no local APIC Attachments: ATT00001.txt >From: Eric W. Biederman >Sent: 2009Äê6ÔÂ20ÈÕ 16:22 > >Keir Fraser <keir.fraser@xxxxxxxxxxxxx> writes: > >> On 20/06/2009 00:44, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx> wrote: >> >>>> I assume that putting AML into Xen has been considered, but I don't >>>> anything about those deliberations. Keir? Jun? >>>> >>> >>> Yes, it was one of the options years ago. We did not do >that because Linux and >>> Solaris (as dom0) already had the AML interpreter and it's >overkill and >>> redundant to have such a large component in the Xen >hypervisor. Since the >>> hypervisor does most of the power management (i.e. P, C, >S-state, etc.) >>> getting the info from dom0 today, we might want to >reconsider the option. >> >> Yes, we could reconsider. However is there any stuff that >dom0 remains >> responsible for (e.g., PCI management, and therefore PCI >hotplug) where it >> would continue to need to be OSPM, interpreting certain AML >objects? In >> general how safe would it be to have two layered entities >both playing at >> being OSPM? > >Short of running the oddball acpi based drivers. I'm not familiar with >any acpi in the pci management. > PCIe hotplug is defined well by its own BUS spec. But conventional PCI hotplug is implemented all kinds of strange things. Some is through ACPI, and thus by moving ACPI into Xen, a new 'virtual' hotplug architecture has to be introduced into dom0 Linux. Or Xen needs to emulate some known interface but as said there's no common standard for PCI hotplug. What's worse is the docking station support which contains diverse legacy devices. How Xen pass those legacy device hotplug events into dom0 Linux become another gray area suffering from same question like whether IOAPIC needs to be changed for Xen... Above comes from the exclusive assumption that ACPI is removed from dom0 by moving into Xen. Another choice is to have two layered ACPI in both dom0 and Xen with dom0's ACPI virtualized a bit by Xen. However it's messy as ACPI encodes most stuff in its own AML encode as a gray box. Many ACPI methods talk to hardware bits internally even by hard coded I/O registers. You don't know whether one ACPI event should be handled by Xen or not, until some AML methods have been evaluated which then may already consume and change some device states and not reversible. Then Xen have to emulate those states when injecting a virtual ACPI event into dom0 as dom0 ACPI methods need to consume same states. However automatic generating emulation code for diverse ACPI implementations to me is far more complex than any discussion here. So the real trouble is ACPI , which encode all platform bits if they're not included in any existing BUS spec, such as power, thermal, processor, battery, PCI routing, hotplug, EC, etc. Some are owned by dom0 and some by Xen. However ACPI's AML encoding makes automatic division between two categories really difficult. Thanks, Kevin
