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
