[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240417194734.GK3039520@ls.amr.corp.intel.com>
Date: Wed, 17 Apr 2024 12:47:34 -0700
From: Isaku Yamahata <isaku.yamahata@...el.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
isaku.yamahata@...el.com, xiaoyao.li@...el.com,
binbin.wu@...ux.intel.com, seanjc@...gle.com,
rick.p.edgecombe@...el.com, isaku.yamahata@...ux.intel.com
Subject: Re: [PATCH 3/7] KVM: x86/mmu: Extract __kvm_mmu_do_page_fault()
On Wed, Apr 17, 2024 at 11:34:46AM -0400,
Paolo Bonzini <pbonzini@...hat.com> wrote:
> From: Isaku Yamahata <isaku.yamahata@...el.com>
>
> Extract out __kvm_mmu_do_page_fault() from kvm_mmu_do_page_fault(). The
> inner function is to initialize struct kvm_page_fault and to call the fault
> handler, and the outer function handles updating stats and converting
> return code. KVM_MAP_MEMORY will call the KVM page fault handler.
To clarify to no update vcpu.stat, let me update the last sentence.
KVM_MAP_MEMORY will call the KVM page fault handler without vcpu stat that
doesn't make sense for pre-population because pre-population (outside TDX) has
the purpose of avoiding page faults
> This patch makes the emulation_type always set irrelevant to the return
> code. kvm_mmu_page_fault() is the only caller of kvm_mmu_do_page_fault(),
> and references the value only when PF_RET_EMULATE is returned. Therefore,
> this adjustment doesn't affect functionality.
For the technical correctness, let me mention about NULL emulation_type.
I added "," and "with non-NULL emulation_type" to the second sentence.
https://lore.kernel.org/all/621c260399a05338ba6d034e275e19714ad3665c.camel@intel.com/
This patch makes the emulation_type always set, irrelevant to the return
code. kvm_mmu_page_fault() is the only caller of kvm_mmu_do_page_fault() with
non-NULL emulation_type and references the value only when PF_RET_EMULATE is
returned. Therefore, this adjustment doesn't affect functionality.
--
Isaku Yamahata <isaku.yamahata@...el.com>
Powered by blists - more mailing lists