On May 14, 2015 1:06:00 AM CDT, "Michael S. Tsirkin" <mst@xxxxxxxxxx> wrote: >On Wed, May 13, 2015 at 08:41:55AM +0200, Michael S. Tsirkin wrote: >> > This also sounds like a case for implementing a shutdown callback >and >> > disabling things properly. A properly shutdown driver should have >> > already disabled MSI's. A driver is responsible for enabling MSIs >so it >> > should be responsible for disabling it. The core disabling MSIs is >> > mostly to catch the handful of lazy drivers that forget. >> >> >> Okay! And I am saying that if the driver did forget, >> we are better off not disabling it - leave it enabled >> until kexec starts and disables it. >> >> >> > The bottom line is that there are a few things that are standard >> > behavior that we can do in the generic code, but at the end of the >day >> > it is the responsibility of the driver to shut things down and >whatever >> > driver you are dealing with clearly has a bunch of bugs and you >aren't >> > fixing it. >> >> So please let us get on with fixing it in driver and stop >> playing with device in core. > >Eric, does this argument make sense? Drivers should do the right thing >in their shutdown callback, let's not try to work around their bugs in >core. Not in context of this patch, as this change appears to be to avoid fixing the driver. Further this behavior in the core has existed for the better part of a decade. Who knows what weird behavior (called regressions) this will trigger with other drivers in other situations. I do not see any reason to change the existing behavior here. Especially as if you try and boot a non-linux kernel with kexec you are almost certainly going to subject it to a screaming MSI interrupt and there almost certainly will not be code to disable MSIs as they are disabled by at boot up by default. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
