From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=41773 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OMNtU-0002Uh-Pa
	for qemu-devel@nongnu.org; Wed, 09 Jun 2010 12:12:46 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1OMNmo-0007Rg-Ej
	for qemu-devel@nongnu.org; Wed, 09 Jun 2010 12:05:51 -0400
Received: from mx1.redhat.com ([209.132.183.28]:33552)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1OMNmo-0007RT-5N
	for qemu-devel@nongnu.org; Wed, 09 Jun 2010 12:05:50 -0400
Message-ID: <4C0FBBD8.6080708@redhat.com>
Date: Wed, 09 Jun 2010 19:05:44 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
References: <4C0D0FB7.80709@redhat.com>
	<1A42CE6F5F474C41B63392A5F80372B21F26E155@shsmsx501.ccr.corp.intel.com>
In-Reply-To: <1A42CE6F5F474C41B63392A5F80372B21F26E155@shsmsx501.ccr.corp.intel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [RFC] Moving the kvm ioapic, pic,
	and pit back to userspace
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Dong, Eddie" <eddie.dong@intel.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, KVM list <kvm@vger.kernel.org>

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

>   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.

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

-- 
error compiling committee.c: too many arguments to function