From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [RFC PATCH 21/24] ARM: vITS: handle INVALL command Date: Tue, 6 Dec 2016 22:32:56 +0100 Message-ID: <1481059976.3445.98.camel@citrix.com> References: <20160928182457.12433-1-andre.przywara@arm.com> <20160928182457.12433-22-andre.przywara@arm.com> <0fce93d4-605b-78b9-9146-b4d65eb4e86a@arm.com> <4a8bb842-bac5-942f-ca84-d223f43ab50b@arm.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1937574010491882462==" Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cENMf-000227-Gt for xen-devel@lists.xenproject.org; Tue, 06 Dec 2016 21:33:29 +0000 In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Stefano Stabellini , Julien Grall Cc: Andre Przywara , Steve Capper , george.dunlap@citrix.com, Vijay Kilari , xen-devel List-Id: xen-devel@lists.xenproject.org --===============1937574010491882462== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-d0dm4y79iNwqttKLkC/x" --=-d0dm4y79iNwqttKLkC/x Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2016-12-06 at 11:36 -0800, Stefano Stabellini wrote: > On Tue, 6 Dec 2016, Julien Grall wrote: > >=C2=A0 > > > Another approach is to let the scheduler know that migration is > > > slower. > > > In fact this is not a new problem: it can be slow to migrate > > > interrupts, > > > even few non-LPIs interrupts, even on x86. I wonder if the Xen > > > scheduler > > > has any knowledge of that (CC'ing George and Dario). I guess > > > that's the > > > reason why most people run with dom0_vcpus_pin. > >=20 > > I gave a quick look at x86, arch_move_irqs is not implemented. Only > > PIRQ are > > migrated when a vCPU is moving to another pCPU. > >=C2=A0 > > In the case of ARM, we directly modify the configuration of the > > hardware. This > > adds much more overhead because you have to do an hardware access > > for every > > single IRQ. >=20 > George, Dario, any comments on whether this would make sense and how > to > do it? > I was actually looking into this, but I think I don't know enough of ARM in general, and about this issue in particular to be useful. That being said, perhaps you could clarify a bit what you mean with "let the scheduler know that migration is slower". What you'd expect the scheduler to do? Checking the code, as Julien says, on x86 all we do when we move vCPUs around is calling=C2=A0evtchn_move_pirqs(). In fact, it was right that function that was called multiple times in schedule.c, and it was you that (as Julien pointed out already): 1) in=C2=A05bd62a757b9 ("xen/arm: physical irq follow virtual irq"),=C2=A0 =C2=A0 =C2=A0created arch_move_irqs() as something that does something on A= RM, =C2=A0 =C2=A0and as an empty stub in x86. 2) in=C2=A014f7e3b8a70 ("xen: introduce sched_move_irqs"), generalized=C2= =A0 =C2=A0 =C2=A0schedule.c code by implementing=C2=A0sched_move_irqs(). So, if I understood correctly what Julien said here "I don't think this would modify the irq migration work flow. etc.", it looks to me that the suggested lazy approach could be a good solution (but I'm saying that lacking the knowledge of what it would actually mean to implement that). If you want something inside the scheduler that sort of delays the wakeup of a domain on the new pCPU until some condition in IRQ handling code is verified (but, please, confirm whether or not it was this that you were thinking of), my thoughts, out of the top of my head about this are: - in general, I think it should be possible; - it has to be arch-specific, I think? - It's easy to avoid the vCPU being woken as a consequence of =C2=A0 vcpu_wake() being called, e.g., at the end of=C2=A0vcpu_migrate(); - we must be careful about not forgetting/failing to (re)wakeup the=C2=A0 =C2=A0 vCPU when the condition verifies Sorry if I can't be more useful than this for now. :-/ Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-d0dm4y79iNwqttKLkC/x 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 iQIcBAABCAAGBQJYRy6KAAoJEBZCeImluHPu8SEQAJaoehYjCG7k14ycEK9ufCbt ojTcdsteVF3ngSA+sTBBlghJMqXOs/Ul5gnROFZQxenf7467g0P8PhoKV0/9YnST uPMeNW/hOUnIWATreMrOlpK1wUUMW2bhoa3wyyJBCtK1LZjMLXHOFStJA7PE0IQ8 zaPWdzNgHRo5c/86qfLsZBunvVXaLZImsteMI8UISzNLAkIdYyXUCJo/g0fFSbsA 4f9S9GiLIwAx07RNmV3tFMVgXrhKGW451dsMRo6E/FS5DJ+trDAptCQtJEA3AMCs /dKjgFAJLbiwS0kQEawZZ1wFg1tWw0LL0+klVAzHDMJ72JvAqtU+8Xsm4kFaLZo0 c7IZ4FSclPEU2+wN17T/oYhvQaTDsf8/VwVj8DwCsCn83bR6JH8JmhG+s3Ve7xh6 fg5DLAcZGol+ptVH08za4i1pn7fIcnqbkDEXjpP2DjZ1/4EklmRHi0ymPuXQLbo4 74jCnPiYqfPZjnL7yae71HbGMc84S4D96BwTkeNDjUtR41EyvKaZH3PsoJNisCbh EdxpzLI99uFODZpciGxjRNX9ZkNlvj6yJXu1+VIpJW/fQ11rO6vvcp/05eS34My3 IQRUwetW04719YqZmVMgfIMvjvcMRvxCDCeE9S6DwEKR1Q1sFpaSb8xmJS7tX5uJ +9Eo/hG2pWiv0q6koQ1a =ys09 -----END PGP SIGNATURE----- --=-d0dm4y79iNwqttKLkC/x-- --===============1937574010491882462== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============1937574010491882462==--