On 07/30/09 08:37, Len Brown wrote: > 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? > The basic idea is that Xen controls the things it must, and leaves everything else to guest kernels. At heart that means it controls the physical CPUs (which includes things like local APICs) and memory (by maintaining control over the CPU's paging hardware via the pagetables). Everything beyond that is left to guest domains which handle various responsibilities; informally we refer to "dom0" which is "the" privileged domain which handles things like hardware discovery, device drivers, domain creation, and a number of other services. However there's no inherent reason why all these jobs must be aggregated together. For example, there's active work on having specific "driver domains" which have responsibility for a specific piece of hardware or class of hardware, but don't (and can't) do any of the other "privileged" jobs. > 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... > There are some parallels, and there's even a paper with a title something like "hypervisors: microkernels done right". I think the rough sketch of the argument is that a Mach-like system with lots of server processes fails in practise because its a poor match for the APIs that people actually want to use and are used to, and if you want Unix-like functionality then you just need to put a Unix in there. Xen's breakdown is more along the lines of the hardware architecture itself, and therefore is in some sense more "natural": kernels which run processes are real kernels, with the full programming interfaces everyone wants to use; shared resources like CPU and memory can be multiplexed fairly easily using well-understood techniques; with some extra work, you can even let guest domains have direct hardware access using their normal device drivers so that the hypervisor doesn't need to deal with them. ACPI - which wears many hats affecting many aspects of the system - doesn't have any neat dividing lines, and doesn't follow the contours of the underlying architecture, and so appears to be a poor match for a Xen-like model. If it were possible to partition ACPI into broad function groupings, then maybe it would be possible to get a better fit, but I'm not sure whether that's possible. In general Xen doesn't have much use for ACPI; aside from this specific case of needing to know how to control the CPUs for power management, it doesn't really care about ACPI's services. It doesn't do interrupt routing, it doesn't really need to know about thermal management, any anything it does need to know it can be told by the kernel which does have a much greater interest in ACPI. S3 suspend/resume needs to go via Xen for the final stage, but aside from that it can all be handled in Linux. J -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html