>From: Magenheimer, Dan
>Sent: 2006年1月11日 3:26
Hi, Dan,
Good background for discussion.
>[...]
>an ugly hack. Some believe that the best way to solve this mess
>is for other architectures to do things more like Xen/x86. Others
>believe there is an advantage to defining clear abstractions and
>making the drivers truly more architecture-independent.
I would say two options above don't conflict actually. ;-) Move to Xen/x86 for
things really common with clearer abstraction for architecture difference. We
need carefully differentiate which part of mess really comes from arch reason,
and which part is common but simply missed due to early quick bring-up
requirement. I don't think this is enough cared by far. Xen, as a well-formed
product, needs to have common policies and common features on all
architectures. Maybe, to implement same features can be more difficult and even
bring some performance impact on some architecture, but it's a must-to-have
requirement from customer's point of view if customer acknowledges it. Just
raise it here as an important factor when considering the final solution
cross-architecture.
>[...]
>XENLINUX IMPACT
>
>Xen in sync. OS code that manipulates physical addresses must be
>modified to access/manage this table and make hypercalls when
>appropriate. Macros can hide much of the complexity but much OS/driver
>code exists that does not use standard macros. There is some
This seems to be an issue for driver modules to be re-compiled... ;-(
>Transparent paravirtualization (also called "shared binary") is the
>ability for the same binary to be used both as a Xen guest and
>natively on real hardware. Xenlinux/ia64 currently support this;
>indeed, ignoring a couple of existing bugs, the same Xenlinux/ia64
>binary can be used natively, and as domain0 and as an unprivileged
>domain. There have been proposals to do the same for Xenlinux/x86,
>but the degree of code changed is much much higher. There is debate
>about the cost/benefit of transparent paravirtualization, but the
>primary beneficiaries -- distros and end customers -- are not very
>well represented here.
Transparent is welcomed, which however doesn't mean conservative
self-restriction upon modification to xenlinux. Transparent with good
performance is the goal to pursue, though xenlinux/x86 does need more efforts
to make it happen.
>
>With P2M, it is unlikely that Xenlinux/ia64 will ever again be
>transparently paravirtualizable. As with Xenlinux/x86, the changes
>will probably be pushed into a subarch (mach-xen).
First sub-arch, and further a configurable feature later with negligible impact
to native running? ;-)
>[...]
>
>Some believe that discovery and policy for machine memory will
>eventually need to move out of Xen into domain0, leaving only
>enforcement mechanism in Xen. For example, oversubscription, NUMA
>or hot-plug memory support are likely to be fairly complicated
>and a commonly stated goal is to move unnecessary complexity out
>of Xen. And the plethora of recent changes in Linux/ia64
>involving machine memory models indicates there are still many
>unknowns. P==M more easily supports a model where domain0
>owns ALL of machine memory *except* a small amount reserved for
>and protected by Xen itself. If this is all true, Xen/x86 may
>eventually need to move to a dom0 P==M model, in which case it
>would be silly for Xen/ia64 to move to P2M and then back to P==M.
I don't think it's a good design choice by complete takeover to dom0. Moving
ownership to dom0 doesn’t mean a simple move, since memory sub-system is the
core/base of Xen. Extra context switches are added for any page related
operation. Also by P==M model, how do you ensure a scalable allocation
environment after a long run? Any activities within dom0 which consumes
Physical frames, thus actually eats Machine frames. Security will be another
issue though I can't come out a clear example immediately...
>
>SUMMARY
>[...]
This summary is good.
Thanks,
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home