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

[Paul Durrant <Paul.Durrant@citrix.com>]

> -----Original Message-----
> From: Tian, Kevin [mailto:kevin.tian@intel.com]
> Sent: 07 August 2018 10:03
> To: Paul Durrant <Paul.Durrant@citrix.com>; Jan Beulich
> <JBeulich@suse.com>
> Cc: George Dunlap <George.Dunlap@citrix.com>; xen-devel <xen-
> devel@lists.xenproject.org>
> Subject: RE: [PATCH v5 09/15] vtd: add lookup_page method to iommu_ops
> 
> > From: Paul Durrant [mailto:Paul.Durrant@citrix.com]
> > Sent: Tuesday, August 7, 2018 4:56 PM
> >
> > > -----Original Message-----
> > > From: Tian, Kevin [mailto:kevin.tian@intel.com]
> > > Sent: 07 August 2018 09:48
> > > To: Paul Durrant <Paul.Durrant@citrix.com>; Jan Beulich
> > > <JBeulich@suse.com>
> > > Cc: George Dunlap <George.Dunlap@citrix.com>; xen-devel <xen-
> > > devel@lists.xenproject.org>
> > > Subject: RE: [PATCH v5 09/15] vtd: add lookup_page method to
> > iommu_ops
> > >
> > > > From: Paul Durrant [mailto:Paul.Durrant@citrix.com]
> > > > Sent: Tuesday, August 7, 2018 4:37 PM
> > > >
> > > > > -----Original Message-----
> > > > > From: Tian, Kevin [mailto:kevin.tian@intel.com]
> > > > > Sent: 07 August 2018 09:33
> > > > > To: Jan Beulich <JBeulich@suse.com>; Paul Durrant
> > > > > <Paul.Durrant@citrix.com>
> > > > > Cc: George Dunlap <George.Dunlap@citrix.com>; xen-devel <xen-
> > > > > devel@lists.xenproject.org>
> > > > > Subject: RE: [PATCH v5 09/15] vtd: add lookup_page method to
> > > > iommu_ops
> > > > >
> > > > > > From: Jan Beulich [mailto:JBeulich@suse.com]
> > > > > > Sent: Tuesday, August 7, 2018 4:30 PM
> > > > > >
> > > > > > >>> On 07.08.18 at 10:21, <Paul.Durrant@citrix.com> wrote:
> > > > > > >> From: Tian, Kevin [mailto:kevin.tian@intel.com]
> > > > > > >> Sent: 07 August 2018 04:25
> > > > > > >>
> > > > > > >> > From: Paul Durrant [mailto:paul.durrant@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...
> > > >
> > > > Indeed and that is why we use it to enforce domain separation. I see no
> > > > need, as yet, to enforce separation within a domain. That need may
> > arise
> > > > later and the code can be modified at that point.
> > > >
> > >
> > > but then you need completely different set of APIs at that time...
> >
> > Ok. Would you be happy if I add the option to supply a an SBDF in the map
> > and unmap hypercalls but ignore the value for now? Or even have a 'global'
> > flag but return -EOPNOTSUPP if it is not specified. That would avoid the
> > need to add new hypercalls for per-device mapping.
> >
> 
> that would be better! maybe also worthy of a capability query interface
> to tell whether global or per-bdf mapping is supported?

I could make it an option to the 'enable' hypercall. A caller could try to enable per-device mappings first and, if that fails, fall back to global.

  Paul

> 
> Thanks
> Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel