RFC: Guest-visible phys2mach part of Xen arch-neutral API? was: [Xen-devel] Uses of &frame_table[xfn]

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

> > 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?

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