On Mon, 5 Mar 2018 12:37:24 +0100
Oliver Heid <oliver.h...@h-next.de> wrote:

> Do I miss something here? I want to allow RW access of a peripheral 
> device to a memory region via
>      struct vfio_iommu_type1_dma_map dma_map = { .argsz = sizeof(dma_map) };
>      __u32* mem = (__u32*)mmap(NULL,size,PROT_READ|PROT_WRITE, 
>      dma_map.argsz = sizeof(dma_map);
>      dma_map.vaddr = (__u64)mem;
>      dma_map.iova  = 0;
>      dma_map.size  = size;
>      ioctl(container, VFIO_IOMMU_MAP_DMA, &dma_map);
> Any idea why theVFIO_IOMMU_MAP_DMA ioctl fails with EINVAL, but then a 
> second, identical call succeeds? Does it actually succeed then? QEMU 
> re-tries if the first attempt fails with EBUSY, but not with EINVAL.

I don't think the QEMU -EBUSY behavior is related, that handles
previous mappings and may no longer even be necessary.  One of my unit
tests[1] does a similar map with no issues.  Your code excerpt doesn't
check whether mmap succeeds, so for all we know mmap is failing too.

> The latest 4.15.7 kernel (4.15.6 too IIRC) does not recognize the AMD 
> Ryzen 3 1200 as  VFIO_TYPE1_IOMMU so I am using version 4.15.4.

This doesn't make sense, anything implementing the kernel's IOMMU API in
the kernel is compatible with type1, that includes anything supporting
AMD-Vi.  There is no whitelist or specific processor support
selection.  There are no iommu or vfio changes between the kernels
you're quoting, perhaps you could do a bisect.  Thanks,


[1] https://github.com/awilliam/tests/blob/master/vfio-iommu-map-unmap.c

vfio-users mailing list

Reply via email to