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

> >     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.
> 
> This seems to make sense to me. How does ia64/xen work right now? 
> Machine addresses visible to domain0 and full virtualisation of 
> addresses exposed to other domains (with no way of seeing underlying 
> machine addresses)?

Not exactly.  The Linux/ia64 memory management code for both domain0
and unprivileged domains is completely unchanged -- no Xen-specific
ifdef's for either.  The difference is managed in Xen(/ia64) itself:
domain 0 physical addresses are currently directly mapped to machine
addresses whereas unprivileged domain physical addresses are managed
in a (multi-level) lookup table.

Lest there be confusion, DMA, SWIOTLB, AGP, etc all currently work
fine in domain0 Xen/ia64 with no guest-visible phys2mach table --
again with no Linux code changes required.

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.

In short, a guest-visible phys2mach table makes porting of Xen
device drivers easier because all of the Xen drivers were written for
Xen-x86 where the guest-visible phys2mach table is a natural
consequence of paravirtualizing the x86 architecture.  The cost
of a guest-visible phys2mach table is that non-trivial changes are
required to Linux's (actually Xenlinux's) memory management code,
increasing difficulty for porting and maintenance of Xen flavors of
Linux as well as for creating a single Xen+native binary (aka
transparent
paravirtualizion).

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

P.S. I'm guessing the PPC guys are on vacation this week.

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