29 messages in com.xensource.lists.xen-develRe: Guest-visible phys2mach part of X...| Subject: | Re: Guest-visible phys2mach part of Xen arch-neutral API? was: [Xen-devel] Uses of &frame_table[xfn] |
|---|---|
| From: | Keir Fraser (Keir...@cl.cam.ac.uk) |
| Date: | 12/29/2005 12:33:59 PM |
| List: | com.xensource.lists.xen-devel |
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-...@lists.xensource.com http://lists.xensource.com/xen-devel