From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [RFC v1 14/15] Suppress posting interrupts when 'SN' is set Date: Fri, 27 Mar 2015 13:49:06 +0000 Message-ID: <55155FD2.8080503@citrix.com> References: <1427286717-4093-1-git-send-email-feng.wu@intel.com> <1427286717-4093-15-git-send-email-feng.wu@intel.com> <55146D5C.4000305@citrix.com> <551547A9.7090408@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Wu, Feng" , "xen-devel@lists.xen.org" Cc: "Zhang, Yang Z" , "Tian, Kevin" , "keir@xen.org" , "JBeulich@suse.com" List-Id: xen-devel@lists.xenproject.org On 27/03/15 13:45, Wu, Feng wrote: > >> -----Original Message----- >> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com] >> Sent: Friday, March 27, 2015 8:06 PM >> To: Wu, Feng; xen-devel@lists.xen.org >> Cc: Zhang, Yang Z; Tian, Kevin; keir@xen.org; JBeulich@suse.com >> Subject: Re: [Xen-devel] [RFC v1 14/15] Suppress posting interrupts when 'SN' is >> set >> >> On 27/03/15 03:00, Wu, Feng wrote: >>>>> static void vmx_deliver_posted_intr(struct vcpu *v, u8 vector) >>>>> { >>>>> + int r, sn; >>>>> + >>>>> if ( pi_test_and_set_pir(vector, &v->arch.hvm_vmx.pi_desc) ) >>>>> return; >>>>> >>>>> + /* >>>>> + * Currently, we don't support urgent interrupt, all interrupts >>>>> + * are recognized as non-urgent interrupt, so we cannot send >>>>> + * posted-interrupt when 'SN' is set. >>>>> + */ >>>>> + >>>>> + sn = pi_test_sn(&v->arch.hvm_vmx.pi_desc); >>>> Is there anywhere which sets sn at all? I cant spot anywhere. >>>> >>> SN is set in [13/15] while vCPU is going to runnable state. >> Then please do not set SN in the first place if we don't support it. > > What do you mean here. Setting 'SN' can suppress non-urgent interrupt. (we only support this) Sorry, in which case patch 13 shouldn't clear SN then. Either way - we should not be fixing up something in this patch which was introduced in the previous patch. ~Andrew