On Sun, Apr 08, 2012 at 04:41:27PM +0300, Avi Kivity wrote: > On 04/08/2012 04:30 PM, Michael S. Tsirkin wrote: > > On Sun, Apr 08, 2012 at 04:24:11PM +0300, Avi Kivity wrote: > > > On 04/08/2012 04:21 PM, Michael S. Tsirkin wrote: > > > > On Sun, Apr 08, 2012 at 04:18:29PM +0300, Avi Kivity wrote: > > > > > On 04/08/2012 04:17 PM, Michael S. Tsirkin wrote: > > > > > > > > > > > > > > Don't we FLR the device, which ought to disable MSI on the real device? > > > > > > > > > > > > AFAIK we call pci_reset, which saves device state, does an FLR > > > > > > and then restores the state. I think this might include msi as well. > > > > > > > > > > > > > > > > > > > > > > Then that is wrong as well, no? > > > > > > > > Not as such assuming we disable msi/msix first :) > > > > > > I think we need to fix both, no? > > > > Isn't this what this patch does? > > If we change pci_reset() (or a variant that we call) to reset MSI, and > update qemu to synchronize from the device after pci_reset(), then we > achieve the same result, in a different way. MSI vectors are set up by kvm in the host. So we should not abruptly drop that by a sysfs write: would need to synchronise with kvm. Once we do, there's nothing left for pci_reset to do. > Since reset can change other config space registers, we achieve > correctness for more of them. Which other registers do you have in mind? > -- > error compiling committee.c: too many arguments to function -- 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
