Joerg/Alex,
We have embedded systems where we use QEMU/KVM and have
the requirement to do device assignment, but have no
iommu. So we would like to get vfio-pci working on
systems like this.
We're aware of the obvious limitations-- no protection,
DMA'able memory must be physically contiguous and will
have no iova->phy translation. But there are use cases
where all OSes involved are trusted and customers can
live with those limitations. Virtualization is used
here not to sandbox untrusted code, but to consolidate
multiple OSes.
We would like to get your feedback on the rough idea. There
are two parts-- iommu driver and vfio-pci.
1. iommu driver
First, we still need device groups created because vfio
is based on that, so we envision a 'dummy' iommu
driver that implements only the add/remove device
ops. Something like:
static struct iommu_ops fsl_none_ops = {
.add_device = fsl_none_add_device,
.remove_device = fsl_none_remove_device,
};
int fsl_iommu_none_init()
{
int ret = 0;
ret = iommu_init_mempool();
if (ret)
return ret;
bus_set_iommu(&platform_bus_type, &fsl_none_ops);
bus_set_iommu(&pci_bus_type, &fsl_none_ops);
return ret;
}
2. vfio-pci
For vfio-pci, we would ideally like to keep user space mostly
unchanged. User space will have to follow the semantics
of mapping only physically contiguous chunks...and iova
will equal phys.
So, we propose to implement a new vfio iommu type,
called VFIO_TYPE_NONE_IOMMU. This implements
any needed vfio interfaces, but there are no calls
to the iommu layer...e.g. map_dma() is a noop.
Would like your feedback.
Thanks,
Stuart Yoder
_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu
