Received: by 2002:a05:7208:9594:b0:7e:5202:c8b4 with SMTP id gs20csp1496727rbb; Mon, 26 Feb 2024 11:04:25 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCUR9OchB/4le4t86QPqxL4snHKpT/ZB3nCdQr/BZMmKe8V+tPu38Ue1UL7sDCXTxxTLP1OW8y/yOw2qsonQPELca+7Vc5yDwH7kl3F/pQ== X-Google-Smtp-Source: AGHT+IF+lP9eWARmos8Jbu/YJLB5jcDqJaTsxm1GmQWwxr9VjLXDfxzX6iWJCfe1+S64uZWHtnkc X-Received: by 2002:a17:906:e204:b0:a3f:7d84:4d2e with SMTP id gf4-20020a170906e20400b00a3f7d844d2emr5663307ejb.30.1708974265423; Mon, 26 Feb 2024 11:04:25 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708974265; cv=pass; d=google.com; s=arc-20160816; b=mFmnHF9dPttgwS29mTg/TNCoG8VCLIE15dyzOTJRJnsD3SEFaySbg4KTvNjUCaJpda aNYP0pNtG+FY4fcHyqfhEGdTpGVi8umJh7O6ctjoc6+muU0SYFMRPENMJLFkdJkQ8hbh wpgBxvCp5eAN2i097YXFbhWZpoOEfqhbaQ7rPPmToOoSo0BBkbchksXnUWWBPHnDE1Rg cNPVtyvv1vrkyQ+DXZzflXq+583pxv0ZJNiaq1AtM4zC6JDimpsND9lUBkfxqQEaV8ex Uuw7CJUP2juV5kGhY5bE78Oiiuoi6hvdY+E56h0Y7LPoY0l9HdDr+xrJaDmCkW7oBn6T gJUg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=kdJK5BZbFMC4q1Whv/dgfBTc0g21lAY+xCZH4PpiiFk=; fh=TLdZJsFzSA0fpm6Q4iUv+uB0sG0oU+h3Bp6HiSGyZm8=; b=cnxEJ7C1l0tesmLdrDL0J6gcrxePJhiNp2F3PK6VMJmSTotu/culQm215mpVL0kbpf Fo3167tcWswS18uCLvc8S2iDzt+XjC2YVkaOF9HoTVibNaUS8Bym/IC+JFF6lP5P7rKi 4U3NcJEKib7r/ztTgPGS+gIxryb/zjwtEouYobyC5nEdgX5ESfAh8FrKBIy9THTNWoCZ TYWUAcQJ4QB7CmG3YoqIfIf67KtGL6IZC8hgFXeSIGLqxOLbFvqzYKo2LY4K2vwH2gMg KwyvViwYCc3pdQosmjr+Zk3iMuei3z9zK7UfBJ3ZQYqg4XSHhcG7E52/n+ZLpUfKxiEU TljQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=TiUpB5e8; arc=pass (i=1 spf=pass spfdomain=redhat.com dkim=pass dkdomain=redhat.com dmarc=pass fromdomain=redhat.com); spf=pass (google.com: domain of linux-kernel+bounces-82183-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-82183-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id f4-20020a170906048400b00a433a980127si19850eja.943.2024.02.26.11.04.25 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Feb 2024 11:04:25 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-82183-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=TiUpB5e8; arc=pass (i=1 spf=pass spfdomain=redhat.com dkim=pass dkdomain=redhat.com dmarc=pass fromdomain=redhat.com); spf=pass (google.com: domain of linux-kernel+bounces-82183-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-82183-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id F0C521F24AB2 for ; Mon, 26 Feb 2024 19:04:24 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 3BBD0130ADE; Mon, 26 Feb 2024 19:03:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="TiUpB5e8" Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A93AB12F395 for ; Mon, 26 Feb 2024 19:03:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708974232; cv=none; b=rUtPxIG8Om2QQRR2D4p2Fi7C7rgo68EKSOkYr+T1nWaDmOXuBQEZI5VRDGxfkTcLC22FYQyTv4K8nQDrqKCWk6Hq/UUr+9k4vQBRQa9a2a1YPpF0dl3qkBvynYlE2eCxApmabBrY3/jfTNqlHgBlfslW/8utPikf+/b/eUcvydk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708974232; c=relaxed/simple; bh=vcWBExDmv7RSnhov0HUdDRLdvfeRiov5FYh3uXoteKs=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version:Content-Type; b=q+E3F+vDUPEUjYtVh2dF5+xGS0NASkvgF9/8M8pYgUTiXYfJAWQ3/mIJFj1vJ4S9nlNuXwxqLDNfyWFdxrndT532bAK4Zl2BvQpYzovSjYW/15HUQE6y7b3eZC2jKhub0FvVisBKtlOai21nzm5KTuIoAJKCx7JnstKv5N2DLPc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=TiUpB5e8; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1708974229; h=from:from: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; bh=kdJK5BZbFMC4q1Whv/dgfBTc0g21lAY+xCZH4PpiiFk=; b=TiUpB5e8yPDy2KHlv4mbIaUHru9TLmQ0pvhBXyJ1QYge4zfYJlsaiRt0RKkk19369MD9nb OTuX8++/drEnXtPrutGXiiN20THuaVyE47n0/Kny7JCpGRBfu4/ozYaWuzh72Nyt8vuKyX JbTsKrzzga0g1O0qGQl8+x6XvQFZsDk= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-522-TihFUZmjNjCqo770pI-c4A-1; Mon, 26 Feb 2024 14:03:46 -0500 X-MC-Unique: TihFUZmjNjCqo770pI-c4A-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A3AF7285F988; Mon, 26 Feb 2024 19:03:45 +0000 (UTC) Received: from virtlab701.virt.lab.eng.bos.redhat.com (virtlab701.virt.lab.eng.bos.redhat.com [10.19.152.228]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7773D492BC6; Mon, 26 Feb 2024 19:03:45 +0000 (UTC) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: seanjc@google.com, michael.roth@amd.com, aik@amd.com Subject: [PATCH v3 00/15] KVM: SEV: allow customizing VMSA features Date: Mon, 26 Feb 2024 14:03:29 -0500 Message-Id: <20240226190344.787149-1-pbonzini@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.9 The idea that no parameter would ever be necessary when enabling SEV or SEV-ES for a VM was decidedly optimistic. The first source of variability that was encountered is the desired set of VMSA features, as that affects the measurement of the VM's initial state and cannot be changed arbitrarily by the hypervisor. This series adds all the APIs that are needed to customize the features, with room for future enhancements: - a new /dev/kvm device attribute to retrieve the set of supported features (right now, only debug swap) - a new sub-operation for KVM_MEM_ENCRYPT_OP that can take a struct, replacing the existing KVM_SEV_INIT and KVM_SEV_ES_INIT It then puts the new op to work by including the VMSA features as a field of the The existing KVM_SEV_INIT and KVM_SEV_ES_INIT use the full set of supported VMSA features for backwards compatibility; but I am considering also making them use zero as the feature mask, and will gladly adjust the patches if so requested. In order to avoid creating *two* new KVM_MEM_ENCRYPT_OPs, I decided that I could as well make SEV and SEV-ES use VM types. And then, why not make a SEV-ES VM, when created with the new VM type instead of KVM_SEV_ES_INIT, reject KVM_GET_REGS/KVM_SET_REGS and friends on the vCPU file descriptor once the VMSA has been encrypted... Which is how the API should have always behaved. The series is structured as follows: - patches 1 to 5 are unrelated fixes and improvements for the SEV code and documentation. In particular they change sev.c so that it is compiled only if SEV is enabled in kconfig - patches 6 to 8 introduce the new device attribute to retrieve supported VMSA features - patch 9 disables DEBUG_SWAP by default - patches 10 and 11 introduce new infrastructure for VM types, replacing the similar code in the TDX patches - patches 12 to 14 introduce the new VM types for SEV and SEV-ES, and KVM_SEV_INIT2 as a new sub-operation for KVM_MEM_ENCRYPT_OP. - patch 15 tests the new ioctl. The idea is that SEV SNP will only ever support KVM_SEV_INIT2. I have patches in progress for QEMU to support this new API. Thanks, Paolo v2->v3: - use u64_to_user_addr() - Compile sev.c if and only if CONFIG_KVM_AMD_SEV=y - remove double signoffs - rebase on top of kvm-x86/next - no bit masking hacks; store CoCo features in kvm_arch - store supported VM types in kvm_caps - introduce to_kvm_sev_info - clearer output messages for failed assertions - remove broken test Paolo Bonzini (14): KVM: SEV: fix compat ABI for KVM_MEMORY_ENCRYPT_OP KVM: x86: use u64_to_user_addr() KVM: SVM: Compile sev.c if and only if CONFIG_KVM_AMD_SEV=y Documentation: kvm/sev: separate description of firmware KVM: introduce new vendor op for KVM_GET_DEVICE_ATTR KVM: SEV: publish supported VMSA features KVM: SEV: store VMSA features in kvm_sev_info KVM: SEV: disable DEBUG_SWAP by default KVM: x86: add fields to struct kvm_arch for CoCo features KVM: x86: Add supported_vm_types to kvm_caps KVM: SEV: introduce to_kvm_sev_info KVM: SEV: define VM types for SEV and SEV-ES KVM: SEV: introduce KVM_SEV_INIT2 operation selftests: kvm: add tests for KVM_SEV_INIT2 Sean Christopherson (1): KVM: SVM: Invert handling of SEV and SEV_ES feature flags Documentation/virt/kvm/api.rst | 2 + .../virt/kvm/x86/amd-memory-encryption.rst | 81 ++++++-- arch/x86/include/asm/kvm-x86-ops.h | 1 + arch/x86/include/asm/kvm_host.h | 8 +- arch/x86/include/uapi/asm/kvm.h | 35 ++++ arch/x86/kvm/Makefile | 7 +- arch/x86/kvm/cpuid.c | 2 +- arch/x86/kvm/svm/sev.c | 133 +++++++++---- arch/x86/kvm/svm/svm.c | 15 +- arch/x86/kvm/svm/svm.h | 37 +++- arch/x86/kvm/x86.c | 174 ++++++++++++------ arch/x86/kvm/x86.h | 2 + tools/testing/selftests/kvm/Makefile | 1 + .../selftests/kvm/include/kvm_util_base.h | 6 +- .../selftests/kvm/set_memory_region_test.c | 8 +- .../selftests/kvm/x86_64/sev_init2_tests.c | 149 +++++++++++++++ 16 files changed, 527 insertions(+), 134 deletions(-) create mode 100644 tools/testing/selftests/kvm/x86_64/sev_init2_tests.c -- 2.39.1