From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D0CF5C04FF8 for ; Tue, 16 Apr 2024 17:01:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 616486B0087; Tue, 16 Apr 2024 13:01:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C6B66B0088; Tue, 16 Apr 2024 13:01:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4669F6B0093; Tue, 16 Apr 2024 13:01:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 28E1E6B0087 for ; Tue, 16 Apr 2024 13:01:16 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id D703FA0F95 for ; Tue, 16 Apr 2024 17:01:15 +0000 (UTC) X-FDA: 82016010510.29.9E34441 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf05.hostedemail.com (Postfix) with ESMTP id C32FE10002A for ; Tue, 16 Apr 2024 17:01:13 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="O4ow/zGY"; spf=pass (imf05.hostedemail.com: domain of pbonzini@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=pbonzini@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713286873; h=from:from: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:dkim-signature; bh=YV3huxxwV4cNX30vuhj/67sfqzzrbon2fJPguOJkhQA=; b=x3PsQE+6TPjCbLG7kvzNg5Po0C8a0Nh9QZgisVObhvoDPMDgupKZSDNiex2aN376UeQzKj nVIjuiaNJuUJem7oyO/49to/jNzrOCG526sMMdapTNYZLRBPAlWXVPOOTyZXwiVJRshlmv 6EnQ9SFEG63og/2/E4Dng4UbwpfBIHY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713286873; a=rsa-sha256; cv=none; b=whvUyFtTBtz2pFAfRfqIX00zl8HMs7E9J/Xfag0Xgx1+dp+2bBHBfUJxYuGWhRmN5yCdma m16MxFGI0Ef8+98RWz9C8VabEjDRmlDgBDGVdHsOB5LUORS4mSoUs+2A1Ge0bXX7/2nQ16 /7RcdxGBw8XmCylIyzUpYFDL6hjomS8= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="O4ow/zGY"; spf=pass (imf05.hostedemail.com: domain of pbonzini@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=pbonzini@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1713286873; 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: in-reply-to:in-reply-to:references:references; bh=YV3huxxwV4cNX30vuhj/67sfqzzrbon2fJPguOJkhQA=; b=O4ow/zGYxRNU6q6pIMtwYnFdMfYWeQfKH74uFs+mqCSjtRFCcEzmO6DFCteaDJ8+FEgxqx LM7PfpThookmC8wW1hqPbaE4IfZeW0C2vdAvhLfZ97su13Fd2fQ68u/ZcrEG/09PR/h3fy 0rohKtZ7kAKRiiuP3Um/QsVdOgUeD8g= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-442-2bToGfxwNVOv12fn83opBg-1; Tue, 16 Apr 2024 13:01:11 -0400 X-MC-Unique: 2bToGfxwNVOv12fn83opBg-1 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-41552c04845so18162535e9.2 for ; Tue, 16 Apr 2024 10:01:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713286870; x=1713891670; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=YV3huxxwV4cNX30vuhj/67sfqzzrbon2fJPguOJkhQA=; b=CWglA3EZ5vTKLPUAL8KjO8JFXj2bSUTA1Nk+sZEWf0MtWDQmIt+Y34yYKgTZfqsVdy 1fNKAVvyQ1ZzhTmVf6OWwcRLza4IiC9BZcJJDCOB/rsb9GNSwb54D9SUzL2lL/M7V4mt Pr4nB3IB6aFigr/2L9N+okv3aYz08qOWEc36NKWNrnaj7zGU1BJA13ui8qPOqS5xo01P 9xDoaNpu6cC7JB7xBNFiDxDc52mLWfZqhEaL028sU2zzInDCW7kEbXuyE5o3d6WJlBFj w1SDx13xdnE8dbmFqhAO2F8TaL2I04F+m6SgBVaGC4LpD42U0pvnTP755Ul6OIkgEJLs XWGQ== X-Forwarded-Encrypted: i=1; AJvYcCVb/uXP1NL3FP/YNY2JbvNkx6vJM3uaJ1xD/VtU04lQNVipUzXrelHQiKxXoWHGW90RLykhDdBqg1z4XwScKL64SBw= X-Gm-Message-State: AOJu0YyMsiZ2UvOfdIjj/7siQb+qQagjLFFULKZ65usu4H+8qzkbK8Qn aB2oBbdvkeLQ7fhuG9vsjO42n5oKL+4gDspSMp5YAMv08OcX+0WKEsMRmYRfz/B/auNXcVH4pjd k4UuzYsrJ0DAoxIn74De0O8OJ3nKGdXX4Mle/ru2+DuFOSvetVKNbuSaFWaZAEgUP/2CXrOKdpn HGgqBX7WgcaWrEec5HoFNCV9A= X-Received: by 2002:a5d:6247:0:b0:348:5e40:62aa with SMTP id m7-20020a5d6247000000b003485e4062aamr2053425wrv.2.1713286870092; Tue, 16 Apr 2024 10:01:10 -0700 (PDT) X-Google-Smtp-Source: AGHT+IG6fYFk6xl1nuI2T7KirzQuQyw/sEuJB0A3gheWB+RJwuSGwFc7r4/2ReNv9v/wLow5jcYtNYlNsRKa11DX2JM= X-Received: by 2002:a5d:6247:0:b0:348:5e40:62aa with SMTP id m7-20020a5d6247000000b003485e4062aamr2053410wrv.2.1713286869755; Tue, 16 Apr 2024 10:01:09 -0700 (PDT) MIME-Version: 1.0 References: <20240329225835.400662-1-michael.roth@amd.com> <20240329225835.400662-19-michael.roth@amd.com> <67685ec7-ca61-43f1-8ecd-120ec137e93a@redhat.com> <758c876d-ff77-0633-7b3e-965d863d5a93@amd.com> In-Reply-To: <758c876d-ff77-0633-7b3e-965d863d5a93@amd.com> From: Paolo Bonzini Date: Tue, 16 Apr 2024 19:00:58 +0200 Message-ID: Subject: Re: [PATCH v12 18/29] KVM: SEV: Use a VMSA physical address variable for populating VMCB To: Tom Lendacky Cc: Michael Roth , kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, jroedel@suse.de, hpa@zytor.com, ardb@kernel.org, seanjc@google.com, vkuznets@redhat.com, jmattson@google.com, luto@kernel.org, dave.hansen@linux.intel.com, slp@redhat.com, pgonda@google.com, peterz@infradead.org, srinivas.pandruvada@linux.intel.com, rientjes@google.com, dovmurik@linux.ibm.com, tobin@ibm.com, bp@alien8.de, vbabka@suse.cz, kirill@shutemov.name, ak@linux.intel.com, tony.luck@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, alpergun@google.com, jarkko@kernel.org, ashish.kalra@amd.com, nikunj.dadhania@amd.com, pankaj.gupta@amd.com, liam.merwick@oracle.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: C32FE10002A X-Stat-Signature: ygrendatp1bjfdjqt4fjaepbwmbbkn44 X-HE-Tag: 1713286873-265182 X-HE-Meta: U2FsdGVkX1/jedTEnPPZJJsxSphLgDNCjMVsv5Je91ljyc897jBvFirFn1jY/9yTcvmfMY3Kp85yvKCjndpNCGF7TBjEGdpMc5Q/fckOSHW9J8b0Im5tEFc/8jwF/ckm4h1Cf9STC4iIlmKYb8DEyH7XotznCru12DfCAiZwQRzUc3rr6r1akw5D6v8M9+xjWzuM0242JbSh3TmURJNcl/RKRbOKOXR8QYy0sCvxD7Sr3RdiBePxXvKxQwTgAoTf2lOg5eirT0B0v+bW959Um3+vS/qBikVkAET2Gschp1LR3Idye4uVUOScMXH7S0jRpMDSYyHVBvjyiY8x/+EbzOVX1MtIt6ccpp7MSvuJwE4lRRAozZ+S53bzl1gldSr5iiKuY2ZA3I+aXCK6jRrYxWei7LTzBHRBl/qv7bRI+fEYsYnl3H22jeiaPLwyfAWr/z3A80jQupJ3mcWPR84Zigkqexk1VHpwT560TGnVNvXPd5OysG1fe78T8AGdcBqmKl9NIDKi8/dvh0S6o+YjzOf7C8ZOzCPSyYdLA0nb7Ir+3Dr1xlSco/c3fWDdIgap2SA4YGGAKbNkkT+SvPPvJRUoidOdW5CYa70M7lwm+rj6IZ5KIXU8GkMkZ72u+/rkrYoidGa4gphIShEsMf+8DxYq0Gg5xVl4J5/P7f5qt/39QaK9gxWiWGrUpoEwmpKVns8X5FODUk4hXszk+au6IJhjNwviRHgQHTWdA/Cezbsp8KaPeHzn6ODvL3ecHBEkWSYhXrINjulcZIKekmjuSTqQl7P0wJEo/qyw9gisiAsKZO0e8PE5lcLjdI+0lTJhUwHAg8eJcxsK+lmbybSwmdBqOAgew6g+mx4IqL+UWESAZxnPfQCenWLQRemC1IQU6GR61WlUiKDLCuicOgaFOCsMSNTDBn4hZb0+4zsxy68g73MzvLyqFB9zbPRweedGwxmL+yEGbTfPbLZ0yt3 rkleTHCK wkBlyV2fTZqJnqze865sJba7djyhd9dpn9IiINHrx5pqjUqJ/gsxx9E5kVs1myIeo1S7di5qpS8XLMjP4qFsj5aBhyHlIVejJQoXw0pv79ROt+5bgdUci7Mbl4dscTB7h4odxlCBNX2F6N28xyPm1e08F0qV3hw3QTUrdagxBH9QmNIZpR/imPy0SrkiJtt2XaOzvDqZTgg5QJxuh6YBmypwWArFbvJPKCCq5kSNKjVgXw0ocjMCLvkBR7P9QldBALg4kR4fYDUEkQOBYcWgTIONhX/324e+NkMJnZA2J5fzJpywH6AQS58/FJcMH8WhEY06ag77pkj8Bsz3uSN+pcRGMO+Rr3BnxDrGXiPvt9vhpVzxbZaiILz+ErQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Apr 16, 2024 at 4:25=E2=80=AFPM Tom Lendacky wrote: > > On 4/16/24 06:53, Paolo Bonzini wrote: > > On Sat, Mar 30, 2024 at 10:01=E2=80=AFPM Paolo Bonzini wrote: > >> > >> On 3/29/24 23:58, Michael Roth wrote: > >>> From: Tom Lendacky > >>> > >>> In preparation to support SEV-SNP AP Creation, use a variable that ho= lds > >>> the VMSA physical address rather than converting the virtual address. > >>> This will allow SEV-SNP AP Creation to set the new physical address t= hat > >>> will be used should the vCPU reset path be taken. > >>> > >>> Signed-off-by: Tom Lendacky > >>> Signed-off-by: Ashish Kalra > >>> Signed-off-by: Michael Roth > >>> --- > >> > >> I'll get back to this one after Easter, but it looks like Sean had som= e > >> objections at https://lore.kernel.org/lkml/ZeCqnq7dLcJI41O9@google.com= /. > > > > Note that AP create is called multiple times per vCPU under OVMF with > and added call by the kernel when booting the APs. Oooh, I somehow thought that + target_svm->sev_es.snp_vmsa_gpa =3D INVALID_PAGE; + target_svm->sev_es.snp_ap_create =3D true; was in svm_create_vcpu(). So there should be separate "snp_ap_waiting_for_reset" and "snp_has_guest_vmsa" flags. The latter is set once in __sev_snp_update_protected_guest_state and is what governs whether the VMSA page was allocated or just refcounted. > But I believe that Sean wants a separate KVM object per VMPL level, so > that would disappear anyway (Joerg and I want to get on the PUCK > schedule to talk about multi-VMPL level support soon.) Yes, agreed on both counts. > > /* > > * gmem pages aren't currently migratable, but if this ever > > * changes then care should be taken to ensure > > * svm->sev_es.vmsa_pa is pinned through some other means. > > */ > > kvm_release_pfn_clean(pfn); > > Removing this here will cause any previous guest VMSA page(s) to remain > pinned, that's the reason for unpinning here. OVMF re-uses the VMSA, but > that isn't a requirement for a firmware, and the kernel will create a > new VMSA page. Yes, and once you understand that I was thinking of a set-once flag "snp_has_guest_vmsa" it should all make a lot more sense. Paolo