[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v5 09/15] vtd: add lookup_page method to iommu_ops



> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Tuesday, August 7, 2018 4:30 PM
> 
> >>> On 07.08.18 at 10:21, <Paul.Durrant@xxxxxxxxxx> wrote:
> >> From: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx]
> >> Sent: 07 August 2018 04:25
> >>
> >> > From: Paul Durrant [mailto:paul.durrant@xxxxxxxxxx]
> >> > 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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.