[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 12/13] q35: ioapic: add support for split irq

From: Radim Krčmář
Subject: Re: [Qemu-devel] [PATCH v3 12/13] q35: ioapic: add support for split irqchip and irqfd
Date: Fri, 15 Apr 2016 17:31:58 +0200

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]