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, Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
