Re: [Qemu-devel] [RFC][PATCH 12/45] msi: Introduce MSIRoutingCache

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Oct 17, 2011 at 01:19:56PM +0200, Jan Kiszka wrote:
> On 2011-10-17 13:06, Avi Kivity wrote:
> > 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.
> 
> See my previously mail: you want to track the life-cycle of an MSI
> source to avoid generating routes for identical sources. A messages is
> not a source. Two identical messages can come from different sources.

Since MSI messages are edge triggered, I don't see how this
would work without losing interrupts. And AFAIK,
existing guests do not use the same message for
different sources.

> So
> we need a separate data structure for that purpose.
> 
> Jan
> 
> -- 
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux