From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38996) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RGELK-0001oI-IH for qemu-devel@nongnu.org; Tue, 18 Oct 2011 14:24:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RGELJ-0005B6-98 for qemu-devel@nongnu.org; Tue, 18 Oct 2011 14:24:50 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]:57393) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RGELI-0005B2-RF for qemu-devel@nongnu.org; Tue, 18 Oct 2011 14:24:49 -0400 Received: from moweb001.kundenserver.de (moweb001.kundenserver.de [172.19.20.114]) by fmmailgate01.web.de (Postfix) with ESMTP id 5BE0719E9616A for ; Tue, 18 Oct 2011 20:24:47 +0200 (CEST) Message-ID: <4E9DC467.3010506@web.de> Date: Tue, 18 Oct 2011 20:24:39 +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="------------enig6F1F471171F354A04CA8544B" 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) --------------enig6F1F471171F354A04CA8544B 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 --------------enig6F1F471171F354A04CA8544B 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/ iEYEARECAAYFAk6dxGcACgkQitSsb3rl5xRH4QCcDsxluVgsJdRMB5/U8Qt3dGtU vFQAoLYccM0pFDW4iBbfW38TjHJYNK/y =SnWo -----END PGP SIGNATURE----- --------------enig6F1F471171F354A04CA8544B--