> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Tuesday, August 7, 2018 4:30 PM > > >>> On 07.08.18 at 10:21, <paul.durr...@citrix.com> wrote: > >> From: Tian, Kevin [mailto:kevin.t...@intel.com] > >> Sent: 07 August 2018 04:25 > >> > >> > From: Paul Durrant [mailto:paul.durr...@citrix.com] > >> > Sent: Saturday, August 4, 2018 1:22 AM > >> > > >> > --- a/xen/drivers/passthrough/vtd/iommu.c > >> > +++ b/xen/drivers/passthrough/vtd/iommu.c > >> > @@ -1830,6 +1830,39 @@ static int __must_check > >> > intel_iommu_unmap_page(struct domain *d, > >> > return dma_pte_clear_one(d, bfn_to_baddr(bfn)); > >> > } > >> > > >> > +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. > > Nut is that a model we can maintain mid and long term? In particular > on ARM, where Julien has told me a single system could have multiple > _different_ IOMMUs, I could easily see the address spaces diverging. >
multiple IOMMUs is another thing. what I questioned is that even one IOMMU needs to support mulitiple address spaces. That is the point of an IOMMU... Thanks Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel