Re: [vfio-users] VFIO_IOMMU_MAP_DMA succeeds only on second try?
On Mon, 12 Mar 2018 15:18:30 +0100
Oliver Heid wrote:
> Many thanks!
>
> mmap succeeds - I removed the checks only to post the code on this list.
> I use this now:
>
> if ( !ioctl(container, VFIO_IOMMU_MAP_DMA, &dma_map) )
> { if ( !ioctl(container, VFIO_IOMMU_MAP_DMA, &dma_map) )
> { perror("mmap ioctl"); return 1; }
> }
>
Um, the ioctl returns zero on success, as most ioctls do. Your test
only reaches the perror if it's able to successfully dma map the same
area twice, so yeah, I would expect that never "fails".
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users
Re: [vfio-users] VFIO_IOMMU_MAP_DMA succeeds only on second try?
Many thanks!
mmap succeeds - I removed the checks only to post the code on this list.
I use this now:
if ( !ioctl(container, VFIO_IOMMU_MAP_DMA, &dma_map) )
{ if ( !ioctl(container, VFIO_IOMMU_MAP_DMA, &dma_map) )
{ perror("mmap ioctl"); return 1; }
}
It mostly succeeds only on second try but I never needed more than two
tries. So it's ok.
Re. IOMMU type 1 recognition: You are right: It is independent of kernel
version. It seems to be related to auto-loading vfio_pci via
/etc/modules.conf. Installing the module later gets it working.
*From:* Alex Williamson <mailto:alex.william...@redhat.com>
*Sent:* Monday, March 12, 2018 6:57AM
*To:* Heid, Oliver <mailto:oliver.h...@h-next.de>
*Cc:* Vfio-users <mailto:vfio-users@redhat.com>
*Subject:* Re: [vfio-users] VFIO_IOMMU_MAP_DMA succeeds only on second try?
On Mon, 5 Mar 2018 12:37:24 +0100
Oliver Heid 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,
MAP_SHARED|MAP_ANONYMOUS|MAP_LOCKED, -1, 0);
dma_map.argsz = sizeof(dma_map);
dma_map.flags = VFIO_DMA_MAP_FLAG_READ | VFIO_DMA_MAP_FLAG_WRITE;
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,
Alex
[1] https://github.com/awilliam/tests/blob/master/vfio-iommu-map-unmap.c
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users
Re: [vfio-users] VFIO_IOMMU_MAP_DMA succeeds only on second try?
On Mon, 5 Mar 2018 12:37:24 +0100
Oliver Heid 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,
> MAP_SHARED|MAP_ANONYMOUS|MAP_LOCKED, -1, 0);
>
> dma_map.argsz = sizeof(dma_map);
> dma_map.flags = VFIO_DMA_MAP_FLAG_READ | VFIO_DMA_MAP_FLAG_WRITE;
> 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,
Alex
[1] https://github.com/awilliam/tests/blob/master/vfio-iommu-map-unmap.c
___
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users
