2016-04-15 11:31+0800, Peter Xu: > This patch allows Intel IR work with splitted irqchip. Two more fields > are added to IOAPICCommonState to support the translation process (For > future AMD IR support, we will need to provide another AMD-specific > callback for int_remap()). In split irqchip mode, IOAPIC is working in > user space, only update kernel irq routes when entry changed. When IR is > enabled, we directly update the kernel with translated messages. It > works just like a kernel cache for the remapping entries.
(Patches are nice, thanks, I'll be looking how to slap EIM on top.) > Since KVM irqfd is using kernel gsi routes to deliver interrupts, as > long as we can support split irqchip, we will support irqfd as > well. Also, since kernel gsi routes will cache translated interrupts, > irqfd delivery will not suffer from any performance impact due to IR. > > And, since we supported irqfd, vhost devices will be able to work > seamlessly with IR now. Logically this should contain both vhost-net and > vhost-user case. Doesn't look that all callers of kvm_irqchip_update_msi_route() are IR aware. I think wrapping the remapping around it might be easiest, kvm_arch_fixup_msi_route() is another candidate. > Here we avoided capturing IOMMU IR invalidation, based on the assumption > that, guest kernel will always first update IR entry, then IOAPIC > entry. As long as guest follows this order to update IOAPIC entries, we > should be safe. The OS configures IOAPIC, MSI and IR independently. e.g. changing the destination LAPIC only updates IRTE and can happen anytime. You have to update kvm_irqchip routes when IRTE changes.
