29 messages in com.xensource.lists.xen-develRE: Guest-visible phys2mach part of X...
FromSent OnAttachments
Magenheimer, Dan (HP Labs Fort Collins)18 Dec 2005 19:18 
Ian Pratt18 Dec 2005 20:23 
Magenheimer, Dan (HP Labs Fort Collins)22 Dec 2005 15:28 
Ewan Mellor23 Dec 2005 02:28 
Keir Fraser23 Dec 2005 03:46 
Magenheimer, Dan (HP Labs Fort Collins)23 Dec 2005 05:05 
Magenheimer, Dan (HP Labs Fort Collins)23 Dec 2005 05:27 
Keir Fraser23 Dec 2005 06:37 
Ewan Mellor23 Dec 2005 07:27 
Magenheimer, Dan (HP Labs Fort Collins)23 Dec 2005 12:33 
Tian, Kevin26 Dec 2005 01:12 
Magenheimer, Dan (HP Labs Fort Collins)28 Dec 2005 14:15 
Muli Ben-Yehuda28 Dec 2005 14:23 
Magenheimer, Dan (HP Labs Fort Collins)28 Dec 2005 14:30 
Magenheimer, Dan (HP Labs Fort Collins)28 Dec 2005 14:42 
Cihula, Joseph28 Dec 2005 17:49 
Tian, Kevin28 Dec 2005 17:58 
Keir Fraser29 Dec 2005 05:47 
Magenheimer, Dan (HP Labs Fort Collins)29 Dec 2005 08:12 
Keir Fraser29 Dec 2005 08:15 
Magenheimer, Dan (HP Labs Fort Collins)29 Dec 2005 10:51 
Keir Fraser29 Dec 2005 12:33 
Magenheimer, Dan (HP Labs Fort Collins)29 Dec 2005 13:38 
Tian, Kevin29 Dec 2005 18:15 
Ewan Mellor30 Dec 2005 05:40 
Kevin Fox30 Dec 2005 08:35 
Magenheimer, Dan (HP Labs Fort Collins)30 Dec 2005 11:49 
Mark Williamson02 Jan 2006 11:22 
Hollis Blanchard03 Jan 2006 13:54 
Subject:RE: Guest-visible phys2mach part of Xen arch-neutral API? was: [Xen-devel] Uses of &frame_table[xfn]
From:Tian, Kevin (kevi@intel.com)
Date:12/28/2005 05:58:54 PM
List:com.xensource.lists.xen-devel

From: Magenheimer, Dan (HP Labs Fort Collins) [mailto:dan.@hp.com]

Sent: 2005年12月29日 6:43

All such troubles come from no phys2mach mapping table within ia64 dom0! So Dan, maybe it's time to revise current ia64 xenlinux design to make life easier. ;-)

This is an important question. In my opinion, it may make life easier to mimic the x86 memory management scheme. But I believe one of the roles of Xen/ia64 as the first non-x86 port is to identify code existing in Xen and Xenlinux that is x86-specific and help to define a better architecture- independent interface. I think the whole concept of a guest-visible phys2mach table is a necessary evil on x86 because the guest writes page tables that are walked by hardware. This is of questionable use on other architectures (and even on x86 in full shadow mode?).

Question for core Xen developers and other arch Xen developers:

As we evolve toward architecture-neutral APIs within Xen, within paravirtualized Xenlinux, and between Xen and paravirtualized Xenlinux, should a guest-visible physical-to- machine mapping table be a necessary part of the arch-neutral API? Or is this concept a useful mechanism for the x86 family only that should not be propagated to other Xen architectures?

Hi, Dan, IMO, I see the phys2mach mapping as a basic virtualization policy, instead of
an architecture specific requirement. After adding phys2mach concept to
XEN/IA64, we can reuse more common code without ifdef. Then correspondingly also
need to add several necessary changes like x86: DMA, SWIOTLB, AGP, etc, to
ensure legal machine address written into physical devices.

For writable page table, it's safe to skip it now even after adding phys2mach,
since software managed page table is not walked by IA64 processor directly.
Later we may evaluate necessity and performance gain after most things done.

With major policy consistent and more code shared, XEN/IA64 then can really
help XEN better run on more architectures. ;-)

Thanks, Kevin

_______________________________________________ Xen-devel mailing list Xen-@lists.xensource.com http://lists.xensource.com/xen-devel