From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sean Christopherson Date: Thu, 21 Sep 2023 07:59:10 -0700 Subject: [RFC PATCH v12 18/33] KVM: x86/mmu: Handle page fault for private memory In-Reply-To: References: <20230914015531.1419405-1-seanjc@google.com> <20230914015531.1419405-19-seanjc@google.com> Message-ID: List-Id: To: kvm-riscv@lists.infradead.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Mon, Sep 18, 2023, Yan Zhao wrote: > On Fri, Sep 15, 2023 at 07:26:16AM -0700, Sean Christopherson wrote: > > On Fri, Sep 15, 2023, Yan Zhao wrote: > > > > static int __kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault) > > > > { > > > > struct kvm_memory_slot *slot = fault->slot; > > > > @@ -4293,6 +4356,14 @@ static int __kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault > > > > return RET_PF_EMULATE; > > > > } > > > > > > > > + if (fault->is_private != kvm_mem_is_private(vcpu->kvm, fault->gfn)) { > > > In patch 21, > > > fault->is_private is set as: > > > ".is_private = kvm_mem_is_private(vcpu->kvm, cr2_or_gpa >> PAGE_SHIFT)", > > > then, the inequality here means memory attribute has been updated after > > > last check. > > > So, why an exit to user space for converting is required instead of a mere retry? > > > > > > Or, is it because how .is_private is assigned in patch 21 is subjected to change > > > in future? > > > > This. Retrying on SNP or TDX would hang the guest. I suppose we could special > Is this because if the guest access a page in private way (e.g. via > private key in TDX), the returned page must be a private page? Yes, the returned page must be private, because the GHCI (TDX) and GHCB (SNP) require that the host allow implicit conversions. I.e. if the guest accesses memory as private (or shared), then the host must map memory as private (or shared). Simply resuming the guest will not change the guest access, nor will it change KVM's memory attributes. Ideally (IMO), implicit conversions would be disallowed, but even if implicit conversions weren't a thing, retrying would still be wrong as KVM would either inject an exception into the guest or exit to userspace to let userspace handle the illegal access. > > case VMs where .is_private is derived from the memory attributes, but the > > SW_PROTECTED_VM type is primary a development vehicle at this point. I'd like to > > have it mimic SNP/TDX as much as possible; performance is a secondary concern. > Ok. But this mimic is somewhat confusing as it may be problematic in below scenario, > though sane guest should ensure no one is accessing a page before doing memory > conversion. > > > CPU 0 CPU 1 > access GFN A in private way > fault->is_private=true > convert GFN A to shared > set memory attribute of A to shared > > faultin, mismatch and exit > set memory attribute of A > to private > > vCPU access GFN A in shared way > fault->is_private = true > faultin, match and map a private PFN B > > vCPU accesses private PFN B in shared way If this is a TDX or SNP VM, then the private vs. shared information comes from the guest itself, e.g. this sequence vCPU access GFN A in shared way fault->is_private = true cannot happen because is_private will be false based on the error code (SNP) or the GPA (TDX). And when hardware doesn't generate page faults based on private vs. shared, i.e. for non-TDX/SNP VMs, from a fault handling perspective there is no concept of the guest accessing a GFN in a "private way" or a "shared way". I.e. there are no implicit conversions. For SEV and SEV-ES, the guest can access memory as private vs. shared, but the and the host VMM absolutely must be in agreement and synchronized with respect to the state of a page, otherwise guest memory will be corrupted. But that has nothing to do with the fault handling, e.g. creating aliases in the guest to access a single GFN as shared and private from two CPUs will create incoherent cache entries and/or corrupt data without any involvement from KVM. In other words, the above isn't possible for TDX/SNP, and for all other types, the conflict between CPU0 and CPU1 is unequivocally a guest bug. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f202.google.com (mail-yw1-f202.google.com [209.85.128.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3F3939475 for ; Thu, 21 Sep 2023 14:59:13 +0000 (UTC) Received: by mail-yw1-f202.google.com with SMTP id 00721157ae682-58f9db8bc1dso14226067b3.3 for ; Thu, 21 Sep 2023 07:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695308352; x=1695913152; darn=lists.linux.dev; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=4hX9qb1Iw7SkuB3FcSZYopfwd6y9xnz247DDm3mrX40=; b=j9g9hg14HoJ9pv99VRfPeMXNDBlasYEzjCwU8sqYnP3eYInU7KifLZV48XrEo+hQ4Y malPfGiYQDCs44FunqzRpY2ei0MpBqmtFsMRwNgyEOzV9AXpsmwzfu/Rk0kX19MTEH3V 1LBZqB/rmMv2lp29T9oFr9PVjysA5HK89Ip6M34tPe/O37B0w+OutEIeDr7mNSUiEvyB vN/aU4XrrNRQ1xhIe3jFM7j/D6zTS5hVukLzvyxXmXqgp93Y/hZSwqOus2ytqmzQMlid sIt4CRxDKlnX69QgZxvUOrNHMJ7ySQwMC4cG07p+oWv59MUUYVBZucbQ9svh2A+syspa cqyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695308352; x=1695913152; 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=4hX9qb1Iw7SkuB3FcSZYopfwd6y9xnz247DDm3mrX40=; b=qJ+UpQkOq1rrUyA25G5dZyl/yE+j/dCZcMo9v5gR1zU9cOO8Qr5hq5XWE4VHesz+Rb g3FVyNbPsSFl1iHyotcA6uVljRYLTR+9RbNcCbDQrSyH9iRdBSHsuYEBJU/EHacE/6DM b2k8Yh+UkufMXKjtq3ELCyu3J9Kt3PqUuZ38V601febXvwIT7PnO3aQ3O41UNXCJvTF3 GfsUQcBQNtW6/YjJ6KEaiRKMu5d6DpFDoC3GNBM9icBrLdQ72+unqtQR6f0SF52Wkf89 P8IK6uiCKHk3ALdLuFtZoniTtqkyDsxvpsXzBoN3S9IY0WpccUmsqJPxf3bIMrfF2mrx D57Q== X-Gm-Message-State: AOJu0YwCCXaL7zR2yLuEn62/zv+hCYt8mL+OVXXvpLfF+oJ8MnwR/1m8 3yw//93Zp2lwH1zmv5DSEESPt0G/jbY= X-Google-Smtp-Source: AGHT+IGMlI3r5pTKtUH2X22CRcKkDXwZa01FQ/zuLj/x6iC6Lpx1DAvznI7oMbumBcX5i3FsE4fH+yzcjSE= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:690c:2906:b0:59e:ee51:52a1 with SMTP id eg6-20020a05690c290600b0059eee5152a1mr76581ywb.10.1695308352199; Thu, 21 Sep 2023 07:59:12 -0700 (PDT) Date: Thu, 21 Sep 2023 07:59:10 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20230914015531.1419405-1-seanjc@google.com> <20230914015531.1419405-19-seanjc@google.com> Message-ID: Subject: Re: [RFC PATCH v12 18/33] KVM: x86/mmu: Handle page fault for private memory From: Sean Christopherson To: Yan Zhao Cc: Paolo Bonzini , Marc Zyngier , Oliver Upton , Huacai Chen , Michael Ellerman , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , "Matthew Wilcox (Oracle)" , Andrew Morton , Paul Moore , James Morris , "Serge E. Hallyn" , kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Chao Peng , Fuad Tabba , Jarkko Sakkinen , Anish Moorthy , Yu Zhang , Isaku Yamahata , Xu Yilun , Vlastimil Babka , Vishal Annapurve , Ackerley Tng , Maciej Szmigiero , David Hildenbrand , Quentin Perret , Michael Roth , Wang , Liam Merwick , Isaku Yamahata , "Kirill A . Shutemov" Content-Type: text/plain; charset="us-ascii" On Mon, Sep 18, 2023, Yan Zhao wrote: > On Fri, Sep 15, 2023 at 07:26:16AM -0700, Sean Christopherson wrote: > > On Fri, Sep 15, 2023, Yan Zhao wrote: > > > > static int __kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault) > > > > { > > > > struct kvm_memory_slot *slot = fault->slot; > > > > @@ -4293,6 +4356,14 @@ static int __kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault > > > > return RET_PF_EMULATE; > > > > } > > > > > > > > + if (fault->is_private != kvm_mem_is_private(vcpu->kvm, fault->gfn)) { > > > In patch 21, > > > fault->is_private is set as: > > > ".is_private = kvm_mem_is_private(vcpu->kvm, cr2_or_gpa >> PAGE_SHIFT)", > > > then, the inequality here means memory attribute has been updated after > > > last check. > > > So, why an exit to user space for converting is required instead of a mere retry? > > > > > > Or, is it because how .is_private is assigned in patch 21 is subjected to change > > > in future? > > > > This. Retrying on SNP or TDX would hang the guest. I suppose we could special > Is this because if the guest access a page in private way (e.g. via > private key in TDX), the returned page must be a private page? Yes, the returned page must be private, because the GHCI (TDX) and GHCB (SNP) require that the host allow implicit conversions. I.e. if the guest accesses memory as private (or shared), then the host must map memory as private (or shared). Simply resuming the guest will not change the guest access, nor will it change KVM's memory attributes. Ideally (IMO), implicit conversions would be disallowed, but even if implicit conversions weren't a thing, retrying would still be wrong as KVM would either inject an exception into the guest or exit to userspace to let userspace handle the illegal access. > > case VMs where .is_private is derived from the memory attributes, but the > > SW_PROTECTED_VM type is primary a development vehicle at this point. I'd like to > > have it mimic SNP/TDX as much as possible; performance is a secondary concern. > Ok. But this mimic is somewhat confusing as it may be problematic in below scenario, > though sane guest should ensure no one is accessing a page before doing memory > conversion. > > > CPU 0 CPU 1 > access GFN A in private way > fault->is_private=true > convert GFN A to shared > set memory attribute of A to shared > > faultin, mismatch and exit > set memory attribute of A > to private > > vCPU access GFN A in shared way > fault->is_private = true > faultin, match and map a private PFN B > > vCPU accesses private PFN B in shared way If this is a TDX or SNP VM, then the private vs. shared information comes from the guest itself, e.g. this sequence vCPU access GFN A in shared way fault->is_private = true cannot happen because is_private will be false based on the error code (SNP) or the GPA (TDX). And when hardware doesn't generate page faults based on private vs. shared, i.e. for non-TDX/SNP VMs, from a fault handling perspective there is no concept of the guest accessing a GFN in a "private way" or a "shared way". I.e. there are no implicit conversions. For SEV and SEV-ES, the guest can access memory as private vs. shared, but the and the host VMM absolutely must be in agreement and synchronized with respect to the state of a page, otherwise guest memory will be corrupted. But that has nothing to do with the fault handling, e.g. creating aliases in the guest to access a single GFN as shared and private from two CPUs will create incoherent cache entries and/or corrupt data without any involvement from KVM. In other words, the above isn't possible for TDX/SNP, and for all other types, the conflict between CPU0 and CPU1 is unequivocally a guest bug. 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 473C0E71086 for ; Thu, 21 Sep 2023 14:59:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:From:Subject:Message-ID: References:Mime-Version:In-Reply-To:Date:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=ZTThyFDUf5kTRnanX1iBzPM9hYosmPEAM2AVuvDFn1E=; b=HPD4XewZY/LMfI4CguozKI7CZ2 R82KDmdjPJEYbqh0s8zbkvfsdjg3vs6QUTc8DmmoY5FUODpQ0jPtPffZ6T9APwQ9Ew7WHLnjJcwCE ICO9ZqTGxWxjtIGj7FgClhRkzseg7GJJPsJ83a5w6oMhp4YkbGTeREETRFAtkUaFC5ewPLSafHMSz b8XFLFC93VPniOCJABfr/DBrsSQSKKbp4piebG2YIM8dRh7/CnfosAJNYEynfZxhmuNwJ4Lrnr+4z rVtW+GAheYCxRWjOZZiTQwbDjgKuoVBunlQWWKZ0KieVcScKpWXr8eGrgvrn6NyuzkGEvvldeBaC/ BmBh4aOQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qjL9N-006LKn-1g; Thu, 21 Sep 2023 14:59:29 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qjL9L-006LJh-00 for linux-riscv@bombadil.infradead.org; Thu, 21 Sep 2023 14:59:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=Content-Type:Cc:To:From:Subject: Message-ID:References:Mime-Version:In-Reply-To:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=4hX9qb1Iw7SkuB3FcSZYopfwd6y9xnz247DDm3mrX40=; b=pDPKZa4CBHSm7SjV0/XsFx1+Ks fg67Abt/9Ou05ndGaDc2LtpOZlkvWOT55gwBslYcyRR/vaXh4fLNK8Q4X1TH0vpRt9VcOIYGfVAjn DwYxfuu7Z6kKypPo7oY2dHBhnja/n8WRNE4EnwuVLn9uC9BP/+AN9pE+ofBx3gkXqz8q9jvtpIoz0 NS1mZ/CpK7i9ArLDvUt6PVVeLWJ5uLeWASNvetisHPZSMKGUgnndlBg01AWWJ3cbr37vzZhV7euYQ 06zPyRt3NAImQhasBFTP4Xs8QocEwpyw7WqZ308ZpSRFv6NXm//0y6OGSoj/7RobsMjHVBfO8WvCY KT205kwQ==; Received: from mail-yw1-x114a.google.com ([2607:f8b0:4864:20::114a]) by desiato.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qjL9G-00FSIZ-1r for linux-riscv@lists.infradead.org; Thu, 21 Sep 2023 14:59:25 +0000 Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-59c12d31d04so14369247b3.1 for ; Thu, 21 Sep 2023 07:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695308352; x=1695913152; darn=lists.infradead.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=4hX9qb1Iw7SkuB3FcSZYopfwd6y9xnz247DDm3mrX40=; b=t2ZJY40VZc7n2whUoq4gyUECPdqwJxm/HhmqvczFVAM8LVHXhDINPB0CiducwvLush JhzDxQnmQeyF3aYoKirpIVNmsHU7RouW5thLM29v33clQAFBYVguBNx7tXmK8LWCAHTV r1KkmH9xv7OY8Vw31wuNZupvr8s3PX8Acvv7S9sahAlXjoorwmelU6m0PDn7ihN6Qmav xRcVwyMSBHsXv4fnsFcLRQOMHVKFha8HYLnz9/cyFZomFI9lLFgFQ4lf4ELbctbDlWDr blJynqKEr5bOSpISgrxyTib6XArOA+CevmVv42xibhGNpuqF8xFc8bdjja9ZVXHGjcLQ GTAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695308352; x=1695913152; 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=4hX9qb1Iw7SkuB3FcSZYopfwd6y9xnz247DDm3mrX40=; b=lHstZxBHd/6GlrtxnLp+bAe2vPB2ys/jbNVJrpDxaLa0bf/ESfGvlmpgDHTg5MAXhh cYhfisMH/f8xWAJ9HE2qdu/6nPFmlIHfVEDktW8W4Uxj9UTE4ToKEqFMA3VDtgEMSNUv deNuZkEygJDsh4T/bsse6rRSwizm1w6Cw9H9RDrTNmKVFfOG1bu2xDXugcQlQUd+Tvgu Cb9LAKrIdK/GNkBErjWr6I38CS3rAuKH8OGhOqXR7dmz1RlEyDn8h6vCFx9FevSdhSlA iC0zJ6h6lY6JyfmB+CN5vDrf2Xz1qZgzPTqFdn/1TLZOfWOWSZLECknSqy0mY7FGUcSZ +TlQ== X-Gm-Message-State: AOJu0Yz3yTC3r7JgEPSJSXp0LZXH4/LlNEWsFVrQ14etr6jLPXyvbl7p zbQlXWR7aWdRVpl1ddcoRxoUXHKCpVA= X-Google-Smtp-Source: AGHT+IGMlI3r5pTKtUH2X22CRcKkDXwZa01FQ/zuLj/x6iC6Lpx1DAvznI7oMbumBcX5i3FsE4fH+yzcjSE= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:690c:2906:b0:59e:ee51:52a1 with SMTP id eg6-20020a05690c290600b0059eee5152a1mr76581ywb.10.1695308352199; Thu, 21 Sep 2023 07:59:12 -0700 (PDT) Date: Thu, 21 Sep 2023 07:59:10 -0700 In-Reply-To: Mime-Version: 1.0 References: <20230914015531.1419405-1-seanjc@google.com> <20230914015531.1419405-19-seanjc@google.com> Message-ID: Subject: Re: [RFC PATCH v12 18/33] KVM: x86/mmu: Handle page fault for private memory From: Sean Christopherson To: Yan Zhao Cc: Paolo Bonzini , Marc Zyngier , Oliver Upton , Huacai Chen , Michael Ellerman , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , "Matthew Wilcox (Oracle)" , Andrew Morton , Paul Moore , James Morris , "Serge E. Hallyn" , kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Chao Peng , Fuad Tabba , Jarkko Sakkinen , Anish Moorthy , Yu Zhang , Isaku Yamahata , Xu Yilun , Vlastimil Babka , Vishal Annapurve , Ackerley Tng , Maciej Szmigiero , David Hildenbrand , Quentin Perret , Michael Roth , Wang , Liam Merwick , Isaku Yamahata , "Kirill A . Shutemov" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230921_155924_127850_F429648F X-CRM114-Status: GOOD ( 27.25 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Mon, Sep 18, 2023, Yan Zhao wrote: > On Fri, Sep 15, 2023 at 07:26:16AM -0700, Sean Christopherson wrote: > > On Fri, Sep 15, 2023, Yan Zhao wrote: > > > > static int __kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault) > > > > { > > > > struct kvm_memory_slot *slot = fault->slot; > > > > @@ -4293,6 +4356,14 @@ static int __kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault > > > > return RET_PF_EMULATE; > > > > } > > > > > > > > + if (fault->is_private != kvm_mem_is_private(vcpu->kvm, fault->gfn)) { > > > In patch 21, > > > fault->is_private is set as: > > > ".is_private = kvm_mem_is_private(vcpu->kvm, cr2_or_gpa >> PAGE_SHIFT)", > > > then, the inequality here means memory attribute has been updated after > > > last check. > > > So, why an exit to user space for converting is required instead of a mere retry? > > > > > > Or, is it because how .is_private is assigned in patch 21 is subjected to change > > > in future? > > > > This. Retrying on SNP or TDX would hang the guest. I suppose we could special > Is this because if the guest access a page in private way (e.g. via > private key in TDX), the returned page must be a private page? Yes, the returned page must be private, because the GHCI (TDX) and GHCB (SNP) require that the host allow implicit conversions. I.e. if the guest accesses memory as private (or shared), then the host must map memory as private (or shared). Simply resuming the guest will not change the guest access, nor will it change KVM's memory attributes. Ideally (IMO), implicit conversions would be disallowed, but even if implicit conversions weren't a thing, retrying would still be wrong as KVM would either inject an exception into the guest or exit to userspace to let userspace handle the illegal access. > > case VMs where .is_private is derived from the memory attributes, but the > > SW_PROTECTED_VM type is primary a development vehicle at this point. I'd like to > > have it mimic SNP/TDX as much as possible; performance is a secondary concern. > Ok. But this mimic is somewhat confusing as it may be problematic in below scenario, > though sane guest should ensure no one is accessing a page before doing memory > conversion. > > > CPU 0 CPU 1 > access GFN A in private way > fault->is_private=true > convert GFN A to shared > set memory attribute of A to shared > > faultin, mismatch and exit > set memory attribute of A > to private > > vCPU access GFN A in shared way > fault->is_private = true > faultin, match and map a private PFN B > > vCPU accesses private PFN B in shared way If this is a TDX or SNP VM, then the private vs. shared information comes from the guest itself, e.g. this sequence vCPU access GFN A in shared way fault->is_private = true cannot happen because is_private will be false based on the error code (SNP) or the GPA (TDX). And when hardware doesn't generate page faults based on private vs. shared, i.e. for non-TDX/SNP VMs, from a fault handling perspective there is no concept of the guest accessing a GFN in a "private way" or a "shared way". I.e. there are no implicit conversions. For SEV and SEV-ES, the guest can access memory as private vs. shared, but the and the host VMM absolutely must be in agreement and synchronized with respect to the state of a page, otherwise guest memory will be corrupted. But that has nothing to do with the fault handling, e.g. creating aliases in the guest to access a single GFN as shared and private from two CPUs will create incoherent cache entries and/or corrupt data without any involvement from KVM. In other words, the above isn't possible for TDX/SNP, and for all other types, the conflict between CPU0 and CPU1 is unequivocally a guest bug. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 343EEE71083 for ; Thu, 21 Sep 2023 15:00:10 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20230601 header.b=Dg9soKZU; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Rrz8m6D8wz3cN7 for ; Fri, 22 Sep 2023 01:00:08 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20230601 header.b=Dg9soKZU; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=flex--seanjc.bounces.google.com (client-ip=2607:f8b0:4864:20::1149; helo=mail-yw1-x1149.google.com; envelope-from=3qfomzqykdfuf1xa6z3bb381.zb985ahkccz-01i85fgf.bm8xyf.be3@flex--seanjc.bounces.google.com; receiver=lists.ozlabs.org) Received: from mail-yw1-x1149.google.com (mail-yw1-x1149.google.com [IPv6:2607:f8b0:4864:20::1149]) (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 lists.ozlabs.org (Postfix) with ESMTPS id 4Rrz7p6n5Rz3c53 for ; Fri, 22 Sep 2023 00:59:17 +1000 (AEST) Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-59c27703cc6so14257167b3.2 for ; Thu, 21 Sep 2023 07:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695308352; x=1695913152; darn=lists.ozlabs.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=4hX9qb1Iw7SkuB3FcSZYopfwd6y9xnz247DDm3mrX40=; b=Dg9soKZUN8rq3tZIGIofD3Y/jm+Gc+IQKGUs8bPYkN/GvOvKhNYGhcDdEG3TslMsEY QfuRnzV81WYXV/OlXaJuu1XMmezderLVQCSH5MWikAAkW20kou3iTKggFi4oN29Av3kM 2DWHqYcPOpnO2sPosliLXT97giuL4MpI9Pdd0wZdSH+HNoYDy4PJ2cEWRRxzv3QDF6KG 50vfakfqs4aOVeONj7MYvBKWaMFW+q9euVWzfBsZz9NnONdh5/OyGogLjcm6mHK7eLJ1 feDSfUtvf8LIqx5gV8AqJmd2Ir7Q6OhdKuq7Zphn6J8KEdjdV9D7gkPeufMUiKSlR8oh V4pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695308352; x=1695913152; 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=4hX9qb1Iw7SkuB3FcSZYopfwd6y9xnz247DDm3mrX40=; b=tHNbzWT7zOmu5OFBgCau69hgJmo47RKVYyCH7rSHRoMfkxqQdEHpyk9bGbZ3rct8O0 hKjlQ9v5SgFcdom32EjUAFvH5gKhhPyJ7J7h+CkvBprM4NB5AjCg6IVrDz79UWuZ4yPr EU8nE7lTSw4xTQ66XIt4WBHZ/vYfe6B4gR/xZOpMcQCwfioZlc7aFpFp6+PkcdrB66oS 4sP2r11O8D3b6LrA8UEhfOHAn5RwSxyi9evSyD+7udqM4UVHECIvWYyyMh2hWpwUTJou to8zPBAJJoIXd2JzF+BALOn8Dv1WBtrmGu8AI3pru6hYFnmKxWj6FqM9MoJ4RvJz5E2E oSyw== X-Gm-Message-State: AOJu0YwNPsn+x4XT1LlEfc1evopM8wUbFOIig/QREXO1uGjMdS0G2f6f r7srXBdBYzy8NDWv5cq1+pjuiIelLsg= X-Google-Smtp-Source: AGHT+IGMlI3r5pTKtUH2X22CRcKkDXwZa01FQ/zuLj/x6iC6Lpx1DAvznI7oMbumBcX5i3FsE4fH+yzcjSE= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:690c:2906:b0:59e:ee51:52a1 with SMTP id eg6-20020a05690c290600b0059eee5152a1mr76581ywb.10.1695308352199; Thu, 21 Sep 2023 07:59:12 -0700 (PDT) Date: Thu, 21 Sep 2023 07:59:10 -0700 In-Reply-To: Mime-Version: 1.0 References: <20230914015531.1419405-1-seanjc@google.com> <20230914015531.1419405-19-seanjc@google.com> Message-ID: Subject: Re: [RFC PATCH v12 18/33] KVM: x86/mmu: Handle page fault for private memory From: Sean Christopherson To: Yan Zhao Content-Type: text/plain; charset="us-ascii" X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kvm@vger.kernel.org, David Hildenbrand , Yu Zhang , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Chao Peng , linux-riscv@lists.infradead.org, Isaku Yamahata , Paul Moore , Marc Zyngier , Huacai Chen , James Morris , "Matthew Wilcox \(Oracle\)" , Wang , Fuad Tabba , Jarkko Sakkinen , "Serge E. Hallyn" , Maciej Szmigiero , Albert Ou , Vlastimil Babka , Michael Roth , Ackerley Tng , Paul Walmsley , kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, Isaku Yamahata , Quentin Perret , Liam Merwick , linux-mips@vger.kernel.org, Oliver Upton , linux-security-module@vger.kernel.org, Palmer Dabbelt , "Kirill A . Shutemov" , kvm-riscv@lists.infradead.org, Anup Patel , linux-fsdevel@vger.kernel.org, Paolo Bonzini , Andrew Morton , Vishal Annapurve , linuxppc-dev@lists.ozlabs.org, Xu Yilun , Anish Moorthy Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Mon, Sep 18, 2023, Yan Zhao wrote: > On Fri, Sep 15, 2023 at 07:26:16AM -0700, Sean Christopherson wrote: > > On Fri, Sep 15, 2023, Yan Zhao wrote: > > > > static int __kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault) > > > > { > > > > struct kvm_memory_slot *slot = fault->slot; > > > > @@ -4293,6 +4356,14 @@ static int __kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault > > > > return RET_PF_EMULATE; > > > > } > > > > > > > > + if (fault->is_private != kvm_mem_is_private(vcpu->kvm, fault->gfn)) { > > > In patch 21, > > > fault->is_private is set as: > > > ".is_private = kvm_mem_is_private(vcpu->kvm, cr2_or_gpa >> PAGE_SHIFT)", > > > then, the inequality here means memory attribute has been updated after > > > last check. > > > So, why an exit to user space for converting is required instead of a mere retry? > > > > > > Or, is it because how .is_private is assigned in patch 21 is subjected to change > > > in future? > > > > This. Retrying on SNP or TDX would hang the guest. I suppose we could special > Is this because if the guest access a page in private way (e.g. via > private key in TDX), the returned page must be a private page? Yes, the returned page must be private, because the GHCI (TDX) and GHCB (SNP) require that the host allow implicit conversions. I.e. if the guest accesses memory as private (or shared), then the host must map memory as private (or shared). Simply resuming the guest will not change the guest access, nor will it change KVM's memory attributes. Ideally (IMO), implicit conversions would be disallowed, but even if implicit conversions weren't a thing, retrying would still be wrong as KVM would either inject an exception into the guest or exit to userspace to let userspace handle the illegal access. > > case VMs where .is_private is derived from the memory attributes, but the > > SW_PROTECTED_VM type is primary a development vehicle at this point. I'd like to > > have it mimic SNP/TDX as much as possible; performance is a secondary concern. > Ok. But this mimic is somewhat confusing as it may be problematic in below scenario, > though sane guest should ensure no one is accessing a page before doing memory > conversion. > > > CPU 0 CPU 1 > access GFN A in private way > fault->is_private=true > convert GFN A to shared > set memory attribute of A to shared > > faultin, mismatch and exit > set memory attribute of A > to private > > vCPU access GFN A in shared way > fault->is_private = true > faultin, match and map a private PFN B > > vCPU accesses private PFN B in shared way If this is a TDX or SNP VM, then the private vs. shared information comes from the guest itself, e.g. this sequence vCPU access GFN A in shared way fault->is_private = true cannot happen because is_private will be false based on the error code (SNP) or the GPA (TDX). And when hardware doesn't generate page faults based on private vs. shared, i.e. for non-TDX/SNP VMs, from a fault handling perspective there is no concept of the guest accessing a GFN in a "private way" or a "shared way". I.e. there are no implicit conversions. For SEV and SEV-ES, the guest can access memory as private vs. shared, but the and the host VMM absolutely must be in agreement and synchronized with respect to the state of a page, otherwise guest memory will be corrupted. But that has nothing to do with the fault handling, e.g. creating aliases in the guest to access a single GFN as shared and private from two CPUs will create incoherent cache entries and/or corrupt data without any involvement from KVM. In other words, the above isn't possible for TDX/SNP, and for all other types, the conflict between CPU0 and CPU1 is unequivocally a guest bug. 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1DA08E71083 for ; Thu, 21 Sep 2023 14:59:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:From:Subject:Message-ID: References:Mime-Version:In-Reply-To:Date:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=PHJrB+QY6HJLQ38nQ6y2Vbq0PP3NPWhUgsvgSNS+nG0=; b=vHWpaTyob+uEH8S84k8WCf4FSP PFvOXur84d0Vwt1N9Ux2RiBFGUO4kSk9lAsH/Cz+eEtlz4DVewa3rHgZ5mkVSUndo7Cxz4qWAQk/M wlRNa11vDyUiRBnLT7TJxEubrUt5tjydmvVePOKVrYhRnZNFmQt7J2SAYoI8jt6TQ1K2ChV+6C/rn YRdGXvjlycMt0ZzjYLQ4bT0ArKAvfMnutyQl1hgpmLuZLxUPvV/pgWIv975FICT5196NTTZx7Wek9 Set0ZIAsTbIRcRFCC9sop2AST10vIowNo54MLj0KG5nB60+m2wrzsUTA/snOPeUwZ6DIoADm1M/FY 2eUT3Z0Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qjL9C-006LHn-2Q; Thu, 21 Sep 2023 14:59:18 +0000 Received: from mail-yw1-x1149.google.com ([2607:f8b0:4864:20::1149]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qjL9A-006LGo-09 for linux-arm-kernel@lists.infradead.org; Thu, 21 Sep 2023 14:59:17 +0000 Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-59c27703cc6so14257117b3.2 for ; Thu, 21 Sep 2023 07:59:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695308352; x=1695913152; darn=lists.infradead.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=4hX9qb1Iw7SkuB3FcSZYopfwd6y9xnz247DDm3mrX40=; b=t2ZJY40VZc7n2whUoq4gyUECPdqwJxm/HhmqvczFVAM8LVHXhDINPB0CiducwvLush JhzDxQnmQeyF3aYoKirpIVNmsHU7RouW5thLM29v33clQAFBYVguBNx7tXmK8LWCAHTV r1KkmH9xv7OY8Vw31wuNZupvr8s3PX8Acvv7S9sahAlXjoorwmelU6m0PDn7ihN6Qmav xRcVwyMSBHsXv4fnsFcLRQOMHVKFha8HYLnz9/cyFZomFI9lLFgFQ4lf4ELbctbDlWDr blJynqKEr5bOSpISgrxyTib6XArOA+CevmVv42xibhGNpuqF8xFc8bdjja9ZVXHGjcLQ GTAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695308352; x=1695913152; 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=4hX9qb1Iw7SkuB3FcSZYopfwd6y9xnz247DDm3mrX40=; b=UUsbHcvWHnOK4fIaCmQurxMeSzKMJQbeKvjdaelgrFLHwD0tOJAZIxA5FegYIPlRrz zY1hsAqXoEqJxdbj88KOpHdHEEJKpw8H95BKjiS72mwb5cKwAnZYV9wzT3rhTlR3HWIv d3NzvJ2CaD/GLKdBj17qjJj52zA2/rLcwWHL3A66jKtCe2bOzjzokHvA87NKmnA0JVR7 12BZ+hEAhSRwuXC1kOykx6pxzIAkRQIDzbtNunaGzlQ3vnt4L4wQ5g0Ih5DAQHyrIx0c +8OKbOHE67szmtfvHRnKI/689Tx0oijPcJO64UkAuT06GZcLYbXPH5jpkFdr3XBOSCKM xGQQ== X-Gm-Message-State: AOJu0YxTSqCH0XrFf6sr3GAvkI02D3yTXqddwWACo0a7XGznV0jpz22K /YQm/RIOIWLctn+W/pOxuA4VzVxbVa4= X-Google-Smtp-Source: AGHT+IGMlI3r5pTKtUH2X22CRcKkDXwZa01FQ/zuLj/x6iC6Lpx1DAvznI7oMbumBcX5i3FsE4fH+yzcjSE= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:690c:2906:b0:59e:ee51:52a1 with SMTP id eg6-20020a05690c290600b0059eee5152a1mr76581ywb.10.1695308352199; Thu, 21 Sep 2023 07:59:12 -0700 (PDT) Date: Thu, 21 Sep 2023 07:59:10 -0700 In-Reply-To: Mime-Version: 1.0 References: <20230914015531.1419405-1-seanjc@google.com> <20230914015531.1419405-19-seanjc@google.com> Message-ID: Subject: Re: [RFC PATCH v12 18/33] KVM: x86/mmu: Handle page fault for private memory From: Sean Christopherson To: Yan Zhao Cc: Paolo Bonzini , Marc Zyngier , Oliver Upton , Huacai Chen , Michael Ellerman , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , "Matthew Wilcox (Oracle)" , Andrew Morton , Paul Moore , James Morris , "Serge E. Hallyn" , kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Chao Peng , Fuad Tabba , Jarkko Sakkinen , Anish Moorthy , Yu Zhang , Isaku Yamahata , Xu Yilun , Vlastimil Babka , Vishal Annapurve , Ackerley Tng , Maciej Szmigiero , David Hildenbrand , Quentin Perret , Michael Roth , Wang , Liam Merwick , Isaku Yamahata , "Kirill A . Shutemov" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230921_075916_086859_E7E617F1 X-CRM114-Status: GOOD ( 28.89 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Sep 18, 2023, Yan Zhao wrote: > On Fri, Sep 15, 2023 at 07:26:16AM -0700, Sean Christopherson wrote: > > On Fri, Sep 15, 2023, Yan Zhao wrote: > > > > static int __kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault) > > > > { > > > > struct kvm_memory_slot *slot = fault->slot; > > > > @@ -4293,6 +4356,14 @@ static int __kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault > > > > return RET_PF_EMULATE; > > > > } > > > > > > > > + if (fault->is_private != kvm_mem_is_private(vcpu->kvm, fault->gfn)) { > > > In patch 21, > > > fault->is_private is set as: > > > ".is_private = kvm_mem_is_private(vcpu->kvm, cr2_or_gpa >> PAGE_SHIFT)", > > > then, the inequality here means memory attribute has been updated after > > > last check. > > > So, why an exit to user space for converting is required instead of a mere retry? > > > > > > Or, is it because how .is_private is assigned in patch 21 is subjected to change > > > in future? > > > > This. Retrying on SNP or TDX would hang the guest. I suppose we could special > Is this because if the guest access a page in private way (e.g. via > private key in TDX), the returned page must be a private page? Yes, the returned page must be private, because the GHCI (TDX) and GHCB (SNP) require that the host allow implicit conversions. I.e. if the guest accesses memory as private (or shared), then the host must map memory as private (or shared). Simply resuming the guest will not change the guest access, nor will it change KVM's memory attributes. Ideally (IMO), implicit conversions would be disallowed, but even if implicit conversions weren't a thing, retrying would still be wrong as KVM would either inject an exception into the guest or exit to userspace to let userspace handle the illegal access. > > case VMs where .is_private is derived from the memory attributes, but the > > SW_PROTECTED_VM type is primary a development vehicle at this point. I'd like to > > have it mimic SNP/TDX as much as possible; performance is a secondary concern. > Ok. But this mimic is somewhat confusing as it may be problematic in below scenario, > though sane guest should ensure no one is accessing a page before doing memory > conversion. > > > CPU 0 CPU 1 > access GFN A in private way > fault->is_private=true > convert GFN A to shared > set memory attribute of A to shared > > faultin, mismatch and exit > set memory attribute of A > to private > > vCPU access GFN A in shared way > fault->is_private = true > faultin, match and map a private PFN B > > vCPU accesses private PFN B in shared way If this is a TDX or SNP VM, then the private vs. shared information comes from the guest itself, e.g. this sequence vCPU access GFN A in shared way fault->is_private = true cannot happen because is_private will be false based on the error code (SNP) or the GPA (TDX). And when hardware doesn't generate page faults based on private vs. shared, i.e. for non-TDX/SNP VMs, from a fault handling perspective there is no concept of the guest accessing a GFN in a "private way" or a "shared way". I.e. there are no implicit conversions. For SEV and SEV-ES, the guest can access memory as private vs. shared, but the and the host VMM absolutely must be in agreement and synchronized with respect to the state of a page, otherwise guest memory will be corrupted. But that has nothing to do with the fault handling, e.g. creating aliases in the guest to access a single GFN as shared and private from two CPUs will create incoherent cache entries and/or corrupt data without any involvement from KVM. In other words, the above isn't possible for TDX/SNP, and for all other types, the conflict between CPU0 and CPU1 is unequivocally a guest bug. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel