From: Eric Auger <eric.auger@linaro.org>
To: eric.auger@st.com, eric.auger@linaro.org,
alex.williamson@redhat.com, will.deacon@arm.com,
christoffer.dall@linaro.org, marc.zyngier@arm.com,
linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org
Cc: patches@linaro.org, linux-kernel@vger.kernel.org,
iommu@lists.linux-foundation.org
Subject: [PATCH 00/10] KVM PCIe/MSI passthrough on ARM/ARM64
Date: Tue, 26 Jan 2016 13:12:38 +0000 [thread overview]
Message-ID: <1453813968-2024-1-git-send-email-eric.auger@linaro.org> (raw)
This series addresses KVM PCIe passthrough with MSI enabled on ARM/ARM64.
It pursues the efforts done on [1], [2], [3]. It also aims at covering the
same need on some PowerPC platforms.
On x86 all accesses to the 1MB PA region [FEE0_0000h - FEF0_000h] are directed
as interrupt messages: accesses to this special PA window directly target the
APIC configuration space and not DRAM, meaning the downstream IOMMU is bypassed.
This is not the case on above mentionned platforms where MSI messages emitted
by devices are conveyed through the IOMMU. This means an IOVA/host PA mapping
must exist for the MSI to reach the MSI controller. Normal way to create
IOVA bindings consists in using VFIO DMA MAP API. However in this case
the MSI IOVA is not mapped onto guest RAM but on host physical page (the MSI
controller frame).
Following first comments, the spirit of [2] is kept: the guest registers
an IOVA range reserved for MSI mapping. When the VFIO-PCIe driver allocates
its MSI vectors, it overwrites the MSI controller physical address with an IOVA,
allocated within the window provided by the userspace. This IOVA is mapped
onto the MSI controller frame physical page.
The series does not address yet the problematic of telling the userspace how
much IOVA he should provision.
Best Regards
Eric
Testing:
This is currently tested on ARM64 AMD Overdrive HW (single GICv2m frame)
with an e1000e PCIe card. This is not tested on PPC.
References:
[1] [RFC 0/2] VFIO: Add virtual MSI doorbell support
(https://lkml.org/lkml/2015/7/24/135)
[2] [RFC PATCH 0/6] vfio: Add interface to map MSI pages
(https://lists.cs.columbia.edu/pipermail/kvmarm/2015-September/016607.html)
[3] [PATCH v2 0/3] Introduce MSI hardware mapping for VFIO
(http://permalink.gmane.org/gmane.comp.emulators.kvm.arm.devel/3858)
Git:
https://git.linaro.org/people/eric.auger/linux.git/shortlog/refs/heads/v4.5-rc1-pcie-passthrough-v1
History:
RFC v1 [2] -> PATCH v1:
- use the existing dma map/unmap ioctl interface with a flag to register a
reserved IOVA range. Use the legacy Rb to store this special vfio_dma.
- a single reserved IOVA contiguous region now is allowed
- use of an RB tree indexed by PA to store allocated reserved slots
- use of a vfio_domain iova_domain to manage iova allocation within the
window provided by the userspace
- vfio alloc_map/unmap_free take a vfio_group handle
- vfio_group handle is cached in vfio_pci_device
- add ref counting to bindings
- user modality enabled at the end of the series
Eric Auger (10):
iommu: Add DOMAIN_ATTR_MSI_MAPPING attribute
vfio: expose MSI mapping requirement through VFIO_IOMMU_GET_INFO
vfio_iommu_type1: add reserved binding RB tree management
vfio: introduce VFIO_IOVA_RESERVED vfio_dma type
vfio/type1: attach a reserved iova domain to vfio_domain
vfio: introduce vfio_group_alloc_map_/unmap_free_reserved_iova
vfio: pci: cache the vfio_group in vfio_pci_device
vfio: introduce vfio_group_require_msi_mapping
vfio-pci: create an iommu mapping for msi address
vfio: allow the user to register reserved iova range for MSI mapping
drivers/iommu/arm-smmu.c | 2 +
drivers/iommu/fsl_pamu_domain.c | 3 +
drivers/vfio/pci/vfio_pci.c | 8 +
drivers/vfio/pci/vfio_pci_intrs.c | 73 ++++++-
drivers/vfio/pci/vfio_pci_private.h | 1 +
drivers/vfio/vfio.c | 64 ++++++
drivers/vfio/vfio_iommu_type1.c | 412 +++++++++++++++++++++++++++++++++++-
include/linux/iommu.h | 1 +
include/linux/vfio.h | 39 +++-
include/uapi/linux/vfio.h | 10 +
10 files changed, 598 insertions(+), 15 deletions(-)
--
1.9.1
next reply other threads:[~2016-01-26 13:12 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-26 13:12 Eric Auger [this message]
2016-01-26 13:12 ` [PATCH 01/10] iommu: Add DOMAIN_ATTR_MSI_MAPPING attribute Eric Auger
2016-01-26 13:12 ` [PATCH 02/10] vfio: expose MSI mapping requirement through VFIO_IOMMU_GET_INFO Eric Auger
[not found] ` <1453813968-2024-1-git-send-email-eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-01-26 13:12 ` [PATCH 03/10] vfio_iommu_type1: add reserved binding RB tree management Eric Auger
2016-01-28 21:51 ` [PATCH 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 Alex Williamson
[not found] ` <1454017899.23148.0.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-01-29 14:35 ` Eric Auger
2016-01-29 19:33 ` Alex Williamson
[not found] ` <1454096004.9301.1.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-01-29 21:25 ` Eric Auger
[not found] ` <56ABD8E0.6080409-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-02-01 14:03 ` Will Deacon
2016-02-03 12:50 ` Christoffer Dall
2016-02-03 13:10 ` Will Deacon
[not found] ` <20160203131057.GA20217-5wv7dgnIgG8@public.gmane.org>
2016-02-03 15:36 ` Christoffer Dall
2016-02-05 17:32 ` ARM PCI/MSI KVM passthrough with GICv2M Eric Auger
[not found] ` <56B4DC97.60904-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-02-05 18:17 ` Alex Williamson
[not found] ` <20160205111700.726ac061-1yVPhWWZRC1BDLzU/O5InQ@public.gmane.org>
2016-02-08 9:48 ` Christoffer Dall
2016-02-08 13:27 ` Eric Auger
2016-01-26 13:12 ` [PATCH 04/10] vfio: introduce VFIO_IOVA_RESERVED vfio_dma type Eric Auger
2016-01-26 13:12 ` [PATCH 05/10] vfio/type1: attach a reserved iova domain to vfio_domain Eric Auger
2016-01-26 13:12 ` [PATCH 06/10] vfio: introduce vfio_group_alloc_map_/unmap_free_reserved_iova Eric Auger
[not found] ` <1453813968-2024-7-git-send-email-eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-01-26 16:17 ` kbuild test robot
2016-01-26 16:37 ` Eric Auger
2016-01-26 13:12 ` [PATCH 07/10] vfio: pci: cache the vfio_group in vfio_pci_device Eric Auger
2016-01-26 13:12 ` [PATCH 08/10] vfio: introduce vfio_group_require_msi_mapping Eric Auger
2016-01-26 13:12 ` [PATCH 09/10] vfio-pci: create an iommu mapping for msi address Eric Auger
[not found] ` <1453813968-2024-10-git-send-email-eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-01-26 14:43 ` kbuild test robot
[not found] ` <201601262259.1kktHLzi%fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2016-01-26 15:14 ` Eric Auger
2016-01-26 13:12 ` [PATCH 10/10] vfio: allow the user to register reserved iova range for MSI mapping Eric Auger
2016-01-26 16:42 ` kbuild test robot
[not found] ` <1453813968-2024-11-git-send-email-eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-01-26 18:32 ` kbuild test robot
2016-01-26 17:25 ` [PATCH 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 Pavel Fedin
2016-01-27 8:52 ` Eric Auger
2016-01-28 7:13 ` Pavel Fedin
2016-01-28 9:50 ` Eric Auger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1453813968-2024-1-git-send-email-eric.auger@linaro.org \
--to=eric.auger@linaro.org \
--cc=alex.williamson@redhat.com \
--cc=christoffer.dall@linaro.org \
--cc=eric.auger@st.com \
--cc=iommu@lists.linux-foundation.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=patches@linaro.org \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).