On 03/18/13 13:54, Alex Williamson wrote: > 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. The real problem is that PCI devices can be bus masters, which means they can screw up *ANYTHING* (almost)! -- 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
