Hi Pavel, On 06/19/2015 08:37 AM, Pavel Fedin wrote: > Hello! > >> The series therefore allows and mandates the usage of KVM_SET_GSI_ROUTING >> ioctl along with KVM_IRQFD. If the userspace does not define any routing >> table, no irqfd injection can happen. The user-space can use >> KVM_CAP_IRQ_ROUTING to detect whether a routing table is needed. > > Yesterday, half-sleeping in the train back home, i've got a simple idea how to resolve > conflicts with existing static GSI->SPI routing without bringing in any more > inconsistencies. > So far, in current implementation GSI is an SPI index (let alone KVM_IRQ_LINE, because > it's already another story on ARM). In order to maintain this convention we could simply > implement default routing which sets all GSIs to corresponding SPI pins. So, if the > userland never cares about KVM_SET_GSI_ROUTING, everything works as before. But it will be > possible to re-route GSIs to MSI. It will perfectly work because SPI signaling is used > with GICv2m, and MSI with GICv3(+), which cannot be used at the same time. I agree with you and I suggested the same approach in my cover letter. Since applying GSI routing to KVM_IRQ_LINE is quite problematic, I would be also in favour to forbid userspace GSI routing setting and implement it kernel-side. Userspace would only be allowed to define MSI routing entries. I will respin accordingly and validate it further with qemu. Best Regards Eric > > Kind regards, > Pavel Fedin > Expert Engineer > Samsung Electronics Research center Russia > > -- To unsubscribe from this list: send the line "unsubscribe kvm" in
