Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp6375025rwb; Tue, 22 Nov 2022 12:26:25 -0800 (PST) X-Google-Smtp-Source: AA0mqf6dNs8sytlVFApqs3iR6nqEOxHlHV6dtW/LntXdlMDlPIMrtzKYXPYGqE72ogZken4fSlvZ X-Received: by 2002:a62:2fc1:0:b0:562:fcae:5f10 with SMTP id v184-20020a622fc1000000b00562fcae5f10mr5557946pfv.28.1669148785370; Tue, 22 Nov 2022 12:26:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669148785; cv=none; d=google.com; s=arc-20160816; b=i7Rd+16jWUqdKTVSqg/Ic4W3mNAMPmw4kwXwygDpN4F/H/jv7FWzAyb6N7AG78S+ox xyP9LjEsyFnH7KZ5rgYHk/KOkuLSzq5EwYM34SqXA+wupw7jyRk/96ZNrKlFb06m+DZ8 WRTes9L3YshHCIhYUSD9iMtVEn3eGRxfFSzwGsIDO5KkuQkVjqJKiGQvn4KGZ8gD3ysi IQzRmsmP1vA2wu2q+R+avd6VeyfW3IqM+1pl3jEkwE9zHy9/Xaaif2CkqVAOW2GtZE8Y 0lK2JqpDQ4ML3l8xjhiv9qQt48s9zjprqu43yh9GmDE5z910HZJulxzFIAoNk2t4oss+ F8mw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:mime-version :dkim-signature; bh=9AgAZ70TrtdzOoBdfiah///XbtqvmKlASUxc0HY4vfg=; b=vFiJmS5fU1htVTWeuglB2kKjDS1e0U0Onecd1m83cVoEuHTmx19cYV2Q87bmYCJASD sP0lV/kb/9rm/FkbEa3wd0F+IzBHvhv6QCtJq4ilvq23LybTnPTdpjId0hYVDC+ioq76 OnaGHCXTLjzU7dkTpclfzWvjkpK6NeYATM6PLJPJ9mhdCzip71H2DA+bQqI4xOAH+qNd 1l1IgIkPp88v3kt8kDdTMWugS+hV1NlVC9xBA92CzQSlSnLTkYm377Ij8ylK7ojTdRZ1 5GVD0CFK9bBBUgOnfo0kvcaysVEPrEF36+vI/q5FtFHrrlo1u7I0ZWaZXwR7NjCfRbzJ 1R1w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=PPusKsb7; 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 g18-20020a17090a579200b0021878aebd90si2514597pji.168.2022.11.22.12.26.13; Tue, 22 Nov 2022 12:26:25 -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=PPusKsb7; 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 S233928AbiKVTh5 (ORCPT + 90 others); Tue, 22 Nov 2022 14:37:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59390 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232491AbiKVThz (ORCPT ); Tue, 22 Nov 2022 14:37:55 -0500 Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4CB4B220FE for ; Tue, 22 Nov 2022 11:37:54 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id d6so25049958lfs.10 for ; Tue, 22 Nov 2022 11:37:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=9AgAZ70TrtdzOoBdfiah///XbtqvmKlASUxc0HY4vfg=; b=PPusKsb75SMY/Pl8RNjMt0TEs608oGnvVRmD1no7NYu9GmKsxFm1Hn0YGi0sCT2SDT 4Iws8zh5UkoPU8t989AySG8Kb4Ziki8ppBI2gYsrUEuNmViGo5t4GeIkEw50+MrAAaAe UshKght/wjdAKP2K324GTWMCkYfnzJPYs9QedYivQ+vzEcdVswjuMDNcCaDz85XxU/qO wXuCziS3KuhCeAgzmfsHI+3wc8gsPaXwMU8St4YT3SYpbsq2O53V6SfgCH0ExSaEQHxy 1gM+KPnryXNI6ceg0obzRNJROLuOkKAZOBMUbKjgG6nq2XZVihiQ9sRyVsUHzm/k0+So JsMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=9AgAZ70TrtdzOoBdfiah///XbtqvmKlASUxc0HY4vfg=; b=Ci++PmnWtW0ulZuCQT8dKdYctQd91fHKjgZtnLOT1yUJmF05DZCJFFbsDYW6jC+jih mYMmykg3KpqCY3VIV02T9PZLmehNpQLSf+nrFCvrQurCAXOP666TcWHSepsgdmmFO49p ukJa556NB+R/7JTQEZK3KFeGRUGtCpAXavgUk3tPu+UUJYglupsm0RG4MA8+rDUSJNq1 2AV+aL76/ul0z0J95HVEcI3+x2I8ZJCxfvJVY29IPmr6aPH6BnKGkeoG6c5vYeOYd1Fo d+t0wtwN2WRAdo96PMXK1CAKlT33A/5eogtYHz2ZTSMS2bIHYHmUW18zQr0nM6VDaMMC YWsg== X-Gm-Message-State: ANoB5pmM8iT+kRmsauiCfTm5sirHM0ACeks9KLYrV/npL40uRe7Yk0Hs oRGJGoV38i36OqHtwZtSFXUcDebMWsHDf+5InEG1eg== X-Received: by 2002:a19:384c:0:b0:494:7055:b085 with SMTP id d12-20020a19384c000000b004947055b085mr4857802lfj.109.1669145872368; Tue, 22 Nov 2022 11:37:52 -0800 (PST) MIME-Version: 1.0 From: Ackerley Tng Date: Tue, 22 Nov 2022 11:37:41 -0800 Message-ID: Subject: Re: [PATCH v10 047/108] KVM: x86/tdp_mmu: Don't zap private pages for unsupported cases To: isaku.yamahata@intel.com Cc: David Matlack , Erdem Aktas , isaku.yamahata@gmail.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, pbonzini@redhat.com, Sagi Shahar , sean.j.christopherson@intel.com, Sean Christopherson Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_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 Subject: Re: [PATCH v10 047/108] KVM: x86/tdp_mmu: Don't zap private pages for unsupported cases > 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; > }