Re: [Xen-devel] [PATCH v6 01/14] iommu: introduce the concept of BFN...

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 30 August 2018 17:00
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>; Julien Grall
> <julien.grall@xxxxxxx>; Kevin Tian <kevin.tian@xxxxxxxxx>; Stefano
> Stabellini <sstabellini@xxxxxxxxxx>; xen-devel <xen-
> devel@xxxxxxxxxxxxxxxxxxxx>
> Subject: Re: [PATCH v6 01/14] iommu: introduce the concept of BFN...
> 
> >>> On 23.08.18 at 11:46, <paul.durrant@xxxxxxxxxx> wrote:
> > --- a/xen/include/xen/mm.h
> > +++ b/xen/include/xen/mm.h
> > @@ -26,6 +26,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
> (i.e.
> > + *   all devices assigned to) a guest share a single IOMMU address space
> and,
> > + *   by default, Xen will ensure bfn == pfn.
> 
> The code changes are purely mechanical and hence fine, but I have
> to admit I continue to struggle with the "bus" part in the name here:
> I don't think it is any less ambiguous than GFN, because which bus
> are you thinking about here? The (virtual) one as seen by the guest,
> aiui. The physical (host) one would be at least as natural to be
> indexed by such typed/named variables. I'd somehow like it to be
> made explicit in the name whose view these represent. GBFN?
> VBFN?
> 

Well, it always refers to whatever physical bus is on the other side of the 
IOMMU from the core so it's the view of whatever peripheral devices are located 
on that bus. As Kevin said each device can have its own address space and the 
fact we always use a global per-VM space is an implementation detail so DFN for 
'device frame number' or IOFN (since IOVA is reasonably widely used term) might 
be more future-proof?

> Jan
> 


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