Amit Shah wrote: > >>> +static irqreturn_t >>> +kvm_pci_pt_dev_intr(int irq, void *dev_id) >>> >>> +{ >>> + struct kvm_pci_pt_dev_list *match; >>> + struct kvm *kvm = (struct kvm *) dev_id; >>> + >>> + if (!test_bit(irq, pt_irq_handled)) >>> + return IRQ_NONE; >>> + >>> + if (test_bit(irq, pt_irq_pending)) >>> + return IRQ_HANDLED; >>> >> Will the interrupt not fire immediately after this returns? >> > > Hmm. This is just an optimisation so that we don't have to look up the list > each time to find out which assigned device it is and (re)injecting the > interrupt. Also we avoid the (TODO) getting/releasing locks which will be > needed for the list lookup. > > Disabling interrupts for PCI devices isn't a good idea even if we don't > support shared interrupts. Any other ideas to avoid this from happening? > >
I don't understand. These are level-triggered interrupts, so if one fires and you don't disable it, it will fire again and again. Seems to me the only choice here is to mask the interrupt at the ioapic level, wait until the guest acks the interrupt, then unmask the interrupt. With the current code, how to the guest interrupt counters and the host interrupt counters compare? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel