RE: [Xen-devel] Essay on an important Xen decision (long)

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>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