On Tue, 2013-04-23 at 16:13 +0000, Yoder Stuart-B08248 wrote:
> 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.
My first thought is that this really detracts from vfio and iommu groups
being a secure interface, so somehow this needs to be clearly an
insecure mode that requires an opt-in and maybe taints the kernel. Any
notion of unprivileged use needs to be blocked and it should test
CAP_COMPROMISE_KERNEL (or whatever it's called now) at critical access
points. We might even have interfaces exported that would allow this to
be an out-of-tree driver (worth a check).
I would guess that you would probably want to do all the iommu group
setup from the vfio fake-iommu driver. In other words, that driver both
creates the fake groups and provides the dummy iommu backend for vfio.
That would be a nice way to compartmentalize this as a
vfio-noiommu-special.
Would map/unmap really be no-ops? Seems like you still want to do page
pinning. Also, you're using fsl in the example above, but would such a
driver have any platform dependency? Thanks,
Alex
_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu
