On Tue, May 06, 2014 at 01:11:37PM +0200, Antonios Motakis wrote: > On Mon, May 5, 2014 at 4:52 PM, Eric Auger <eric.auger@xxxxxxxxxx> wrote: > > > > Dear All, > > > > I will try to sketch a global view of how to assign a physical IRQ to a > > KVM guest using the following subsystems: > > > > - on kernel side: VFIO driver, KVM IRQFD and GSI routing > > On the kernel side there are two sides: > > 1) The VFIO eventfd support which is underway for v6, as mentioned in > the VFIO patches. > 2) KVM IRQFD support, which depends on GSI routing as we discussed here. > > For (1) it is not a different story than what VFIO already does on > x86. We are going to support the same API already documented in > include/uapi/linux/vfio.h and will be part of the next version of the > VFIO_PLATFORM patches. > > For (2) we would like to offer an RFC patch, as soon as we have some > kind of agreement with that what we have started is the right > direction and desirable, which is why we started this thread. > > > - on user side: QEMU system image featuring VFIO QEMU device. > > > > It aims at sharing knowledge and checking that the understanding of the > > legacy is correct (MSI routing is out of scope). > > > > GSI routing table: > > > > Each VM has its own routing table. This later aims at storing how a > > physical IRQ (the gsi) is connected to a guest. > > > > GSI routing entries contain the following fields (not exhaustive): > > - gsi (the physical IRQ) > > - irqchip (the virtual interrupt controller) > > - irqchip.pin (the interrupt controller input the gsi is routed to). > > - set() is the method that enables to trigger the virtual interrupt for > > this entry (basically depends on the irqchip, IOAPI, PIC, GIC, ...). > > The complete definition can be found in include/linux/kvm_host.h. > > set() is internal to the kernel and will not be exposed to userspace > (see discussions on the API previously in the thread) > > > > > IRQFD: > > > > irqfd framework makes it possible to assign physical IRQs (the gsi > > above) to KVM guests. An eventfd is associated to a physical IRQ (the > > gsi). When the eventfd is signaled (typically by a VFIO driver ISR), the > > irqfd framework has the role to inject the virtual IRQ associated to > > this physical IRQ. This is done on kernel side. The injection is made > > through the virtual interrupt controller and made visible on next VM > > runtime window. > > > > the _irqfd struct (eventfd.c) itself stores the VM it applies to and the > > gsi it is linked with. > > > > The irqfd framework depends on the KVM routing table to find the > > remaining information needed to perform the guest injection: > > - the virtual interrupt controller used for injection (irqchip) > > - the input pin of the interrupt controller (irqchip.pin) > > - the set() function irdfq must call to trigger the virtual IRQ > > > > Although the _irqfd struct has a routing entry field (irq_entry), this > > one is not used for GSI (it is for MSI). Thus when the eventfd is > > signaled, the routing table is searched for the associated GSI and > > eventually set() is called. > > > > Note that irqfd allows you to define a second (optional) eventfd (called > > the resampler), which can be signaled by KVM when the virtual IRQ is > > completed (EOI). > > The resamplerfd part is actually very important to properly support > level sensitive (automasked) interrupts. For edge triggered interrupts > IRQFD is just a matter of efficiency, but level-sensitive interrupts > absolutely need a IRQFD and a RESAMPLEFD to be implemented in a sane > way. Are you saying you cannot support passthrough level-triggered interrupts without IRQFD? Can you be more concrete? -Christoffer _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
