qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] RE: [RFC] Moving the kvm ioapic, pic, and pit back to users


From: Dong, Eddie
Subject: [Qemu-devel] RE: [RFC] Moving the kvm ioapic, pic, and pit back to userspace
Date: Thu, 10 Jun 2010 10:37:53 +0800

Avi Kivity wrote:
> On 06/09/2010 06:59 PM, Dong, Eddie wrote:
>> 
>> Besides VF IO interrupt and timer interrupt introduced performance
>> overhead risk, 
> 
> VF usually uses MSI

Typo, I mean PV IO. 
A VF interrupt usually happens in 4-8KHZ. How about the virtio?
I assume virtio will be widely used together w/ leagcy guest with INTx mode.

> 
>>   EOI message deliver from lapic to ioapic,
> 
> Only for non-MSI
> 
>>   which becomes in user land now, may have potential scalability
>> issue. For example, if we have a 64 VCPU guest, if each vcpu has
>> 1khz interrupt (or ipi), the EOI from guest will normally have to
>> involve ioapic module for clearance in 64khz which may have long
>> lock contentio.    
> 
> No, EOI for IPI or for local APIC timer does not involve the IOAPIC.
> 
>> you may reduce the involvement of ioapic eoi by tracking ioapic
>> pin<->  vector map in kernel, but not sure if it is clean enough. 
> 
> It's sufficient to look at TMR, no?  For edge triggered I don't think
> we need the EOI.

Mmm, I noticed statements difference between new SDM & old SDM.
In old SDM, IPI can have both edge and level trigger mode. But new SDM says 
only INIT can have both choice.
Given the new SDM eliminates the level trigger mode, it is OK.

> 
> But, the amount of churn and risk worries me, so I don't think the
> move is worthwhile.

This also remind me the debate at early stage of KVM when Gregory Haskins is 
working on any arbitrary choice of irqchip.
The patch even at that time (without SMP) is very complicated.

I agree from ROI point of view, this movement may be not worthwhile.
thx, eddie




reply via email to

[Prev in Thread] Current Thread [Next in Thread]