On Mon, 2015-06-29 at 13:27 +0000, Wu, Feng wrote: > > > > -----Original Message----- > > From: Alex Williamson [mailto:alex.williamson@xxxxxxxxxx] > > Sent: Friday, June 19, 2015 4:04 AM > > To: Wu, Feng > > Cc: Eric Auger; Avi Kivity; kvm@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > > pbonzini@xxxxxxxxxx; mtosatti@xxxxxxxxxx; Joerg Roedel > > Subject: Re: [v4 08/16] KVM: kvm-vfio: User API for IRQ forwarding > > > > [Adding Joerg since he was part of this original idea] > > > > > > There are plenty of details to be filled in, but I think the basics > > looks something like the code below. The IRQ bypass manager just > > defines a pair of structures, one for interrupt producers and one for > > interrupt consumers. I'm certain that we'll need more callbacks than > > I've defined below, but figuring out what those should be for the best > > abstraction is the hardest part of this idea. The manager provides both > > registration and de-registration interfaces for both types of objects > > and keeps lists for each, protected by a lock. The manager doesn't even > > really need to know what the match token is, but I assume for our > > purposes it will be an eventfd_ctx. > > > > On the vfio side, the producer struct would be embedded in the > > vfio_pci_irq_ctx struct. KVM would probably embed the consumer struct > > in _irqfd. As I've coded below, the IRQ bypass manager calls the > > consumer callbacks, so the producer struct would need fields or > > callbacks to provide the consumer the info it needs. AIUI the Posted > > Interrupt model, VFIO only needs to provide data to the consumer. For > > IRQ Forwarding, I think the producer needs to be informed when bypass is > > active to model the incoming interrupt as edge vs level. > > > > I've prototyped the base IRQ bypass manager here as static, but I don't > > see any reason it couldn't be a module that's loaded by dependency when > > either vfio-pci or kvm-intel is loaded (or other producer/consumer > > objects). > > > > Is this a reasonable starting point to craft the additional fields and > > callbacks and interaction of who calls who that we need to support > > Posted Interrupts and IRQ Forwarding? Is the AMD version of this still > > alive? Thanks, > > > > Alex > > > > diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig > > index 413a7bf..22f6fcb 100644 > > --- a/arch/x86/kvm/Kconfig > > +++ b/arch/x86/kvm/Kconfig > > @@ -61,6 +61,7 @@ config KVM_INTEL > > depends on KVM > > # for perf_guest_get_msrs(): > > depends on CPU_SUP_INTEL > > + select IRQ_BYPASS_MANAGER > > ---help--- > > Provides support for KVM on Intel processors equipped with the VT > > extensions. > > diff --git a/drivers/vfio/pci/Kconfig b/drivers/vfio/pci/Kconfig > > index 579d83b..02912f1 100644 > > --- a/drivers/vfio/pci/Kconfig > > +++ b/drivers/vfio/pci/Kconfig > > @@ -2,6 +2,7 @@ config VFIO_PCI > > tristate "VFIO support for PCI devices" > > depends on VFIO && PCI && EVENTFD > > select VFIO_VIRQFD > > + select IRQ_BYPASS_MANAGER > > help > > Support for the PCI VFIO bus driver. This is required to make > > use of PCI drivers using the VFIO framework. > > diff --git a/drivers/vfio/pci/vfio_pci_intrs.c b/drivers/vfio/pci/vfio_pci_intrs.c > > index 1f577b4..4e053be 100644 > > --- a/drivers/vfio/pci/vfio_pci_intrs.c > > +++ b/drivers/vfio/pci/vfio_pci_intrs.c > > @@ -181,6 +181,7 @@ static int vfio_intx_set_signal(struct vfio_pci_device > > *vdev, int fd) > > > > if (vdev->ctx[0].trigger) { > > free_irq(pdev->irq, vdev); > > + /* irq_bypass_unregister_producer(); */ > > kfree(vdev->ctx[0].name); > > eventfd_ctx_put(vdev->ctx[0].trigger); > > vdev->ctx[0].trigger = NULL; > > @@ -214,6 +215,8 @@ static int vfio_intx_set_signal(struct vfio_pci_device > > *vdev, int fd) > > return ret; > > } > > > > + /* irq_bypass_register_producer(); */ > > + > > /* > > * INTx disable will stick across the new irq setup, > > * disable_irq won't. > > @@ -319,6 +322,7 @@ static int vfio_msi_set_vector_signal(struct > > vfio_pci_device *vdev, > > > > if (vdev->ctx[vector].trigger) { > > free_irq(irq, vdev->ctx[vector].trigger); > > + /* irq_bypass_unregister_producer(); */ > > kfree(vdev->ctx[vector].name); > > eventfd_ctx_put(vdev->ctx[vector].trigger); > > vdev->ctx[vector].trigger = NULL; > > @@ -360,6 +364,8 @@ static int vfio_msi_set_vector_signal(struct > > vfio_pci_device *vdev, > > return ret; > > } > > > > + /* irq_bypass_register_producer(); */ > > + > > vdev->ctx[vector].trigger = trigger; > > > > return 0; > > diff --git a/include/linux/irqbypass.h b/include/linux/irqbypass.h > > new file mode 100644 > > index 0000000..718508e > > --- /dev/null > > +++ b/include/linux/irqbypass.h > > @@ -0,0 +1,23 @@ > > +#ifndef IRQBYPASS_H > > +#define IRQBYPASS_H > > + > > +#include <linux/list.h> > > + > > +struct irq_bypass_producer { > > + struct list_head node; > > + void *token; > > + /* TBD */ > > +}; > > + > > +struct irq_bypass_consumer { > > + struct list_head node; > > + void *token; > > + void (*add_producer)(struct irq_bypass_producer *); > > + void (*del_producer)(struct irq_bypass_producer *); > > These two callbacks should be common function, for PI, I need to add > something specific to x86, such as, updating the associated IRTE, how > should I do for this? These are function pointers, the consumer (kvm in this case) can populate them with whatever implementation it needs. The details of updating the IRTE should be completely hidden from this interface. This interface only handles identifying matches between producer and consumer and providing an API for the handshake. Feel free to use more appropriate callbacks and structure fields, these are only meant as a rough sketch of the idea and possible interaction, but please keep layering in mind to make a generic interface. > > +}; > > + > > +int irq_bypass_register_producer(struct irq_bypass_producer *); > > +void irq_bypass_unregister_producer(struct irq_bypass_producer *); > > +int irq_bypass_register_consumer(struct irq_bypass_consumer *); > > +void irq_bypass_unregister_consumer(struct irq_bypass_consumer *); > > +#endif /* IRQBYPASS_H */ > > diff --git a/kernel/irq/Kconfig b/kernel/irq/Kconfig > > index 9a76e3b..4502cdc 100644 > > --- a/kernel/irq/Kconfig > > +++ b/kernel/irq/Kconfig > > @@ -100,4 +100,7 @@ config SPARSE_IRQ > > > > If you don't know what to do here, say N. > > > > +config IRQ_BYPASS_MANAGER > > + bool > > + > > endmenu > > diff --git a/kernel/irq/Makefile b/kernel/irq/Makefile > > index d121235..a30ed77 100644 > > --- a/kernel/irq/Makefile > > +++ b/kernel/irq/Makefile > > @@ -7,3 +7,4 @@ obj-$(CONFIG_PROC_FS) += proc.o > > obj-$(CONFIG_GENERIC_PENDING_IRQ) += migration.o > > obj-$(CONFIG_PM_SLEEP) += pm.o > > obj-$(CONFIG_GENERIC_MSI_IRQ) += msi.o > > +obj-$(CONFIG_IRQ_BYPASS_MANAGER) += bypass.o > > diff --git a/kernel/irq/bypass.c b/kernel/irq/bypass.c > > new file mode 100644 > > index 0000000..5d0f92b > > --- /dev/null > > +++ b/kernel/irq/bypass.c > > Is it better to put this code here or in vfio folder? What about it is specific to vfio? Both vfio and kvm are clients to the interface, but I don't think we want to add any barriers that restrict it to that pair. I think we originally thought of this as an IOMMU service, so drivers/iommu might be another possible home for it. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
