Re: [PATCH v9 0/8] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 2/3: msi changes
On 5/10/16, 12:34 AM, "Eric Auger"wrote: >Hi Chalamarla, >> On 5/9/16, 12:48 AM, "Eric Auger" wrote: >> >>> Hi Chalarmala, >>> On 05/05/2016 07:44 PM, Chalamarla, Tirumalesh wrote: Hi Eric, Does this series supports gicv3-its emulation? Do we have a tree with all the dependent patches >>> GICv3 ITS emulation support comes with: >>> [PATCH v4 00/12] KVM: arm64: GICv3 ITS emulation >>> http://permalink.gmane.org/gmane.comp.emulators.kvm.arm.devel/5738 >>> >>> My series just allows PCI device MSI transactions to reach the host MSI >>> frame through the SMMU. Only host GICv2m has been tested at the moment >>> with a guest exposed with a GICv2m too. >> >> >> I wanted to test this series on Cavium Thunder, but the only mode supported >> is Gicv3 with ITS, is there a chance >> That I get a tree with all the dependencies? >I can prepare a kernel tree with all the dependencies including ITS >patches supporting get_doorbell_info. > >Then on userspace side: >- do you plan to use QEMU? >- then can you expose your guest with a GICv3 + v2m? I think this should >work. > >exposing ITS to the guest requires a respin of Pavel's series: >[Qemu-devel] [RFC PATCH v3 0/5] vITS support >(https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg05197.html) >and has more complex kernel dependencies. > >I think exposing the guest with GICv3 + v2m should work Will try both. We have a qemu with that patches will try once the kernel tree is ready. Thanks, Tirumalesh. > >Best Regards > >Eric Thanks, Tirumalesh. On 5/4/16, 8:18 AM, "linux-arm-kernel on behalf of Eric Auger" wrote: > This series implements the MSI address mapping/unmapping in the MSI layer. > IOMMU binding happens on pci_enable_msi since this function can sleep and > return errors. On msi_domain_set_affinity, msi_domain_(de)activate, which > are not allowed to sleep, we simply look for the already existing binding. > > A new MSI domain info flag value is introduced to report whether the msi > domain implements IRQ remapping. GIC v3 ITS is the first MSI controller > advertising it. This flag value will be used by VFIO subsystem to > determine whether MSI forwarding is safe. > > More details & context can be found at: > http://www.linaro.org/blog/core-dump/kvm-pciemsi-passthrough-armarm64/ > > Best Regards > > Eric > > Applies on top of PART 1/3. Also depends on > [PATCH 1/3] iommu: Add MMIO mapping type, > http://comments.gmane.org/gmane.linux.kernel.iommu/12869 > > Git: complete series available at > https://git.linaro.org/people/eric.auger/linux.git/shortlog/refs/heads/v4.6-rc6-pcie-passthrough-v9-msi-v9 > > This branch contains all parts in v9. > > History: > > v8 -> v9: > - use a union in irq_chip_msi_doorbell_info + boolean telling whether the > doorbell is percpu > - decouple irq_data parsing from the actual mapping/unmapping in > msi_handle_doorbell_mappings > - fix misc style issues > > v7 -> v8: > take into account Marc's comments: > - use iommu_msi_msg_pa_to_va with new proto > - change in irq_chip_msi_doorbell_info struct definition: > prot and size became shared between all doorbells and phys_addr_t > __percpu > - cleanups in v2m irqchip > - eventually did not touch MSI_FLAG_IRQ_REMAPPING naming > - On msi_handle_doorbell_mappings, stop on the first irqchip where > doorbells > can be found > - fix resource deallocation on mapping failure in msi_domain_alloc_irqs > > v6 -> v7: > - do alloc/map handling on pci_enable_msi and search on > msi_(de)domain_activate > - add msi_doorbell_info callback in irq-chip to retrieve the > characteristics > of doorbells > > RFC v5 -> patch v6: > - split to ease the review process > - rebase on default iommu domain code (irq_data_to_msi_mapping_domain > checks IOMMU_DOMAIN_DMA type) > - fix unmap sequence on msi_domain_set_affinity (reported by Marc): > unmap the previous doorbell when the new one has been mapped & written to > the device, ie. irq_chip_write_msi_msg. > - "msi: msi_compose wrapper removed" following change above > - add size parameter to iommu_get_reserved_iova API following Marc's > request > > RFC v4 -> RFC v5: > - take into account Thomas' comments on MSI related patches > - split "msi: IOMMU map the doorbell address when needed" > - increase readability and add comments > - fix style issues > - split "iommu: Add DOMAIN_ATTR_MSI_MAPPING attribute" > - platform ITS now advertises IOMMU_CAP_INTR_REMAP > - fix compilation issue with CONFIG_IOMMU API unset > - arm-smmu-v3 now advertises
Re: [PATCH v9 0/8] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 2/3: msi changes
Hi Chalamarla, > On 5/9/16, 12:48 AM, "Eric Auger"wrote: > >> Hi Chalarmala, >> On 05/05/2016 07:44 PM, Chalamarla, Tirumalesh wrote: >>> Hi Eric, >>> >>> Does this series supports gicv3-its emulation? >>> Do we have a tree with all the dependent patches >> GICv3 ITS emulation support comes with: >> [PATCH v4 00/12] KVM: arm64: GICv3 ITS emulation >> http://permalink.gmane.org/gmane.comp.emulators.kvm.arm.devel/5738 >> >> My series just allows PCI device MSI transactions to reach the host MSI >> frame through the SMMU. Only host GICv2m has been tested at the moment >> with a guest exposed with a GICv2m too. > > > I wanted to test this series on Cavium Thunder, but the only mode supported > is Gicv3 with ITS, is there a chance > That I get a tree with all the dependencies? I can prepare a kernel tree with all the dependencies including ITS patches supporting get_doorbell_info. Then on userspace side: - do you plan to use QEMU? - then can you expose your guest with a GICv3 + v2m? I think this should work. exposing ITS to the guest requires a respin of Pavel's series: [Qemu-devel] [RFC PATCH v3 0/5] vITS support (https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg05197.html) and has more complex kernel dependencies. I think exposing the guest with GICv3 + v2m should work Best Regards Eric >>> Thanks, >>> Tirumalesh. >>> On 5/4/16, 8:18 AM, "linux-arm-kernel on behalf of Eric Auger" >>> >> eric.au...@linaro.org> wrote: >>> This series implements the MSI address mapping/unmapping in the MSI layer. IOMMU binding happens on pci_enable_msi since this function can sleep and return errors. On msi_domain_set_affinity, msi_domain_(de)activate, which are not allowed to sleep, we simply look for the already existing binding. A new MSI domain info flag value is introduced to report whether the msi domain implements IRQ remapping. GIC v3 ITS is the first MSI controller advertising it. This flag value will be used by VFIO subsystem to determine whether MSI forwarding is safe. More details & context can be found at: http://www.linaro.org/blog/core-dump/kvm-pciemsi-passthrough-armarm64/ Best Regards Eric Applies on top of PART 1/3. Also depends on [PATCH 1/3] iommu: Add MMIO mapping type, http://comments.gmane.org/gmane.linux.kernel.iommu/12869 Git: complete series available at https://git.linaro.org/people/eric.auger/linux.git/shortlog/refs/heads/v4.6-rc6-pcie-passthrough-v9-msi-v9 This branch contains all parts in v9. History: v8 -> v9: - use a union in irq_chip_msi_doorbell_info + boolean telling whether the doorbell is percpu - decouple irq_data parsing from the actual mapping/unmapping in msi_handle_doorbell_mappings - fix misc style issues v7 -> v8: take into account Marc's comments: - use iommu_msi_msg_pa_to_va with new proto - change in irq_chip_msi_doorbell_info struct definition: prot and size became shared between all doorbells and phys_addr_t __percpu - cleanups in v2m irqchip - eventually did not touch MSI_FLAG_IRQ_REMAPPING naming - On msi_handle_doorbell_mappings, stop on the first irqchip where doorbells can be found - fix resource deallocation on mapping failure in msi_domain_alloc_irqs v6 -> v7: - do alloc/map handling on pci_enable_msi and search on msi_(de)domain_activate - add msi_doorbell_info callback in irq-chip to retrieve the characteristics of doorbells RFC v5 -> patch v6: - split to ease the review process - rebase on default iommu domain code (irq_data_to_msi_mapping_domain checks IOMMU_DOMAIN_DMA type) - fix unmap sequence on msi_domain_set_affinity (reported by Marc): unmap the previous doorbell when the new one has been mapped & written to the device, ie. irq_chip_write_msi_msg. - "msi: msi_compose wrapper removed" following change above - add size parameter to iommu_get_reserved_iova API following Marc's request RFC v4 -> RFC v5: - take into account Thomas' comments on MSI related patches - split "msi: IOMMU map the doorbell address when needed" - increase readability and add comments - fix style issues - split "iommu: Add DOMAIN_ATTR_MSI_MAPPING attribute" - platform ITS now advertises IOMMU_CAP_INTR_REMAP - fix compilation issue with CONFIG_IOMMU API unset - arm-smmu-v3 now advertises DOMAIN_ATTR_MSI_MAPPING RFC v3 -> v4: - Move doorbell mapping/unmapping in msi.c - fix ref count issue on set_affinity: in case of a change in the address the previous address is decremented - doorbell map/unmap now is done on msi composition. Should allow the use case for platform MSI
Re: [PATCH v9 0/8] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 2/3: msi changes
On 5/9/16, 12:48 AM, "Eric Auger"wrote: >Hi Chalarmala, >On 05/05/2016 07:44 PM, Chalamarla, Tirumalesh wrote: >> Hi Eric, >> >> Does this series supports gicv3-its emulation? >> Do we have a tree with all the dependent patches >GICv3 ITS emulation support comes with: >[PATCH v4 00/12] KVM: arm64: GICv3 ITS emulation >http://permalink.gmane.org/gmane.comp.emulators.kvm.arm.devel/5738 > >My series just allows PCI device MSI transactions to reach the host MSI >frame through the SMMU. Only host GICv2m has been tested at the moment >with a guest exposed with a GICv2m too. I wanted to test this series on Cavium Thunder, but the only mode supported is Gicv3 with ITS, is there a chance That I get a tree with all the dependencies? > >Best Regards > >Eric > > >> >> >> >> >> >> Thanks, >> Tirumalesh. >> On 5/4/16, 8:18 AM, "linux-arm-kernel on behalf of Eric Auger" >> > eric.au...@linaro.org> wrote: >> >>> This series implements the MSI address mapping/unmapping in the MSI layer. >>> IOMMU binding happens on pci_enable_msi since this function can sleep and >>> return errors. On msi_domain_set_affinity, msi_domain_(de)activate, which >>> are not allowed to sleep, we simply look for the already existing binding. >>> >>> A new MSI domain info flag value is introduced to report whether the msi >>> domain implements IRQ remapping. GIC v3 ITS is the first MSI controller >>> advertising it. This flag value will be used by VFIO subsystem to >>> determine whether MSI forwarding is safe. >>> >>> More details & context can be found at: >>> http://www.linaro.org/blog/core-dump/kvm-pciemsi-passthrough-armarm64/ >>> >>> Best Regards >>> >>> Eric >>> >>> Applies on top of PART 1/3. Also depends on >>> [PATCH 1/3] iommu: Add MMIO mapping type, >>> http://comments.gmane.org/gmane.linux.kernel.iommu/12869 >>> >>> Git: complete series available at >>> https://git.linaro.org/people/eric.auger/linux.git/shortlog/refs/heads/v4.6-rc6-pcie-passthrough-v9-msi-v9 >>> >>> This branch contains all parts in v9. >>> >>> History: >>> >>> v8 -> v9: >>> - use a union in irq_chip_msi_doorbell_info + boolean telling whether the >>> doorbell is percpu >>> - decouple irq_data parsing from the actual mapping/unmapping in >>> msi_handle_doorbell_mappings >>> - fix misc style issues >>> >>> v7 -> v8: >>> take into account Marc's comments: >>> - use iommu_msi_msg_pa_to_va with new proto >>> - change in irq_chip_msi_doorbell_info struct definition: >>> prot and size became shared between all doorbells and phys_addr_t __percpu >>> - cleanups in v2m irqchip >>> - eventually did not touch MSI_FLAG_IRQ_REMAPPING naming >>> - On msi_handle_doorbell_mappings, stop on the first irqchip where doorbells >>> can be found >>> - fix resource deallocation on mapping failure in msi_domain_alloc_irqs >>> >>> v6 -> v7: >>> - do alloc/map handling on pci_enable_msi and search on >>> msi_(de)domain_activate >>> - add msi_doorbell_info callback in irq-chip to retrieve the characteristics >>> of doorbells >>> >>> RFC v5 -> patch v6: >>> - split to ease the review process >>> - rebase on default iommu domain code (irq_data_to_msi_mapping_domain >>> checks IOMMU_DOMAIN_DMA type) >>> - fix unmap sequence on msi_domain_set_affinity (reported by Marc): >>> unmap the previous doorbell when the new one has been mapped & written to >>> the device, ie. irq_chip_write_msi_msg. >>> - "msi: msi_compose wrapper removed" following change above >>> - add size parameter to iommu_get_reserved_iova API following Marc's request >>> >>> RFC v4 -> RFC v5: >>> - take into account Thomas' comments on MSI related patches >>> - split "msi: IOMMU map the doorbell address when needed" >>> - increase readability and add comments >>> - fix style issues >>> - split "iommu: Add DOMAIN_ATTR_MSI_MAPPING attribute" >>> - platform ITS now advertises IOMMU_CAP_INTR_REMAP >>> - fix compilation issue with CONFIG_IOMMU API unset >>> - arm-smmu-v3 now advertises DOMAIN_ATTR_MSI_MAPPING >>> >>> RFC v3 -> v4: >>> - Move doorbell mapping/unmapping in msi.c >>> - fix ref count issue on set_affinity: in case of a change in the address >>> the previous address is decremented >>> - doorbell map/unmap now is done on msi composition. Should allow the use >>> case for platform MSI controllers >>> - create dma-reserved-iommu.h/c exposing/implementing a new API dedicated >>> to reserved IOVA management (looking like dma-iommu glue) >>> - series reordering to ease the review: >>> - first part is related to IOMMU >>> - second related to MSI sub-system >>> - third related to VFIO (except arm-smmu IOMMU_CAP_INTR_REMAP removal) >>> - expose the number of requested IOVA pages through VFIO_IOMMU_GET_INFO >>> [this partially addresses Marc's comments on iommu_get/put_single_reserved >>> size/alignment problematic - which I did not ignore - but I don't know >>> how much I can do at the moment] >>> >>> RFC v2
Re: [PATCH v9 0/8] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 2/3: msi changes
Hi Chalarmala, On 05/05/2016 07:44 PM, Chalamarla, Tirumalesh wrote: > Hi Eric, > > Does this series supports gicv3-its emulation? > Do we have a tree with all the dependent patches GICv3 ITS emulation support comes with: [PATCH v4 00/12] KVM: arm64: GICv3 ITS emulation http://permalink.gmane.org/gmane.comp.emulators.kvm.arm.devel/5738 My series just allows PCI device MSI transactions to reach the host MSI frame through the SMMU. Only host GICv2m has been tested at the moment with a guest exposed with a GICv2m too. Best Regards Eric > > > > > > Thanks, > Tirumalesh. > On 5/4/16, 8:18 AM, "linux-arm-kernel on behalf of Eric Auger" >eric.au...@linaro.org> wrote: > >> This series implements the MSI address mapping/unmapping in the MSI layer. >> IOMMU binding happens on pci_enable_msi since this function can sleep and >> return errors. On msi_domain_set_affinity, msi_domain_(de)activate, which >> are not allowed to sleep, we simply look for the already existing binding. >> >> A new MSI domain info flag value is introduced to report whether the msi >> domain implements IRQ remapping. GIC v3 ITS is the first MSI controller >> advertising it. This flag value will be used by VFIO subsystem to >> determine whether MSI forwarding is safe. >> >> More details & context can be found at: >> http://www.linaro.org/blog/core-dump/kvm-pciemsi-passthrough-armarm64/ >> >> Best Regards >> >> Eric >> >> Applies on top of PART 1/3. Also depends on >> [PATCH 1/3] iommu: Add MMIO mapping type, >> http://comments.gmane.org/gmane.linux.kernel.iommu/12869 >> >> Git: complete series available at >> https://git.linaro.org/people/eric.auger/linux.git/shortlog/refs/heads/v4.6-rc6-pcie-passthrough-v9-msi-v9 >> >> This branch contains all parts in v9. >> >> History: >> >> v8 -> v9: >> - use a union in irq_chip_msi_doorbell_info + boolean telling whether the >> doorbell is percpu >> - decouple irq_data parsing from the actual mapping/unmapping in >> msi_handle_doorbell_mappings >> - fix misc style issues >> >> v7 -> v8: >> take into account Marc's comments: >> - use iommu_msi_msg_pa_to_va with new proto >> - change in irq_chip_msi_doorbell_info struct definition: >> prot and size became shared between all doorbells and phys_addr_t __percpu >> - cleanups in v2m irqchip >> - eventually did not touch MSI_FLAG_IRQ_REMAPPING naming >> - On msi_handle_doorbell_mappings, stop on the first irqchip where doorbells >> can be found >> - fix resource deallocation on mapping failure in msi_domain_alloc_irqs >> >> v6 -> v7: >> - do alloc/map handling on pci_enable_msi and search on >> msi_(de)domain_activate >> - add msi_doorbell_info callback in irq-chip to retrieve the characteristics >> of doorbells >> >> RFC v5 -> patch v6: >> - split to ease the review process >> - rebase on default iommu domain code (irq_data_to_msi_mapping_domain >> checks IOMMU_DOMAIN_DMA type) >> - fix unmap sequence on msi_domain_set_affinity (reported by Marc): >> unmap the previous doorbell when the new one has been mapped & written to >> the device, ie. irq_chip_write_msi_msg. >> - "msi: msi_compose wrapper removed" following change above >> - add size parameter to iommu_get_reserved_iova API following Marc's request >> >> RFC v4 -> RFC v5: >> - take into account Thomas' comments on MSI related patches >> - split "msi: IOMMU map the doorbell address when needed" >> - increase readability and add comments >> - fix style issues >> - split "iommu: Add DOMAIN_ATTR_MSI_MAPPING attribute" >> - platform ITS now advertises IOMMU_CAP_INTR_REMAP >> - fix compilation issue with CONFIG_IOMMU API unset >> - arm-smmu-v3 now advertises DOMAIN_ATTR_MSI_MAPPING >> >> RFC v3 -> v4: >> - Move doorbell mapping/unmapping in msi.c >> - fix ref count issue on set_affinity: in case of a change in the address >> the previous address is decremented >> - doorbell map/unmap now is done on msi composition. Should allow the use >> case for platform MSI controllers >> - create dma-reserved-iommu.h/c exposing/implementing a new API dedicated >> to reserved IOVA management (looking like dma-iommu glue) >> - series reordering to ease the review: >> - first part is related to IOMMU >> - second related to MSI sub-system >> - third related to VFIO (except arm-smmu IOMMU_CAP_INTR_REMAP removal) >> - expose the number of requested IOVA pages through VFIO_IOMMU_GET_INFO >> [this partially addresses Marc's comments on iommu_get/put_single_reserved >> size/alignment problematic - which I did not ignore - but I don't know >> how much I can do at the moment] >> >> RFC v2 -> RFC v3: >> - should fix wrong handling of some CONFIG combinations: >> CONFIG_IOVA, CONFIG_IOMMU_API, CONFIG_PCI_MSI_IRQ_DOMAIN >> - fix MSI_FLAG_IRQ_REMAPPING setting in GICv3 ITS (although not tested) >> >> PATCH v1 -> RFC v2: >> - reverted to RFC since it looks more reasonable ;-) the code is split >> between VFIO, IOMMU, MSI controller and I
[PATCH v9 0/8] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 2/3: msi changes
This series implements the MSI address mapping/unmapping in the MSI layer. IOMMU binding happens on pci_enable_msi since this function can sleep and return errors. On msi_domain_set_affinity, msi_domain_(de)activate, which are not allowed to sleep, we simply look for the already existing binding. A new MSI domain info flag value is introduced to report whether the msi domain implements IRQ remapping. GIC v3 ITS is the first MSI controller advertising it. This flag value will be used by VFIO subsystem to determine whether MSI forwarding is safe. More details & context can be found at: http://www.linaro.org/blog/core-dump/kvm-pciemsi-passthrough-armarm64/ Best Regards Eric Applies on top of PART 1/3. Also depends on [PATCH 1/3] iommu: Add MMIO mapping type, http://comments.gmane.org/gmane.linux.kernel.iommu/12869 Git: complete series available at https://git.linaro.org/people/eric.auger/linux.git/shortlog/refs/heads/v4.6-rc6-pcie-passthrough-v9-msi-v9 This branch contains all parts in v9. History: v8 -> v9: - use a union in irq_chip_msi_doorbell_info + boolean telling whether the doorbell is percpu - decouple irq_data parsing from the actual mapping/unmapping in msi_handle_doorbell_mappings - fix misc style issues v7 -> v8: take into account Marc's comments: - use iommu_msi_msg_pa_to_va with new proto - change in irq_chip_msi_doorbell_info struct definition: prot and size became shared between all doorbells and phys_addr_t __percpu - cleanups in v2m irqchip - eventually did not touch MSI_FLAG_IRQ_REMAPPING naming - On msi_handle_doorbell_mappings, stop on the first irqchip where doorbells can be found - fix resource deallocation on mapping failure in msi_domain_alloc_irqs v6 -> v7: - do alloc/map handling on pci_enable_msi and search on msi_(de)domain_activate - add msi_doorbell_info callback in irq-chip to retrieve the characteristics of doorbells RFC v5 -> patch v6: - split to ease the review process - rebase on default iommu domain code (irq_data_to_msi_mapping_domain checks IOMMU_DOMAIN_DMA type) - fix unmap sequence on msi_domain_set_affinity (reported by Marc): unmap the previous doorbell when the new one has been mapped & written to the device, ie. irq_chip_write_msi_msg. - "msi: msi_compose wrapper removed" following change above - add size parameter to iommu_get_reserved_iova API following Marc's request RFC v4 -> RFC v5: - take into account Thomas' comments on MSI related patches - split "msi: IOMMU map the doorbell address when needed" - increase readability and add comments - fix style issues - split "iommu: Add DOMAIN_ATTR_MSI_MAPPING attribute" - platform ITS now advertises IOMMU_CAP_INTR_REMAP - fix compilation issue with CONFIG_IOMMU API unset - arm-smmu-v3 now advertises DOMAIN_ATTR_MSI_MAPPING RFC v3 -> v4: - Move doorbell mapping/unmapping in msi.c - fix ref count issue on set_affinity: in case of a change in the address the previous address is decremented - doorbell map/unmap now is done on msi composition. Should allow the use case for platform MSI controllers - create dma-reserved-iommu.h/c exposing/implementing a new API dedicated to reserved IOVA management (looking like dma-iommu glue) - series reordering to ease the review: - first part is related to IOMMU - second related to MSI sub-system - third related to VFIO (except arm-smmu IOMMU_CAP_INTR_REMAP removal) - expose the number of requested IOVA pages through VFIO_IOMMU_GET_INFO [this partially addresses Marc's comments on iommu_get/put_single_reserved size/alignment problematic - which I did not ignore - but I don't know how much I can do at the moment] RFC v2 -> RFC v3: - should fix wrong handling of some CONFIG combinations: CONFIG_IOVA, CONFIG_IOMMU_API, CONFIG_PCI_MSI_IRQ_DOMAIN - fix MSI_FLAG_IRQ_REMAPPING setting in GICv3 ITS (although not tested) PATCH v1 -> RFC v2: - reverted to RFC since it looks more reasonable ;-) the code is split between VFIO, IOMMU, MSI controller and I am not sure I did the right choices. Also API need to be further discussed. - iova API usage in arm-smmu.c. - MSI controller natively programs the MSI addr with either the PA or IOVA. This is not done anymore in vfio-pci driver as suggested by Alex. - check irq remapping capability of the group 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 (8): genirq/msi: Add a new MSI_FLAG_IRQ_REMAPPING flag irqchip/gic-v3-its: ITS advertises