From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [RFC][PATCH 12/45] msi: Introduce MSIRoutingCache Date: Mon, 17 Oct 2011 21:23:56 +0200 Message-ID: <4E9C80CC.4020608@web.de> References: <20111017154347.GB7876@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBFAAC09B1C9642530E833BF4" Cc: Avi Kivity , Marcelo Tosatti , "kvm@vger.kernel.org" , Alex Williamson , "qemu-devel@nongnu.org" To: "Michael S. Tsirkin" Return-path: Received: from fmmailgate02.web.de ([217.72.192.227]:39390 "EHLO fmmailgate02.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751460Ab1JRJkX (ORCPT ); Tue, 18 Oct 2011 05:40:23 -0400 Received: from moweb002.kundenserver.de (moweb002.kundenserver.de [172.19.20.108]) by fmmailgate02.web.de (Postfix) with ESMTP id 7AA461B490DCF for ; Mon, 17 Oct 2011 21:48:13 +0200 (CEST) In-Reply-To: <20111017154347.GB7876@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBFAAC09B1C9642530E833BF4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-10-17 17:43, Michael S. Tsirkin wrote: > On Mon, Oct 17, 2011 at 11:27:46AM +0200, Jan Kiszka wrote: >> This cache will help us implementing KVM in-kernel irqchip support >> without spreading hooks all over the place. >> >> KVM requires us to register it first and then deliver it by raising a >> pseudo IRQ line returned on registration. While this could be changed >> for QEMU-originated MSI messages by adding direct MSI injection, we wi= ll >> still need this translation for irqfd-originated messages. The >> MSIRoutingCache will allow to track those registrations and update the= m >> lazily before the actual delivery. This avoid having to track MSI >> vectors at device level (like qemu-kvm currently does). >> >> Signed-off-by: Jan Kiszka >=20 > So if many devices are added, exhausting the number of GSIs supported, > we get terrible performance intead of simply failing outright. >=20 > To me, this looks more like a bug than a feature ... If that ever turns out to be a bottleneck, failing looks like the worst we can do. Reporting excessive cache flushes would make some sense and could still be added. Jan --------------enigBFAAC09B1C9642530E833BF4 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 Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6cgMwACgkQitSsb3rl5xSPiACgz48V/JFyaJfbLD9SUgCzRIrv YFoAoOEJCdnOzGXNb7ekJQjZX1TOCPfw =xxqK -----END PGP SIGNATURE----- --------------enigBFAAC09B1C9642530E833BF4--