From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:33725)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rkrcmar@redhat.com>) id 1av5Wl-00006a-Ks
	for qemu-devel@nongnu.org; Tue, 26 Apr 2016 12:07:56 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <rkrcmar@redhat.com>) id 1av5Wg-0002Bm-Gz
	for qemu-devel@nongnu.org; Tue, 26 Apr 2016 12:07:55 -0400
Received: from mx1.redhat.com ([209.132.183.28]:51772)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rkrcmar@redhat.com>) id 1av5Wg-0002Bi-Bf
	for qemu-devel@nongnu.org; Tue, 26 Apr 2016 12:07:50 -0400
Date: Tue, 26 Apr 2016 18:07:44 +0200
From: Radim =?utf-8?B?S3LEjW3DocWZ?= <rkrcmar@redhat.com>
Message-ID: <20160426160744.GE19789@potion>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <571F8901.8000100@web.de>
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [PATCH v4 00/16] IOMMU: Enable interrupt remapping
 for Intel IOMMU
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: Peter Xu <peterx@redhat.com>, 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 17:28+0200, Jan Kiszka:
> On 2016-04-26 16:59, Radim Kr=C4=8Dm=C3=A1=C5=99 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 =3D irq->dest). We may possibly need to use the high 32 bi=
ts
>>>> 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. Current=
ly,
>>> 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?).
>>=20
>> 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. :])
>>=20
>> The conceptually different idea is forcing all userspace interrupts
>> through irqfd routes, which would obsolete the ad-host inject.
>=20
> 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 ...