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

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