From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Bader Subject: Re: Question about apic ipi interface Date: Thu, 23 May 2013 11:24:56 +0200 Message-ID: <519DE068.1050205@canonical.com> References: <51765D56.1000906@canonical.com> <518A7CC0.6030504@canonical.com> <20130522194007.GE10617@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4669785309395605526==" Return-path: In-Reply-To: <20130522194007.GE10617@phenom.dumpdata.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: Konrad Rzeszutek Wilk Cc: Lin Ming , "xen-devel@lists.xensource.com" , zhenzhong.duan@oracle.com, Ben Guthro List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============4669785309395605526== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigF9E1BD3120EB432BD2697EAB" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF9E1BD3120EB432BD2697EAB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 22.05.2013 21:40, Konrad Rzeszutek Wilk wrote: > On Wed, May 08, 2013 at 06:26:40PM +0200, Stefan Bader wrote: >> On 23.04.2013 12:07, Stefan Bader wrote: >>> I was looking at some older patch and there is one thing I do not und= erstand. >>> >>> commit f447d56d36af18c5104ff29dcb1327c0c0ac3634 >>> xen: implement apic ipi interface >>> >>> Specifically there the implementation of xen_send_IPI_mask_allbutself= (). >>> >>> void xen_send_IPI_mask_allbutself(const struct cpumask *mask, >>> int vector) >>> { >>> unsigned cpu; >>> unsigned int this_cpu =3D smp_processor_id(); >>> >>> if (!(num_online_cpus() > 1)) >>> return; >>> >>> for_each_cpu_and(cpu, mask, cpu_online_mask) { >>> if (this_cpu =3D=3D cpu) >>> continue; >>> >>> xen_smp_send_call_function_single_ipi(cpu); >>> } >>> } >>> >>> Why is this using xen_smp_send_call_function_single_ipi()? This dumps= the >>> supplied vector and always uses XEN_CALL_FUNCTION_SINGLE_VECTOR. In c= ontrast the >>> xen_send_IPI_all() and xen_send_IPI_self() keep the (mapped) vector. >>> >>> Mildly wondering about whether call function would need special casin= g (just >>> because xen_smp_send_call_function_ipi() is special). But I don't hav= e the big >>> picture there. >>> >> >> This never got really answered, so lets try this: Does the following p= atch seem >> to make sense? I know, it has not caused any obvious regressions but a= t least >> this would look more in agreement with the other code. It has not blow= n up on a >> normal boot either. >> Ben, is there a simple way that I would trigger the problem you had? >> >> -Stefan >> >> >> From e13703426f367c618f2984d376289b197a8c0402 Mon Sep 17 00:00:00 2001= >> From: Stefan Bader >> Date: Wed, 8 May 2013 16:37:35 +0200 >> Subject: [PATCH] xen: Clean up apic ipi interface >> >> Commit f447d56d36af18c5104ff29dcb1327c0c0ac3634 introduced the >> implementation of the PV apic ipi interface. But there were some >> odd things (it seems none of which cause really any issue but >> maybe they should be cleaned up anyway): >> - xen_send_IPI_mask_allbutself (and by that xen_send_IPI_allbutself) >> ignore the passed in vector and only use the CALL_FUNCTION_SINGLE >> vector. While xen_send_IPI_all and xen_send_IPI_mask use the vector= =2E >> - physflat_send_IPI_allbutself is declared unnecessarily. It is never= >> used. >> >> This patch tries to clean up those things. >> >> Signed-off-by: Stefan Bader >=20 > Looks very similar to=20 >=20 > https://patchwork.kernel.org/patch/2414311/ >=20 > So two people pointing out the same thing.=20 Yeah, from this discussion and further looking into it I am relatively su= re this has no visible effect either way because there currently is no user of th= e "odd" implementations. >> --- >> arch/x86/xen/smp.c | 10 ++++------ >> arch/x86/xen/smp.h | 1 - >> 2 files changed, 4 insertions(+), 7 deletions(-) >> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c >> index 8ff3799..fb44426 100644 >> --- a/arch/x86/xen/smp.c >> +++ b/arch/x86/xen/smp.c >> @@ -576,24 +576,22 @@ void xen_send_IPI_mask_allbutself(const struct c= pumask *mask, >> { >> unsigned cpu; >> unsigned int this_cpu =3D smp_processor_id(); >> + int xen_vector =3D xen_map_vector(vector); >> >> - if (!(num_online_cpus() > 1)) >> + if (!(num_online_cpus() > 1) || (xen_vector < 0)) >> return; >> >> for_each_cpu_and(cpu, mask, cpu_online_mask) { >> if (this_cpu =3D=3D cpu) >> continue; >> >> - xen_smp_send_call_function_single_ipi(cpu); >> + xen_send_IPI_one(cpu, xen_vector); >> } >> } >> >> void xen_send_IPI_allbutself(int vector) >> { >> - int xen_vector =3D xen_map_vector(vector); >> - >> - if (xen_vector >=3D 0) >> - xen_send_IPI_mask_allbutself(cpu_online_mask, xen_vect= or); >> + xen_send_IPI_mask_allbutself(cpu_online_mask, vector); >> } >> >> static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id)= >> diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h >> index 8981a76..c7c2d89 100644 >> --- a/arch/x86/xen/smp.h >> +++ b/arch/x86/xen/smp.h >> @@ -5,7 +5,6 @@ extern void xen_send_IPI_mask(const struct cpumask *ma= sk, >> extern void xen_send_IPI_mask_allbutself(const struct cpumask *mask, >> int vector); >> extern void xen_send_IPI_allbutself(int vector); >> -extern void physflat_send_IPI_allbutself(int vector); >> extern void xen_send_IPI_all(int vector); >> extern void xen_send_IPI_self(int vector); >> >> --=20 >> 1.7.9.5 >> >=20 >=20 --------------enigF9E1BD3120EB432BD2697EAB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCgAGBQJRneBoAAoJEOhnXe7L7s6j2ioP+gM5ReFqFfX2hsiUg72T4trc s/zpWmNtLeP3pvCcyzaofc8KiUKe1y7MITuYeg4rImNpIkS7yFdxDUuqstgxowMS TqaVQefBEIoMbdrsBnP4/tQrOt5JdKnjdwZ7aH7MUPVj/ItDzRRRVix8AcWRNRyd 4l78YpWYTsup9GXEr+KhzYRbwKfRSQ/LGMR164OnwVLbMeOexLDJhBqGSlVuBiFK DhIiCq3Qd2yrK7RgSktLAPP5wb6O+4RuVIux+0mYs2bKudG/F6QB5EbGGrSkF48y 2LkTSNsTXPaqa3ixU36JnOCQwDDYUFc+h5sLfwLcDncBtsoBhfBF+N6aLqICb47m WMugMH451ZiC7KYR89qpt9S0+LVIrRHQKzeutGFduUYL3qd2XDGFhJCuS7fVcIU3 iBFYWYujkaBADaaPaiV2Rfc0y6GHMaP6LQuoH/BtZJFP5L2w0wTKgE/Mb0ieVZMU zD1N/DkyP5sZj5YsoC9joNbcGP5bDIniUbnzpfWZq4RxFLuC3aMCn7slPx9avCXT weBjgxdGqyqsxvTnL4O9g5AQkoP6VhWUgZ2W6RYPiObdeQSOH+YJDeOBHdhZc+MP e4lgdixdUcXshiUo6R7SHWZIRQh7fA5AI7I9SdI2vnefuW6uyl8NnC+G0yBg7RCe 9Ng9GVlO+zbr7XFetjwm =TacX -----END PGP SIGNATURE----- --------------enigF9E1BD3120EB432BD2697EAB-- --===============4669785309395605526== 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 --===============4669785309395605526==--