From nobody Fri Apr 26 07:26:43 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 63.128.21.124 as permitted sender) client-ip=63.128.21.124; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-124.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 63.128.21.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1610123032; cv=none; d=zohomail.com; s=zohoarc; b=ZSm4LoPRKTaaRcJYTOKeG3DptgXao8d8UMEAsVVnRsJgV0e/xZ4vP/7sihy6VtaJ/Ki7ARgZOFgHNXni1Zrw02qX3ssSkdqwOFhDSKkD6SekiWD00whvaxiwHWitHKm62jbtggGfDDAttOiYO3OKyvzDqs2IML5vH7Sc7wrROA8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1610123032; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=RgrWBt2S68UjgTdtT70lA+NnUQsh+iYbB2drRIkFXoQ=; b=JVE+1C4PSjR5KuDxMZFGDQOzmTphJGsv4KlK5IhLJjHU4V6LU9xFOvVIkjQ/Uxq7VujPTt/dBB+KM8gg4QB+ioejKSBFvexRISZrTEJCbIHmJp0cbQ+xj0hYIt2eNGaGDllHQug28QNtmq1eP3HCgbbWl7eb5BHSTWdyJN2tUWw= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 63.128.21.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mx.zohomail.com with SMTPS id 1610123032392601.6974439702503; Fri, 8 Jan 2021 08:23:52 -0800 (PST) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-254-m-RGbOb6P0-EbMsw72OniA-1; Fri, 08 Jan 2021 11:23:48 -0500 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CC3DD801AA3; Fri, 8 Jan 2021 16:23:42 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8564619D7D; Fri, 8 Jan 2021 16:23:41 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id C825B4A7C6; Fri, 8 Jan 2021 16:23:39 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 108GNckR018620 for ; Fri, 8 Jan 2021 11:23:38 -0500 Received: by smtp.corp.redhat.com (Postfix) id 26CA01981C; Fri, 8 Jan 2021 16:23:38 +0000 (UTC) Received: from nautilus.redhat.com (unknown [10.40.192.117]) by smtp.corp.redhat.com (Postfix) with ESMTP id 73DEA12D7E; Fri, 8 Jan 2021 16:23:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1610123031; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=RgrWBt2S68UjgTdtT70lA+NnUQsh+iYbB2drRIkFXoQ=; b=QfyGYScF+pQv5a/XqlO2Qx6KCcjLfucFsrO2FVObgoAVH0EEuT20vJYJp2UOvNIq3rxtu1 FXVviWNYfKBCKqsg+OTq/It7lkWt0uZeOKBc3GddzQi97rpze63t2iPatvEgJaA9WLWRtW zeC44+fhXWR3k7AVIMiMZvG7gm1X1Q8= X-MC-Unique: m-RGbOb6P0-EbMsw72OniA-1 From: Erik Skultety To: libvir-list@redhat.com Subject: [libvirt PATCH 1/1] docs: kbase: sev: Adjust the claims that virtio-blk doesn't work Date: Fri, 8 Jan 2021 17:23:32 +0100 Message-Id: <0afcf375fa5f7465f0768f92ed06e7753ba5ce9b.1610123002.git.eskultet@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-loop: libvir-list@redhat.com Cc: eskultet@redhat.com X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=libvir-list-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) Content-Type: text/plain; charset="utf-8" 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 --- 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_securit= y_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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 -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 Q= EMU +from touching the device. This can be resolved by upgrading the package, t= uning +the selinux policy rules manually to allow svirt_t to access the device (s= ee +``audit2allow`` on how to do that) or putting SELinux into permissive mode +(discouraged). =20 Full domain XML examples =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --=20 2.29.2