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

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(a)redhat.com&gt;

--- 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