Re: [Qemu-devel] RFC: vfio / device assignment -- layout of device fd files

[Scott Wood <scottwood@freescale.com>]

On 08/29/2011 11:55 PM, Alex Williamson wrote:
> Thanks for the example.  Is it always the case that you need a path and
> an index?  If so, why are they separate sub-regions instead of combined
> into a DT_INFO sub-region?

You'll always need both.  DTPATH was put into a separate subrecord
because it is of variable length.  Putting it at the end of DTINDEX
would inhibit DTINDEX's extensibility.

> On Mon, 2011-08-29 at 18:14 -0500, Scott Wood wrote:
>> On 08/29/2011 05:46 PM, Alex Williamson wrote:
>>> I could imagine a platform device described by ACPI that might want to
>>> differentiate.  The physical device doesn't get moved of course, but
>>> guest drivers might care how the device is described if we need to
>>> rebuild those ACPI tables.  ACPI might even be a good place to leverage
>>> these data structures... /me ducks.
>>
>> ACPI info could be another subrecord type, but in the device tree
>> system-bus case we generally don't have this information at the generic
>> infrastructure level.  Drivers are expected to know how their devices'
>> regions should be mapped.
> 
> The device tree tells them how they're mapped, right?
> Or maybe more precisely, the device tree tells them where they're mapped and it
> doesn't really matter whether they're 32bit or 64bit because they can't
> be moved.

The device tree says where they're mapped.  The concept of "32/64bit"
doesn't really apply to a fixed mapping -- or if not fixed, there may be
arbitrary constraints, and the OS should just treat it as fixed.

> Maybe this is sub-region material.  It just feels wrong to enumerate a
> region and not be able to include any basic properties beyond offset and
> size in a common field.

offset, size, and whether you can use mmap() are the only things we
could think of that were universal.  The rest can go in subrecords.

>>> Put their instance numbers outside of the BAR region?  We have a fixed
>>> REGION space on PCI, so we could just define BAR0 == instance 0, BAR1 ==
>>> instance 1... ROM == instance 6, CONFIG == instance 0xF (or 7).
>>
>> Seems more awkward than just having each region say what it is.  What do
>> you do to fill in the gaps?
> 
> You don't, instance numbers would just be non-contiguous.

OK, maybe I'm not understanding what you mean by instance numbers -- I
thought you were talking about the order in which they appear.  If you
mean to put an index field in the common REGION struct, I'd prefer not
to.  It would lack meaning without the context of some particular
encoding scheme.  Better to put it in a typed subrecord where we can be
explicit about what it means.

> The reason I cringe at PCI_INFO sub-regions is that all the info is already available
> in PCI config space

BAR index isn't.  I'm neutral on whether it makes sense to include BAR type.

> We also have MSI/X
> interrupts on PCI.  Do we need to describe those via info records or
> parse PCI config space and know that vfio-pci device fds support the
> VFIO_PCI_DEVICE_SET_MSI_FDS ioctl?

I'm not very familiar with MSI-X, but if it's workable without it then
probably no need.

-Scott