|
|
|
|
|
|
|
|
|
|
xen-devel
Re: Guest-visible phys2mach part of Xen arch-neutral API? was: [Xen-deve
On 29 Dec 2005, at 18:51, Magenheimer, Dan (HP Labs Fort Collins) wrote:
So then is p==m in dom0 (and driver domains) an unacceptable design
alternative for (non-x86) Xen architectures? If it is acceptable,
then the question remains:
I think *that* is the critical question here. My feeling is that having
p==m for any domain (even domain0) may have a siginificant effect on
the amount of otherwise arch-indep xenlinux code you can share. My
feeling is therefore that dom0 should be like any domU and have
virtualised p (!= m). This is somewhat a gut feeling though -- perhaps
something to discuss and think about at the summit?
It's true that p!=m in a driver domain is a bit more of a pain than
p==m, but a lot of the work has been done for x86/xen and I think can
be used by other architectures.
So the question becomes: Should Xen drivers be made more portable
to accommodate architectures where a guest-visible phys2mach table
is NOT required for paravirtualizing the architecture? Or should
Linux code for each architecture that is ported to Xen be modified
to utilize data structures that are only really necessary for x86?
This I care less about. If we decide that even driver domains will have
p!=m, you will certainly need some way to get at m, but I think whether
that is via an array mapped into the guest's address space or by some
other means (e.g., hypercall) is an implementation detail that can vary
across architectures.
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|