From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Bader Subject: Re: Question about apic ipi interface Date: Thu, 09 May 2013 16:33:49 +0200 Message-ID: <518BB3CD.7000402@canonical.com> References: <51765D56.1000906@canonical.com> <518A7CC0.6030504@canonical.com> <1368089794.17285.111.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2112513930845687621==" Return-path: In-Reply-To: <1368089794.17285.111.camel@zakaz.uk.xensource.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: Ian Campbell Cc: "xen-devel@lists.xensource.com" , Ben Guthro , Konrad Rzeszutek Wilk , Lin Ming List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2112513930845687621== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigCC580DB61867D50E6BEF097C" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCC580DB61867D50E6BEF097C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 09.05.2013 10:56, Ian Campbell wrote: > On Wed, 2013-05-08 at 17:26 +0100, 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? >=20 > It certainly seems too. Although I traced the call chain back to > default_send_IPI_allbutself() which nothing actually seems to call. Or > my grep is faulty... >=20 > There is a call path via send_IPI_allbutself which looks to only > potentially be called as: > apic->send_IPI_allbutself(APIC_DM_NMI); > apic->send_IPI_allbutself(NMI_VECTOR); > (the other calls are in native_smp_foo which I assume doesn't apply). If I am not missing something send_IPI_allbutself as a function only exis= ts on non-x86 archs. And as you say the other users seem to be in a function th= at gets replaced under Xen PV. >=20 > xen_map_vector( doesn't seem to handle those two, I'm not sure if that > will constitute a regression since it doesn't seem likely that either o= f > those would have worked properly with the current code either. Yeah best case it would hide unimplemented vectors to be used. With the c= hange this would at least be obvious. Like I found when realizing that all this= only applies to dom0 because other PV domUs seem to get the noop_apic assigned= =2E So one can do a "echo l >/proc/sysrq-trigger" and get vector 0x2 (NMI_VECTOR= ) not implemented (in dom0). Luckily the only bad thing happening is a delay an= d no stack traces being produced. -Stefan >=20 > Ian. >=20 --------------enigCC580DB61867D50E6BEF097C 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/ iQIcBAEBCgAGBQJRi7PNAAoJEOhnXe7L7s6jIHwQAManQMgY90xQ2hKAUvZ94MUv E0R70TdYrMauwyoN6HgK9FGYprqk2tngKTZw145gnbJbtw8bNlIxX3jsZAGY5/gb j1aXFlfx3aY2hdz/0BVBAyDcQhz7woB4wXpgffcjxCQnqJYnn1czHyxfMDMPXqah gAFAcOFuZ3S0hUHX5ufO0sHeEIv7RrjBU+anGV5guiF9mZB3iJYuVHMYgtYht+yy 14mtg5u15WUQOI+3nVMJyJm1goZvkfyZvncLp5PdciydjfupfGINFbAplDIPqsG1 IXDS0RcgFBgA00IM6NlsBvMYx3grfVqcpJwPPTMuOS5IJSoLyaHZ9X304pM7Pu2R LU/f0m3FegxX7A+qOcW/mg9T8T7VBF8LvbN4DBS7rlVP5Ij+bm/F2xrsm9kon9Qh gUEhZfJa7kpL1SQVLpbDJtbrS1rVGBZWO3KaZs8YFwSm/PHUc90lQ5SOseKWxISt FXhSRmmn+Xo2EAOWR9V09yrZ4VuHxB4LpfLg9VHhfSrrGTkxVFneTr2fzFXLhe55 yft9UM6iP+1xUteYWuCAmspx8Q00Fp548ctgUI0VDFs+JID2t7IGLpL95SWuj6yR hf24nplKpmKEUAUuCzYySXS9EJl/7DCr1mdoMu7QmcFOQLnS9URw9ZR5rcn3k8QF Xs+8ijKmZVyj4nYmT+Oc =dO0x -----END PGP SIGNATURE----- --------------enigCC580DB61867D50E6BEF097C-- --===============2112513930845687621== 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 --===============2112513930845687621==--