Re: [RFC PATCH 0/3] VFIO: capability chains
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/:xx:xx:x/vfio_? 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 kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] VFIO: capability chains
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/:xx:xx:x/vfio_? 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
Re: [RFC PATCH 0/3] VFIO: capability chains
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/:xx:xx:x/vfio_? It seems not to change after vfio_pci driver is bound to a device. Alex --- Alex Williamson (3): vfio: Define capability chains vfio: Define sparse mmap capability for regions vfio/pci: Include sparse mmap capability for MSI-X table regions drivers/vfio/pci/vfio_pci.c | 101 +++ include/uapi/linux/vfio.h | 53 ++- 2 files changed, 152 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Alexey -- 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
