From mboxrd@z Thu Jan  1 00:00:00 1970
From: Gleb Natapov <gleb@redhat.com>
Subject: Re: [PATCH v3 3/4] x86, apicv: add virtual interrupt delivery support
Date: Fri, 7 Dec 2012 09:28:23 +0200
Message-ID: <20121207072823.GF14176@redhat.com>
References: <1354518064-3066-1-git-send-email-yang.z.zhang@intel.com>
 <1354518064-3066-4-git-send-email-yang.z.zhang@intel.com>
 <20121205223148.GA26880@amt.cnet>
 <A9667DDFB95DB7438FA9D7D576C3D87E2D55F7@SHSMSX101.ccr.corp.intel.com>
 <20121206063652.GW19514@redhat.com>
 <20121206200805.GA11007@amt.cnet>
 <A9667DDFB95DB7438FA9D7D576C3D87E2D6AD9@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"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]:54603 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1755456Ab2LGH20 (ORCPT <rfc822;kvm@vger.kernel.org>);
	Fri, 7 Dec 2012 02:28:26 -0500
Content-Disposition: inline
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E2D6AD9@SHSMSX101.ccr.corp.intel.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Fri, Dec 07, 2012 at 01:00:18AM +0000, Zhang, Yang Z wrote:
> Marcelo Tosatti wrote on 2012-12-07:
> >>> How about to recaculate irr_pending according the VIRR on each vmexit?
> >>> 
> >> No need really. Since HW can only clear VIRR the only situation that may
> >> happen is that irr_pending will be true but VIRR is empty and
> >> apic_find_highest_irr() will return correct result in this case.
> >> 
> >> If we will see a lot of unneeded irr scans because of stale irr_pending
> >> value we can do irr_pending = rvi != 0 on vmexit.
> >> 
> >> --
> >> 			Gleb.
> > 
> > Yes, it is harmless ATM. But its clearer if irr_pending is not used when
> > virtual interrupt delivery is in effect (that is, just skip irr_pending
> > if virtual interrupt delivery is enabled).
> irr_pending still is useful in virtual interrupt delivery case. Or else, as gleb said ,there may be lots of unneeded irr scan.
> 
Actually, looking at it close, irr_pending will always be true (and
thus effectively disabled without any additional checks) since it is
cleared only in kvm_get_apic_interrupt() which will not be called with
vid enabled. It is racy to do irr_pending = rvi != 0 on vmexit either.
The code should be something like that:
 irr_pending = (rvi != 0) ? : apic_search_irr(apic) != -1;
But we do not want to do that on each exit since rvi will be mostly
zero and irr is, more often than not, empty.

--
			Gleb.