Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp1152081rwb; Wed, 16 Nov 2022 12:55:41 -0800 (PST) X-Google-Smtp-Source: AA0mqf4m/UA1k8zsvUmHij5Bby0qrxqAOF6dOXb+cS20LOumt1EgyJ3A6FK/x7EH3yxvRzUY+kxj X-Received: by 2002:a17:906:a057:b0:79e:4f34:a8e1 with SMTP id bg23-20020a170906a05700b0079e4f34a8e1mr18789756ejb.194.1668632141367; Wed, 16 Nov 2022 12:55:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668632141; cv=none; d=google.com; s=arc-20160816; b=Wu+Il3C0C/OujJ/KJoyhBdBMx9TpB1B7gOOGyYeWVPxB54edbV1KWNsGMZtVu6Eyvm 6U0uMV/BX7/s7Za9imi9TJk9mpFoNVGJPWBNWfhl4txmFJEulV8T/VGxt7UO4oybaxLc CTwSBKzObGuKvSd6FCdDrOE+G4+LaF2XNc5bKGw8/PVR7pNnZVafqpRoL7e8YVCq3+5H kG0/W9J5KgNWdyVs8uwVo9nsTlTSor/vr1XnfzNLOrSnNhjRjwyRYY6EW47QYjskX86G /rtqugZ41ZMJ/TV7ZQnN3odRIYa/9lxRq8qHUJ0jPwbZ6QQtrzn5dnguSFdF7vP4DQRU TYaQ== 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:references :mime-version:in-reply-to:date:dkim-signature; bh=Vm8HknjbQpP5x1fHUQZ8Fa+JhrBUsKYRYb84Ljw06/8=; b=ZoEKibrPAwGSalhySyvGOKwJRVEDZQQIa3xzWsqtW77uSYUVwQsSJnvDZwb8hF4rXP BBHylIW0LbOzp/wqZPmDxQytwMOfCrkNFtKam/tigO7TJpGWEM5igEv3B3B0DZiP/MR8 azEkMjiJn9CKHib7aUcZbrMNWSy66clL0knN1yFHS+H+jx9hIh+cGFAJIllyapjt56rY 1YSXBNwdX1aG4TP0YT4eOILACau4zEFgyDSrcZcQYrOGw0ez4yb4KhbJYBgKLibb5u/C IroxDyh9MB+mY5Ht0MpR40LVR5Fr+1Asd+9BeNCCq/4hvNShKPJW1oxOOY1V/AkVpLM9 a3AQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=BxC9ZIiQ; 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 e14-20020a17090658ce00b007aea5ae39b1si15879279ejs.443.2022.11.16.12.55.20; Wed, 16 Nov 2022 12:55:41 -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=BxC9ZIiQ; 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 S233188AbiKPUub (ORCPT + 90 others); Wed, 16 Nov 2022 15:50:31 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33560 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233262AbiKPUu2 (ORCPT ); Wed, 16 Nov 2022 15:50:28 -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 DCFF8623A0 for ; Wed, 16 Nov 2022 12:50:26 -0800 (PST) Received: by mail-pl1-x64a.google.com with SMTP id q6-20020a170902dac600b001873ef77938so14663645plx.18 for ; Wed, 16 Nov 2022 12:50:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=Vm8HknjbQpP5x1fHUQZ8Fa+JhrBUsKYRYb84Ljw06/8=; b=BxC9ZIiQoKs8ZVqFtGoVwkhZjhvx+R8PRQB6GTtgA210grIKaMUfq2t0MWY3kI6kkp Ri7QGvFmdcQHkk1hdrwKgiBlH7UL9kkXPXLqHdnAIp3PIrrDNkNKuXekVJ7+ZRLfdmPg cQkuCip07OmxTzEL5JEZGej5dA3zvd1W4OtdIo2gBJqiIu2fJkfRqzbucnRGJGmvoaGQ JeagXDUkI3LTmVilwN+XEnCxUy4kfrqeJ1CvBsbW5yvysO4wop2f/STxLeY9zAtDUUFw n8gsLiJIOgQlD8T85gNo08kYyGRdhjrlcaafVDzmuk2vc2ElQCmnrFZnsbi5bwPjtr2C xOpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=Vm8HknjbQpP5x1fHUQZ8Fa+JhrBUsKYRYb84Ljw06/8=; b=SWQcZijAN/uaTey6wMhgD8uAjl0NVr90907niygtWud9+uWsymwfex5IjHGdFGGlao PBKuOKEaUK0kocbYdvKJkKdDr1pWBkKfwticfGHftTHnNOBZCYpwsb9WRsq1m9yiz3S5 z1zsvWdSpOeqS2xJldmW84UhR/Ytk7pk4uUU1qGm3QO1hHTZSQ037LNiBYCf+F6wplc5 H7jnOg8foj3EwCCOO4UgOH6d65ijL2T099EXRn7nkna0nBmy+gr4CDYZwxAeTg1aEli3 vj92XNWzcnbRZrn2Vsu3gNtrHZ80b5MGvL8ykrIAN7g87yiShIGvisJMuM9g6AQsLD38 Nt7g== X-Gm-Message-State: ANoB5pneb9c7RczispMQb4ETg0juoyRaTtYlQ2DLg0WfjOwMWqdVJ6cG A7vkwlW7zmn2G6cl59ib1gw+cYK8DJP0ID2oJw== X-Received: from ackerleytng-cloudtop.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:1f5f]) (user=ackerleytng job=sendgmr) by 2002:aa7:9041:0:b0:572:9681:1018 with SMTP id n1-20020aa79041000000b0057296811018mr6472865pfo.39.1668631826322; Wed, 16 Nov 2022 12:50:26 -0800 (PST) Date: Wed, 16 Nov 2022 20:50:25 +0000 In-Reply-To: <20221025151344.3784230-8-chao.p.peng@linux.intel.com> Mime-Version: 1.0 References: <20221025151344.3784230-8-chao.p.peng@linux.intel.com> X-Mailer: git-send-email 2.38.1.584.g0f3c55d4c2-goog Message-ID: <20221116205025.1510291-1-ackerleytng@google.com> Subject: Re: [PATCH v9 7/8] KVM: Handle page fault for private memory From: Ackerley Tng To: chao.p.peng@linux.intel.com Cc: aarcange@redhat.com, ak@linux.intel.com, akpm@linux-foundation.org, bfields@fieldses.org, bp@alien8.de, corbet@lwn.net, dave.hansen@intel.com, david@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, hpa@zytor.com, hughd@google.com, jlayton@kernel.org, jmattson@google.com, joro@8bytes.org, jun.nakajima@intel.com, kirill.shutemov@linux.intel.com, kvm@vger.kernel.org, linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, luto@kernel.org, mail@maciej.szmigiero.name, mhocko@suse.com, michael.roth@amd.com, mingo@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org, qperret@google.com, rppt@kernel.org, seanjc@google.com, shuah@kernel.org, songmuchun@bytedance.com, steven.price@arm.com, tabba@google.com, tglx@linutronix.de, vannapurve@google.com, vbabka@suse.cz, vkuznets@redhat.com, wanpengli@tencent.com, wei.w.wang@intel.com, x86@kernel.org, yu.c.zhang@linux.intel.com Content-Type: text/plain; charset="UTF-8" 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 > A memslot with KVM_MEM_PRIVATE being set can include both fd-based > private memory and hva-based shared memory. Architecture code (like TDX > code) can tell whether the on-going fault is private or not. This patch > adds a 'is_private' field to kvm_page_fault to indicate this and > architecture code is expected to set it. > > To handle page fault for such memslot, the handling logic is different > depending on whether the fault is private or shared. KVM checks if > 'is_private' matches the host's view of the page (maintained in > mem_attr_array). > - For a successful match, private pfn is obtained with > restrictedmem_get_page () from private fd and shared pfn is obtained > with existing get_user_pages(). > - For a failed match, KVM causes a KVM_EXIT_MEMORY_FAULT exit to > userspace. Userspace then can convert memory between private/shared > in host's view and retry the fault. > > Co-developed-by: Yu Zhang > Signed-off-by: Yu Zhang > Signed-off-by: Chao Peng > --- > arch/x86/kvm/mmu/mmu.c | 56 +++++++++++++++++++++++++++++++-- > arch/x86/kvm/mmu/mmu_internal.h | 14 ++++++++- > arch/x86/kvm/mmu/mmutrace.h | 1 + > arch/x86/kvm/mmu/spte.h | 6 ++++ > arch/x86/kvm/mmu/tdp_mmu.c | 3 +- > include/linux/kvm_host.h | 28 +++++++++++++++++ > 6 files changed, 103 insertions(+), 5 deletions(-) > > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c > index 67a9823a8c35..10017a9f26ee 100644 > --- a/arch/x86/kvm/mmu/mmu.c > +++ b/arch/x86/kvm/mmu/mmu.c > @@ -3030,7 +3030,7 @@ static int host_pfn_mapping_level(struct kvm *kvm, gfn_t gfn, > > int kvm_mmu_max_mapping_level(struct kvm *kvm, > const struct kvm_memory_slot *slot, gfn_t gfn, > - int max_level) > + int max_level, bool is_private) > { > struct kvm_lpage_info *linfo; > int host_level; > @@ -3042,6 +3042,9 @@ int kvm_mmu_max_mapping_level(struct kvm *kvm, > break; > } > > + if (is_private) > + return max_level; > + > if (max_level == PG_LEVEL_4K) > return PG_LEVEL_4K; > > @@ -3070,7 +3073,8 @@ void kvm_mmu_hugepage_adjust(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault > * level, which will be used to do precise, accurate accounting. > */ > fault->req_level = kvm_mmu_max_mapping_level(vcpu->kvm, slot, > - fault->gfn, fault->max_level); > + fault->gfn, fault->max_level, > + fault->is_private); > if (fault->req_level == PG_LEVEL_4K || fault->huge_page_disallowed) > return; > > @@ -4141,6 +4145,32 @@ void kvm_arch_async_page_ready(struct kvm_vcpu *vcpu, struct kvm_async_pf *work) > kvm_mmu_do_page_fault(vcpu, work->cr2_or_gpa, 0, true); > } > > +static inline u8 order_to_level(int order) > +{ > + BUILD_BUG_ON(KVM_MAX_HUGEPAGE_LEVEL > PG_LEVEL_1G); > + > + if (order >= KVM_HPAGE_GFN_SHIFT(PG_LEVEL_1G)) > + return PG_LEVEL_1G; > + > + if (order >= KVM_HPAGE_GFN_SHIFT(PG_LEVEL_2M)) > + return PG_LEVEL_2M; > + > + return PG_LEVEL_4K; > +} > + > +static int kvm_faultin_pfn_private(struct kvm_page_fault *fault) > +{ > + int order; > + struct kvm_memory_slot *slot = fault->slot; > + > + if (kvm_restricted_mem_get_pfn(slot, fault->gfn, &fault->pfn, &order)) >+ return RET_PF_RETRY; >+ >+ fault->max_level = min(order_to_level(order), fault->max_level); >+ fault->map_writable = !(slot->flags & KVM_MEM_READONLY); >+ return RET_PF_CONTINUE; >+} >+ > static int kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault) > { > struct kvm_memory_slot *slot = fault->slot; >@@ -4173,6 +4203,22 @@ static int kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault) > return RET_PF_EMULATE; > } > >+ if (kvm_slot_can_be_private(slot) && >+ fault->is_private != kvm_mem_is_private(vcpu->kvm, fault->gfn)) { >+ vcpu->run->exit_reason = KVM_EXIT_MEMORY_FAULT; >+ if (fault->is_private) >+ vcpu->run->memory.flags = KVM_MEMORY_EXIT_FLAG_PRIVATE; >+ else >+ vcpu->run->memory.flags = 0; >+ vcpu->run->memory.padding = 0; >+ vcpu->run->memory.gpa = fault->gfn << PAGE_SHIFT; >+ vcpu->run->memory.size = PAGE_SIZE; >+ return RET_PF_USER; >+ } >+ >+ if (fault->is_private) >+ return kvm_faultin_pfn_private(fault); >+ Since each memslot may also not be backed by restricted memory, we should also check if the memslot has been set up for private memory with if (fault->is_private && kvm_slot_can_be_private(slot)) return kvm_faultin_pfn_private(fault); Without this check, restrictedmem_get_page will get called with NULL in slot->restricted_file, which causes a NULL pointer dereference. > async = false; > fault->pfn = __gfn_to_pfn_memslot(slot, fault->gfn, false, &async, > fault->write, &fault->map_writable, >@@ -5557,6 +5603,9 @@ int noinline kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa, u64 err > return -EIO; > } > >+ if (r == RET_PF_USER) >+ return 0; >+ > if (r < 0) > return r; > if (r != RET_PF_EMULATE) >@@ -6408,7 +6457,8 @@ static bool kvm_mmu_zap_collapsible_spte(struct kvm *kvm, > */ > if (sp->role.direct && > sp->role.level < kvm_mmu_max_mapping_level(kvm, slot, sp->gfn, >- PG_LEVEL_NUM)) { >+ PG_LEVEL_NUM, >+ false)) { > kvm_zap_one_rmap_spte(kvm, rmap_head, sptep); > > if (kvm_available_flush_tlb_with_range())