On Thu, 2015-12-03 at 16:40 +0800, Lan, Tianyu wrote: > On 12/3/2015 6:25 AM, Alex Williamson wrote: > > I didn't seen a matching kernel patch series for this, but why is the > > kernel more capable of doing this than userspace is already? > The following link is the kernel patch. > http://marc.info/?l=kvm&m=144837328920989&w=2 > > > These seem > > like pointless ioctls, we're creating a purely virtual PCI capability, > > the kernel doesn't really need to participate in that. > > VFIO kernel driver has pci_config_map which indicates the PCI capability > position and length which helps to find free PCI config regs. Qemu side > doesn't have such info and can't get the exact table size of PCI > capability. If we want to add such support in the Qemu, needs duplicates > a lot of code of vfio_pci_configs.c in the Qemu. That's an internal implementation detail of the kernel, not motivation for creating a new userspace ABI. QEMU can recreate this data on its own. The kernel is in no more of an authoritative position to determine capability extents than userspace. > > Also, why are we > > restricting ourselves to standard capabilities? > > This version is to check whether it's on the right way and We can extend > this to pci extended capability later. > > > That's often a crowded > > space and we can't always know whether an area is free or not based only > > on it being covered by a capability. Some capabilities can also appear > > more than once, so there's context that isn't being passed to the kernel > > here. Thanks, > > The region outside of PCI capability are not passed to kernel or used by > Qemu for MSI/MSIX . It's possible to use these places for new > capability. One concerns is that guest driver may abuse them and quirk > of masking some special regs outside of capability maybe helpful. That's not correct, see kernel commit a7d1ea1c11b33bda2691f3294b4d735ed635535a. Gaps between capabilities are exposed with raw read-write access from the kernel and some drivers and devices depend on this. There's also no guarantee that there's a sufficiently sized gap in conventional space. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
