From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 03/15] xen/tools: tracing: several improvements on IRQs tracing Date: Fri, 2 Jun 2017 01:12:17 +0200 Message-ID: <1496358737.10189.9.camel@citrix.com> References: <149633614204.12814.14390287626133023934.stgit@Solace.fritz.box> <149633843555.12814.16573412358602741145.stgit@Solace.fritz.box> <3b869d43-2925-134e-32a9-76c6cedf35f2@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5670162393810707436==" Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGZGT-0007jG-UZ for xen-devel@lists.xenproject.org; Thu, 01 Jun 2017 23:12:26 +0000 In-Reply-To: <3b869d43-2925-134e-32a9-76c6cedf35f2@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Andrew Cooper , xen-devel@lists.xenproject.org Cc: George Dunlap , Wei Liu , Ian Jackson , Jan Beulich List-Id: xen-devel@lists.xenproject.org --===============5670162393810707436== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-l3GdH6FoFeayIzWaoIWk" --=-l3GdH6FoFeayIzWaoIWk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2017-06-01 at 19:02 +0100, Andrew Cooper wrote: > On 01/06/17 18:33, Dario Faggioli wrote: > > More specifically: > > =C2=A0- the handling of the TRC_HW_IRQ_HANDLED is fixed, both in > > =C2=A0=C2=A0=C2=A0xentrace_format and in xenalyze; > > =C2=A0- simple events for recording when we enter and exit the > > =C2=A0=C2=A0=C2=A0do_IRQ function, as well as when we deal with a guest > > =C2=A0=C2=A0=C2=A0IRQ, are added; > > =C2=A0- tracing of IRQs handled with direct vectors is also > > =C2=A0=C2=A0=C2=A0added. > >=20 > > With all the above, a trace will now look like this (using > > xenalyze): > >=20 > > =C2=A00.001299072 .x- d32768v5 irq_enter, irq 80000000 > > =C2=A00.001299072 .x- d32768v5 irq_direct, vec fa, handler =3D > > 0xffff82d08026d7e4 >=20 > Please consistently use 0x$hex.=C2=A0=C2=A0vec in particular has 10/16ths= of > its > values which are completely ambiguous between hex and decimal. >=20 I fully agree. The file is not super consistent about this already, and I was basically following the suit of the majority of existing cases. But I really do agree, so I'll probably make a pre-patch, that converts everyone to 0x$hex, and then use it in this patch as well. > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0{ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0if ( unlikely(tb_init_done) ) > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0{ > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0struct __packed { > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0uint32_t vec; > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0uint64_t handler; > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0} d; > > + > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0d.vec =3D vector; > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0d.handler =3D (uint64_t)direct_apic_vector[vecto= r]; >=20 > As there is no code inbetween, you can do this as a straight > initialisation of d. >=20 > i.e. >=20 > } d =3D { vector, (uint64_t)direct_apic_vector[vector] }; >=20 > Otherwise, Reviewed-by: Andrew Cooper >=20 Ok, thanks. I'll take care of this, and of all the others print format and style comments. Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-l3GdH6FoFeayIzWaoIWk 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 v2 iQIcBAABCAAGBQJZMJ9RAAoJEBZCeImluHPuAgAP/25vKpTy6A7EzZHUScl1kUmI TLu0l2IQnvBCWQ6t3DuUUQhUVoAChiU7bfnc/O9IThPJLlXrqo+5oo0nCeGGlXBa u2DEGzc6Xv+6KvzRBinAyx4H4LThqi6agGsICoyvq7EjGY9a3EscQaXMNDDqFONt wVFV7ctLh7UnRYt3onGnOX4cgN3PYSsoo//JAc+HmsOAsHE4sEyjnR4+vIdkxLR/ qEbo59qMmhy6Ue5ycRytAck8/xmRsq3f+GugtF3Jeldgg0bNtU972X6F0KedNaI5 MEO8aCroSTBndtww6a+HErFFgcb6I9ABywDJ/DNUuRa29sh7dtIezVwOYX+u9fIp 9GNU3MUZzHKjVQKu2vlmQKck1HRXZwQC4oMPvLdQm6QQzu1IUon+wsKmeE6YGBL0 1Sw7cYvaTVBdih2i2ZGkbYF40NoD8PRE1JZTb3ZAlj+bHn9SvwYE42fRIrV7MSXX kmb75ZB76N2sN4C4dFc8VZ+405H3l7y3r9ZHbW/fHqsX+eFOUWBnpCLeNieHgf3s cr2u8+o9EO7Hir8WgIMuDrF10uHkYlSHnCf4xkAhRW7K/rX6BqvZP74fXnxzxJc4 6BMyw5AA2e7ld1+lf7X5oyOrtrJGeXR6WgPz736lFeD4mE2/NAoOnt+TDgdHcVh7 sSI7QKXi+mKiZuaD9EvF =Q1K8 -----END PGP SIGNATURE----- --=-l3GdH6FoFeayIzWaoIWk-- --===============5670162393810707436== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============5670162393810707436==--