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 31864C25B75 for ; Tue, 14 May 2024 14:36:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9D3CD6B033F; Tue, 14 May 2024 10:36:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 95C5D6B0340; Tue, 14 May 2024 10:36:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7D6486B0341; Tue, 14 May 2024 10:36:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 57F936B033F for ; Tue, 14 May 2024 10:36:29 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id F409E14130A for ; Tue, 14 May 2024 14:36:28 +0000 (UTC) X-FDA: 82117252056.09.6F0D3E0 Received: from mail-yb1-f202.google.com (mail-yb1-f202.google.com [209.85.219.202]) by imf25.hostedemail.com (Postfix) with ESMTP id 1F3A1A000C for ; Tue, 14 May 2024 14:36:26 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=W2j+3KFG; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of 36nZDZgYKCB8N95IE7BJJBG9.7JHGDIPS-HHFQ57F.JMB@flex--seanjc.bounces.google.com designates 209.85.219.202 as permitted sender) smtp.mailfrom=36nZDZgYKCB8N95IE7BJJBG9.7JHGDIPS-HHFQ57F.JMB@flex--seanjc.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715697387; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=KYTu2iCc2EA3s2d3YSNEraBt/XVrVyPfkFgkt4k3sTk=; b=MJnS6wr9L0mnKGTCSb5pVkn/kJMd9INiC2hktbA2hMpOPNc2ui2cX4/N6qkQEIkOOXCn5I zCdN58oOpoHwdSUV2UjtyPDpt9lB0z+vEabJqyj8nZQce5cbxJ2jDGoe9PZ1vcEz8gO0Rz ONHgeCb7uwprRwFBM93hrBFAPTp1a50= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=W2j+3KFG; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of 36nZDZgYKCB8N95IE7BJJBG9.7JHGDIPS-HHFQ57F.JMB@flex--seanjc.bounces.google.com designates 209.85.219.202 as permitted sender) smtp.mailfrom=36nZDZgYKCB8N95IE7BJJBG9.7JHGDIPS-HHFQ57F.JMB@flex--seanjc.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715697387; a=rsa-sha256; cv=none; b=xNq5cZ9MicMbfX7YhsHYraT5WAaT9iTAhMJ7Vzh1ISYGXk+PvfQXoErGexe+UuZAntdt62 lOy6y08FdNdncDZmVGO1xXwIgnLFnJrcfDn9BFYXignQSt6asd40ILBycQ0ZP7JlB4Pjyp 1S21NA1fPlE6nbg4coZz7RWqCHtt6wE= Received: by mail-yb1-f202.google.com with SMTP id 3f1490d57ef6-dee6d17bf14so5134181276.0 for ; Tue, 14 May 2024 07:36:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1715697386; x=1716302186; darn=kvack.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=KYTu2iCc2EA3s2d3YSNEraBt/XVrVyPfkFgkt4k3sTk=; b=W2j+3KFGyNNwl2gW23x0ifI21sj2M9U2+vovFfPzkQrdRcjJnGbxq6wZzdOygakqAg 0D0AhjGGSkclmFV5ZkaOxbXhpdYVtPT21v95TXwWH/B2wQbpHXvlI/4uGoIca4yButk2 X3NU3xkLbNd4KnziH4crVtv8iJgNUAmhdhbXkTy5xqX/a0zPbudTXh1B/tsGea9jRsWw WF9fX/ekIPfwJKJrDHTNHIqqH7NCjCrzWESqGzsTLXaEqsBTOVPrSpbLsWCynhWyz3ev nDys2vRRaEI01HNg2n8ci4ftI0jZgDi7eHFUwwQDRBmwoRxKMbZf3eaMLhJsz0Git9dc dBjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715697386; x=1716302186; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KYTu2iCc2EA3s2d3YSNEraBt/XVrVyPfkFgkt4k3sTk=; b=t7cBJE4fr6Zm0BByDubKo0nYEnlIv0LGXvhR8O45wsJgCvO5wDzf02yX90AC7EPJcx oFGC5UxRg0LafF+zJa2Bb/04wzfhpUQwGNF0QNOcAxMJdxpmkULDAYfPCZEwKvyK6TEV 6++bz45SWIJ9yf5uPssMnlhB+lNdHynFy+UhZjZwQMpzmi639a08AmV/UwH50kIBlElD UHRs9+Zpcf3Fm7B8koTsBgM/JF4XvLDY8lqiusfkVzIPLBm/IG2UaeUc/6G8LRyuPfNX T+mBRFBC58UC5vbMcFrOz8no2a5UpVciH88i9PNOOEOPcx2kjLJpnLIi9NmXLXjU1o0U xIxw== X-Forwarded-Encrypted: i=1; AJvYcCXMKeVC+KAvbRyITmJkXeLJmvMRkMMUvXlmMHjGRW3qAhz1nbqvA1qFx6NqsRCqUK4SCHrUqbWzPgHncL7tm+422yQ= X-Gm-Message-State: AOJu0YyIeDx80mhO9u/kat+nCHgwmHdhiq7TqHmmEZ3Dfx093ML5JYI5 qo0lefu1M4fD9uUKmoMvfMvZg5xoZLHPFpdvzuN35aPjZW2AYpGXO5zctO8Ja4dCjab4kuGD/Ut L+A== X-Google-Smtp-Source: AGHT+IHYaKqQtQDZbvNEErS6KoOnbawFKVawxYz7fbohTiQjqYIJFXlVkCIxnrX3xKI/sJJLEXcxbqiBdX4= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:fb0e:0:b0:de6:bf2:b026 with SMTP id 3f1490d57ef6-dee4f506a8amr1045972276.13.1715697386197; Tue, 14 May 2024 07:36:26 -0700 (PDT) Date: Tue, 14 May 2024 07:36:20 -0700 In-Reply-To: <20240514025115.dkw3ysqrdbfaa2sg@amd.com> Mime-Version: 1.0 References: <20240501085210.2213060-1-michael.roth@amd.com> <20240501085210.2213060-20-michael.roth@amd.com> <20240514025115.dkw3ysqrdbfaa2sg@amd.com> Message-ID: Subject: Re: [PATCH v15 19/20] KVM: SEV: Provide support for SNP_EXTENDED_GUEST_REQUEST NAE event From: Sean Christopherson To: Michael Roth Cc: 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, thomas.lendacky@amd.com, hpa@zytor.com, ardb@kernel.org, pbonzini@redhat.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 Content-Type: text/plain; charset="us-ascii" X-Rspamd-Queue-Id: 1F3A1A000C X-Stat-Signature: iont9xd3a7i997y9fqimoups45pimfig X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1715697386-441111 X-HE-Meta: U2FsdGVkX1+uQljrJfyIMDZxYRZoCPTyOJ7Sv95Vo7gD0uiXjEjDSwoJqHmZiJeF+rJS1mKnc6LPiXkX+w+A7apEwkVPkOrj/AyRvfA4U9mKqs9QYksF9sE5S9eExvb5TIJ0FYC69fSEv30PRz3GkYS+aWwHfF6ov1eSSgOTmPLQZrn6mNvmhB29IfumPdq6pDoRFgNEx+UZiIjJ1FQ/HRBuV2wzeYmumjlAFAGsqXsFl4DDnUVE0LSsgFdcJ+diOCNJTrCIRfp2h2t0vDeffVGh327VTU4u8eN5pwHuV1Fa3sSVPtLVXmP0Pkg/uoxotXtGlUcuh5GPUKvtyWwhCqEKz+It2ljz3oI26QDqN2quomr8bVDgTQflW+WvKkIABSv5PHXePtSDcpBt8UGbZ6tyJTHVgchiWg2Vii3zZIHFMDbWhN3BSsOh/U9zB4EEI2i6QJ+ED5ap2rcYxGMEmazIDJKy+TyUrX6x3pqZQg9rZ8aNBFn1015SYWAfWmR5AzmT8oPyJKCmrzn/qTZny/9STNjwCEdIJ6QiJISsj5j3pZNdiSZUJiSiF53PISnaw+oNQBn+F/CrOT1WzXMaooOVcVMbuBO8AKtP9nCx4TLL6fpsSAoVP3n5J3VnjgkUduiEwQA8bSTXxMxg10pPR0h2D9yqTGzh+JQiGMznZZFdQZjtkoViOoePh2yF4W9K5PU7OwbZNWZI+CKt35oW6dDGiMtat0ZDNc3s7T672EG39zhJkbU4DLfhHnT+3s3D05qJL5B0N2JADNa6+kvBepudOxYaDLajuBXnUr6WK8sp3sMayYuvytb57sbRZQ+X/7q9EfR+9817QnwExqhFBTFVMDuwfyNTaHklM4K4g6TGLnkp+N0KcB2laCDcpyyDORsJzKRZ/NpuPUdvlkFGP1Q0RAcQMlJbsephgWta8Sw3E1ifaWzST60TYr37ZpCuWPiKRSKQgGniVvCo/W2 MQ39QI5A OCOcgPezREkFbPv95v0qVM3eBBmHh1A039+wk2uMvOKFmYsxaWiulFabkzQ3FcEQCnhQCNQ4olJUioMzNkxQlQURnpTY9HGkxOKXhUqzBm9La1Nz5XGmBLQyCeL+ogcddUEZryG7wJUWSKNrKMqFU2dW9nEoZy+JZwG6srA4KEbSVVKZzeoVYMkymNXVJ3JIxlj9b5VqSDDNrruHczu/6JJwoHO0JQJL/lRroF68WVOmDogJkSVDkk440ZC40pHwNlroS/fIKtsSkwSMNziQ73dtLt7FgFBnBUPsIYEWa6wpIhy81fONvaP1XkStBuwG/5D+aM2gcOMgUjuVqOPW0+SJ9DKICj0GVq3/JEfNt0Y/ToW0ZOhUbeVjqz3hHR/0LLBjlpbq/XKjz12e7fGQgKyzt3ODRSPt+SA0RM8NZplAD9Xy92STa/OalM3GlNvXPbbnCRjzWhQW39YY8X0HGX6mGRNZMn+DrOna/8blQgVRp17suwD8p6CYuAPsgmrHI4NvuvpK+6RR9bMDhqaKLt8/cmUaKMEV8KnRSBND8DBRXqszAQCRmTzZdUmHq7G/2RllHfJH/AJxh1nDRn4j2xJBMT7ddWf67qyVios8c8QX7m3QEqumWGPGNNg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000055, 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 Mon, May 13, 2024, Michael Roth wrote: > On Mon, May 13, 2024 at 04:48:25PM -0700, Sean Christopherson wrote: > > Actually, I take that back, this isn't even an optimization, it's literally a > > non-generic implementation of kvm_run.immediate_exit. > > Relying on a generic -EINTR response resulting from kvm_run.immediate_exit > doesn't seem like a very robust way to ensure the attestation request > was made to firmware. It seems fully possible that future code changes > could result in EINTR being returned for other reasons. So how do you > reliably detect that the EINTR is a result of immediate_exit being called > after the attestation request is made to firmware? We could squirrel something > away in struct kvm_run to probe for, but delivering another > KVM_EXIT_SNP_REQ_CERT with an extra flag set seems to be reasonably > userspace-friendly. And unnecessarily specific to a single exit. But it's a non-issue (except possibly on ARM). I doubt it's formally documented anywhere, but userspace absolutely relies on kvm_run.immediate_exit to be processed _after_ complete_userspace_io(). If KVM exits with -EINTR before invoking cui(), live migration will break due to taking a snapshot of vCPU state in the middle of an instruction. Given that userspace has likely built up rigid expectations for immediate_exit, I don't see any problem formally documenting KVM's behavior, i.e. signing a contract guaranteeing that KVM will complete the "back half" of emulation if immediate_exit is set and KVM_RUN return -EINTR. ARM is the only arch that is at all suspect, due to its rather massive kvm_arch_vcpu_run_pid_change() hook. At a quick glance, it seems to be ok, too. And if it's not, we need to fix that asap, because it's like a bug waiting to happen. > > If this were an optimization, i.e. KVM truly notified userspace without exiting, > > then it would need to be a lot more robust, e.g. to ensure userspace actually > > received the notification before KVM moved on. > > Right, this does rely on exiting via , not userspace polling for flags or > anything along that line. > > > > > > + __u8 flags; > > > + #define KVM_USER_VMGEXIT_REQ_CERTS_STATUS_PENDING 0 > > > + #define KVM_USER_VMGEXIT_REQ_CERTS_STATUS_DONE 1 > > > > This is also a weird reimplementation of generic functionality. KVM nullifies > > vcpu->arch.complete_userspace_io _before_ invoking the callback. So if a callback > > needs to run again on the next KVM_RUN, it can simply set complete_userspace_io > > again. In other words, literally doing nothing will get you what you want :-) > > We could just have the completion callback set complete_userspace_io > again, but then you'd always get 2 userspace exit events per attestation > request. There could be some userspaces that don't implement the > file-locking scheme, in which case they wouldn't need the 2nd notification. Then they don't set immediate_exit. > That's why the KVM_USER_VMGEXIT_REQ_CERTS_FLAGS_NOTIFY_DONE flag is provided > as an opt-in. > > The pending/done status bits are so userspace can distinguish between the > start of a certificate request and the completion side of it after it gets > bound a completed attestation request and the filelock can be released.