RE: [Xen-devel] [PATCH][pvops_dom0][2/4] Introduce the external control operation interface for domain0 ACPI parser

[Len Brown <lenb@kernel.org>]

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

I agree with Kevin that it would be a mistake to put ACPI both into
both dom0 and the hypervisor.  Frankly, on many levels, ACPI was
designed with Windows in mind, and the further an OS strays from
how Windows does things, the less likely you'll run well on many 
systems.  Obviously, Xen looks nothing like windows, or any other OS,
for it seems to have not one division between implementation and
policy, but multiple...

So I have a fundamental lack of understanding of the logic
behind the partitioning behind the hypervisor and dom0.
Maybe somebody explain it to me in terms that I'll understand?

It reminds me of the partitioning between the Mach microkernel
and the "user-space OS personality, eg Unix".  This looked really neat
in proposals for funding and academic papers, but in reality it turned
out to have little value other than employing programmers to
re-invent the wheel, only to discover that the original round
wheel was better than the square one that they produced...

-Len Brown, Intel Open Source Technology Center