On 10/17/2011 11:27 AM, Jan Kiszka wrote:
> This cache will help us implementing KVM in-kernel irqchip support
> without spreading hooks all over the place.
>
> KVM requires us to register it first and then deliver it by raising a
> pseudo IRQ line returned on registration. While this could be changed
> for QEMU-originated MSI messages by adding direct MSI injection, we will
> still need this translation for irqfd-originated messages. The
> MSIRoutingCache will allow to track those registrations and update them
> lazily before the actual delivery. This avoid having to track MSI
> vectors at device level (like qemu-kvm currently does).
>
>
> +typedef enum {
> + MSI_ROUTE_NONE = 0,
> + MSI_ROUTE_STATIC,
> +} MSIRouteType;
> +
> +struct MSIRoutingCache {
> + MSIMessage msg;
> + MSIRouteType type;
> + int kvm_gsi;
> + int kvm_irqfd;
> +};
> +
> diff --git a/hw/pci.h b/hw/pci.h
> index 329ab32..5b5d2fd 100644
> --- a/hw/pci.h
> +++ b/hw/pci.h
> @@ -197,6 +197,10 @@ struct PCIDevice {
> MemoryRegion rom;
> uint32_t rom_bar;
>
> + /* MSI routing chaches */
> + MSIRoutingCache *msi_cache;
> + MSIRoutingCache *msix_cache;
> +
> /* MSI entries */
> int msi_entries_nr;
> struct KVMMsiMessage *msi_irq_entries;
IMO this needlessly leaks kvm information into core qemu. The cache
should be completely hidden in kvm code.
I think msi_deliver() can hide the use of the cache completely. For
pre-registered events like kvm's irqfd, you can use something like
qemu_irq qemu_msi_irq(MSIMessage msg)
for non-kvm, it simply returns a qemu_irq that triggers a stl_phys();
for kvm, it allocates an irqfd and a permanent entry in the cache and
returns a qemu_irq that triggers the irqfd.
--
error compiling committee.c: too many arguments to function
