Magenheimer, Dan (HP Labs Fort Collins)
2005-Dec-29 16:12 UTC
RE: Guest-visible phys2mach part of Xen arch-neutral API? was: [Xen-devel] Uses of &frame_table[xfn]
> > 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@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2005-Dec-29 16:16 UTC
Re: Guest-visible phys2mach part of Xen arch-neutral API? was: [Xen-devel] Uses of &frame_table[xfn]
On 29 Dec 2005, at 16:12, Magenheimer, Dan (HP Labs Fort Collins) wrote:> 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). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel