Re: Re: Re: Re: how test the Translation Support for SMMUv3?

Nicolin Chen
2024-01-04T22:50:34Z

On Thu, Jan 04, 2024 at 09:13:39PM +0800, Ben wrote:
> At 2024-01-04 01:38:11, "Nicolin Chen" <nicolinc@nvidia.com> wrote:
> >The "Unassigned class" returned by the lspci running in the
> >host is likely telling you that your kernel doesn't support
> >the device at all?
>
> The device (13b5 ff80) is a special device (SMMUv3TestEngine) implemented in FVP,
> I wrote a simple PCI driver for it, just probe and call dma_alloc_coherent() API to alloc a DMA buffer.
>
> Here is log on Guest side:
> / # insmod smmu_test.ko
> [ 8251.668308] smmu_test: module verification failed: signature and/or required key missing - tainting kernel
> [ 8251.671198] smmu_test 0000:00:02.0: Adding to iommu group 1
> [ 8251.672748] arm_smmu_attach_dev========
> [ 8251.673823] arm_smmu_domain_finalise_s1 ====
> [17991.095955] arm-smmu-v3 arm-smmu-v3.0.auto: arm_smmu_domain_finalise_nested ======
> [ 8251.675278] smmu_test 0000:00:02.0: enabling device (0000 -> 0002)
> qemu-system-aarch64-iommufd: IOMMU_IOAS_MAP failed: Bad address
> qemu-system-aarch64-iommufd: vfio_container_dma_map(0xaaaaf4b56c60, 0x8000000000, 0x40000, 0xffffbc6a4000) = -14 (Bad address)
> qemu-system-aarch64-iommufd: IOMMU_IOAS_MAP failed: Bad address
> qemu-system-aarch64-iommufd: vfio_container_dma_map(0xaaaaf4b56c60, 0x800004c000, 0x1000, 0xffffbf49d000) = -14 (Bad address)
> [ 8251.678163] smmu_test_pci_probe === reg_phy 0x8000000000, len 0x40000
> [ 8251.679978] smmu_test_pci_probe === reg 0xffff800009300000
> [ 8251.681908] smmu_test_alloc_dma ---- iova 0xffff800008008000 dma_addr 0xfffff000

Given the dma_addr looks good to me, I think the result is a "pass"?

> so in this log, some qemu error logs are observed, does it the nested SMMU work fine?

0x8000000000 stuff are the PCI bar memory space that isn't supported
well yet, which shouldn't break a DMA test with 2-stage translation.

> In the Guest side, is it GPA or SPA about the return address (dma_addr) of dma_alloc_coherent() API?

I think so. Try the same test in the host and see if it returns a
similar print, just ignoring those QEMU logs.

> >Try some simpler device that's supported first. What happens
> >to the 0000:05:00.0 that you passed through previously?
>
> 05:00.0 is a SATA device on FVP, but it is very strange that failed to assigned to VM, "device busy" reported. I changed to use SMMUv3TestEngine device.

OK.