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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.09.18 at 08:48, <kevin.tian@xxxxxxxxx> wrote:
>>  From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: Monday, September 3, 2018 7:47 PM
>> 
>> >>> 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.
>> 
> 
> bus address is commonly used along with physical/virtual address, to
> represent different views between devices and CPU. From that angle
> I think BFN is a clear term in this context. btw it is not necessary to
> differentiate GBFN and MBFN since there is only one BFN view per 
> device.

Sure, but you neglect the presence of one or more IOMMUs when
you say "between devices and CPU". There addresses prior to and
after IOMMU translation are distinct, and while the one before the
translation matches the device view, the one after translation does
not necessarily match the CPU view. Hence there are two "bus"
frame numbers here - one representing the device view, and the
other representing the IOMMU (output) view.

Jan



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