Re: [RFC PATCH v2 2/5] iommu/virtio-iommu: Add probe request
From: Auger Eric <eric.auger@redhat.com>
Date: 2018-01-19 17:22:30
Hi Jean-Philippe, On 19/01/18 17:21, Jean-Philippe Brucker wrote:
On 16/01/18 23:26, Auger Eric wrote: [...]quoted
quoted
+ switch (mem->subtype) { + case VIRTIO_IOMMU_RESV_MEM_T_MSI: + region = iommu_alloc_resv_region(addr, size, prot, + IOMMU_RESV_MSI);if (!region) return -ENOMEM;quoted
+ break; + case VIRTIO_IOMMU_RESV_MEM_T_RESERVED: + default: + region = iommu_alloc_resv_region(addr, size, 0, + IOMMU_RESV_RESERVED);same.I'll add them, thanksquoted
There is another issue related to the exclusion of iovas belonging to reserved regions. Typically on x86, when attempting to run virtio-blk-pci with iommu I eventually saw the driver using iova belonging to the IOAPIC regions to map phys addr and this stalled qemu with a drown trace: "virtio: bogus descriptor or out of resources" those regions need to be excluded from the iova allocator. This was resolved by adding if (iommu_dma_init_domain(domain, vdev->viommu->geometry.aperture_start, vdev->viommu->geometry.aperture_end, dev)) in viommu_attach_dev()The most recent hack for x86 [1] does call iommu_dma_init_domain() in attach_dev(). Is it buggy?
Oh OK. Actually I have never used that branch and in my version the last arg of iommu_dma_init_domain was NULL hence the issue. But I was thinking more generally that care must be taken to exclude all those regions. Thanks Eric
We probably shouldn't call iommu_dma_init_domain() unconditionally (outside of CONFIG_X86 that is), since it's normally done by the arch (arch/arm64/mm/dma-mapping.c) Thanks, Jean [1] http://www.linux-arm.org/git?p=linux-jpb.git;a=commitdiff;h=e910e224b58712151dda06df595a53ff07edef63 on branch virtio-iommu/v0.5-x86