From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:49290) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RG7Bh-00055X-0u for qemu-devel@nongnu.org; Tue, 18 Oct 2011 06:46:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RG7Bf-0001pU-Lp for qemu-devel@nongnu.org; Tue, 18 Oct 2011 06:46:24 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:47552) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RG7Bf-0001pD-5X for qemu-devel@nongnu.org; Tue, 18 Oct 2011 06:46:23 -0400 Received: from moweb001.kundenserver.de (moweb001.kundenserver.de [172.19.20.114]) by fmmailgate02.web.de (Postfix) with ESMTP id 876681B45AA69 for ; Mon, 17 Oct 2011 21:19:39 +0200 (CEST) Message-ID: <4E9C7FC6.7040009@web.de> Date: Mon, 17 Oct 2011 21:19:34 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4E9C0C42.60201@redhat.com> <4E9C0F5C.8000602@siemens.com> <20111017153756.GA7876@redhat.com> In-Reply-To: <20111017153756.GA7876@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig553DCE31340011882B8FA42F" Subject: Re: [Qemu-devel] [RFC][PATCH 12/45] msi: Introduce MSIRoutingCache 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) --------------enig553DCE31340011882B8FA42F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-10-17 17:37, Michael S. Tsirkin wrote: > On Mon, Oct 17, 2011 at 01:19:56PM +0200, Jan Kiszka wrote: >> On 2011-10-17 13:06, Avi Kivity wrote: >>> On 10/17/2011 11:27 AM, 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 change= d >>>> for QEMU-originated MSI messages by adding direct MSI injection, we = will >>>> still need this translation for irqfd-originated messages. The >>>> MSIRoutingCache will allow to track those registrations and update t= hem >>>> lazily before the actual delivery. This avoid having to track MSI >>>> vectors at device level (like qemu-kvm currently does). >>>> >>>> >>>> +typedef enum { >>>> + MSI_ROUTE_NONE =3D 0, >>>> + MSI_ROUTE_STATIC, >>>> +} MSIRouteType; >>>> + >>>> +struct MSIRoutingCache { >>>> + MSIMessage msg; >>>> + MSIRouteType type; >>>> + int kvm_gsi; >>>> + int kvm_irqfd; >>>> +}; >>>> + >>>> diff --git a/hw/pci.h b/hw/pci.h >>>> index 329ab32..5b5d2fd 100644 >>>> --- a/hw/pci.h >>>> +++ b/hw/pci.h >>>> @@ -197,6 +197,10 @@ struct PCIDevice { >>>> MemoryRegion rom; >>>> uint32_t rom_bar; >>>> =20 >>>> + /* MSI routing chaches */ >>>> + MSIRoutingCache *msi_cache; >>>> + MSIRoutingCache *msix_cache; >>>> + >>>> /* MSI entries */ >>>> int msi_entries_nr; >>>> struct KVMMsiMessage *msi_irq_entries; >>> >>> IMO this needlessly leaks kvm information into core qemu. The cache >>> should be completely hidden in kvm code. >>> >>> I think msi_deliver() can hide the use of the cache completely. For >>> pre-registered events like kvm's irqfd, you can use something like >>> >>> qemu_irq qemu_msi_irq(MSIMessage msg) >>> >>> for non-kvm, it simply returns a qemu_irq that triggers a stl_phys();= >>> for kvm, it allocates an irqfd and a permanent entry in the cache and= >>> returns a qemu_irq that triggers the irqfd. >> >> See my previously mail: you want to track the life-cycle of an MSI >> source to avoid generating routes for identical sources. A messages is= >> not a source. Two identical messages can come from different sources. >=20 > Since MSI messages are edge triggered, I don't see how this > would work without losing interrupts. And AFAIK, > existing guests do not use the same message for > different sources. Just like we handle shared edge-triggered line-base IRQs, shared MSIs are in principle feasible as well. Jan --------------enig553DCE31340011882B8FA42F 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/ iEYEARECAAYFAk6cf8YACgkQitSsb3rl5xSBSgCfVTDyT1MkVEul0TvWHRDsRD6E IdMAoLMkVFQoFgxNF8hUyXdekeJtyDrq =iuBP -----END PGP SIGNATURE----- --------------enig553DCE31340011882B8FA42F--