On Fri, Apr 15, 2016 at 05:31:58PM +0200, Radim Krčmář wrote: > 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.
You are right, failed to find this during smoke test. It seems that kvm_arch_fixup_msi_route() is a good place. Thanks! > > > 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. Thanks to point out. Will add one more patch to do that. -- peterx