Re: [Qemu-devel] [PATCH v6 00/16] KVM platform device passthrough

[Christoffer Dall]

On Thu, Sep 11, 2014 at 04:14:09PM -0600, Alex Williamson wrote:
> On Tue, 2014-09-09 at 08:31 +0100, Eric Auger wrote:
> > This RFC series aims at enabling KVM platform device passthrough.
> > It implements a VFIO platform device, derived from VFIO PCI device.
> > 
> > The VFIO platform device uses the host VFIO platform driver which must
> > be bound to the assigned device prior to the QEMU system start.
> > 
> > - the guest can directly access the device register space
> > - assigned device IRQs are transparently routed to the guest by
> >   QEMU/KVM (3 methods currently are supported: user-level eventfd
> >   handling, irqfd, forwarded IRQs)
> > - iommu is transparently programmed to prevent the device from
> >   accessing physical pages outside of the guest address space
> > 
> > This patch series is made of the following patch files:
> > 
> > 1-7) Modifications to PCI code to prepare for VFIO platform device
> > 8) split of PCI specific code and generic code (move)
> > 9-11) creation of the VFIO calxeda xgmac platform device, without irqfd
> >       support (MMIO direct access and IRQ assignment).
> > 12) fake injection test modality (to test multiple IRQ)
> > 13) addition of irqfd/virqfd support
> > 14-16) forwarded IRQ
> > 
> > Dependency List:
> > 
> > QEMU dependencies:
> > [1] [PATCH v2 0/9] Dynamic sysbus device allocation support, Alex Graf
> >     http://lists.gnu.org/archive/html/qemu-ppc/2014-07/msg00047.html
> > [2] [RFC v3] machvirt dynamic sysbus device instantiation, Eric Auger
> > [3] [PATCH v2 0/2] actual checks of KVM_CAP_IRQFD and 
> > KVM_CAP_IRQFD_RESAMPLE,
> >     Eric Auger
> >     http://lists.nongnu.org/archive/html/qemu-devel/2014-09/msg00589.html
> > [4] [RFC] vfio: migration to trace points, Eric Auger
> >     http://lists.nongnu.org/archive/html/qemu-devel/2014-09/msg00569.html
> > 
> > Kernel Dependencies:
> > [5] [RFC Patch v6 0/20] VFIO support for platform devices, Antonios Motakis
> >     https://www.mail-archive.com/address@hidden/msg103247.html
> > [6] [PATCH v3] ARM: KVM: add irqfd support, Eric Auger
> >     https://lkml.org/lkml/2014/9/1/141
> > [7] arm/arm64: KVM: Various VGIC cleanups and improvements, Christoffer Dall
> >     http://comments.gmane.org/gmane.linux.ports.arm.kernel/340430
> > [8] [RFC v2 0/9] KVM-VFIO IRQ forward control, Eric Auger
> >     https://lkml.org/lkml/2014/9/1/344
> > [9] [RFC PATCH 0/9] ARM: Forwarding physical interrupts to a guest VM,
> >     Marc Zyngier
> >     http://lwn.net/Articles/603514/
> > 
> > kernel pieces can be found at:
> > http://git.linaro.org/people/eric.auger/linux.git
> > (branch 3.17rc3_irqfd_forward_integ_v2)
> > QEMU pieces can be found at:
> > http://git.linaro.org/people/eric.auger/qemu.git (branch vfio_integ_v6)
> > 
> > The patch series was tested on Calxeda Midway (ARMv7) where one xgmac
> > is assigned to KVM host while the second one is assigned to the guest.
> > Reworked PCI device is not tested.
> > 
> > Wiki for Calxeda Midway setup:
> > https://wiki.linaro.org/LEG/Engineering/Virtualization/Platform_Device_Passthrough_on_Midway
> > 
> > History:
> > 
> > v5->v6:
> > - rebase on 2.1rc5 PCI code
> > - forwarded IRQ first integraton
> 
> Why?  Are there acceleration paths that you're concerned cannot be
> implemented or we do not already have a proof of concept for?  The base
> kernel patch series you depend on is 3 months old yet this series
> continues to grow and add new dependencies.  Please let's prioritize
> getting something upstream instead of adding more blockers to prevent
> that.  Thanks,
> 
I'm not exactly sure what this changelog line was referring to
(depending on Marc's forwarding IRQ patches?), but just want to add that
there are a number of dependencies for the GIC that need to go in as
well (should happen within a few weeks), but I think it's unlikely that
the IRQ forwarding stuff goes in for v3.18 at this point.

It may make sense as you suggest to keep that part out of this patch set
and something merged sooner as opposed to later, but I'm too jet-lagged
to completely understand if that's going to be a horrible mess.

Thanks,
-Christoffer