On Sun, Feb 21, 2021 at 06:45:18AM -0500, Michael S. Tsirkin wrote: > On Thu, Feb 18, 2021 at 11:59:30AM +0100, Jean-Philippe Brucker wrote: > > Currently the virtio-iommu device must be programmed before it allows > > DMA from any PCI device. This can make the VM entirely unusable when a > > virtio-iommu driver isn't present, for example in a bootloader that > > loads the OS from storage. > > > > Similarly to the other vIOMMU implementations, default to DMA bypassing > > the IOMMU during boot. Add a "boot-bypass" option that lets users change > > this behavior. > > > > Signed-off-by: Jean-Philippe Brucker <jean-phili...@linaro.org> > > wouldn't this be a spec violation? > > > When the device is reset, endpoints are not attached to any domain. > > If the VIRTIO_IOMMU_F_BYPASS feature is negotiated, all accesses from > unattached endpoints are allowed and translated by the IOMMU using the > identity function. If the feature is not negotiated, any memory access > from an unattached endpoint fails. Upon attaching an endpoint in > bypass mode to a new domain, any memory access from the endpoint fails, > since the domain does not contain any mapping.
Right, but the device behavior regarding BYPASS is specified as: If the driver does not accept the VIRTIO_IOMMU_F_BYPASS feature, the device SHOULD NOT let endpoints access the guest-physical address space. So I figured that the spec could be read as "before feature negotiation it's undefined whether the IOMMU is bypassed or not" and so a device implementation can choose either (previously discussed at [1]). But it's a stretch, we should clarify this. Also, the OS might want to know whether DMA was bypassing the IOMMU before the device is initialized. If there are strong security requirements, then boot-bypass means the system was vulnerable to DMA attacks during boot. So I'd like to add a new feature bit for this, VIRTIO_IOMMU_F_BOOT_BYPASS, that tells whether DMA bypasses the IOMMU before feature negotiation. It's only an indicator, accepting the feature doesn't change anything. I'll send the spec change shortly. Thanks, Jean [1] https://lore.kernel.org/qemu-devel/20200109104032.GA937123@myrica/ > Maybe it's not too late to change the spec here - want to try sending > a spec patch?
