On Fri, 15 May 2020 00:11:55 +0200 Halil Pasic <pa...@linux.ibm.com> wrote:
> The virtio specification tells that the device is to present > VIRTIO_F_ACCESS_PLATFORM (a.k.a. VIRTIO_F_IOMMU_PLATFORM) when the > device "can only access certain memory addresses with said access > specified and/or granted by the platform". This is the case for a > protected VMs, as the device can access only memory addresses that are > in pages that are currently shared (only the guest can share/unsare its > pages). > > No VM, however, starts out as a protected VM, but some VMs may be > converted to protected VMs if the guest decides so. > > Making the end user explicitly manage the VIRTIO_F_ACCESS_PLATFORM via > the property iommu_on is a minor disaster. Since the correctness of the > paravirtualized virtio devices depends (and thus in a sense the > correctness of the hypervisor) it, then the hypervisor should have the > last word about whether VIRTIO_F_ACCESS_PLATFORM is to be presented or > not. > > Currently presenting a PV guest with a (paravirtualized) virtio-ccw > device has catastrophic consequences for the VM (after the hypervisors > access to protected memory). This is especially grave in case of device > hotplug (because in this case the guest is more likely to be in the > middle of something important). > > Let us manage the VIRTIO_F_ACCESS_PLATFORM virtio feature automatically > for virtio-ccw devices, i.e. force it before we start the protected VM. > If the VM should cease to be protected, the original value is restored. > > Signed-off-by: Halil Pasic <pa...@linux.ibm.com> > --- > > NOTES: > > * Doing more system_resets() is a big hack. We should look into this. > * The user interface implications of this patch are also an ugly can of > worms. We need to discuss them. > > > v1 --> v2: > * Use the default or user supplied iommu_on flag when when !PV > * Use virtio functions for feature manipulation > > Link to v1: > https://www.mail-archive.com/qemu-devel@nongnu.org/msg683775.html > > Unfortunately the v1 did not see much discussion because we had more > pressing issues. > > polite ping