[libvirt PATCH 1/1] docs: kbase: sev: Adjust the claims that virtio-blk doesn't work

[Erik Skultety]

Using virtio-blk with SEV on host kernels prior to 5.1 didn't work
because of SWIOTLB limitations and the way virtio has to use it over
DMA-API for SEV (see [1] for detailed info). That is no longer true, so
reword the kbase article accordingly.

For reference, these are the upstream kernel commits lifting the
virtio-blk limitation:
abe420bfae528c92bd8cc5ecb62dc95672b1fd6f
492366f7b4237257ef50ca9c431a6a0d50225aca
133d624b1cee16906134e92d5befb843b58bcf31
e6d6dd6c875eb3c9b69bb640419405726e6e0bbe
fd1068e1860e44aaaa337b516df4518d1ce98da1

[1] https://lore.kernel.org/linux-block/20190110134433.15672-1-joro@8bytes.org/

Signed-off-by: Erik Skultety <eskultet at redhat.com>
---
 docs/kbase/launch_security_sev.rst | 19 +++++++++----------
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/docs/kbase/launch_security_sev.rst b/docs/kbase/launch_security_sev.rst
index 8f58413261..e65dcd6824 100644
--- a/docs/kbase/launch_security_sev.rst
+++ b/docs/kbase/launch_security_sev.rst
@@ -374,16 +374,15 @@ running:
 Limitations
 ===========
 
-Currently, the boot disk cannot be of type virtio-blk, instead,
-virtio-scsi needs to be used if virtio is desired. This limitation is
-expected to be lifted with future releases of kernel (the kernel used at
-the time of writing the article is 5.0.14). If you still cannot start an
-SEV VM, it could be because of wrong SELinux label on the ``/dev/sev``
-device with selinux-policy <3.14.2.40 which prevents QEMU from touching
-the device. This can be resolved by upgrading the package, tuning the
-selinux policy rules manually to allow svirt_t to access the device (see
-``audit2allow`` on how to do that) or putting SELinux into permissive
-mode (discouraged).
+With older kernels (kernel <5.1) the boot disk cannot not be of type
+virtio-blk, instead, virtio-scsi needs to be used if virtio is desired.
+
+If you still cannot start an SEV VM, it could be because of wrong SELinux label
+on the ``/dev/sev`` device with selinux-policy <3.14.2.40 which prevents QEMU
+from touching the device. This can be resolved by upgrading the package, tuning
+the selinux policy rules manually to allow svirt_t to access the device (see
+``audit2allow`` on how to do that) or putting SELinux into permissive mode
+(discouraged).
 
 Full domain XML examples
 ========================
-- 
2.29.2