Am 02.11.2010 20:53, Michael S. Tsirkin wrote: > 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. > Maybe just save/restore before/after assigning the device? Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
