Hi Chalamarla, > On 5/9/16, 12:48 AM, "Eric Auger" <eric.au...@linaro.org> 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" >>> <linux-arm-kernel-boun...@lists.infradead.org on behalf of >>> 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 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 MSI_FLAG_IRQ_REMAPPING >>>> genirq/msi: export msi_get_domain_info >>>> genirq/msi: msi_compose wrapper >>>> genirq/irq: introduce msi_doorbell_info >>>> irqchip/gicv2m: implement msi_doorbell_info callback >>>> genirq/msi: map/unmap the MSI doorbells on msi_domain_alloc/free_irqs >>>> genirq/msi: use the MSI doorbell's IOVA when requested >>>> >>>> drivers/irqchip/irq-gic-v2m.c | 16 +++ >>>> drivers/irqchip/irq-gic-v3-its-pci-msi.c | 3 +- >>>> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 3 +- >>>> include/linux/irq.h | 15 ++- >>>> include/linux/msi.h | 2 + >>>> kernel/irq/msi.c | 136 >>>> +++++++++++++++++++++++--- >>>> 6 files changed, 161 insertions(+), 14 deletions(-) >>>> >>>> -- >>>> 1.9.1 >>>> >>>> >>>> _______________________________________________ >>>> linux-arm-kernel mailing list >>>> linux-arm-ker...@lists.infradead.org >>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >> _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
