Re: [Xen-devel] [PATCH v5 02/15] iommu: introduce the concept of BFN...

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Paul Durrant [mailto:Paul.Durrant@xxxxxxxxxx]
> Sent: Tuesday, August 7, 2018 4:00 PM
> 
> > >   *
> > >   * gfn: Guest Frame Number
> > >   *   The values a guest puts in its own pagetables.  For an auto-
> translated
> > > @@ -26,6 +27,11 @@
> > >   *   A linear idea of a guest physical address space. For an auto-
> translated
> > >   *   guest, pfn == gfn while for a non-translated guest, pfn != gfn.
> > >   *
> > > + * bfn: Bus Frame Number (definitions in include/xen/iommu.h)
> > > + *   The linear frame numbers of IOMMU address space. All initiators
> for a
> > > + *   given domain share a single IOMMU address space and, by default,
> > > Xen will
> > > + *   ensure bfn == pfn.
> > > + *
> >
> > Above description is a bit confusing:
> >
> > - for 'domain', are you talking about VM or IOMMU domain? If the
> former
> > then each initiator could have its own IOMMU address space when a
> virtual
> > IOMMU (either pvIOMMU or emulated IOMMU) is exposed.
> >
> 
> I mean VM and, yes, while each initiator *could* have its own IOMMU
> address space, that is not what we do in (or have ever done) in Xen. I can
> replace the word 'domain' with the abbreviation 'VM' if you feel it makes
> things clearer.
> 

domain is OK here. just want to confirm.

> > - since you talk about 'by default', better also talk about non-default 
> > case,
> > i.e. when virtual IOMMU is exposed then bfn is a separate address space
> > managed by guest
> 
> That's putting the cart before the horse really. There is no PV-IOMMU at
> this stage in the series. I guess I could modify the comment in the later
> patch where I add the hypercall to enable PV-IOMMU.
> 

it's fine as long as finally the information is complete. 

Thanks
Kevin


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