From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v8 15/17] vmx: VT-d posted-interrupt core logic handling Date: Tue, 27 Oct 2015 13:22:13 +0100 Message-ID: <1445948533.2937.135.camel@citrix.com> References: <1444640103-4685-1-git-send-email-feng.wu@intel.com> <1444640103-4685-16-git-send-email-feng.wu@intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0178412235093409912==" Return-path: In-Reply-To: <1444640103-4685-16-git-send-email-feng.wu@intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Feng Wu , xen-devel@lists.xen.org Cc: George Dunlap , Andrew Cooper , Kevin Tian , Keir Fraser , Jan Beulich List-Id: xen-devel@lists.xenproject.org --===============0178412235093409912== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-urwJOH5Jze28RiXtNWiI" --=-urwJOH5Jze28RiXtNWiI Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Oh, one more thing. On Mon, 2015-10-12 at 16:55 +0800, Feng Wu wrote:=20 > diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c > index e448b31..cad70b4 100644 > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > +void vmx_vcpu_block_cancel(struct vcpu *v) > +{ > + unsigned long flags; > + > + if ( !has_arch_pdevs(v->domain) ) > + return; > + > + spin_lock_irqsave(&v->arch.hvm_vmx.pi_lock, flags); > + > + if ( !test_bit(_VPF_blocked, &v->pause_flags) ) > + { > + struct pi_desc *pi_desc =3D &v->arch.hvm_vmx.pi_desc; > + unsigned int pi_block_cpu; > + > + /* the vCPU is not on any blocking list. */ > + pi_block_cpu =3D v->arch.hvm_vmx.pi_block_cpu; > + if ( pi_block_cpu =3D=3D NR_CPUS ) > + goto out; > + > + /* > + * Set 'NV' field back to posted_intr_vector, so the > + * Posted-Interrupts can be delivered to the vCPU by > + * VT-d HW after it is scheduled to run. > + */ > + write_atomic(&pi_desc->nv, posted_intr_vector); > + > + spin_lock(&per_cpu(pi_blocked_vcpu_lock, pi_block_cpu)); > + > + /* > + * v->arch.hvm_vmx.pi_block_cpu =3D=3D NR_CPUS here means the > vCPU was > + * removed from the blocking list while we are acquiring the > lock. > + */ > + if ( v->arch.hvm_vmx.pi_block_cpu =3D=3D NR_CPUS ) > + { > + spin_unlock(&per_cpu(pi_blocked_vcpu_lock, > pi_block_cpu)); > + goto out; > + } > + > + list_del(&v->arch.hvm_vmx.pi_blocked_vcpu_list); > + v->arch.hvm_vmx.pi_block_cpu =3D NR_CPUS; > + spin_unlock(&per_cpu(pi_blocked_vcpu_lock, pi_block_cpu)); > + } > + > +out: > + spin_unlock_irqrestore(&v->arch.hvm_vmx.pi_lock, flags); > +} > + > +void vmx_vcpu_wake_prepare(struct vcpu *v) > +{ > This function looks exactly identical to vmx_vcpu_block_cancel(), with the only exception of... > + unsigned long flags; > + > + if ( !has_arch_pdevs(v->domain) ) > + return; > + > + spin_lock_irqsave(&v->arch.hvm_vmx.pi_lock, flags); > + > + if ( !test_bit(_VPF_blocked, &v->pause_flags) ) > + { > + struct pi_desc *pi_desc =3D &v->arch.hvm_vmx.pi_desc; > + unsigned int pi_block_cpu; > + > + /* the vCPU is not on any blocking list. */ > + pi_block_cpu =3D v->arch.hvm_vmx.pi_block_cpu; > + if ( pi_block_cpu =3D=3D NR_CPUS ) > + goto out; > + > + /* > + * We cannot set 'SN' here since we don't change 'SN' during > lazy > + * context switch, if we set 'SN' here, we may end up in the > situation > + * that the vCPU is running with 'SN' set. > + */ > + > ... this comment (which is present here and not there). Is that the case, or am I overlooking something? In any case, there seems to be a lot of common code between the twos. If we are to keep this design, I think common code should be factored. Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-urwJOH5Jze28RiXtNWiI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEUEABECAAYFAlYvbHUACgkQk4XaBE3IOsTBjQCfSlBNK/X73TkG6bBmlf6j1AIG 3vMAl2rxf7sTcP80jYyEbfJZO4Nikik= =1fLZ -----END PGP SIGNATURE----- --=-urwJOH5Jze28RiXtNWiI-- --===============0178412235093409912== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0178412235093409912==--