Re: [RFC PATCH 0/3] VFIO: capability chains

From: Alexey Kardashevskiy
Date: Thu Dec 17 2015 - 23:35:17 EST


On 12/18/2015 01:38 PM, Alex Williamson wrote:
On Fri, 2015-12-18 at 13:05 +1100, Alexey Kardashevskiy wrote:
On 11/24/2015 07:43 AM, Alex Williamson wrote:
Please see the commit log and comments in patch 1 for a general
explanation of the problems that this series tries to address. The
general problem is that we have several cases where we want to
expose
variable sized information to the user, whether it's sparse mmaps
for
a region, as implemented here, or DMA mapping ranges of an IOMMU,
or
reserved MSI mapping ranges, etc. Extending data structures is
hard;
extending them to report variable sized data is really hard. After
considering several options, I think the best approach is to copy
how
PCI does capabilities. This allows the ioctl to only expose the
capabilities that are relevant for them, avoids data structures
that
are too complicated to parse, and avoids creating a new ioctl each
time we think of something else that we'd like to report. This
method
also doesn't preclude extensions to the fixed structure since the
offset of these capabilities is entirely dynamic.

Comments welcome, I'll also follow-up to the QEMU and KVM lists
with
an RFC making use of this for mmaps skipping over the MSI-X table.
Thanks,

Out of curiosity - could this information be exposed to the userspace
via
/sys/bus/pci/devices/xxxx:xx:xx:x/vfio_xxxx? It seems not to change
after
vfio_pci driver is bound to a device.

For what purpose? vfio doesn't have a sysfs interface, why start one?
Thanks,

well, it could simplify debugging a bit if this information was available from the userspace without programming a test tool doing some ioctl()'s. Not a big deal though...



--
Alexey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/