Re: [Qemu-devel] [PATCH v4 00/16] IOMMU: Enable interrupt remapping for Intel IOMMU

[Jan Kiszka <jan.kiszka@web.de>]

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