From: Eric Auger <hidden> Date: 2016-01-26 13:13:25
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
From: Eric Auger <hidden> Date: 2016-01-26 13:13:32
This patch allows the user-space to retrieve whether msi write
transaction addresses must be mapped. This is returned through the
VFIO_IOMMU_GET_INFO API using a new flag: VFIO_IOMMU_INFO_REQUIRE_MSI_MAP.
Signed-off-by: Bharat Bhushan <redacted>
Signed-off-by: Eric Auger <redacted>
---
RFC v1 -> RFC v2:
- derived from
[RFC PATCH 3/6] vfio: Extend iommu-info to return MSIs automap state
- renamed allow_msi_reconfig into require_msi_mapping
- fixed VFIO_IOMMU_GET_INFO
---
drivers/vfio/vfio_iommu_type1.c | 26 ++++++++++++++++++++++++++
include/uapi/linux/vfio.h | 1 +
2 files changed, 27 insertions(+)
@@ -255,6 +255,29 @@ static int vaddr_get_pfn(unsigned long vaddr, int prot, unsigned long *pfn)}/*+*vfio_domains_require_msi_mapping:indicateswhetherMSIwritetransaction+*addressesmustbemapped+*+*returnstrueifitdoes+*/+staticboolvfio_domains_require_msi_mapping(structvfio_iommu*iommu)+{+structvfio_domain*d;+boolret;++mutex_lock(&iommu->lock);+/* All domains have same require_msi_map property, pick first */+d=list_first_entry(&iommu->domain_list,structvfio_domain,next);+if(iommu_domain_get_attr(d->domain,DOMAIN_ATTR_MSI_MAPPING,NULL)<0)+ret=false;+else+ret=true;+mutex_unlock(&iommu->lock);++returnret;+}++/**Attempttopinpages.Wereallydon'twanttotrackallthepfnsand*theiommucanonlymapchunksofconsecutivepfnsanyway,sogetthe*firstpageandallconsecutivepageswiththesamelocking.
@@ -997,6 +1020,9 @@ static long vfio_iommu_type1_ioctl(void *iommu_data,info.flags=VFIO_IOMMU_INFO_PGSIZES;+if(vfio_domains_require_msi_mapping(iommu))+info.flags|=VFIO_IOMMU_INFO_REQUIRE_MSI_MAP;+info.iova_pgsizes=vfio_pgsize_bitmap(iommu);returncopy_to_user((void__user*)arg,&info,minsz);
From: Eric Auger <hidden> Date: 2016-01-26 13:13:34
Legacy dma_list is just used to insert the reserved iova region and
check mapping of reserved iova happens in this window. As opposed to
other vfio_dma slots, the reserved one is not necessarily mapped.
We will need to track which host physical addresses are mapped to
reserved IOVA. In that prospect we introduce a new RB tree indexed
by physical address. This reverse RB tree only is used for reserved
IOVA bindings. It belongs to a given iommu domain.
It is expected this RB tree will contain very few bindings. Those
generally correspond to single page mapping one MSI frame (at least
for ARM, containing the GICv2m frame or ITS GITS_TRANSLATER frame.
Signed-off-by: Eric Auger <redacted>
---
drivers/vfio/vfio_iommu_type1.c | 63 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
@@ -56,6 +56,7 @@ MODULE_PARM_DESC(disable_hugepages,structvfio_iommu{structlist_headdomain_list;structmutexlock;+/* rb tree indexed by IOVA */structrb_rootdma_list;boolv2;boolnesting;
@@ -65,6 +66,8 @@ struct vfio_domain {structiommu_domain*domain;structlist_headnext;structlist_headgroup_list;+/* rb tree indexed by PA, for reserved bindings only */+structrb_rootreserved_binding_list;intprot;/* IOMMU_CACHE */boolfgsp;/* Fine-grained super pages */};
From: Eric Auger <hidden> Date: 2016-01-26 13:13:40
We introduce a vfio_dma type since we will need to discriminate
legacy vfio_dma's from new reserved ones. Since those latter are
not mapped at registration, some handlings must be unplugged:
removal, replay. They will be enhanced later on.
Signed-off-by: Eric Auger <redacted>
---
drivers/vfio/vfio_iommu_type1.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
@@ -53,6 +53,15 @@ module_param_named(disable_hugepages,MODULE_PARM_DESC(disable_hugepages,"Disable VFIO IOMMU support for IOMMU hugepages.");+enumvfio_iova_type{+VFIO_IOVA_USER=0,/* standard IOVA used to map user vaddr */+/*+*IOVAreservedtomapspecialhostphysicaladdresses,+*MSIframesforinstance+*/+VFIO_IOVA_RESERVED,+};+structvfio_iommu{structlist_headdomain_list;structmutexlock;
@@ -78,6 +87,7 @@ struct vfio_dma {unsignedlongvaddr;/* Process virtual addr */size_tsize;/* Map size (bytes) */intprot;/* IOMMU_READ/WRITE */+enumvfio_iova_typetype;/* type of IOVA */};structvfio_reserved_binding{
From: Eric Auger <hidden> Date: 2016-01-26 13:13:44
This patch adds a reserved iova_domain to the vfio_domain struct.
This iova domain will enable to allocate iova within the reserved
iova region.
alloc_reserved_iova_domain makes possible to allocate and initialize
this iova domain. The user will be introduced in subsequent patches.
Signed-off-by: Eric Auger <redacted>
---
drivers/vfio/vfio_iommu_type1.c | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
@@ -77,6 +78,7 @@ struct vfio_domain {structlist_headgroup_list;/* rb tree indexed by PA, for reserved bindings only */structrb_rootreserved_binding_list;+structiova_domain*reserved_iova_domain;intprot;/* IOMMU_CACHE */boolfgsp;/* Fine-grained super pages */};
@@ -178,6 +180,41 @@ static struct vfio_dma *vfio_find_dma(struct vfio_iommu *iommu,returnNULL;}+/* alloc_reserved_iova_domain: allocate an iova domain used to manage+*reservediova+*@iova:baseiovaofthedomain+*@size:sizeofthedomain+*@order:iommupagesizeorder+*/+staticintalloc_reserved_iova_domain(structvfio_domain*domain,+dma_addr_tiova,size_tsize,+unsignedlongorder)+{+unsignedlonggranule,mask;+intret=0;++granule=1UL<<order;+mask=granule-1;+if(iova&mask)+return-EINVAL;+if((!size)||(size&mask))+return-EINVAL;++domain->reserved_iova_domain=+kzalloc(sizeof(structiova_domain),GFP_KERNEL);+if(!domain->reserved_iova_domain){+ret=-ENOMEM;+gotoout_free;+}+init_iova_domain(domain->reserved_iova_domain,+granule,iova>>order,(iova+size-1)>>order);+returnret;++out_free:+kfree(domain->reserved_iova_domain);+returnret;+}+staticvoidvfio_link_dma(structvfio_iommu*iommu,structvfio_dma*new){structrb_node**link=&iommu->dma_list.rb_node,*parent=NULL;
From: Eric Auger <hidden> Date: 2016-01-26 13:13:53
Some platforms require the MSI address programmed in the PCI
device to be an IOVA and not a host physical address.
This is typically the case for ARM and PowerPC, as opposed
to x86. This patch allocates an IOVA page and maps it onto
the physical page which contains the target MSI write transaction
address. In case an IOMMU binding already exists between those 2,
simply reprogram the device.
The binding is destroyed by the VFIO IOMMU backend.
Signed-off-by: Bharat Bhushan <redacted>
Signed-off-by: Eric Auger <redacted>
---
---
drivers/vfio/pci/vfio_pci_intrs.c | 73 ++++++++++++++++++++++++++++++++++++---
1 file changed, 68 insertions(+), 5 deletions(-)
@@ -305,6 +305,57 @@ static int vfio_msi_enable(struct vfio_pci_device *vdev, int nvec, bool msix)return0;}+/**+*vfio_set_mapped_msi_addr:overwritesthemsiphysicaladdresswithaniova+*+*@pdev:vfiopcidevicehandle+*@irq:irqlinuxnumber+*returns0uponsuccess,<0onfailure+*/+staticintvfio_set_mapped_msi_addr(structvfio_pci_device*vdev,intirq)+{+phys_addr_tmsi_addr;+dma_addr_tmsi_iova;+structvfio_group*group=vdev->vfio_group;+structmsi_msgmsg;+intret;++get_cached_msi_msg(irq,&msg);+msi_addr=(phys_addr_t)(msg.address_hi)<<32|+(phys_addr_t)(msg.address_lo);++ret=vfio_group_alloc_map_reserved_iova(group,msi_addr,+IOMMU_WRITE,&msi_iova);+if(ret)+gotoout;++/* Re-program the msi-address with the iova */+msg.address_hi=(u32)(msi_iova>>32);+msg.address_lo=(u32)(msi_iova&0xffffffff);+pci_write_msi_msg(irq,&msg);++out:+returnret;+}++/**+*vfio_unset_mapped_msi_addr:decrementtherefcounterofthemsiiovapage+*associatedtothelinuxirq(incaseitisnullunmapsandfreesresources)+*+*@pdev:vfiopcidevicehandle+*@irq:irqlinuxnumber+*/+staticvoidvfio_unset_mapped_msi_addr(structvfio_pci_device*vdev,intirq)+{+dma_addr_tmsi_iova;+structvfio_group*group=vdev->vfio_group;+structmsi_msgmsg;++get_cached_msi_msg(irq,&msg);+msi_iova=(u64)(msg.address_hi)<<32|(u64)(msg.address_lo);+vfio_group_unmap_free_reserved_iova(group,msi_iova);+}+staticintvfio_msi_set_vector_signal(structvfio_pci_device*vdev,intvector,intfd,boolmsix){
@@ -318,6 +369,7 @@ static int vfio_msi_set_vector_signal(struct vfio_pci_device *vdev,return-EINVAL;if(vdev->ctx[vector].trigger){+vfio_unset_mapped_msi_addr(vdev,irq);free_irq(irq,vdev->ctx[vector].trigger);irq_bypass_unregister_producer(&vdev->ctx[vector].producer);kfree(vdev->ctx[vector].name);
@@ -355,11 +407,8 @@ static int vfio_msi_set_vector_signal(struct vfio_pci_device *vdev,ret=request_irq(irq,vfio_msihandler,0,vdev->ctx[vector].name,trigger);-if(ret){-kfree(vdev->ctx[vector].name);-eventfd_ctx_put(trigger);-returnret;-}+if(ret)+gotoerror_free;vdev->ctx[vector].producer.token=trigger;vdev->ctx[vector].producer.irq=irq;
From: Eric Auger <hidden> Date: 2016-01-26 13:13:58
The user is allowed to register a reserved IOVA range by using the
DMA MAP API and setting the new flag: VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA.
It provides the base address and the size. This region is stored in the
vfio_dma rb tree. At that point the iova range is not mapped to any target
address yet. The host kernel will use those iova when needed, typically
when the VFIO-PCI device allocates its MSI's.
This patch also handles the destruction of the reserved binding RB-tree and
domain's iova_domains.
Signed-off-by: Eric Auger <redacted>
Signed-off-by: Bharat Bhushan <redacted>
---
- Currently the user is not yet informed about the number of pages to
provide
RFC v1 -> RFC v2:
- takes into account Alex comments, based on
[RFC PATCH 1/6] vfio: Add interface for add/del reserved iova region:
- use the existing dma map/unmap ioctl interface with a flag to register
a reserved IOVA range. A single reserved iova region is allowed.
---
drivers/vfio/vfio_iommu_type1.c | 98 ++++++++++++++++++++++++++++++++++++++++-
include/uapi/linux/vfio.h | 9 ++++
2 files changed, 106 insertions(+), 1 deletion(-)
@@ -538,10 +538,40 @@ static void vfio_unmap_unpin(struct vfio_iommu *iommu, struct vfio_dma *dma)vfio_lock_acct(-unlocked);}+/* vfio_unmap_reserved: unmap and free all reserved binding nodes+*foralldomainsanddestroytheiriova_domain+*+*@iommu:iommuhandle+*/+staticvoidvfio_unmap_reserved(structvfio_iommu*iommu)+{+structvfio_domain*d;++list_for_each_entry(d,&iommu->domain_list,next){+structrb_node*node;++while((node=rb_first(&d->reserved_binding_list))){+structvfio_reserved_binding*b=+rb_entry(node,+structvfio_reserved_binding,node);++while(!kref_put(&b->kref,+vfio_reserved_binding_release)){+}+}+d->reserved_binding_list=RB_ROOT;++put_iova_domain(d->reserved_iova_domain);+kfree(d->reserved_iova_domain);+}+}+staticvoidvfio_remove_dma(structvfio_iommu*iommu,structvfio_dma*dma){if(likely(dma->type!=VFIO_IOVA_RESERVED))vfio_unmap_unpin(iommu,dma);+else+vfio_unmap_reserved(iommu);vfio_unlink_dma(iommu,dma);kfree(dma);}
@@ -785,6 +815,68 @@ static int vfio_dma_do_map(struct vfio_iommu *iommu,returnret;}+staticintvfio_register_reserved_iova_range(structvfio_iommu*iommu,+structvfio_iommu_type1_dma_map*map)+{+dma_addr_tiova=map->iova;+size_tsize=map->size;+uint64_tmask;+structvfio_dma*dma;+intret=0;+structvfio_domain*d;+unsignedlongorder;++/* Verify that none of our __u64 fields overflow */+if(map->size!=size||map->iova!=iova)+return-EINVAL;++order=__ffs(vfio_pgsize_bitmap(iommu));+mask=((uint64_t)1<<order)-1;++WARN_ON(mask&PAGE_MASK);++/* we currently only support MSI_RESERVED_IOVA */+if(!(map->flags&VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA))+return-EINVAL;++if(!size||(size|iova)&mask)+return-EINVAL;++/* Don't allow IOVA address wrap */+if(iova+size-1<iova)+return-EINVAL;++mutex_lock(&iommu->lock);++/* check if the iova domain has not been instantiated already*/+d=list_first_entry(&iommu->domain_list,+structvfio_domain,next);++if(d->reserved_iova_domain||vfio_find_dma(iommu,iova,size)){+ret=-EEXIST;+gotoout;+}++dma=kzalloc(sizeof(*dma),GFP_KERNEL);+if(!dma){+ret=-ENOMEM;+gotoout;+}++dma->iova=iova;+dma->size=size;+dma->type=VFIO_IOVA_RESERVED;++vfio_link_dma(iommu,dma);++list_for_each_entry(d,&iommu->domain_list,next)+alloc_reserved_iova_domain(d,iova,size,order);++out:+mutex_unlock(&iommu->lock);+returnret;+}+staticintvfio_bus_type(structdevice*dev,void*data){structbus_type**bus=data;
@@ -1297,7 +1389,8 @@ static long vfio_iommu_type1_ioctl(void *iommu_data,}elseif(cmd==VFIO_IOMMU_MAP_DMA){structvfio_iommu_type1_dma_mapmap;uint32_tmask=VFIO_DMA_MAP_FLAG_READ|-VFIO_DMA_MAP_FLAG_WRITE;+VFIO_DMA_MAP_FLAG_WRITE|+VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA;minsz=offsetofend(structvfio_iommu_type1_dma_map,size);
@@ -1307,6 +1400,9 @@ static long vfio_iommu_type1_ioctl(void *iommu_data,if(map.argsz<minsz||map.flags&~mask)return-EINVAL;+if(map.flags&VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA)+returnvfio_register_reserved_iova_range(iommu,&map);+returnvfio_dma_do_map(iommu,&map);}elseif(cmd==VFIO_IOMMU_UNMAP_DMA){
From: Eric Auger <hidden> Date: 2016-01-26 13:14:58
Add a new set_group operation which allows to cache the vfio_group
handle within the vfio_pci_device struct. This is useful to do
iommu operations from the vfio_pci device.
Signed-off-by: Eric Auger <redacted>
---
drivers/vfio/pci/vfio_pci.c | 8 ++++++++
drivers/vfio/pci/vfio_pci_private.h | 1 +
drivers/vfio/vfio.c | 3 +++
include/linux/vfio.h | 3 +++
4 files changed, 15 insertions(+)
@@ -548,6 +548,9 @@ struct vfio_device *vfio_group_create_device(struct vfio_group *group,/* No need to get group_lock, caller has group reference */vfio_group_get(group);+if(device->ops->set_group)+device->ops->set_group(device_data,group);+mutex_lock(&group->device_lock);list_add(&device->group_next,&group->device_list);mutex_unlock(&group->device_lock);
From: Eric Auger <hidden> Date: 2016-01-26 13:15:28
This patch introduces vfio_group_alloc_map_/unmap_free_reserved_iova
and implements corresponding vfio_iommu_type1 operations.
alloc_map allows to allocate a new reserved iova page and map it
onto the physical page that contains a given PA. It returns the iova
that is mapped onto the provided PA. In case a mapping already exist
between both pages, the IOVA corresponding to the PA is directly returned.
Signed-off-by: Eric Auger <redacted>
Signed-off-by: Ankit Jindal <redacted>
Signed-off-by: Pranavkumar Sawargaonkar <redacted>
Signed-off-by: Bharat Bhushan <redacted>
---
drivers/vfio/vfio.c | 39 ++++++++++
drivers/vfio/vfio_iommu_type1.c | 163 ++++++++++++++++++++++++++++++++++++++--
include/linux/vfio.h | 34 ++++++++-
3 files changed, 228 insertions(+), 8 deletions(-)
@@ -1034,6 +1047,138 @@ done:mutex_unlock(&iommu->lock);}+staticstructvfio_domain*vfio_find_iommu_domain(void*iommu_data,+structiommu_group*group)+{+structvfio_iommu*iommu=iommu_data;+structvfio_group*g;+structvfio_domain*d;++list_for_each_entry(d,&iommu->domain_list,next){+list_for_each_entry(g,&d->group_list,next){+if(g->iommu_group==group)+returnd;+}+}+returnNULL;+}++staticintvfio_iommu_type1_alloc_map_reserved_iova(void*iommu_data,+structiommu_group*group,+phys_addr_taddr,intprot,+dma_addr_t*iova)+{+structvfio_iommu*iommu=iommu_data;+structvfio_domain*d;+uint64_tmask,iommu_page_size;+structvfio_reserved_binding*b;+unsignedlongorder;+structiova*p_iova;+phys_addr_taligned_addr,offset;+intret=0;++order=__ffs(vfio_pgsize_bitmap(iommu));+iommu_page_size=(uint64_t)1<<order;+mask=iommu_page_size-1;+aligned_addr=addr&~mask;+offset=addr-aligned_addr;++mutex_lock(&iommu->lock);++d=vfio_find_iommu_domain(iommu_data,group);+if(!d){+ret=-EINVAL;+gotounlock;+}++b=vfio_find_reserved_binding(d,aligned_addr,iommu_page_size);+if(b){+ret=0;+*iova=b->iova+offset;+kref_get(&b->kref);+gotounlock;+}++/* allocate a new reserved IOVA page and a new binding node */+p_iova=alloc_iova(d->reserved_iova_domain,1,+d->reserved_iova_domain->dma_32bit_pfn,true);+if(!p_iova){+ret=-ENOMEM;+gotounlock;+}+*iova=p_iova->pfn_lo<<order;++b=kzalloc(sizeof(*b),GFP_KERNEL);+if(!b){+ret=-ENOMEM;+gotofree_iova_unlock;+}++ret=iommu_map(d->domain,*iova,aligned_addr,iommu_page_size,prot);+if(ret)+gotofree_binding_iova_unlock;++kref_init(&b->kref);+kref_get(&b->kref);+b->domain=d;+b->addr=aligned_addr;+b->iova=*iova;+b->size=iommu_page_size;+vfio_link_reserved_binding(d,b);+*iova+=offset;++gotounlock;++free_binding_iova_unlock:+kfree(b);+free_iova_unlock:+free_iova(d->reserved_iova_domain,*iova>>order);+unlock:+mutex_unlock(&iommu->lock);+returnret;+}++staticintvfio_iommu_type1_unmap_free_reserved_iova(void*iommu_data,+structiommu_group*group,+dma_addr_tiova)+{+structvfio_iommu*iommu=iommu_data;+structvfio_reserved_binding*b;+structvfio_domain*d;+phys_addr_taligned_addr;+dma_addr_taligned_iova,iommu_page_size,mask,offset;+unsignedlongorder;+intret=0;++order=__ffs(vfio_pgsize_bitmap(iommu));+iommu_page_size=(uint64_t)1<<order;+mask=iommu_page_size-1;+aligned_iova=iova&~mask;+offset=iova-aligned_iova;++mutex_lock(&iommu->lock);++d=vfio_find_iommu_domain(iommu_data,group);+if(!d){+ret=-EINVAL;+gotounlock;+}++aligned_addr=iommu_iova_to_phys(d->domain,aligned_iova);++b=vfio_find_reserved_binding(d,aligned_addr,iommu_page_size);+if(!b){+ret=-EINVAL;+gotounlock;+}++kref_put(&b->kref,vfio_reserved_binding_release);++unlock:+mutex_unlock(&iommu->lock);+returnret;+}+staticvoid*vfio_iommu_type1_open(unsignedlongarg){structvfio_iommu*iommu;
@@ -1180,13 +1325,17 @@ static long vfio_iommu_type1_ioctl(void *iommu_data,}staticconststructvfio_iommu_driver_opsvfio_iommu_driver_ops_type1={-.name="vfio-iommu-type1",-.owner=THIS_MODULE,-.open=vfio_iommu_type1_open,-.release=vfio_iommu_type1_release,-.ioctl=vfio_iommu_type1_ioctl,-.attach_group=vfio_iommu_type1_attach_group,-.detach_group=vfio_iommu_type1_detach_group,+.name="vfio-iommu-type1",+.owner=THIS_MODULE,+.open=vfio_iommu_type1_open,+.release=vfio_iommu_type1_release,+.ioctl=vfio_iommu_type1_ioctl,+.attach_group=vfio_iommu_type1_attach_group,+.detach_group=vfio_iommu_type1_detach_group,+.alloc_map_reserved_iova=+vfio_iommu_type1_alloc_map_reserved_iova,+.unmap_free_reserved_iova=+vfio_iommu_type1_unmap_free_reserved_iova,};staticint__initvfio_iommu_type1_init(void)
From: Eric Auger <hidden> Date: 2016-01-26 13:17:11
Introduce new DOMAIN_ATTR_MSI_MAPPING domain attribute. If supported,
this means the MSI addresses need to be mapped in the IOMMU. ARM SMMUS
and FSL PAMU, at least expose this attribute.
x86 IOMMUs typically don't expose the attribute since on x86 MSI write
transaction addresses always are within the 1MB PA region [FEE0_0000h -
FEF0_000h] window which directly targets the APIC configuration space and
hence bypass the sMMU.
Signed-off-by: Bharat Bhushan <redacted>
Signed-off-by: Eric Auger <redacted>
---
to be honest I wonder whether this is property of the sMMU? Isn't it
a platform property?
RFC v1 -> RFC v2:
- the data field is not used
- for this attribute domain_get_attr simply returns 0 if the MSI_MAPPING
capability if needed or <0 if not.
- removed struct iommu_domain_msi_maps
---
drivers/iommu/arm-smmu.c | 2 ++
drivers/iommu/fsl_pamu_domain.c | 3 +++
include/linux/iommu.h | 1 +
3 files changed, 6 insertions(+)
From: kbuild test robot <hidden> Date: 2016-01-26 14:44:24
Hi Eric,
[auto build test WARNING on v4.5-rc1]
[also build test WARNING on next-20160125]
[cannot apply to iommu/next]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]
url: https://github.com/0day-ci/linux/commits/Eric-Auger/KVM-PCIe-MSI-passthrough-on-ARM-ARM64/20160126-211921
config: i386-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/vfio/pci/vfio_pci_intrs.c: In function 'vfio_set_mapped_msi_addr':
quoted
drivers/vfio/pci/vfio_pci_intrs.c:324:43: warning: left shift count >= width of type [-Wshift-count-overflow]
From: Eric Auger <hidden> Date: 2016-01-26 15:14:46
Hi,
On 01/26/2016 03:43 PM, kbuild test robot wrote:
Hi Eric,
[auto build test WARNING on v4.5-rc1]
[also build test WARNING on next-20160125]
[cannot apply to iommu/next]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]
url: https://github.com/0day-ci/linux/commits/Eric-Auger/KVM-PCIe-MSI-passthrough-on-ARM-ARM64/20160126-211921
config: i386-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/vfio/pci/vfio_pci_intrs.c: In function 'vfio_set_mapped_msi_addr':
quoted
quoted
drivers/vfio/pci/vfio_pci_intrs.c:324:43: warning: left shift count >= width of type [-Wshift-count-overflow]
From: kbuild test robot <hidden> Date: 2016-01-26 16:19:06
Hi Eric,
[auto build test ERROR on v4.5-rc1]
[also build test ERROR on next-20160125]
[cannot apply to iommu/next]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]
url: https://github.com/0day-ci/linux/commits/Eric-Auger/KVM-PCIe-MSI-passthrough-on-ARM-ARM64/20160126-211921
config: x86_64-randconfig-s3-01262306 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
From: Eric Auger <hidden> Date: 2016-01-26 16:38:12
Hi,
On 01/26/2016 05:17 PM, kbuild test robot wrote:
Hi Eric,
[auto build test ERROR on v4.5-rc1]
[also build test ERROR on next-20160125]
[cannot apply to iommu/next]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]
url: https://github.com/0day-ci/linux/commits/Eric-Auger/KVM-PCIe-MSI-passthrough-on-ARM-ARM64/20160126-211921
config: x86_64-randconfig-s3-01262306 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
From: kbuild test robot <hidden> Date: 2016-01-26 16:43:28
Hi Eric,
[auto build test ERROR on v4.5-rc1]
[also build test ERROR on next-20160125]
[cannot apply to iommu/next]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]
url: https://github.com/0day-ci/linux/commits/Eric-Auger/KVM-PCIe-MSI-passthrough-on-ARM-ARM64/20160126-211921
config: x86_64-randconfig-s3-01262306 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
ERROR: "alloc_iova" [drivers/vfio/vfio_iommu_type1.ko] undefined!
From: Pavel Fedin <hidden> Date: 2016-01-26 17:25:14
Hello!
I'd like just to clarify some things for myself and better wrap my head around it...
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.
So, this is effectively the same as always having hardwired 1:1 mappings on all IOMMUs, isn't it ?
If so, then we can't we just do the same, just by forcing similar 1:1 mapping? This is what i tried to do in my patchset. All of
you are talking about a situation which arises when we are emulating different machine with different physical addresses layout. And
e. g. if our host has MSI at 0xABADCAFE, our target could have valid RAM at the same location, and we need to handle it somehow,
therefore we have to move our MSI window out of target's RAM. But how does this work on a PC then? What if our host is PC, and we
want to emulate some ARM board, which has RAM at FE00 0000 ? Or does it mean that PC architecture is flawed and can reliably handle
PCI passthrough only for itself ?
Kind regards,
Pavel Fedin
Senior Engineer
Samsung Electronics Research center Russia
From: kbuild test robot <hidden> Date: 2016-01-26 18:38:01
Hi Eric,
[auto build test ERROR on v4.5-rc1]
[also build test ERROR on next-20160125]
[cannot apply to iommu/next]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]
url: https://github.com/0day-ci/linux/commits/Eric-Auger/KVM-PCIe-MSI-passthrough-on-ARM-ARM64/20160126-211921
config: x86_64-randconfig-s3-01270003 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/built-in.o: In function `vfio_reserved_binding_release':
vfio_iommu_type1.c:(.text+0x1d537b): undefined reference to `free_iova'
drivers/built-in.o: In function `vfio_iommu_type1_alloc_map_reserved_iova':
vfio_iommu_type1.c:(.text+0x1d5b32): undefined reference to `alloc_iova'
vfio_iommu_type1.c:(.text+0x1d5d67): undefined reference to `free_iova'
drivers/built-in.o: In function `vfio_remove_dma':
quoted
vfio_iommu_type1.c:(.text+0x1d6c80): undefined reference to `put_iova_domain'
drivers/built-in.o: In function `vfio_iommu_type1_ioctl':
quoted
vfio_iommu_type1.c:(.text+0x1d81f8): undefined reference to `init_iova_domain'
From: Eric Auger <hidden> Date: 2016-01-27 08:52:54
Hi Pavel,
On 01/26/2016 06:25 PM, Pavel Fedin wrote:
Hello!
I'd like just to clarify some things for myself and better wrap my head around it...
quoted
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.
So, this is effectively the same as always having hardwired 1:1 mappings on all IOMMUs, isn't it ?
If so, then we can't we just do the same, just by forcing similar 1:1 mapping? This is what i tried to do in my patchset. All of
you are talking about a situation which arises when we are emulating different machine with different physical addresses layout. And
e. g. if our host has MSI at 0xABADCAFE, our target could have valid RAM at the same location, and we need to handle it somehow,
therefore we have to move our MSI window out of target's RAM. But how does this work on a PC then? What if our host is PC, and we
want to emulate some ARM board, which has RAM at FE00 0000 ? Or does it mean that PC architecture is flawed and can reliably handle
PCI passthrough only for itself ?
Alex answered to this I think:
"
x86 isn't problem-free in this space. An x86 VM is going to know that
the 0xfee00000 address range is special, it won't be backed by RAM and
won't be a DMA target, thus we'll never attempt to map it for an iova
address. However, if we run a non-x86 VM or a userspace driver, it
doesn't necessarily know that there's anything special about that range
of iovas. I intend to resolve this with an extension to the iommu info
ioctl that describes the available iova space for the iommu. The
interrupt region would simply be excluded.
"
I am not sure I've addressed this requirement yet but it seems more
future proof to have an IOMMU mapping for those addresses.
For the ARM use case I think Marc gave guidance:
"
We want userspace to be in control of the memory map, and it
is the kernel's job to tell us whether or not this matches the HW
capabilities or not. A fixed mapping may completely clash with the
memory map I want (think emulating HW x on platform y), and there is no
reason why we should have the restrictions x86 has.
"
That's the rationale behind respining that way.
Waiting for other comments & discussions, I am going to address the iova
and dma_addr_t kbuilt reported compilation issues. Please apologize for
those.
Best Regards
Eric
Kind regards,
Pavel Fedin
Senior Engineer
Samsung Electronics Research center Russia
From: Pavel Fedin <hidden> Date: 2016-01-28 07:13:28
Hello!
x86 isn't problem-free in this space. An x86 VM is going to know that
the 0xfee00000 address range is special, it won't be backed by RAM and
won't be a DMA target, thus we'll never attempt to map it for an iova
address. However, if we run a non-x86 VM or a userspace driver, it
doesn't necessarily know that there's anything special about that range
of iovas. I intend to resolve this with an extension to the iommu info
ioctl that describes the available iova space for the iommu. The
interrupt region would simply be excluded.
I see now, but i still don't understand how it would work. How can we tell the guest OS that we cannot do DMA to this particular
area? Just exclude it from RAM at all? But this means we would have to modify machine's model...
I know that this is a bit different story from what we are implementing now. Just curious.
Kind regards,
Pavel Fedin
Senior Engineer
Samsung Electronics Research center Russia
From: Eric Auger <hidden> Date: 2016-01-28 09:50:24
Hi Pavel,
On 01/28/2016 08:13 AM, Pavel Fedin wrote:
Hello!
quoted
x86 isn't problem-free in this space. An x86 VM is going to know that
the 0xfee00000 address range is special, it won't be backed by RAM and
won't be a DMA target, thus we'll never attempt to map it for an iova
address. However, if we run a non-x86 VM or a userspace driver, it
doesn't necessarily know that there's anything special about that range
of iovas. I intend to resolve this with an extension to the iommu info
ioctl that describes the available iova space for the iommu. The
interrupt region would simply be excluded.
I see now, but i still don't understand how it would work. How can we tell the guest OS that we cannot do DMA to this particular
area? Just exclude it from RAM at all? But this means we would have to modify machine's model...
I know that this is a bit different story from what we are implementing now. Just curious.
Well in QEMU mach-virt we have a static guest PA memory map. Maybe in
some other virt machines this is different and it is possible to take
into account the fact an IOVA range cannot be used?
Regards
Eric
Kind regards,
Pavel Fedin
Senior Engineer
Samsung Electronics Research center Russia
From: Alex Williamson <hidden> Date: 2016-01-28 21:52:08
On Tue, 2016-01-26 at 13:12 +0000, Eric Auger wrote:
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.
I'm sort of on a think-different approach today, so bear with me; how is
it that x86 can make interrupt remapping so transparent to drivers like
vfio-pci while for ARM and ppc we seem to be stuck with doing these
fixups of the physical vector ourselves, implying ugly (no offense)
paths bouncing through vfio to connect the driver and iommu backends?
We know that x86 handles MSI vectors specially, so there is some
hardware that helps the situation.??It's not just that x86 has a fixed
range for MSI, it's how it manages that range when interrupt remapping
hardware is enabled.??A device table indexed by source-ID references a
per device table indexed by data from the MSI write itself.??So we get
much, much finer granularity, but there's still effectively an interrupt
domain per device that's being transparently managed under the covers
whenever we request an MSI vector for a device.
So why can't we do something more like that here???There's no predefined
MSI vector range, so defining an interface for the user to specify that
is unavoidable.??But why shouldn't everything else be transparent???We
could add an interface to the IOMMU API that allows us to register that
reserved range for the IOMMU domain.??IOMMU-core (or maybe interrupt
remapping) code might allocate an IOVA domain for this just as you've
done in the type1 code here.??But rather than having any interaction
with vfio-pci, why not do this at lower levels such that the platform
interrupt vector allocation code automatically uses one of those IOVA
ranges and returns the IOVA rather than the physical address for the PCI
code to program into the device???I think we know what needs to be done,
but we're taking the approach of managing the space ourselves and doing
a fixup of the device after the core code has done its job when we
really ought to be letting the core code manage a space that we define
and programming the device so that it doesn't need a fixup in the
vfio-pci code.??Wouldn't it be nicer if pci_enable_msix_range() returned
with the device properly programmed or generate an error if there's not
enough reserved mapping space in IOMMU domain? Can it be done???Thanks,
Alex
From: Eric Auger <hidden> Date: 2016-01-29 14:35:51
Hi Alex,
On 01/28/2016 10:51 PM, Alex Williamson wrote:
On Tue, 2016-01-26 at 13:12 +0000, Eric Auger wrote:
quoted
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.
I'm sort of on a think-different approach today, so bear with me; how is
it that x86 can make interrupt remapping so transparent to drivers like
vfio-pci while for ARM and ppc we seem to be stuck with doing these
fixups of the physical vector ourselves, implying ugly (no offense)
paths bouncing through vfio to connect the driver and iommu backends?
We know that x86 handles MSI vectors specially, so there is some
hardware that helps the situation. It's not just that x86 has a fixed
range for MSI, it's how it manages that range when interrupt remapping
hardware is enabled. A device table indexed by source-ID references a
per device table indexed by data from the MSI write itself. So we get
much, much finer granularity,
About the granularity, I think ARM GICv3 now provides a similar
capability with GICv3 ITS (interrupt translation service). Along with
the MSI MSG write transaction, the device outputs a DeviceID conveyed on
the bus. This DeviceID (~ your source-ID) enables to index a device
table. The entry in the device table points to a DeviceId interrupt
translation table indexed by the EventID found in the msi msg. So the
entry in the interrupt translation table eventually gives you the
eventual interrupt ID targeted by the MSI MSG.
This translation capability if not available in GICv2M though, ie. the
one I am currently using.
Those tables currently are built by the ITS irqchip (irq-gic-v3-its.c)
but there's still effectively an interrupt
domain per device that's being transparently managed under the covers
whenever we request an MSI vector for a device.
So why can't we do something more like that here? There's no predefined
MSI vector range, so defining an interface for the user to specify that
is unavoidable.
Do you confirm that VFIO user API still still is the good choice to
provide that IOVA range?
But why shouldn't everything else be transparent? We
could add an interface to the IOMMU API that allows us to register that
reserved range for the IOMMU domain. IOMMU-core (or maybe interrupt
remapping) code might allocate an IOVA domain for this just as you've
done in the type1 code here.
I have no objection to move that iova allocation scheme somewhere else.
I just need to figure out how to deal with the fact iova.c is not
compiled everywhere as I noticed too late ;-)
But rather than having any interaction
with vfio-pci, why not do this at lower levels such that the platform
interrupt vector allocation code automatically uses one of those IOVA
ranges and returns the IOVA rather than the physical address for the PCI
code to program into the device? I think we know what needs to be done,
but we're taking the approach of managing the space ourselves and doing
a fixup of the device after the core code has done its job when we
really ought to be letting the core code manage a space that we define
and programming the device so that it doesn't need a fixup in the
vfio-pci code. Wouldn't it be nicer if pci_enable_msix_range() returned
with the device properly programmed or generate an error if there's not
enough reserved mapping space in IOMMU domain? Can it be done?
I agree with you on the fact it would be cleaner to manage that natively
at MSI controller level instead of patching the address value in
vfio_pci_intrs.c. I will investigate in that direction but I need some
more time to understand the links between the MSI controller, the PCI
device and the IOMMU.
Best Regards
Eric
Thanks,
From: Alex Williamson <hidden> Date: 2016-01-29 19:33:29
On Fri, 2016-01-29 at 15:35 +0100, Eric Auger wrote:
Hi Alex,
On 01/28/2016 10:51 PM, Alex Williamson wrote:
quoted
On Tue, 2016-01-26 at 13:12 +0000, Eric Auger wrote:
quoted
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.
?
I'm sort of on a think-different approach today, so bear with me; how is
it that x86 can make interrupt remapping so transparent to drivers like
vfio-pci while for ARM and ppc we seem to be stuck with doing these
fixups of the physical vector ourselves, implying ugly (no offense)
paths bouncing through vfio to connect the driver and iommu backends?
?
We know that x86 handles MSI vectors specially, so there is some
hardware that helps the situation.??It's not just that x86 has a fixed
range for MSI, it's how it manages that range when interrupt remapping
hardware is enabled.??A device table indexed by source-ID references a
per device table indexed by data from the MSI write itself.??So we get
much, much finer granularity,
About the granularity, I think ARM GICv3 now provides a similar
capability with GICv3 ITS (interrupt translation service). Along with
the MSI MSG write transaction, the device outputs a DeviceID conveyed on
the bus. This DeviceID (~ your source-ID) enables to index a device
table. The entry in the device table points to a DeviceId interrupt
translation table indexed by the EventID found in the msi msg. So the
entry in the interrupt translation table eventually gives you the
eventual interrupt ID targeted by the MSI MSG.
This translation capability if not available in GICv2M though, ie. the
one I am currently using.
?
Those tables currently are built by the ITS irqchip (irq-gic-v3-its.c)
So it sounds like the interrupt remapping plumbing needs to be
implemented for those chips.??How does ITS identify an MSI versus any
other DMA write???Does it need to be within a preconfigured address
space like on x86 or does it know this implicitly by the transaction
(which doesn't seem possible on PCIe)?
Along with this discussion, we should probably be revisiting whether
existing ARM SMMUs should be exposing the IOMMU_CAP_INTR_REMAP
capability.??This capability is meant to indicate interrupt isolation,
but if an entire page of IOVA space is mapped through the IOMMU to a
range of interrupts and some of those interrupts are shared with host
devices or other VMs, then we really don't have that isolation and the
system is susceptible to one VM interfering with another or with the
host.??If that's the case, the SMMU should not be claiming
IOMMU_CAP_INTR_REMAP.
?but there's still effectively an interrupt
quoted
domain per device that's being transparently managed under the covers
whenever we request an MSI vector for a device.
?
So why can't we do something more like that here???There's no predefined
MSI vector range, so defining an interface for the user to specify that
is unavoidable.
Do you confirm that VFIO user API still still is the good choice to
provide that IOVA range?
I don't see that we have an option there unless ARM wants to
retroactively reserve a range of IOVA space in the spec, which is
certainly not going to happen.??The only other thing that comes to mind
would be if there was an existing address space which could never be
backed by RAM or other DMA capable targets.??But that seems far fetched
as well.
? But why shouldn't everything else be transparent???We
quoted
could add an interface to the IOMMU API that allows us to register that
reserved range for the IOMMU domain.??IOMMU-core (or maybe interrupt
remapping) code might allocate an IOVA domain for this just as you've
done in the type1 code here.
I have no objection to move that iova allocation scheme somewhere else.
I just need to figure out how to deal with the fact iova.c is not
compiled everywhere as I noticed too late ;-)
? But rather than having any interaction
quoted
with vfio-pci, why not do this at lower levels such that the platform
interrupt vector allocation code automatically uses one of those IOVA
ranges and returns the IOVA rather than the physical address for the PCI
code to program into the device???I think we know what needs to be done,
but we're taking the approach of managing the space ourselves and doing
a fixup of the device after the core code has done its job when we
really ought to be letting the core code manage a space that we define
and programming the device so that it doesn't need a fixup in the
vfio-pci code.??Wouldn't it be nicer if pci_enable_msix_range() returned
with the device properly programmed or generate an error if there's not
enough reserved mapping space in IOMMU domain???Can it be done?
I agree with you on the fact it would be cleaner to manage that natively
at MSI controller level instead of patching the address value in
vfio_pci_intrs.c. I will investigate in that direction but I need some
more time to understand the links between the MSI controller, the PCI
device and the IOMMU.
Since the current interrupt remapping schemes seem to operate in a
different address space, I expect there will be work to do to fit the
interrupt remapping within a provided address space, but it seems like a
very reasonable constraint to add.??Thanks,
Alex
From: Eric Auger <hidden> Date: 2016-01-29 21:26:15
Hi Alex,
On 01/29/2016 08:33 PM, Alex Williamson wrote:
On Fri, 2016-01-29 at 15:35 +0100, Eric Auger wrote:
quoted
Hi Alex,
On 01/28/2016 10:51 PM, Alex Williamson wrote:
quoted
On Tue, 2016-01-26 at 13:12 +0000, Eric Auger wrote:
quoted
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.
I'm sort of on a think-different approach today, so bear with me; how is
it that x86 can make interrupt remapping so transparent to drivers like
vfio-pci while for ARM and ppc we seem to be stuck with doing these
fixups of the physical vector ourselves, implying ugly (no offense)
paths bouncing through vfio to connect the driver and iommu backends?
We know that x86 handles MSI vectors specially, so there is some
hardware that helps the situation. It's not just that x86 has a fixed
range for MSI, it's how it manages that range when interrupt remapping
hardware is enabled. A device table indexed by source-ID references a
per device table indexed by data from the MSI write itself. So we get
much, much finer granularity,
About the granularity, I think ARM GICv3 now provides a similar
capability with GICv3 ITS (interrupt translation service). Along with
the MSI MSG write transaction, the device outputs a DeviceID conveyed on
the bus. This DeviceID (~ your source-ID) enables to index a device
table. The entry in the device table points to a DeviceId interrupt
translation table indexed by the EventID found in the msi msg. So the
entry in the interrupt translation table eventually gives you the
eventual interrupt ID targeted by the MSI MSG.
This translation capability if not available in GICv2M though, ie. the
one I am currently using.
Those tables currently are built by the ITS irqchip (irq-gic-v3-its.c)
So it sounds like the interrupt remapping plumbing needs to be
implemented for those chips. How does ITS identify an MSI versus any
other DMA write? Does it need to be within a preconfigured address
space like on x86 or does it know this implicitly by the transaction
(which doesn't seem possible on PCIe)?
It seems there is a kind of misunderstanding here. Assuming a "simple"
system with a single ITS, all devices likely to produce MSI must write
those messages in a single register, located in the ITS MSI 64kB frame
(this register is called GITS_TRANSLATER). Then the ITS discriminates
between senders using the DeviceID conveyed out-of-band on the bus (or
by other implementation defined means). For those DeviceId, a deviceId
interrupt translation table is supposed to exist, else it is going to
fault. If any "undeclared" device is writing into that register, its
deviceid will be unknown. It looks like on Intel the interrupt remapping
HW rather is abstracted on the IOMMU side; I did not take time yet to
carefully read the VT-d spec but maybe the Intel interrupt remapping HW
rather acts as an IOMMU that takes an input MSI address within the
famous window and apply a translation scheme based on the MSI address &
data? On ARM the input MSI address always is the GITS_TRANSLATER and
then the translation scheme is based on out-of-band info (deviceid) +
data content(eventid). I Hope this clarifies.
Along with this discussion, we should probably be revisiting whether
existing ARM SMMUs should be exposing the IOMMU_CAP_INTR_REMAP
capability.
so according to the above explanation not sure it is relevant. Will/Marc
might correct me if I told some wrong things.
This capability is meant to indicate interrupt isolation,
but if an entire page of IOVA space is mapped through the IOMMU to a
range of interrupts and some of those interrupts are shared with host
devices or other VMs, then we really don't have that isolation and the
system is susceptible to one VM interfering with another or with the
host. If that's the case, the SMMU should not be claiming
IOMMU_CAP_INTR_REMAP.
My understanding is a PCI device working for the host must have its own
deviceid translation table while another one assigned to a guest needs
to have another one. Each of those will then trigger different final
interrupt IDs in separate domains.
To be honest for the time being I was not addressing the ITS case but
just the simpler GICv2m case where we do not have interrupt translation.
In GICv2m with a single 4kB MSI frame you still have a single register
written by devices. The msg data content then induces a given interrupt ID.
My kernel series "just" aimed at allowing the device to reach the
physical address of the GICv2m MSI frame through the IOMMU.
But you're right here I think I should have a larger vision of what is
targeted with ITS. In GICv2m with a single MSI frame the discrimination
only works on the msi data (there is no deviceid). However it is also
possible to have several GICv2M MSI 4kB frames and in that case you can
give 1 MSI 4kB frame per VM but it is yet another use case. My AMD
system currently exposes a single MSI frame - in which case we have poor
isolation as you say -.
quoted
but there's still effectively an interrupt
quoted
domain per device that's being transparently managed under the covers
whenever we request an MSI vector for a device.
So why can't we do something more like that here? There's no predefined
MSI vector range, so defining an interface for the user to specify that
is unavoidable.
Do you confirm that VFIO user API still still is the good choice to
provide that IOVA range?
I don't see that we have an option there unless ARM wants to
retroactively reserve a range of IOVA space in the spec, which is
certainly not going to happen. The only other thing that comes to mind
would be if there was an existing address space which could never be
backed by RAM or other DMA capable targets. But that seems far fetched
as well.
I don't think there is a plan for such change and I am afraid we need to
integrate above configurations (GICv2M with a single frame, GICv2M with
several frames, ITS and there may be others not covered here that I am
not aware of).
quoted
But why shouldn't everything else be transparent? We
quoted
could add an interface to the IOMMU API that allows us to register that
reserved range for the IOMMU domain. IOMMU-core (or maybe interrupt
remapping) code might allocate an IOVA domain for this just as you've
done in the type1 code here.
I have no objection to move that iova allocation scheme somewhere else.
I just need to figure out how to deal with the fact iova.c is not
compiled everywhere as I noticed too late ;-)
But rather than having any interaction
quoted
with vfio-pci, why not do this at lower levels such that the platform
interrupt vector allocation code automatically uses one of those IOVA
ranges and returns the IOVA rather than the physical address for the PCI
code to program into the device? I think we know what needs to be done,
but we're taking the approach of managing the space ourselves and doing
a fixup of the device after the core code has done its job when we
really ought to be letting the core code manage a space that we define
and programming the device so that it doesn't need a fixup in the
vfio-pci code. Wouldn't it be nicer if pci_enable_msix_range() returned
with the device properly programmed or generate an error if there's not
enough reserved mapping space in IOMMU domain? Can it be done?
I agree with you on the fact it would be cleaner to manage that natively
at MSI controller level instead of patching the address value in
vfio_pci_intrs.c. I will investigate in that direction but I need some
more time to understand the links between the MSI controller, the PCI
device and the IOMMU.
Since the current interrupt remapping schemes seem to operate in a
different address space, I expect there will be work to do to fit the
interrupt remapping within a provided address space, but it seems like a
very reasonable constraint to add. Thanks,
I hope this discussion will help. Please ARM guys, correct me if there
are some unclarities or wrong statements.
Thank you for reading up to here and have a nice WE!
Best Regards
Eric
From: Will Deacon <hidden> Date: 2016-02-01 14:03:55
On Fri, Jan 29, 2016 at 10:25:52PM +0100, Eric Auger wrote:
On 01/29/2016 08:33 PM, Alex Williamson wrote:
quoted
quoted
quoted
We know that x86 handles MSI vectors specially, so there is some
hardware that helps the situation. It's not just that x86 has a fixed
range for MSI, it's how it manages that range when interrupt remapping
hardware is enabled. A device table indexed by source-ID references a
per device table indexed by data from the MSI write itself. So we get
much, much finer granularity,
About the granularity, I think ARM GICv3 now provides a similar
capability with GICv3 ITS (interrupt translation service). Along with
the MSI MSG write transaction, the device outputs a DeviceID conveyed on
the bus. This DeviceID (~ your source-ID) enables to index a device
table. The entry in the device table points to a DeviceId interrupt
translation table indexed by the EventID found in the msi msg. So the
entry in the interrupt translation table eventually gives you the
eventual interrupt ID targeted by the MSI MSG.
This translation capability if not available in GICv2M though, ie. the
one I am currently using.
Those tables currently are built by the ITS irqchip (irq-gic-v3-its.c)
That's right. GICv3/ITS disambiguates the interrupt source using the
DeviceID, which for PCI is derived from the Requester ID of the endpoint.
GICv2m is less flexible and requires a separate physical frame per guest
to achieve isolation.
Will
From: Christoffer Dall <hidden> Date: 2016-02-03 12:50:26
On Mon, Feb 01, 2016 at 02:03:51PM +0000, Will Deacon wrote:
On Fri, Jan 29, 2016 at 10:25:52PM +0100, Eric Auger wrote:
quoted
On 01/29/2016 08:33 PM, Alex Williamson wrote:
quoted
quoted
quoted
We know that x86 handles MSI vectors specially, so there is some
hardware that helps the situation. It's not just that x86 has a fixed
range for MSI, it's how it manages that range when interrupt remapping
hardware is enabled. A device table indexed by source-ID references a
per device table indexed by data from the MSI write itself. So we get
much, much finer granularity,
About the granularity, I think ARM GICv3 now provides a similar
capability with GICv3 ITS (interrupt translation service). Along with
the MSI MSG write transaction, the device outputs a DeviceID conveyed on
the bus. This DeviceID (~ your source-ID) enables to index a device
table. The entry in the device table points to a DeviceId interrupt
translation table indexed by the EventID found in the msi msg. So the
entry in the interrupt translation table eventually gives you the
eventual interrupt ID targeted by the MSI MSG.
This translation capability if not available in GICv2M though, ie. the
one I am currently using.
Those tables currently are built by the ITS irqchip (irq-gic-v3-its.c)
That's right. GICv3/ITS disambiguates the interrupt source using the
DeviceID, which for PCI is derived from the Requester ID of the endpoint.
GICv2m is less flexible and requires a separate physical frame per guest
to achieve isolation.
We should still support MSI passthrough with a single MSI frame host
system though, right?
(Users should just be aware that guests are not fully protected against
misbehaving hardware in that case).
-Christoffer
From: Will Deacon <hidden> Date: 2016-02-03 13:11:10
On Wed, Feb 03, 2016 at 01:50:47PM +0100, Christoffer Dall wrote:
On Mon, Feb 01, 2016 at 02:03:51PM +0000, Will Deacon wrote:
quoted
On Fri, Jan 29, 2016 at 10:25:52PM +0100, Eric Auger wrote:
quoted
On 01/29/2016 08:33 PM, Alex Williamson wrote:
quoted
quoted
quoted
We know that x86 handles MSI vectors specially, so there is some
hardware that helps the situation. It's not just that x86 has a fixed
range for MSI, it's how it manages that range when interrupt remapping
hardware is enabled. A device table indexed by source-ID references a
per device table indexed by data from the MSI write itself. So we get
much, much finer granularity,
About the granularity, I think ARM GICv3 now provides a similar
capability with GICv3 ITS (interrupt translation service). Along with
the MSI MSG write transaction, the device outputs a DeviceID conveyed on
the bus. This DeviceID (~ your source-ID) enables to index a device
table. The entry in the device table points to a DeviceId interrupt
translation table indexed by the EventID found in the msi msg. So the
entry in the interrupt translation table eventually gives you the
eventual interrupt ID targeted by the MSI MSG.
This translation capability if not available in GICv2M though, ie. the
one I am currently using.
Those tables currently are built by the ITS irqchip (irq-gic-v3-its.c)
That's right. GICv3/ITS disambiguates the interrupt source using the
DeviceID, which for PCI is derived from the Requester ID of the endpoint.
GICv2m is less flexible and requires a separate physical frame per guest
to achieve isolation.
We should still support MSI passthrough with a single MSI frame host
system though, right?
I think we should treat the frame as an exclusive resource and assign it
to a single VM.
(Users should just be aware that guests are not fully protected against
misbehaving hardware in that case).
Is it confined to misbehaving hardware? What if a malicious/buggy guest
configures its device to DMA all over the doorbell?
Will
From: Christoffer Dall <hidden> Date: 2016-02-03 15:35:40
On Wed, Feb 03, 2016 at 01:10:58PM +0000, Will Deacon wrote:
On Wed, Feb 03, 2016 at 01:50:47PM +0100, Christoffer Dall wrote:
quoted
On Mon, Feb 01, 2016 at 02:03:51PM +0000, Will Deacon wrote:
quoted
On Fri, Jan 29, 2016 at 10:25:52PM +0100, Eric Auger wrote:
quoted
On 01/29/2016 08:33 PM, Alex Williamson wrote:
quoted
quoted
quoted
We know that x86 handles MSI vectors specially, so there is some
hardware that helps the situation. It's not just that x86 has a fixed
range for MSI, it's how it manages that range when interrupt remapping
hardware is enabled. A device table indexed by source-ID references a
per device table indexed by data from the MSI write itself. So we get
much, much finer granularity,
About the granularity, I think ARM GICv3 now provides a similar
capability with GICv3 ITS (interrupt translation service). Along with
the MSI MSG write transaction, the device outputs a DeviceID conveyed on
the bus. This DeviceID (~ your source-ID) enables to index a device
table. The entry in the device table points to a DeviceId interrupt
translation table indexed by the EventID found in the msi msg. So the
entry in the interrupt translation table eventually gives you the
eventual interrupt ID targeted by the MSI MSG.
This translation capability if not available in GICv2M though, ie. the
one I am currently using.
Those tables currently are built by the ITS irqchip (irq-gic-v3-its.c)
That's right. GICv3/ITS disambiguates the interrupt source using the
DeviceID, which for PCI is derived from the Requester ID of the endpoint.
GICv2m is less flexible and requires a separate physical frame per guest
to achieve isolation.
We should still support MSI passthrough with a single MSI frame host
system though, right?
I think we should treat the frame as an exclusive resource and assign it
to a single VM.
so on a single frame GICv2m system, either your host or a single VM gets
to do MSIs...
quoted
(Users should just be aware that guests are not fully protected against
misbehaving hardware in that case).
Is it confined to misbehaving hardware? What if a malicious/buggy guest
configures its device to DMA all over the doorbell?
I guess not, I suppose we can't trap any configuration access and
mediate that for any device. Bummer.
-Christoffer