RE: 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>]

Thought I should sleep on this before replying... 

> p==m for any domain (even domain0) may have a siginificant effect on 
> the amount of otherwise arch-indep xenlinux code you can share.

Not to be snide, but its hard to call code arch-indep if it only
runs on one machine and has been designed only to meet the needs
of one architecture.  The discussion is about whether this code
should be made more flexible to accommodate other approaches,
or whether another approach should be disallowed.  This has
already been done for the block driver and most "core" code,
but not yet for the balloon driver or network driver.

> > So then is p==m in dom0 (and driver domains) an unacceptable design
> I think *that* is the critical question here.

I think there are two critical questions that are very highly
related.  To me, the critical question is how many changes
to a guest are required to run on Xen.  I've argued for a long
time that paravirtualization changes should be minimized/optimized
to only those that are absolutely necessary for functionality
and performance.   DMA-capable domains require either p==m
or non-trivial changes to the guest.  On x86, non-trivial changes
to the guest are necessary anyway due to the x86 memory architecture
so p!=m comes "for free".  This is not necessarily the case
for non-x86 Xen machines.

> something to discuss and think about at the summit?

Sounds good.

Dan

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