> From: Paul Durrant [mailto:paul.durr...@citrix.com] > Sent: Tuesday, August 7, 2018 4:36 PM > > > > > > +static int intel_iommu_lookup_page(struct domain *d, bfn_t bfn, > > > mfn_t > > > > > *mfn, > > > > > + unsigned int *flags) > > > > > > > > Not looking at later patches yet... but in concept bfn address > > > > space is per device instead of per domain. > > > > > > Not in this case. Xen has always maintained a single IOMMU address > per > > > virtual machine. That is what BFN refers to. > > > > > > Paul > > > > > > > In default situation > > > > (w/o pvIOMMU exposed), all devices assigned to dom0 share > > > > the same address space (bfn=pfn) which is currently linked > > > > from domain structure. Then with pvIOMMU exposed, dom0 > > > > starts to manage individual pfn address space (called IOVA > > > > address space within dom0) per assigned device. In that case > > > > lookup should accept a bdf number and then find the right > > > > page table... > > > > > > > > > > No. That is over-complicating things and would probably involve re- > writing > > > most of the IOMMU code in Xen AFAICT. > > > > > > > it's not over-complicating. it's about correctness. > > > > think about the role of IOMMU. Now you expose it to dom0. Then > > dom0 wants to use it to isolate devices. What is the matter having > > an IOMMU which supports only one global address space cross all > > devices, from dom0's p.o.v? If that is the case, why does dom0 ever > > want to change bfn globally on all devices? > > > > Because even a PV dom0 would be beter off with a BFN:GFN map rather > than a BFN:MFN map, since then the xen_swiotlb code and be avoided and > lots of things that are contiguous in GFN space become contiguous in BFN > space and hence become DMA-able without bouncing. >
so this pvIOMMU really loses most functionalities which a physical IOMMU provides... maybe not call it pvIOMMU. sort of pvDMA engine. Thanks Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
