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 ...