[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v6 00/16] KVM platform device passthrough
From: |
Eric Auger |
Subject: |
Re: [Qemu-devel] [PATCH v6 00/16] KVM platform device passthrough |
Date: |
Tue, 16 Sep 2014 00:01:01 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 |
On 09/12/2014 01:05 AM, Christoffer Dall wrote:
> 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,
Hi Alex,
Sorry for the delay, I was travelling.
I understand your impatience. I personally would be happy if we could
envision upstreaming this patch in several steps. Let me know if it
makes sense.
STEP I: integrate 1 - 11: leads to have a non-KVM accelerated VFIO QEMU
device. 12 can be part of it too but since it is a test feature this one
might be dropped. just let me know what you think.
depends on:
QEMU:
[1] [PATCH v2 0/9] Dynamic sysbus device allocation support, A. Graf
http://lists.gnu.org/archive/html/qemu-ppc/2014-07/msg00047.html
[2] [RFC v3] machvirt dynamic sysbus device instantiation, E. Auger
[4] [RFC] vfio: migration to trace points, E. Auger
http://lists.nongnu.org/archive/html/qemu-devel/2014-09/msg00569.html
KERNEL:
[5] [RFC Patch v6 0/20] VFIO support for platform devices, A. Motakis
https://www.mail-archive.com/address@hidden/msg103247.html
Step II: integrate 13: kvm-accelerated QEMU VFIO device featuring
iqrfd/virqfd
depends on
[7] arm/arm64: KVM: Various VGIC cleanups and improvements, C. Dall
[6] [PATCH v3] ARM: KVM: add irqfd support, E. Auger
https://lkml.org/lkml/2014/9/1/141
Step III: integrate > 13: kvm-accelerated QEMU VFIO device featuring
forwarded IRQs:
[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/
To me these 3 steps are quite independent from each other.
with respect to performance I think we have something reasonable now
with irqfd and forwarded IRQ so I do not expect any new features added
soon.
from now on, I do not plan to add any new patch file to this series but
just correct/modify according to comments & weaknesses.
I Hope it clarifies plans. Please let me know.
Best Regards
Eric
>>
> 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
>
- Re: [Qemu-devel] [PATCH v6 11/16] hw/arm/dyn_sysbus_devtree: enable vfio-calxeda-xgmac dynamic instantiation, (continued)
- [Qemu-devel] [PATCH v6 13/16] hw/vfio/platform: Add irqfd support, Eric Auger, 2014/09/09
- [Qemu-devel] [PATCH v6 12/16] vfio/platform: add fake injection modality, Eric Auger, 2014/09/09
- [Qemu-devel] [PATCH v6 14/16] linux-headers: Update KVM headers from linux-next tag ToBeFilled, Eric Auger, 2014/09/09
- [Qemu-devel] [PATCH v6 15/16] VFIO: COMMON: vfio_kvm_device_fd moved in the common header, Eric Auger, 2014/09/09
- [Qemu-devel] [PATCH v6 16/16] VFIO: PLATFORM: add forwarded irq support, Eric Auger, 2014/09/09
- Re: [Qemu-devel] [PATCH v6 00/16] KVM platform device passthrough, Alex Williamson, 2014/09/11
- Re: [Qemu-devel] [PATCH v6 00/16] KVM platform device passthrough, Christoffer Dall, 2014/09/11
- Re: [Qemu-devel] [PATCH v6 00/16] KVM platform device passthrough, Alex Williamson, 2014/09/11
- Re: [Qemu-devel] [PATCH v6 00/16] KVM platform device passthrough, Christoffer Dall, 2014/09/11
- Re: [Qemu-devel] [PATCH v6 00/16] KVM platform device passthrough,
Eric Auger <=
- Re: [Qemu-devel] [PATCH v6 00/16] KVM platform device passthrough, Alex Williamson, 2014/09/16
- Re: [Qemu-devel] [PATCH v6 00/16] KVM platform device passthrough, Eric Auger, 2014/09/16
- Re: [Qemu-devel] [PATCH v6 00/16] KVM platform device passthrough, Alex Williamson, 2014/09/16
- Re: [Qemu-devel] [PATCH v6 00/16] KVM platform device passthrough, Eric Auger, 2014/09/18