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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx]
> Sent: 07 August 2018 03:38
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx
> Cc: Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>; Stefano
> Stabellini <sstabellini@xxxxxxxxxx>; Julien Grall <julien.grall@xxxxxxx>; Jan
> Beulich <jbeulich@xxxxxxxx>
> Subject: RE: [PATCH v5 02/15] iommu: introduce the concept of BFN...
> 
> > From: Paul Durrant [mailto:paul.durrant@xxxxxxxxxx]
> > Sent: Saturday, August 4, 2018 1:22 AM
> >
> > ...meaning 'bus frame number' i.e. a frame number mapped in the IOMMU
> > rather than the MMU.
> >
> > This patch is a largely cosmetic change that substitutes the terms 'gfn'
> > and 'gaddr' for 'bfn' and 'baddr' in all the places where the frame number
> > or address relate to the IOMMU rather than the MMU.
> >
> > The parts that are not purely cosmetic are:
> >
> >  - the introduction of a type-safe declaration of bfn_t and definition of
> >    INVALID_BFN to make the substitution of gfn_x(INVALID_GFN)
> mechanical.
> >  - the introduction of __bfn_to_baddr and __baddr_to_bfn (and type-safe
> >    variants without the leading __) with some use of the former.
> >
> > Subsequent patches will convert code to make use of type-safe BFNs.
> >
> > Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
> > Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx>
> 
> [...]
> 
> > diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
> > index 24654e8e22..4ebf91f17e 100644
> > --- a/xen/include/xen/mm.h
> > +++ b/xen/include/xen/mm.h
> > @@ -14,8 +14,9 @@
> >   * should be adhered to.
> >   *
> >   * mfn: Machine Frame Number
> > - *   The values Xen puts into its own pagetables.  This is the host 
> > physical
> > - *   memory address space with RAM, MMIO etc.
> > + *   The values Xen puts into its own pagetables, 2nd stage pagetables
> > (where
> > + *   hardware assisted 2nd stage translation is used) or IOMMU page
> > tables.
> > + *   This is the host physical memory address space with RAM, MMIO etc.
> 
> there is also shadow page table... not sure whether it is really helpful
> to list all of them out. "Xen-owned pagetables" should be sufficient to cover.
> 
> >   *
> >   * 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.

> - 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.

  Paul

> 
> >   * WARNING: Some of these terms have changed over time while others
> > have been
> >   * used inconsistently, meaning that a lot of existing code does not match
> > the
> >   * definitions above.  New code should use these terms as described here,
> > and
> > --
> > 2.11.0


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