Dong, Eddie wrote:
>> diff --git a/drivers/kvm/ioapic.c b/drivers/kvm/ioapic.c
>> index 3ee13c3..b8c7da4 100644
>> --- a/drivers/kvm/ioapic.c
>> +++ b/drivers/kvm/ioapic.c
>> @@ -243,17 +243,10 @@ void kvm_ioapic_set_irq(struct
>> kvm_ioapic *ioapic, int irq, int level)
>> entry = ioapic->redirtbl[irq];
>> if (!level)
>> ioapic->irr &= ~mask;
>> - if (entry.fields.trig_mode) { /* level triggered */
>> - if (level && !entry.fields.remote_irr) {
>> - ioapic->irr |= mask;
>> - ioapic_service(ioapic, irq);
>> - }
>> - } else if (level && !(ioapic->irr & mask)) {
>> - /*
>> - * edge triggered
>> - */
>> + else {
>> ioapic->irr |= mask;
>> - ioapic_service(ioapic, irq);
>> + if (!entry.fields.trig_mode ||
>> !entry.fields.remote_irr)
>> + ioapic_service(ioapic, irq);
>>
>
> Good fix for ioapic->irr to indicate the line state. But
> I think this one will cause a redunadant edge trigger IRQ. A device
> model may repeat call SET_IRQ_LINE state even w/o state change
> (thus no IRQ), with this logic, a redunadnat IRQ will happen.
>
> if (!entry.fields.trig_mode || =====>
> if ((!entry.fields.trig_mode && (old_irr & mask ==0)) ||
>
>
Thanks, I'll do that.
> Also architectually level = 0 may also mean an IRQ to IOAPIC
> if the polarity is negative though today we may not see this.
> But this change will expose the risk, and the propose of pass-through
> hardware device will change the polarity.
>
Sure, if you run Xen + pci passthrough with the polarity reversal on kvm :)
We do want a correct polarity implementation -- I'll do that later on.
I certainly won't say no to patches...
--
error compiling committee.c: too many arguments to function
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel
