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 471E7C25B10 for ; Fri, 10 May 2024 16:02:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AE6CB6B00FC; Fri, 10 May 2024 12:02:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A95876B00FD; Fri, 10 May 2024 12:02:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 937D76B00FE; Fri, 10 May 2024 12:02:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 742B96B00FC for ; Fri, 10 May 2024 12:02:03 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 1A7F41A0597 for ; Fri, 10 May 2024 16:02:03 +0000 (UTC) X-FDA: 82102952526.21.F9F1CE5 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf02.hostedemail.com (Postfix) with ESMTP id AE02A80007 for ; Fri, 10 May 2024 16:02:00 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=DqjQ0yl+; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf02.hostedemail.com: domain of pbonzini@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=pbonzini@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715356920; 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=XEweVzuXk9Nl8kIRn1D6Og8vyZm+06CghOgjLCvkUZ4=; b=ym2PEoNQ7Pkd3runZYeUMfG1VVXZGzgPUiVqdgH4ah2RI4jNGB5rCmcihnxtpruLQut2oj hcrT8sn+1QB/2ourRF1KbKyRsSJaYfuccwxjHZX+0rsRmQ9bXeAbnc2I8voMEHHjtc2sbO EWFSha7Wu9NjEg+jBnZWBJcqm/eZrgo= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=DqjQ0yl+; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf02.hostedemail.com: domain of pbonzini@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=pbonzini@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715356920; a=rsa-sha256; cv=none; b=O45dwPAm0/47+Ak63B3y3onCRmKzZkZDZ8uqMRjWfxax/326rPgVAav/jg186Z/whf7so5 KbH4sJIoDjMzy+HQ358fF03HcwHXj1V6nnE5kRmica9NMmL05OxC6lxAmSxHnaRLe70yZ9 o/HUyCiT/spvGPW42Jy7cwlLzmEcFWE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1715356920; 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:autocrypt:autocrypt; bh=XEweVzuXk9Nl8kIRn1D6Og8vyZm+06CghOgjLCvkUZ4=; b=DqjQ0yl+5wNBh7/TDtvX1ht44RbYBsEXuLkD1BfdACOlvVca6ZkAfeSUzJpSSxXT7UyPvd 1QdueHaMG1+MxWX8dgSqkTW64TrUVN/BDMFE4dcLO5dYCOk+P1QhZ06qofTarrS8a8Hz7M 5AhMd57PFQUBCLhsE50hArq1q8mf1kY= Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-98-gOEmPT0hO5qm5vPXqF8DZQ-1; Fri, 10 May 2024 12:01:58 -0400 X-MC-Unique: gOEmPT0hO5qm5vPXqF8DZQ-1 Received: by mail-ej1-f69.google.com with SMTP id a640c23a62f3a-a5a1b50d45cso121615066b.2 for ; Fri, 10 May 2024 09:01:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715356917; x=1715961717; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :from:references:cc:to:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XEweVzuXk9Nl8kIRn1D6Og8vyZm+06CghOgjLCvkUZ4=; b=DpSLM8wNAR1DEiLNyR3kSRWKQ6oOdU/a+8FGP3rzRr1uwh55WiRkzMeKEaaZmh68mh VDL3MH4snETiLt525kS055CT/lQQ5r8g83ETZDD3AtX87VTCR4aru4qHrcdqeg+hYzDu wprpVfPw/a/PrTiCl6lX6hTXdtX3YJ4hjS0OBe8QCWIl7A8hOXuT5z9JJ1WADpiWXW9m sQ775w7bAZN6gUveUnrUQMkbY9VsfunT4WmZ+xSAK5G2YX1TOlVPiZ4uKo5BQrX2JO3N UwWM24ygdHwP0uc7wruHoU3oIgnoBkH3vScUdW45XmPt/7XYEXYDuZyEBGA146wNDe0L bjBw== X-Forwarded-Encrypted: i=1; AJvYcCWhy1iwEQc51jPAtsb0qE1W+9lCclgvDbzjCw129fuEjDpTnu4+B+kPxmKJUhvb9e0KybXeJ82XshjxQiFNYxjhTts= X-Gm-Message-State: AOJu0Yy9oCtv+p4jqY7Uj7Ca41Dmf89SbvbJZz8TiVPJJVFZJSKsnuBZ LoNMoE/utgnfShIxkDN1OJU+pl9mj6IlCzPS4LAwizs0nNPu5LktqycJLUnVX7lFAP64knUpNK8 ClniDMZ63ZeAsi7m1KnnpObYaH8/jUevlDdWK8IhSFAWTs7ZV X-Received: by 2002:a50:ab59:0:b0:56e:238e:372c with SMTP id 4fb4d7f45d1cf-5734d67ab0fmr2148508a12.26.1715356917187; Fri, 10 May 2024 09:01:57 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHwDW7Zdiqefqy6/qqc/upaOXcCLAV24nf7L7k4NUD7zh+JFcxK63AO5jZdtXNTpm0lbHaQmg== X-Received: by 2002:a50:ab59:0:b0:56e:238e:372c with SMTP id 4fb4d7f45d1cf-5734d67ab0fmr2148461a12.26.1715356916665; Fri, 10 May 2024 09:01:56 -0700 (PDT) Received: from [192.168.10.48] ([151.95.155.52]) by smtp.googlemail.com with ESMTPSA id 4fb4d7f45d1cf-5733bebb6casm1934867a12.29.2024.05.10.09.01.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 May 2024 09:01:55 -0700 (PDT) Message-ID: <566b57c0-27cd-4591-bded-9a397a1d44d5@redhat.com> Date: Fri, 10 May 2024 18:01:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v15 22/23] KVM: SEV: Fix return code interpretation for RMP nested page faults To: Sean Christopherson , 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, 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 References: <20240501085210.2213060-1-michael.roth@amd.com> <20240510015822.503071-1-michael.roth@amd.com> <20240510015822.503071-2-michael.roth@amd.com> From: Paolo Bonzini Autocrypt: addr=pbonzini@redhat.com; keydata= xsEhBFRCcBIBDqDGsz4K0zZun3jh+U6Z9wNGLKQ0kSFyjN38gMqU1SfP+TUNQepFHb/Gc0E2 CxXPkIBTvYY+ZPkoTh5xF9oS1jqI8iRLzouzF8yXs3QjQIZ2SfuCxSVwlV65jotcjD2FTN04 hVopm9llFijNZpVIOGUTqzM4U55sdsCcZUluWM6x4HSOdw5F5Utxfp1wOjD/v92Lrax0hjiX DResHSt48q+8FrZzY+AUbkUS+Jm34qjswdrgsC5uxeVcLkBgWLmov2kMaMROT0YmFY6A3m1S P/kXmHDXxhe23gKb3dgwxUTpENDBGcfEzrzilWueOeUWiOcWuFOed/C3SyijBx3Av/lbCsHU Vx6pMycNTdzU1BuAroB+Y3mNEuW56Yd44jlInzG2UOwt9XjjdKkJZ1g0P9dwptwLEgTEd3Fo UdhAQyRXGYO8oROiuh+RZ1lXp6AQ4ZjoyH8WLfTLf5g1EKCTc4C1sy1vQSdzIRu3rBIjAvnC tGZADei1IExLqB3uzXKzZ1BZ+Z8hnt2og9hb7H0y8diYfEk2w3R7wEr+Ehk5NQsT2MPI2QBd wEv1/Aj1DgUHZAHzG1QN9S8wNWQ6K9DqHZTBnI1hUlkp22zCSHK/6FwUCuYp1zcAEQEAAc0j UGFvbG8gQm9uemluaSA8cGJvbnppbmlAcmVkaGF0LmNvbT7CwU0EEwECACMFAlRCcBICGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRB+FRAMzTZpsbceDp9IIN6BIA0Ol7MoB15E 11kRz/ewzryFY54tQlMnd4xxfH8MTQ/mm9I482YoSwPMdcWFAKnUX6Yo30tbLiNB8hzaHeRj jx12K+ptqYbg+cevgOtbLAlL9kNgLLcsGqC2829jBCUTVeMSZDrzS97ole/YEez2qFpPnTV0 VrRWClWVfYh+JfzpXmgyhbkuwUxNFk421s4Ajp3d8nPPFUGgBG5HOxzkAm7xb1cjAuJ+oi/K CHfkuN+fLZl/u3E/fw7vvOESApLU5o0icVXeakfSz0LsygEnekDbxPnE5af/9FEkXJD5EoYG SEahaEtgNrR4qsyxyAGYgZlS70vkSSYJ+iT2rrwEiDlo31MzRo6Ba2FfHBSJ7lcYdPT7bbk9 AO3hlNMhNdUhoQv7M5HsnqZ6unvSHOKmReNaS9egAGdRN0/GPDWr9wroyJ65ZNQsHl9nXBqE AukZNr5oJO5vxrYiAuuTSd6UI/xFkjtkzltG3mw5ao2bBpk/V/YuePrJsnPFHG7NhizrxttB nTuOSCMo45pfHQ+XYd5K1+Cv/NzZFNWscm5htJ0HznY+oOsZvHTyGz3v91pn51dkRYN0otqr bQ4tlFFuVjArBZcapSIe6NV8C4cEiSTOwE0EVEJx7gEIAMeHcVzuv2bp9HlWDp6+RkZe+vtl KwAHplb/WH59j2wyG8V6i33+6MlSSJMOFnYUCCL77bucx9uImI5nX24PIlqT+zasVEEVGSRF m8dgkcJDB7Tps0IkNrUi4yof3B3shR+vMY3i3Ip0e41zKx0CvlAhMOo6otaHmcxr35sWq1Jk tLkbn3wG+fPQCVudJJECvVQ//UAthSSEklA50QtD2sBkmQ14ZryEyTHQ+E42K3j2IUmOLriF dNr9NvE1QGmGyIcbw2NIVEBOK/GWxkS5+dmxM2iD4Jdaf2nSn3jlHjEXoPwpMs0KZsgdU0pP JQzMUMwmB1wM8JxovFlPYrhNT9MAEQEAAcLBMwQYAQIACQUCVEJx7gIbDAAKCRB+FRAMzTZp sadRDqCctLmYICZu4GSnie4lKXl+HqlLanpVMOoFNnWs9oRP47MbE2wv8OaYh5pNR9VVgyhD OG0AU7oidG36OeUlrFDTfnPYYSF/mPCxHttosyt8O5kabxnIPv2URuAxDByz+iVbL+RjKaGM GDph56ZTswlx75nZVtIukqzLAQ5fa8OALSGum0cFi4ptZUOhDNz1onz61klD6z3MODi0sBZN Aj6guB2L/+2ZwElZEeRBERRd/uommlYuToAXfNRdUwrwl9gRMiA0WSyTb190zneRRDfpSK5d usXnM/O+kr3Dm+Ui+UioPf6wgbn3T0o6I5BhVhs4h4hWmIW7iNhPjX1iybXfmb1gAFfjtHfL xRUr64svXpyfJMScIQtBAm0ihWPltXkyITA92ngCmPdHa6M1hMh4RDX+Jf1fiWubzp1voAg0 JBrdmNZSQDz0iKmSrx8xkoXYfA3bgtFN8WJH2xgFL28XnqY4M6dLhJwV3z08tPSRqYFm4NMP dRsn0/7oymhneL8RthIvjDDQ5ktUjMe8LtHr70OZE/TT88qvEdhiIVUogHdo4qBrk41+gGQh b906Dudw5YhTJFU3nC6bbF2nrLlB4C/XSiH76ZvqzV0Z/cAMBo5NF/w= In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: AE02A80007 X-Stat-Signature: 6s3jg7o18ntmict8az3pix87ibztf1go X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1715356920-981798 X-HE-Meta: U2FsdGVkX18LQLPzX6zTYUDOAiRrnofpXvDAhH7Kc7mTkWsIPFOQt5vIWLiNu1tEp0DAgElurULws0a2JJghzV4jUtXFk7LFisUJn1FqMxYCG7Bo5YhhS9cy1fsagFoJTBcIh1mzmtUaErFBUhs+dYUNN1siFNhbPSQvVwJLLQcoZ6d6yxEDrfqqJAdtYQR8LkwtiY9OhS4NuKK+akdDajrbsYH1L51xFMf/9tIN509xeTnApEkKf29IZo1Ljie78BtLgmOuPpOLvxkPHf1Z437L2Hf7lQSS7a1k/Z93E4YZanl1FxgKFPAxJ/CuIfBOPyQbYRxViQ9zVA0gPH6cJ1EGK4H6wwIGrhNw8lRJzGIOrIxX7HBc95f5GiKFeAX8Lyf7cqDn/6ogXDO0btwVsXIbofOCqNlW9fHmvcKzmjn0sKaEsbRLLKmYk0uQun3lT5AzeFBDLRxc/TrBL4lOLg7uxMACXrztzVpZcgnU0YNzHpTKByb71tZ4JP5omQ/1v1g56sKzk8QYhLMlmq7zC0Hexy9BP6sara9S2AK+kjcEs0+g2iSsWoQDdWOLUACe02JIZgOPZSQ6OY1mU9W3s4wOAHWpa3Hx5XXuJX/QQxnQpRcTzYQsSk8uCynTA+k/Oy+uAOzIjBf/TOX59OOTohcGstUIz93Lg6R/4+pwxCdytqJiLsEmMM0ERGMkft/0zQoF6/1do7s5cBZJE7APw8MmpqCCu2MG5MVSJb1G2/A9W9G8VoUE2FlqW7uTeohwz4R2Ylekrzeo0QUnwpQU0oqISTRa10W+szCUIevzCREIwQjfPRVeKsxV8488NX3ocyNMlhJoPdPcIl676nNK7ru52OfGVaFg1ME3R7Mr8Rt559Y5d8Wbzuoq6YEyzIaOsyjRtXs4b+c2IbtPZRbR//ZjpYPla18juK5jBwfwLeKue7HN/vxRE8FLIY8/eiQCa9c3NCjAKBIEHuwH+Xi 0s6jaWh2 ZuqUadpLXjwv29NFZePDARbkuEQQ9pF5k8vh9ehIKddugiUoCwptBFDp2UtwigMzLURDONOgiCr8L2JVMgKxf71GYy0KCIV85UC1IX+OqcaVHJH+HMt9ZBEqJnKT0++GvF/HcyB0/Ks+l77FUlzOKdfLgwTrzNWq6Q2vA+WvtBxvhPEPpe+8CD5Kr6ofR5t9RQ8rHlxIGpQdTB6xYTO6BNcfCY5xYqOUpzSPTbAb1kpGtAJimNWSIeAnYoOq3D3Naq06648yhqpoOh3zshrtBC7nnTvbhPYxqhsQw1jHn3a2+fE94tTqFx4L+YkKugMlwCnM5hZ9/U8Qm8BaEgIY8HaQtVd3sjit/Pg6jLEhq9wOs87S5TeY1OwKqYIeteDO8ZUhIEFhxdsdT3wosB27VJ0i9XxK0IOlgVFQZH4WCZ/ZnraMysLS9387601JvznjVV+T80rk4bc3Fk5FK8DFAcRQbbHcaVmgqg5WWz+vcpHcEELQ= 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 5/10/24 15:58, Sean Christopherson wrote: > 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". So IIUC you're suggesting diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 426ad49325d7..c39eaeb21981 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -2068,16 +2068,11 @@ static int npf_interception(struct kvm_vcpu *vcpu) static_cpu_has(X86_FEATURE_DECODEASSISTS) ? svm->vmcb->control.insn_bytes : NULL, svm->vmcb->control.insn_len); + if (rc <= 0) + return rc; - /* - * rc == 0 indicates a userspace exit is needed to handle page - * transitions, so do that first before updating the RMP table. - */ - if (error_code & PFERR_GUEST_RMP_MASK) { - if (rc == 0) - return rc; + if (error_code & PFERR_GUEST_RMP_MASK) sev_handle_rmp_fault(vcpu, fault_address, error_code); - } return rc; } ? So, we're... a bit tight for 6.10 to include SNP and that is an understatement. My plan is to merge it for 6.11, but do so immediately after the merge window ends. In other words, it is a delay in terms of release but not in terms of time. I don't want QEMU and kvm-unit-tests work to be delayed any further, in particular. Once we sort out the loose ends of patches 21-23, you could send it as a pull request. Paolo