Magenheimer, Dan (HP Labs Fort Collins)
2005-Dec-29 18:51 UTC
RE: Guest-visible phys2mach part of Xen arch-neutral API? was: [Xen-devel] Uses of &frame_table[xfn]
> > 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@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2005-Dec-29 20:34 UTC
Re: Guest-visible phys2mach part of Xen arch-neutral API? was: [Xen-devel] Uses of &frame_table[xfn]
On 29 Dec 2005, at 18:51, Magenheimer, Dan (HP Labs Fort Collins) wrote:> 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:I think *that* is the critical question here. My feeling is that having p==m for any domain (even domain0) may have a siginificant effect on the amount of otherwise arch-indep xenlinux code you can share. My feeling is therefore that dom0 should be like any domU and have virtualised p (!= m). This is somewhat a gut feeling though -- perhaps something to discuss and think about at the summit? It''s true that p!=m in a driver domain is a bit more of a pain than p==m, but a lot of the work has been done for x86/xen and I think can be used by other architectures.>> 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?This I care less about. If we decide that even driver domains will have p!=m, you will certainly need some way to get at m, but I think whether that is via an array mapped into the guest''s address space or by some other means (e.g., hypercall) is an implementation detail that can vary across architectures. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Apparently Analagous Threads
- RE: Guest-visible phys2mach part of Xen arch-neutral API? was: Uses of &frame_table[xfn]
- RE: [Xen-ia64-devel] RE: [BUNDLE] Testing a simplerinter-domain transport
- relationship of the auto_translated_physmap feature and the shadow_mode_translate mode of domain
- How to change the significant codes default?
- [PATCH] Arch-neutral balloon driver