From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [RFC][PATCH 28/45] qemu-kvm: msix: Drop tracking of used vectors Date: Tue, 18 Oct 2011 20:26:05 +0200 Message-ID: <4E9DC4BD.6040208@web.de> 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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCE85311D32FA11F7099A6F40" 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]:44203 "EHLO fmmailgate02.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751889Ab1JRS0P (ORCPT ); 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 CC99B1B50A321 for ; Tue, 18 Oct 2011 20:26:11 +0200 (CEST) In-Reply-To: <20111018170640.GB6362@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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--