Messages in this thread | | | Subject | Re: [RFC PATCH 0/3] VFIO: capability chains | From | Alexey Kardashevskiy <> | Date | Fri, 18 Dec 2015 15:34:30 +1100 |
| |
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
| |