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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 03.09.18 at 10:23, <Paul.Durrant@xxxxxxxxxx> wrote:
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: 30 August 2018 17:00
>> 
>> >>> 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?

I don't think any name alone would make things future-proof. Considering
the per-device address space case, a frame number would always need
to come in a tuple paired with a device identifier. Nevertheless I think
either of the names you suggest would be a slight improvement, perhaps
DFN even more than IOFN, as that includes whose view this is. But I'd
certainly appreciate opinions of others, so you don't again end up doing
something that I've asked for,just to subsequently undo it again.

Jan



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