From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [PATCH v8 2/3] x86, apicv: add virtual interrupt delivery support
Date: Wed, 9 Jan 2013 13:10:04 -0200
Message-ID: <20130109151004.GA21533@amt.cnet>
References: <1357524157-4666-1-git-send-email-yang.z.zhang@intel.com>
 <1357524157-4666-3-git-send-email-yang.z.zhang@intel.com>
 <20130107135221.GA25775@amt.cnet>
 <20130107174843.GA4872@redhat.com>
 <20130107213239.GB31677@amt.cnet>
 <20130108100332.GI21250@redhat.com>
 <A9667DDFB95DB7438FA9D7D576C3D87E2F3CC6@SHSMSX101.ccr.corp.intel.com>
 <20130108135759.GB5121@amt.cnet>
 <20130108154314.GA7005@redhat.com>
 <A9667DDFB95DB7438FA9D7D576C3D87E2F4B2F@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Gleb Natapov <gleb@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"Shan, Haitao" <haitao.shan@intel.com>,
	"Tian, Kevin" <kevin.tian@intel.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:60676 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1755990Ab3AIPVX (ORCPT <rfc822;kvm@vger.kernel.org>);
	Wed, 9 Jan 2013 10:21:23 -0500
Content-Disposition: inline
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E2F4B2F@SHSMSX101.ccr.corp.intel.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Wed, Jan 09, 2013 at 08:07:31AM +0000, Zhang, Yang Z wrote:
> >> 	if(check_request(KVM_REQ_, ....)) {
> >> 		ioapic_lock();		(*)
> >> 		update local EOI exit bitmap from IOAPIC
> In my patch, it traverses IOAPIC entry once and only updates target vcpus's eoi exit bitmap. Then make request for all vcpus.
> With your suggestion , all vcpus will traverse all IOAPIC entries. Though ioapic entry write is rare, it's still not reasonable.

It should be fast, and very rare (as in once during system
initialization, or device hotplug). 

Is there a particular case that makes it necessary to optimize scanning?

> 
> >> 		ioapic_unlock();
> >> 	}
> >> 
> > Fine by me. Looks simpler.
> > 
> >> 
> >> 
> >> (*) plus any other lock that paths that update the map take
> >> 
> >> 
> >> 
> >> 
> >> 
> >>> 
> >>> Best regards,
> >>> Yang
> > 
> > --
> > 			Gleb.
> 
> 
> Best regards,
> Yang