Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1294432
| From | Alexey Kardashevskiy <aik@ozlabs.ru> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC PATCH 0/3] VFIO: capability chains |
| Date | 2015-12-18 05:40 +0100 |
| Message-ID | <qGUZH-Qh-1@gated-at.bofh.it> (permalink) |
| References | <qy6dH-6Rx-5@gated-at.bofh.it> <qGSEy-7Qe-1@gated-at.bofh.it> <qGT7A-81l-11@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
Re: [RFC PATCH 0/3] VFIO: capability chains Alexey Kardashevskiy <aik@ozlabs.ru> - 2015-12-18 03:10 +0100
Re: [RFC PATCH 0/3] VFIO: capability chains Alex Williamson <alex.williamson@redhat.com> - 2015-12-18 03:40 +0100
Re: [RFC PATCH 0/3] VFIO: capability chains Alexey Kardashevskiy <aik@ozlabs.ru> - 2015-12-18 05:40 +0100
csiph-web