Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp6474712rwb; Tue, 22 Nov 2022 14:02:48 -0800 (PST) X-Google-Smtp-Source: AA0mqf5JBZ62l5Fqp//vqWfafMeOBPIdGJnmEwVCx7cd50i4XeB0zRtYsAipa8U9juTlxqApF1th X-Received: by 2002:a62:1d86:0:b0:56d:d08c:baf0 with SMTP id d128-20020a621d86000000b0056dd08cbaf0mr6628748pfd.72.1669154568190; Tue, 22 Nov 2022 14:02:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669154568; cv=none; d=google.com; s=arc-20160816; b=pmzNJxXXSi0Sa9/tzbnzV8/eZdCAB5vhtrYdrjygN59lohKspQOsxZB44Ks2CNLC4J BNzdE2qAkI89WTh4Kfc3o63W3b/sZiTqiTV2kWAyTFqQUB+1vSXqoWBY9YkDonsJMGo8 V1wGdjWhvoVNIdRT85fC6i5F1Pdx9DF/SZlT/RESvM+8sH42cUU/ONTeUXLWbu+YG5jK SCFqyoPZigMIeGa6SdIlzm7fWvLyCnGRieWDe2CcJLJxfRrKaVDHsXx/l5VBP/WD3oSH gqAe05ruTDy5osBYfIOFuCJuK5YD/U5Kn6NhCBh5j7yfGr7sldDN8wl0+SKIufHYPuN6 fAWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:mime-version :in-reply-to:date:dkim-signature; bh=zgimOf2fhkQleYDBm+3WEMJX9iyYgXrpyh87WZyj3iY=; b=gA2Hp9VYQqMKOgoUn5I/lts070/v4LyZ+UZOA+B5abwi4kCydO2nlBfHZcWlJiTVq9 fjt40+CeoZRxI4PeE3FHVgPlrrB8wgGtp5UnvChT4tJ6jABeKVCTSWBWptd158LWtVxS 2ufIgFt0ei1bTNllaJUn9mjdp0S8FyRlw1a3sDeT+sC+/fw7SCF0i24eQUSuXvzA9C7A GIRuPJLsBpH2nhMMrmZmUUGrsj8Q6nyWrDX6b1t/W9oyC9MqL9k8b0wSVTusBeMEwy9S lD0eMjOhKl4yhGbkSfp95aY1DPqv2FPTCg63bvr70zocbRGQG8BTLqCTjqrvkQHjr2tA xXBQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=lVv2mTak; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c10-20020a170902c1ca00b00188f3b1d0d0si13322003plc.376.2022.11.22.14.02.35; Tue, 22 Nov 2022 14:02:48 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=lVv2mTak; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234329AbiKVV0Q (ORCPT + 89 others); Tue, 22 Nov 2022 16:26:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51048 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234416AbiKVV0O (ORCPT ); Tue, 22 Nov 2022 16:26:14 -0500 Received: from mail-pl1-x64a.google.com (mail-pl1-x64a.google.com [IPv6:2607:f8b0:4864:20::64a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 03972B70C5 for ; Tue, 22 Nov 2022 13:26:13 -0800 (PST) Received: by mail-pl1-x64a.google.com with SMTP id c7-20020a170903234700b0018729febd96so12352893plh.19 for ; Tue, 22 Nov 2022 13:26:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:mime-version:in-reply-to:date:from:to :cc:subject:date:message-id:reply-to; bh=zgimOf2fhkQleYDBm+3WEMJX9iyYgXrpyh87WZyj3iY=; b=lVv2mTakLyH0mUQEmNwxYoDh+3DxuzDGtIVYSniYeHvEtMOtdEPVoNfksWen4QT0H0 6H+2+LjZrO2G2h88rSxZ39aZ/CfY0OGjAs5EHQcpFqTCqSYHCLCig1EK8P3sZQl49ALf GB5hn6rrVf3oqbw3wC1vBug2kvL1DcUtnatLFJfLk5JoA4NWjjhtmQllFS/q3Ka0CbhH rKjGCIHW3yFzoUJHB2j4HiD2Vg8M2MXcHFbxzCvuEIufeJfbB2jT5YBXs3kOOIcgukES XZGYLg62U2fMD2/rIUXsFc6d9o7uDcAUBjoJRL7j4vx4/+Yi4UQUBtUQSR2PqoeWb5oz xNfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:mime-version:in-reply-to:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=zgimOf2fhkQleYDBm+3WEMJX9iyYgXrpyh87WZyj3iY=; b=heT12XDyYZ6Y6TL18BFuBqsrvwuWlLVV0G+vpe1Ys++/YML4IpL6jZqOZHagS/cd0Y n8C9OnK/4NtPc/DfYojGI+x2MFytK+HYyzz0PVUM8bU65wHZDsRmoZQpnXcem2GPw2dO Ny2QUTdcbV3nFFwXyIslHaWTShpNirDqVqOfdaFdgxmqWhQ1M9P4UhugeW8eekYz/fGQ vmZovipJ3s/iCybgyw4J66UJqfOwYiXdBtltbWEAmZgGh0pzBD4W9SWoRJJoxfwQxj6N j6C9B3mo5GSYrFNsWdsalPJlhPH0KdBFBNc5B1SL1BBnbULt6t36OK3JxDRIb2/gvYxQ NBzQ== X-Gm-Message-State: ANoB5pmozcBmMSZNDlyHTrXB89gY81iLtQD8UXRJj8wmkKBSMJ57Z879 MNJKgLi7MmpOCEIqMcKvIsCAmPtQ+u2/IP3Zgw== X-Received: from ackerleytng-cloudtop.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:1f5f]) (user=ackerleytng job=sendgmr) by 2002:a63:cd57:0:b0:46e:c9d0:96c with SMTP id a23-20020a63cd57000000b0046ec9d0096cmr4913454pgj.586.1669152372521; Tue, 22 Nov 2022 13:26:12 -0800 (PST) Date: Tue, 22 Nov 2022 13:26:10 -0800 In-Reply-To: <9e8346b692eb377576363a028c3688c66f3c0bfe.1667110240.git.isaku.yamahata@intel.com> Mime-Version: 1.0 Message-ID: Subject: Re: [PATCH v10 047/108] KVM: x86/tdp_mmu: Don't zap private pages for unsupported cases From: Ackerley Tng To: isaku.yamahata@intel.com Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, isaku.yamahata@intel.com, isaku.yamahata@gmail.com, pbonzini@redhat.com, erdemaktas@google.com, seanjc@google.com, sagis@google.com, dmatlack@google.com, sean.j.christopherson@intel.com Content-Type: text/plain; charset="UTF-8"; format=flowed; delsp=yes X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > From: Sean Christopherson > TDX supports only write-back(WB) memory type for private memory > architecturally so that (virtualized) memory type change doesn't make > sense > for private memory. Also currently, page migration isn't supported for > TDX > yet. (TDX architecturally supports page migration. it's KVM and kernel > implementation issue.) > Regarding memory type change (mtrr virtualization and lapic page mapping > change), pages are zapped by kvm_zap_gfn_range(). On the next KVM page > fault, the SPTE entry with a new memory type for the page is populated. > Regarding page migration, pages are zapped by the mmu notifier. On the > next > KVM page fault, the new migrated page is populated. Don't zap private > pages on unmapping for those two cases. > When deleting/moving a KVM memory slot, zap private pages. Typically > tearing down VM. Don't invalidate private page tables. i.e. zap only leaf > SPTEs for KVM mmu that has a shared bit mask. The existing > kvm_tdp_mmu_invalidate_all_roots() depends on role.invalid with read-lock > of mmu_lock so that other vcpu can operate on KVM mmu concurrently. It > marks the root page table invalid and zaps SPTEs of the root page > tables. The TDX module doesn't allow to unlink a protected root page table > from the hardware and then allocate a new one for it. i.e. replacing a > protected root page table. Instead, zap only leaf SPTEs for KVM mmu with > a > shared bit mask set. > Signed-off-by: Sean Christopherson > Signed-off-by: Isaku Yamahata > --- > arch/x86/kvm/mmu/mmu.c | 85 ++++++++++++++++++++++++++++++++++++-- > arch/x86/kvm/mmu/tdp_mmu.c | 24 ++++++++--- > arch/x86/kvm/mmu/tdp_mmu.h | 5 ++- > 3 files changed, 103 insertions(+), 11 deletions(-) > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c > index faf69774c7ce..0237e143299c 100644 > --- a/arch/x86/kvm/mmu/mmu.c > +++ b/arch/x86/kvm/mmu/mmu.c > @@ -1577,8 +1577,38 @@ bool kvm_unmap_gfn_range(struct kvm *kvm, struct > kvm_gfn_range *range) > if (kvm_memslots_have_rmaps(kvm)) > flush = kvm_handle_gfn_range(kvm, range, kvm_zap_rmap); > - if (is_tdp_mmu_enabled(kvm)) > - flush = kvm_tdp_mmu_unmap_gfn_range(kvm, range, flush); > + if (is_tdp_mmu_enabled(kvm)) { > + bool zap_private; We should initialize zap_private to true, otherwise zap_private is uninitialized in call kvm_tdp_mmu_unmap_gfn_range(kvm, range, flush, zap_private) if the condition if (kvm_slot_can_be_private(range->slot)) { evaluates to false. > + > + if (kvm_slot_can_be_private(range->slot)) { > + if (range->flags & KVM_GFN_RANGE_FLAGS_RESTRICTED_MEM) > + /* > + * For private slot, the callback is triggered > + * via falloc. Mode can be allocation or punch > + * hole. Because the private-shared conversion > + * is done via > + * KVM_MEMORY_ENCRYPT_REG/UNREG_REGION, we can > + * ignore the request from restrictedmem. > + */ > + return flush; > + else if (range->flags & KVM_GFN_RANGE_FLAGS_SET_MEM_ATTR) { > + if (range->attr == KVM_MEM_ATTR_SHARED) > + zap_private = true; > + else { > + WARN_ON_ONCE(range->attr != KVM_MEM_ATTR_PRIVATE); > + zap_private = false; > + } > + } else > + /* > + * kvm_unmap_gfn_range() is called via mmu > + * notifier. For now page migration for private > + * page isn't supported yet, don't zap private > + * pages. > + */ > + zap_private = false; > + } > + flush = kvm_tdp_mmu_unmap_gfn_range(kvm, range, flush, zap_private); > + } > return flush; > }