> -----Original Message----- > From: Tian, Kevin [mailto:kevin.t...@intel.com] > Sent: 07 August 2018 03:38 > To: Paul Durrant <paul.durr...@citrix.com>; xen-devel@lists.xenproject.org > Cc: Suravee Suthikulpanit <suravee.suthikulpa...@amd.com>; Stefano > Stabellini <sstabell...@kernel.org>; Julien Grall <julien.gr...@arm.com>; Jan > Beulich <jbeul...@suse.com> > Subject: RE: [PATCH v5 02/15] iommu: introduce the concept of BFN... > > > From: Paul Durrant [mailto:paul.durr...@citrix.com] > > 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.durr...@citrix.com> > > Reviewed-by: Wei Liu <wei.l...@citrix.com> > > [...] > > > 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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
