From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42562) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Thzq4-0003nZ-Kt for qemu-devel@nongnu.org; Mon, 10 Dec 2012 04:39:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Thzq0-000623-HW for qemu-devel@nongnu.org; Mon, 10 Dec 2012 04:39:52 -0500 Received: from mout.web.de ([212.227.17.11]:53290) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Thzq0-00061p-65 for qemu-devel@nongnu.org; Mon, 10 Dec 2012 04:39:48 -0500 Message-ID: <50C5ADDB.1010503@web.de> Date: Mon, 10 Dec 2012 10:39:39 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <20121206075935.GA10837@redhat.com> <50C19CB2.8090808@web.de> <20121210093638.GA25390@redhat.com> In-Reply-To: <20121210093638.GA25390@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4959DFB191E59E789148AB44" Subject: Re: [Qemu-devel] removing on-demand msix vector allocation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: "qemu-devel@nongnu.org" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4959DFB191E59E789148AB44 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2012-12-10 10:36, Michael S. Tsirkin wrote: > On Fri, Dec 07, 2012 at 08:37:22AM +0100, Jan Kiszka wrote: >> On 2012-12-06 08:59, Michael S. Tsirkin wrote: >>> I've been looking at handling of msix masking >>> in qemu. It looks like all of virtio,vfio and >>> device assignment implemented their own >>> similar but slightly different thing. >>> So I am inclined to move this handling to common >>> code in msix.c, adding irqfd support right there. >>> >>> While doing this rework, one of the more painful >>> bits of code to change is the code that dynamically >>> allocates msix table entries as we inject msi. >>> If this actually triggers it's going to be >>> painfully slow as route changes are rcu >>> write side in kernel. >>> Since recent kernels support direct injection, >>> do we care anymore? I think if you run out of >>> vectors, it's better to simply disable irqchip >>> than try to limp along changing routes all the time. >> >> But how would the logic without dynamic allocation look like? Always >> configure a route in the PCI layer if an MSI/MSI-X entry is enabled? >> That would also affect emulated devices that don't use irqfd, thus you= >> would waste routing entries. >=20 > Yes.=20 > So we can fail during initialization and ask user to > disable irqchip: at the moment, at least in my testing, > dynamic swap out of MSI entries performs very badly > anyway. That would be a poor approach as it regresses needlessly even over latest kernels. We only allocate/flush dynamically over older kernels without direct MSI injections. What we need is a flag, set e.g. on msi[x]_init, to give the core a hint if it should allocate static routes for irqfd or if it will be able to use direct injection later on. Then we can simply do static allocation unconditionally on kernels without direct injection. Jan --------------enig4959DFB191E59E789148AB44 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDFrd4ACgkQitSsb3rl5xRp6ACg24ichSwoq6wT5cZRogOaihfj jF8AoLcDZd51mPI5QTlwnMfWUPzCit22 =0W13 -----END PGP SIGNATURE----- --------------enig4959DFB191E59E789148AB44--