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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home