On 19.03.20 18:45, Michael S. Tsirkin wrote: > On Thu, Mar 19, 2020 at 02:54:11PM +0100, David Hildenbrand wrote: >> Why does the balloon driver not support VIRTIO_F_IOMMU_PLATFORM? It is >> absolutely not clear to me. The introducing commit mentioned that it >> "bypasses DMA". I fail to see that. > > Well sure one can put the balloon behind an IOMMU. If will shuffle PFN > lists through a shared page. Problem is, you can't run an untrusted > driver with it since if you do it can corrupt guest memory. > And VIRTIO_F_IOMMU_PLATFORM so far meant that you can run > a userspace driver.
Just to clarify: Is it sufficient to clear VIRTIO_F_IOMMU_PLATFORM in the *guest kernel driver* to prohibit *guest userspace drivers*? I would have thought we would have to disallow on the hypervisor/device side. (no expert on user space drivers, especially how they detect/enable/access virtio devices) > > Maybe we need a separate feature bit for this kind of thing where you > assume the driver is trusted? Such a bit - unlike > VIRTIO_F_IOMMU_PLATFORM - would allow legacy guests ... Let's take virtio-mem as an example. You cannot zap memory outside of the scope of a virtio-mem device. So I assume having a user space driver would be ok (although most probably of limited use :) )? Still, for virtio-mem, special s390x handling, similar to virtio-balloon - (un)sharing of pages - would have to be performed. So some feature bits to cleanly separate the different limitations would be great. At least in regard to s390x, I guess we don't have to worry too much about legacy guests. -- Thanks, David / dhildenb
