Blame SOURCES/kvm-virtio-fix-the-condition-for-iommu_platform-not-supp.patch

97168e
From c731ffdf9faee74e9522dff06e61cda817902088 Mon Sep 17 00:00:00 2001
97168e
From: Halil Pasic <pasic@linux.ibm.com>
97168e
Date: Mon, 7 Feb 2022 12:28:57 +0100
97168e
Subject: [PATCH 1/2] virtio: fix the condition for iommu_platform not
97168e
 supported
97168e
MIME-Version: 1.0
97168e
Content-Type: text/plain; charset=UTF-8
97168e
Content-Transfer-Encoding: 8bit
97168e
97168e
RH-Author: Dr. David Alan Gilbert <dgilbert@redhat.com>
97168e
RH-MergeRequest: 224: virtiofs on s390 secure execution
97168e
RH-Bugzilla: 2116302
97168e
RH-Acked-by: Thomas Huth <thuth@redhat.com>
97168e
RH-Acked-by: Cornelia Huck <cohuck@redhat.com>
97168e
RH-Acked-by: Cédric Le Goater <None>
97168e
RH-Commit: [1/2] d7edc7e3905a04644c9ff44b0d36122c72068e08
97168e
97168e
The commit 04ceb61a40 ("virtio: Fail if iommu_platform is requested, but
97168e
unsupported") claims to fail the device hotplug when iommu_platform
97168e
is requested, but not supported by the (vhost) device. On the first
97168e
glance the condition for detecting that situation looks perfect, but
97168e
because a certain peculiarity of virtio_platform it ain't.
97168e
97168e
In fact the aforementioned commit introduces a regression. It breaks
97168e
virtio-fs support for Secure Execution, and most likely also for AMD SEV
97168e
or any other confidential guest scenario that relies encrypted guest
97168e
memory.  The same also applies to any other vhost device that does not
97168e
support _F_ACCESS_PLATFORM.
97168e
97168e
The peculiarity is that iommu_platform and _F_ACCESS_PLATFORM collates
97168e
"device can not access all of the guest RAM" and "iova != gpa, thus
97168e
device needs to translate iova".
97168e
97168e
Confidential guest technologies currently rely on the device/hypervisor
97168e
offering _F_ACCESS_PLATFORM, so that, after the feature has been
97168e
negotiated, the guest  grants access to the portions of memory the
97168e
device needs to see. So in for confidential guests, generally,
97168e
_F_ACCESS_PLATFORM is about the restricted access to memory, but not
97168e
about the addresses used being something else than guest physical
97168e
addresses.
97168e
97168e
This is the very reason for which commit f7ef7e6e3b ("vhost: correctly
97168e
turn on VIRTIO_F_IOMMU_PLATFORM") fences _F_ACCESS_PLATFORM from the
97168e
vhost device that does not need it, because on the vhost interface it
97168e
only means "I/O address translation is needed".
97168e
97168e
This patch takes inspiration from f7ef7e6e3b ("vhost: correctly turn on
97168e
VIRTIO_F_IOMMU_PLATFORM"), and uses the same condition for detecting the
97168e
situation when _F_ACCESS_PLATFORM is requested, but no I/O translation
97168e
by the device, and thus no device capability is needed. In this
97168e
situation claiming that the device does not support iommu_plattform=on
97168e
is counter-productive. So let us stop doing that!
97168e
97168e
Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
97168e
Reported-by: Jakob Naucke <Jakob.Naucke@ibm.com>
97168e
Fixes: 04ceb61a40 ("virtio: Fail if iommu_platform is requested, but
97168e
unsupported")
97168e
Acked-by: Cornelia Huck <cohuck@redhat.com>
97168e
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
97168e
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
97168e
Cc: Kevin Wolf <kwolf@redhat.com>
97168e
Cc: qemu-stable@nongnu.org
97168e
97168e
Message-Id: <20220207112857.607829-1-pasic@linux.ibm.com>
97168e
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
97168e
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
97168e
Acked-by: Jason Wang <jasowang@redhat.com>
97168e
(cherry picked from commit e65902a913bf31ba79a83a3bd3621108b85cf645)
97168e
---
97168e
 hw/virtio/virtio-bus.c | 12 +++++++-----
97168e
 1 file changed, 7 insertions(+), 5 deletions(-)
97168e
97168e
diff --git a/hw/virtio/virtio-bus.c b/hw/virtio/virtio-bus.c
97168e
index d23db98c56..0f69d1c742 100644
97168e
--- a/hw/virtio/virtio-bus.c
97168e
+++ b/hw/virtio/virtio-bus.c
97168e
@@ -48,6 +48,7 @@ void virtio_bus_device_plugged(VirtIODevice *vdev, Error **errp)
97168e
     VirtioBusClass *klass = VIRTIO_BUS_GET_CLASS(bus);
97168e
     VirtioDeviceClass *vdc = VIRTIO_DEVICE_GET_CLASS(vdev);
97168e
     bool has_iommu = virtio_host_has_feature(vdev, VIRTIO_F_IOMMU_PLATFORM);
97168e
+    bool vdev_has_iommu;
97168e
     Error *local_err = NULL;
97168e
 
97168e
     DPRINTF("%s: plug device.\n", qbus->name);
97168e
@@ -69,11 +70,6 @@ void virtio_bus_device_plugged(VirtIODevice *vdev, Error **errp)
97168e
         return;
97168e
     }
97168e
 
97168e
-    if (has_iommu && !virtio_host_has_feature(vdev, VIRTIO_F_IOMMU_PLATFORM)) {
97168e
-        error_setg(errp, "iommu_platform=true is not supported by the device");
97168e
-        return;
97168e
-    }
97168e
-
97168e
     if (klass->device_plugged != NULL) {
97168e
         klass->device_plugged(qbus->parent, &local_err);
97168e
     }
97168e
@@ -82,9 +78,15 @@ void virtio_bus_device_plugged(VirtIODevice *vdev, Error **errp)
97168e
         return;
97168e
     }
97168e
 
97168e
+    vdev_has_iommu = virtio_host_has_feature(vdev, VIRTIO_F_IOMMU_PLATFORM);
97168e
     if (klass->get_dma_as != NULL && has_iommu) {
97168e
         virtio_add_feature(&vdev->host_features, VIRTIO_F_IOMMU_PLATFORM);
97168e
         vdev->dma_as = klass->get_dma_as(qbus->parent);
97168e
+        if (!vdev_has_iommu && vdev->dma_as != &address_space_memory) {
97168e
+            error_setg(errp,
97168e
+                       "iommu_platform=true is not supported by the device");
97168e
+            return;
97168e
+        }
97168e
     } else {
97168e
         vdev->dma_as = &address_space_memory;
97168e
     }
97168e
-- 
97168e
2.37.3
97168e