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

> > Note that the current physical=machine in domain0 is not a
> > design requirement, just the current implementation.  The question
> > at hand isn't whether Xen/ia64 domain0 should be mapped
> > physical=machine,
> > but -- if it is not -- whether the mapping should be guest-visible.
> 
> The mapping will need to be guest-visible to allow correct 
> programming 
> of DMA engines. It works okay for you right now because dom0 
> has p==m. 
> But if that is no longer the case then drivers will break, and you 
> won't be able to implement driver domains either.
> 
> Even if you don't go with an explicit p2m table, you'll need a 
> hypercall for getting the same info (which would also be a hook point 
> for maintaining IOMMU mappings, if the architecture needs 
> such a thing 
> and the IOMMU is managed by Xen).

Sorry, I am supposed to be on vacation this week so my mind
is not quite all together.

Yes, right, because of DMA, p==m *is* a design requirement for
Xen/ia64 domain0 and driver domains unless there is an explicit
p2m table or hypercall.

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:

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

Thanks,
Dan

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