From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58355) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RGEMj-0002bX-DN for qemu-devel@nongnu.org; Tue, 18 Oct 2011 14:26:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RGEMh-0005Oe-J9 for qemu-devel@nongnu.org; Tue, 18 Oct 2011 14:26:17 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:44192) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RGEMg-0005OY-W9 for qemu-devel@nongnu.org; Tue, 18 Oct 2011 14:26:15 -0400 Received: from moweb002.kundenserver.de (moweb002.kundenserver.de [172.19.20.108]) by fmmailgate02.web.de (Postfix) with ESMTP id C90231B50A063 for ; Tue, 18 Oct 2011 20:26:11 +0200 (CEST) Message-ID: <4E9DC4BD.6040208@web.de> Date: Tue, 18 Oct 2011 20:26:05 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4E9D734C.2060504@siemens.com> <20111018124818.GO28776@redhat.com> <4E9D786D.4060802@siemens.com> <20111018133719.GS28776@redhat.com> <4E9D831E.100@siemens.com> <20111018140156.GA4980@redhat.com> <4E9D886E.3090201@siemens.com> <20111018150834.GA6103@redhat.com> <4E9D99BE.2030600@siemens.com> <4E9DA18A.8040001@siemens.com> <20111018170640.GB6362@redhat.com> In-Reply-To: <20111018170640.GB6362@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCE85311D32FA11F7099A6F40" Subject: Re: [Qemu-devel] [RFC][PATCH 28/45] qemu-kvm: msix: Drop tracking of used vectors List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Alex Williamson , Marcelo Tosatti , Avi Kivity , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCE85311D32FA11F7099A6F40 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-10-18 19:06, Michael S. Tsirkin wrote: > On Tue, Oct 18, 2011 at 05:55:54PM +0200, Jan Kiszka wrote: >> On 2011-10-18 17:22, Jan Kiszka wrote: >>> What KVM has to do is just mapping an arbitrary MSI message >>> (theoretically 64+32 bits, in practice it's much of course much less)= to >> >> ( There are 24 distinguishing bits in an MSI message on x86, but that'= s >> only a current interpretation of one specific arch. ) >=20 > Confused. vector mask is 8 bits. the rest is destination id etc. Right, but those additional bits like the destination make different messages. We have to encode those 24 bits into a unique GSI number and restore them (by table lookup) on APIC injection inside the kernel. If we only had to encode 256 different vectors, we would be done already. >=20 >>> a single GSI and vice versa. As there are less GSIs than possible MSI= >>> messages, we could run out of them when creating routes, statically o= r >>> lazily. >>> >>> What would probably help us long-term out of your concerns regarding >>> lazy routing is to bypass that redundant GSI translation for dynamic >>> messages, i.e. those that are not associated with an irqfd number or = an >>> assigned device irq. Something like a KVM_DELIVER_MSI IOCTL that acce= pts >>> address and data directly. >> >> This would be a trivial extension in fact. Given its beneficial impact= >> on our GSI limitation issue, I think I will hack up something like tha= t. >> >> And maybe this makes a transparent cache more reasonable. Then only ol= d >> host kernels would force us to do searches for already cached messages= =2E >> >> Jan >=20 > Hmm, I'm not all that sure. Existing design really allows > caching the route in various smart ways. We currently do > this for irqfd but this can be extended to ioctls. > If we just let the guest inject arbitrary messages, > that becomes much more complex. irqfd and kvm device assignment do not allow us to inject arbitrary messages at arbitrary points. The new API offers kvm_msi_irqfd_set and kvm_device_msix_set_vector (etc.) for those scenarios to set static routes from an MSI message to a GSI number (+they configure the related backends). >=20 > Another concern is mask bit emulation. We currently > handle mask bit in userspace but patches > to do them in kernel for assigned devices where seen > and IMO we might want to do that for virtio as well. >=20 > For that to work the mask bit needs to be tied to > a specific gsi or specific device, which does not > work if we just inject arbitrary writes. Yes, but I do not see those valuable plans being negatively affected. Jan --------------enigCE85311D32FA11F7099A6F40 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/ iEYEARECAAYFAk6dxL0ACgkQitSsb3rl5xQ2gACdEbCYg/+M5BxV7KbxUXQ7TK9/ SzgAoJeOn1Gq7V3ui9zwIhvzDfPJxOWe =/DcY -----END PGP SIGNATURE----- --------------enigCE85311D32FA11F7099A6F40--