qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Christoffer Dall
Subject: Re: [Qemu-devel] [PATCH v6 00/16] KVM platform device passthrough
Date: Thu, 11 Sep 2014 16:05:40 -0700
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Sep 11, 2014 at 04:51:14PM -0600, Alex Williamson wrote:
> On Thu, 2014-09-11 at 15:23 -0700, Christoffer Dall wrote:
> > 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.
> 
> The point is that we're on v6 of a patch series and its first non-RFC
> posting and we're rolling in a first pass at a QEMU implementation that
> depends on a contested kernel RFC, which depends on another stagnant
> kernel RFC.  I'm fine with working on it in parallel, but give me some
> light at the end of the tunnel as a reviewer and maintainer that this
> code isn't going to live indefinitely on the mailing list.  Do we really
> need those GIC patches do be able to have non-KVM accelerated VFIO
> platform device assignment?  We certainly don't need IRQ forwarding.
> Thanks,
> 
You need the vgic cleanup and fixes series to do platform device
assignment on ARM, yes.

I would also like to see us moving faster on the VFIO platform patch
set, but we're not driving this effort so not sure what we (Linaro) can
do here.

The irqfd patch itself doesn't require IRQ forwarding and Eric was
accurately sending that as a separate patch, which I expect will be in
an upstreamable state soon.

The QEMU patch set should then probably be split, so an initial version
of the patch set without irq forwarding can go in.

The whole KVM-VFIO patch set is only about IRQ forwarding and I think
Eric prioritized this work in parallel because it makes the whole thing
useful performance-wise.

But, I agree with your point, this has been floating around for a long
time, so we should try to get some fixed points.  I'm mostly worried
about the vfio platform kernel patch set at this point though...

-Christoffer



reply via email to

[Prev in Thread] Current Thread [Next in Thread]