From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37671) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1av75i-0005ug-Mz for qemu-devel@nongnu.org; Tue, 26 Apr 2016 13:48:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1av75e-0007d1-MK for qemu-devel@nongnu.org; Tue, 26 Apr 2016 13:48:06 -0400 Received: from mout.web.de ([212.227.17.11]:62965) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1av75e-0007cp-Db for qemu-devel@nongnu.org; Tue, 26 Apr 2016 13:48:02 -0400 References: <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> <20160426145945.GD19789@potion> <571F8901.8000100@web.de> <20160426160744.GE19789@potion> From: Jan Kiszka Message-ID: <571FA9C1.7000209@web.de> Date: Tue, 26 Apr 2016 19:47:45 +0200 MIME-Version: 1.0 In-Reply-To: <20160426160744.GE19789@potion> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= 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 On 2016-04-26 18:07, Radim Krčmář wrote: > 2016-04-26 17:28+0200, Jan Kiszka: >> On 2016-04-26 16:59, Radim Krčmář wrote: >>> 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. >> >> irqfd for userspace sources is a bit clumsy from the API POV. On the >> other hand, we need to tweak the routing API anyway to achieve the same >> address extension there, too. > > I agree, both of them should change. KVM_SIGNAL_MSI was added just > because the route-based injection in kvm_irqchip_send_msi() sucked; > maybe we could find a good solution now, but the direct interface is > already here ... We won't get away without irq routes because we need them for sources that only issue binary signals for interrupt events (in-kernel, eventfd from userspace). In fact, those sources should not know more than that about their irqs. But we also do not want them to route everything through userspace for on-the-fly translation and reinjection to kvm. Jan