From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39731) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1av4Sx-0007e3-LG for qemu-devel@nongnu.org; Tue, 26 Apr 2016 10:59:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1av4Su-00078e-Fp for qemu-devel@nongnu.org; Tue, 26 Apr 2016 10:59:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50909) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1av4Su-00078W-AH for qemu-devel@nongnu.org; Tue, 26 Apr 2016 10:59:52 -0400 Date: Tue, 26 Apr 2016 16:59:45 +0200 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Message-ID: <20160426145945.GD19789@potion> References: <571DA823.1030003@web.de> <20160425071806.GF3261@pxdev.xzpeter.org> <571DC61C.9020006@web.de> <20160426073426.GD28545@pxdev.xzpeter.org> <571F1F7F.5050604@web.de> <571F23B2.3000902@web.de> <20160426103819.GE28545@pxdev.xzpeter.org> <571F4840.2060800@web.de> <20160426114051.GF28545@pxdev.xzpeter.org> <571F7A14.9050805@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <571F7A14.9050805@web.de> Subject: Re: [Qemu-devel] [PATCH v4 00/16] IOMMU: Enable interrupt remapping for Intel IOMMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Peter Xu , qemu-devel@nongnu.org, imammedo@redhat.com, rth@twiddle.net, ehabkost@redhat.com, jasowang@redhat.com, marcel@redhat.com, mst@redhat.com, pbonzini@redhat.com, alex.williamson@redhat.com, wexu@redhat.com 2016-04-26 16:24+0200, Jan Kiszka: > On 2016-04-26 13:40, Peter Xu wrote: >> Currently, all the interrupts will be translated into one MSI in >> vtd_generate_msi_message(), in which only 8 bits of dest_id is used >> (msg.dest = irq->dest). We may possibly need to use the high 32 bits >> of MSI address to store the rest dest[31:8]? Don't know whether this >> would be enough though. > > Yes, I ran into this topic as well as I hacked up those line. Currently, > KVM does not support more than 254 vCPUs, so 8 bits of those 32 are > actually fine, and piggy-backing them in an MSI message works. > > Once KVM supports more CPUs, it has to come up with a new userspace > interface to inject APIC events for more than 255 CPUs. Maybe the > existing direct MSI inject with its unused flags could be "bended", > maybe there are already better ideas (Radim?). Adding a flag to msi_msg and taking 3-4 bytes from padding to express x2APIC addresses is reasonable. (It is what my prototype did. :]) The conceptually different idea is forcing all userspace interrupts through irqfd routes, which would obsolete the ad-host inject. > In any case, the KVM layer in userspace will then have to pick up all 32 > destination bits from the IRTE and deliver them via that new interface > to the in-kernel APICs. I'll keep that in mind, thanks.