On Wed, 2010-06-30 at 16:36 +0300, Michael S. Tsirkin wrote: > On Wed, Jun 30, 2010 at 12:14:12AM -0600, Alex Williamson wrote: > > On Tue, 2010-06-08 at 14:21 -0700, Tom Lyon wrote: > > > The VFIO "driver" is used to allow privileged AND non-privileged processes to > > > implement user-level device drivers for any well-behaved PCI, PCI-X, and PCIe > > > devices. > > > > Hi Tom, > > > > I found a few bugs. Patch below. The first chunk clears the > > pci_config_map on close, otherwise we end up passing virtualized state > > from one user to the next. The second is an off by one in the basic > > perms. Finally, vfio_bar_fixup() needs an overhaul. It wasn't setting > > the lower bits right and is allowing virtual writes of bits that aren't > > aligned to the size. This section probably needs another pass or two of > > refinement. Thanks, > > > > Alex > > > > I still don't see why are we sticking all this emulation in kernel. It > is far from performance hotpath and can easily be emulated in userspace. > qemu does this, you can lift code from there if you like. > Maybe we need to protect the BARs from being manipulated by userspace, > but that should be all. No need for tables. The benefit I see so far is that it removes duplicate code. Should every user of this interface try to extract qemu's PCI config space emulation and jury rig it into their code base? Tom is already providing access to more capability bits than the kvm device assignment code. If the kernel community will accept it, I think it saves vfio usperspace writers some hassle and provides a better environment by having emulation in a single, well tested, hopefully well used place. 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
