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 C68E0C25B10 for ; Fri, 10 May 2024 13:58:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 358416B00EA; Fri, 10 May 2024 09:58:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3054C6B00EB; Fri, 10 May 2024 09:58:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1CCDE6B00EC; Fri, 10 May 2024 09:58:50 -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 F07D26B00EA for ; Fri, 10 May 2024 09:58:49 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 88B6DC06D4 for ; Fri, 10 May 2024 13:58:49 +0000 (UTC) X-FDA: 82102641978.16.14FD34D Received: from mail-yb1-f201.google.com (mail-yb1-f201.google.com [209.85.219.201]) by imf29.hostedemail.com (Postfix) with ESMTP id CC306120023 for ; Fri, 10 May 2024 13:58:47 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=lSr4Tbe9; spf=pass (imf29.hostedemail.com: domain of 3Fig-ZgYKCJcJ51EA37FF7C5.3FDC9ELO-DDBM13B.FI7@flex--seanjc.bounces.google.com designates 209.85.219.201 as permitted sender) smtp.mailfrom=3Fig-ZgYKCJcJ51EA37FF7C5.3FDC9ELO-DDBM13B.FI7@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715349527; 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=zXb1tTtHZSnRGr8DHQ0sXsDcFePLXbMaowVFp+PbHiA=; b=RsUuwgQUocksS3dc524K10fEVkZa6I9njiIMiLvwwZz0RlQpSjKmdkAu1LLlAVy6kQ7r6M 7i5jwtEJCrQCXuNSeE3RU5vaJaQuOUZWaGvWty8D3iEYCqSo8KmUEOkOKV9ufKO3AqYU3Z pjSZ/m/f1VaLFw2ra9nrBLZRd3yBa74= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=lSr4Tbe9; spf=pass (imf29.hostedemail.com: domain of 3Fig-ZgYKCJcJ51EA37FF7C5.3FDC9ELO-DDBM13B.FI7@flex--seanjc.bounces.google.com designates 209.85.219.201 as permitted sender) smtp.mailfrom=3Fig-ZgYKCJcJ51EA37FF7C5.3FDC9ELO-DDBM13B.FI7@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715349527; a=rsa-sha256; cv=none; b=UF1w5hr5OgNsODWvVqZWcj637k8Lg0bExnCiu4IYpLkVRzieVFQKAyiV7U7yAdBKtFLH5r u6dt/gMlxx2Wh99L+PfqFYvhdudLof6RnpdIgw8Jtmc8qfo4flWN4q1DF7RWVNA/BjHxoj 2t8rIBECIJzHkcDP4TmaW2S0xrzwE0Y= Received: by mail-yb1-f201.google.com with SMTP id 3f1490d57ef6-de0b4063e59so1592257276.3 for ; Fri, 10 May 2024 06:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1715349527; x=1715954327; 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=zXb1tTtHZSnRGr8DHQ0sXsDcFePLXbMaowVFp+PbHiA=; b=lSr4Tbe9Qvic/CZ6apkvdFxMBou0TOW+rIINiE/e0iLFGhqG3xAJihsDC4MHOslBba 8SFkWx1nWMbgoRH2qnwbIxlWD4DsgWvLP721zQBq7LhtJRnurcrJHbJj82VjcVL5lqtf 9D4GZiqjx7uF8Lud2/5LXq3SOS6eR1LLLQDmULrBp9Y6/GGX3mK9PKyqb257F6rXrjQL NEBIBiykqr+z3mLMg7nYB1u8+LsEfz/ZcEqnvDf703ODqxQB1qRCIKURF7hpcOF8zSpB qk6T6yKbi3hSoVJybUvrASH8/JaEopxSb3Y3KuhZlvX6IkEBvM/RiGLeUbfnIKkOHyHs amKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715349527; x=1715954327; 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=zXb1tTtHZSnRGr8DHQ0sXsDcFePLXbMaowVFp+PbHiA=; b=gZyrAJ29dl2AijP4KqexuUHXVCl/pxCCX3/lr2cUyejC6Rz0AdH1paFpBDEqEz/qGy bLBsD8KHblb0gio5H+v9bjldZKVc2p3yiyKkQD7pTLnvF3+tPl/vYvfq17dEeXApW7mh YNZ11BKCBB0ptpb2cPcwGJKFjq9ECYdCPZFLUrI9/FoZzHMtOKhaWndzF1cB4zRr/Pdr BNGpgGaGftPYyWfloNW2kvwrSOqeCBBGjRzidJ+oeBctYD+HDqA9g9wn8eTDGiGHLqya dv4sBhoAB9q0FZeTvDZbslrqMVtMx1GtL/+0VUrbUZguk9+uM61sj0ZPCFTpa4nVBSbB 25pg== X-Forwarded-Encrypted: i=1; AJvYcCUexIsUfd7IUaNIV2/tf8SIku7t1XGrIr9A+gMESwl8EFEA2FjiJ/bDbFPoWrl5OgLILEk5gFqqyOA6AlxpDD8U4gg= X-Gm-Message-State: AOJu0YxyeeHbwccbKOZxKnGKMsC+eiQaJ1l+ztPj5l5gRumJNCv6x+81 oiJOlEU6rau/c+yhD4HrLAgdUuAA1CjXLTs4uRkR9ykppFaYgQ/7+uO3lPvHRNG9lsktjni2bju wlg== X-Google-Smtp-Source: AGHT+IGef3UtqI5teaXhSDky2PH9t9XWbnO9HU0F8LPXySNaeV0PQq0Qu57IKZM57LTb/VaFi/Mcd40zVdg= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6902:1002:b0:de5:9f2c:c17c with SMTP id 3f1490d57ef6-dee4f37bbfbmr661252276.9.1715349526730; Fri, 10 May 2024 06:58:46 -0700 (PDT) Date: Fri, 10 May 2024 06:58:45 -0700 In-Reply-To: <20240510015822.503071-2-michael.roth@amd.com> Mime-Version: 1.0 References: <20240501085210.2213060-1-michael.roth@amd.com> <20240510015822.503071-1-michael.roth@amd.com> <20240510015822.503071-2-michael.roth@amd.com> Message-ID: Subject: Re: [PATCH v15 22/23] KVM: SEV: Fix return code interpretation for RMP nested page faults 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, papaluri@amd.com Content-Type: text/plain; charset="us-ascii" X-Stat-Signature: 1irusi5zd1ndaucksngxdm7s1m5nspky X-Rspamd-Queue-Id: CC306120023 X-Rspamd-Server: rspam10 X-Rspam-User: X-HE-Tag: 1715349527-717660 X-HE-Meta: U2FsdGVkX19V+Y3uFsvPM2+/vwP31xrYliibVP8UHTeYiG6gSxzuWMldPFrXyG62L+bGVQfFLcWPalfeydhP/89uTj537wRz14jHBgyaVF+2N8tFVFwrgOSWVWk5n8WQzume3cziMnZKuKFZhAdu6gcqvFRaGaphotKaXFujPiQPDY0ZSFpRE5oGA3xt9BmhTz3rxtDo6xm53WUGqxzrN3kDaP4clkejYO8E6vJaaHENiK59tbKVCRkGEUJOhC2PPNKAK8EyGDT2FDbB3HFjKJYIvqRVcygsSDEIvaIqFDWxLt8NYDfIoXccAE6jQEv3mW7Fcq3+VmjXewPkP3L4pHwF6rvqL6AdiPgU3G9c0GkaVMDayWXg/ksWG9qxGSJ+/hz4pJy4TpkRXOrlmjy8qA2J6ssK1pcsHccIJRKVbtYn7ZIPCw1J7qyjoiBV1eOxFuy2DeACEOlv6Ot46FAu1lLEcZZE9x+Infz64HU8T59bo0ZruuiIdz7+43Yw3JErtaHF//tiiCFBqeNSQ4KWuCVaDSjRJH8ffm7BQsD+9dmaS2Fqql8kSaWWk0TXwT2euWGJCNbZl+sSCmhjDdCDlKM8fWMqlG++/dRkOCktZzYceRnJ1m0K3H4Mkh9ta3jDQI1SWAk3wCrVZ6eT5CRiGGpvZqhupmcAfKuHBreveWfHfnamx2wUGaXGHmmBhcBMiqPS1Wh4okhmIKk6rKwd44c49OOUTlL7vSSAvRCw43q1fb/MnhnozPJMnA+dpz823nWi7jQMMMTl4C+snaBcCbCMBl+zeKnV8hLyMT385iK/+Lk19JZrJzawHDKj9iYXfhTA8y2YZYyhqzjBpyawI2iL4q3B4NXFqUHMbS6E+H6b/wTjgBCQGS0saNeX5HMapowBEKHJLJlKeYtq9DJYlVdNSqZTZlEb2LRzVU3yDV+dC22WdruREl6e/CRM/S/yKTX9u7wabF/Pz+vJWhH HEVUNdrH funcbJQFVTlTmVTCLpZYFFEKxJbM0oiv93tF8MGUQ/isoadc7oJm4ZZday9BQARuuez2f6ApC6m3EsevwFQCYAgbe+0Zh6zpYIcEqNwOGrXY8BH+5fQKs0UCb91njapCqJEmhkwBS823QjHYOusdPRiuPlMeGf6IGWFBwv25GD2NGBw1JygBpYP8XhN8LkPguZMtcv2SeXM2zurvzIHfiPNxb1tNGvLJawDGiaR9DIZpDuELOE42YHiSqiOBpJfXsZozVCrm6uXNkrISqHf5YN27rSulPlooqRHXj63WAP52IptXL8ZiuKNOzLgauJZo1WRoA4tz2UNqiJGbjOAITewo9fd/r9j8aUFXHEwWAOMKFbgzKAA1EmNl7+1PVsSzc5glPrd/OnmIr8ij08a0Jp7VOfVzv/Q71pRuYdduf9l/wOEc5OEQWrooHwwp6ozmQuyxeuqbtLPKOkr23KJTgPkdyFMd5Q1Xyt8D+pySggLu16vi0MR3raiRSFzbm51l4m5NcS0nLmK9Lit/eGzM94basSZ+s+YOXciME782r/B0vyPW+3E9zIYd9iygNGfVZfOR6P6A4tAe6M7jMNlISJMOzT9c7zzE8tPS8lnq9ghi9JZpgk4IshTAU5vTwVQSsg3USsn/c+h04ACGT3Xq6htVXfg== 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 Thu, May 09, 2024, Michael Roth wrote: > The intended logic when handling #NPFs with the RMP bit set (31) is to > first check to see if the #NPF requires a shared<->private transition > and, if so, to go ahead and let the corresponding KVM_EXIT_MEMORY_FAULT > get forwarded on to userspace before proceeding with any handling of > other potential RMP fault conditions like needing to PSMASH the RMP > entry/etc (which will be done later if the guest still re-faults after > the KVM_EXIT_MEMORY_FAULT is processed by userspace). > > The determination of whether any userspace handling of > KVM_EXIT_MEMORY_FAULT is needed is done by interpreting the return code > of kvm_mmu_page_fault(). However, the current code misinterprets the > return code, expecting 0 to indicate a userspace exit rather than less > than 0 (-EFAULT). This leads to the following unexpected behavior: > > - for KVM_EXIT_MEMORY_FAULTs resulting for implicit shared->private > conversions, warnings get printed from sev_handle_rmp_fault() > because it does not expect to be called for GPAs where > KVM_MEMORY_ATTRIBUTE_PRIVATE is not set. Standard linux guests don't > generally do this, but it is allowed and should be handled > similarly to private->shared conversions rather than triggering any > sort of warnings > > - if gmem support for 2MB folios is enabled (via currently out-of-tree > code), implicit shared<->private conversions will always result in > a PSMASH being attempted, even if it's not actually needed to > resolve the RMP fault. This doesn't cause any harm, but results in a > needless PSMASH and zapping of the sPTE > > Resolve these issues by calling sev_handle_rmp_fault() only when > kvm_mmu_page_fault()'s return code is greater than or equal to 0, > indicating a KVM_MEMORY_EXIT_FAULT/-EFAULT isn't needed. While here, > simplify the code slightly and fix up the associated comments for better > clarity. > > Fixes: ccc9d836c5c3 ("KVM: SEV: Add support to handle RMP nested page faults") > > Signed-off-by: Michael Roth > --- > arch/x86/kvm/svm/svm.c | 10 ++++------ > 1 file changed, 4 insertions(+), 6 deletions(-) > > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c > index 426ad49325d7..9431ce74c7d4 100644 > --- a/arch/x86/kvm/svm/svm.c > +++ b/arch/x86/kvm/svm/svm.c > @@ -2070,14 +2070,12 @@ static int npf_interception(struct kvm_vcpu *vcpu) > svm->vmcb->control.insn_len); > > /* > - * rc == 0 indicates a userspace exit is needed to handle page > - * transitions, so do that first before updating the RMP table. > + * rc < 0 indicates a userspace exit may be needed to handle page > + * attribute updates, so deal with that first before handling other > + * potential RMP fault conditions. > */ > - if (error_code & PFERR_GUEST_RMP_MASK) { > - if (rc == 0) > - return rc; > + if (rc >= 0 && error_code & PFERR_GUEST_RMP_MASK) This isn't correct either. A return of '0' also indiciates "exit to userspace", it just doesn't happen with SNP because '0' is returned only when KVM attempts emulation, and that too gets short-circuited by svm_check_emulate_instruction(). And I would honestly drop the comment, KVM's less-than-pleasant 1/0/-errno return values overload is ubiquitous enough that it should be relatively self-explanatory. Or if you prefer to keep a comment, drop the part that specifically calls out attributes updates, because that incorrectly implies that's the _only_ reason why KVM checks the return. But my vote is to drop the comment, because it essentially becomes "don't proceed to step 2 if step 1 failed", which kind of makes the reader go "well, yeah".