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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6F174C4332F for ; Tue, 22 Nov 2022 21:26:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235013AbiKVV0Q (ORCPT ); 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-Google-Smtp-Source: AA0mqf6tF7wuZFNnT06MIDxN4K88WuS+gvWo34APH7cHAv8iYvQPOdJIW8aHcfgRyichIBKp9SpUgsF/jBKIFuZIDA== 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 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; > }