On Tue, Nov 02, 2010 at 08:30:25PM +0100, Jan Kiszka wrote: > Am 02.11.2010 19:54, Michael S. Tsirkin wrote: > > On Tue, Nov 02, 2010 at 07:51:39PM +0100, Jan Kiszka wrote: > >> Am 02.11.2010 19:48, Jan Kiszka wrote: > >>> Am 02.11.2010 19:40, Jan Kiszka wrote: > >>>>>>>> @@ -199,6 +343,13 @@ static void kvm_free_assigned_device(struct kvm > >>>>>>>> *kvm, > >>>>>>>> > >>>>>>>> pci_reset_function(assigned_dev->dev); > >>>>>>>> > >>>>>>>> + /* > >>>>>>>> + * Unmask the IRQ at PCI level once the reset is done - the > >>>>>>>> next user > >>>>>>>> + * may not expect the IRQ being masked. > >>>>>>>> + */ > >>>>>>>> + if (assigned_dev->pci_2_3) > >>>>>>>> + pci_2_3_irq_unmask(assigned_dev->dev); > >>>>>>>> + > >>>>>>> > >>>>>>> Doesn't pci_reset_function clear mask bit? It seems to ... > >>>>>> > >>>>>> I was left with non-functional devices for the host here if I was not > >>>>>> doing this. Need to recheck, but I think it was required. > >>>>> > >>>>> Interesting. Could you check why please? > >>>>> > >>>> > >>>> Can't reproduce anymore. This was early code, maybe affected by some > >>>> bits or buts that no longer exist. > >>>> > >>>> Spec says it's cleared on reset, so I removed those lines now. > >>>> > >>> > >>> Hmpf, it just happened again: Guest was using my ath9k, I killed the > >>> guest, lspci says DisINTx+. Strange. Is anyone (qemu) restoring the > >>> config space after the reset, bringing the disable bit back? > >> > >> Or does the kernel cache the control word? > >> > >> Jan > > > > Maybe it does, need to dig in drivers/pci. If it does this > > might have other implications. > > OK, that mystery is resolved now: pci_reset_function saves & restores > the device state. > > Jan
Aha. I wonder what other state we need to clear. > -- > Siemens AG, Corporate Technology, CT T DE IT 1 > Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
