On Mon, 2013-03-18 at 18:20 +0100, Bjørn Mork wrote: > Alex Williamson <alex.williamson@xxxxxxxxxx> writes: > > > At least for KVM the kernel fix is the addition of the vfio driver which > > gives us a non-sysfs way to do this. If this problem was found a few > > years later and we were ready to make the switch I'd support just > > removing these resource files. In the meantime we have userspace that > > depends on this interface, so I'm open to suggestions how to fix it. > > I am puzzled by a couple of things in this discussion: > > 1) do you seriously mean that a userspace application (any, not just > udevadm or qemu or whatever) should be able to read and write these > registers while the device is owned by a driver? How is that ever > going to work? The expectation is that the user doesn't mess with the device through pci-sysfs while it's running. This is really no different than config space or MMIO space in that respect. You can use setpci to break your PCI card while it's used by the driver today. The difference is that MMIO spaces side-step the issue by only allowing mmap and config space is known not to have read side-effects. > 2) is it really so that a device can be so fundamentally screwed up by > reading some registers, that a later driver probe cannot properly > reinitialize it? Never underestimate how broken hardware can be, though in this case reading a device register seems to be causing a system hang/reset. > I would have thought that the solution to all this was to return -EINVAL > on any attemt to read or write these files while a driver is bound to > the device. If userspace is going to use the API, then the application > better unbind any driver first. > > Or? Am I missing something here? That doesn't really solve anything though. Let's pretend the resource files only work while the device is bound to pci-stub. Now what happens when you run this udevadm command as admin while it's in use by the userspace driver? All we've done is limit the scope of the problem. > > If we want to blacklist this specific device, that's fine, but as others > > have pointed out it's really a class problem. Perhaps we report 1 byte > > extra for the file length where EOF-1 is an enable byte? Is there > > anything else in file ops that we could use to make it slightly more > > complicated than open(), read() to access the device? Thanks, > > If there really are devices which cannot handle reading at all, and > cannot be reset to a sane state by later driver initialization, then a > blacklist could be added for those devices. This should not be a common > problem. Yes, if these are dead registers, let's blacklist and move along. I suspect though that these registers probably work fine if you access them according to the device programming model, so blacklisting just prevents full use through something like KVM device assignment. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
