From: Sean Christopherson <seanjc@google.com>
To: Yan Zhao <yan.y.zhao@intel.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
pbonzini@redhat.com, chao.gao@intel.com, kai.huang@intel.com,
robert.hoo.linux@gmail.com, yuan.yao@linux.intel.com
Subject: Re: [PATCH v4 10/12] KVM: x86/mmu: fine-grained gfn zap when guest MTRRs are honored
Date: Fri, 25 Aug 2023 16:13:35 -0700 [thread overview]
Message-ID: <ZOk1n3ssdU7bXalP@google.com> (raw)
In-Reply-To: <20230714065530.20748-1-yan.y.zhao@intel.com>
On Fri, Jul 14, 2023, Yan Zhao wrote:
> void kvm_honors_guest_mtrrs_zap_on_cd_toggle(struct kvm_vcpu *vcpu)
> {
> - return kvm_mtrr_zap_gfn_range(vcpu, gpa_to_gfn(0), gpa_to_gfn(~0ULL));
> + struct kvm_mtrr *mtrr_state = &vcpu->arch.mtrr_state;
> + bool mtrr_enabled = mtrr_is_enabled(mtrr_state);
> + u8 default_mtrr_type;
> + bool cd_ipat;
> + u8 cd_type;
> +
> + kvm_honors_guest_mtrrs_get_cd_memtype(vcpu, &cd_type, &cd_ipat);
> +
> + default_mtrr_type = mtrr_enabled ? mtrr_default_type(mtrr_state) :
> + mtrr_disabled_type(vcpu);
> +
> + if (cd_type != default_mtrr_type || cd_ipat)
> + return kvm_mtrr_zap_gfn_range(vcpu, gpa_to_gfn(0), gpa_to_gfn(~0ULL));
Why does this use use the MTRR version but the failure path does not? Ah, because
trying to allocate in the failure path will likely fail to allocate memory. With
a statically sized array, we can just special case the 0 => -1 case. Actually,
we can do that regardless, it just doesn't need a dedicated flag if we use an
array.
Using the MTRR version on failure (array is full) means that other vCPUs can see
that everything is being zapped and go straight to waitin.
> +
> + /*
> + * If mtrr is not enabled, it will go to zap all above if the default
Pronouns again. Maybe this?
/*
* The default MTRR type has already been checked above, if MTRRs are
* disabled there are no other MTRR types to consider.
*/
> + * type does not equal to cd_type;
> + * Or it has no need to zap if the default type equals to cd_type.
> + */
> + if (mtrr_enabled) {
To save some indentation:
if (!mtrr_enabled)
return;
> + if (prepare_zaplist_fixed_mtrr_of_non_type(vcpu, default_mtrr_type))
> + goto fail;
> +
> + if (prepare_zaplist_var_mtrr_of_non_type(vcpu, default_mtrr_type))
> + goto fail;
> +
> + kvm_zap_or_wait_mtrr_zap_list(vcpu->kvm);
> + }
> + return;
> +fail:
> + kvm_clear_mtrr_zap_list(vcpu->kvm);
> + /* resort to zapping all on failure*/
> + kvm_zap_gfn_range(vcpu->kvm, gpa_to_gfn(0), gpa_to_gfn(~0ULL));
> + return;
> }
> --
> 2.17.1
>
next prev parent reply other threads:[~2023-08-25 23:14 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-14 6:46 [PATCH v4 00/12] KVM: x86/mmu: refine memtype related mmu zap Yan Zhao
2023-07-14 6:50 ` [PATCH v4 01/12] KVM: x86/mmu: helpers to return if KVM honors guest MTRRs Yan Zhao
2023-10-07 7:00 ` Like Xu
2023-10-09 19:52 ` Sean Christopherson
2023-10-09 21:27 ` Sean Christopherson
2023-10-09 21:36 ` Sean Christopherson
2023-10-10 3:46 ` Yan Zhao
2023-10-11 0:08 ` Sean Christopherson
2023-10-11 1:47 ` Yan Zhao
2023-07-14 6:50 ` [PATCH v4 02/12] KVM: x86/mmu: Use KVM honors guest MTRRs helper in kvm_tdp_page_fault() Yan Zhao
2023-07-14 6:51 ` [PATCH v4 03/12] KVM: x86/mmu: Use KVM honors guest MTRRs helper when CR0.CD toggles Yan Zhao
2023-07-14 6:51 ` [PATCH v4 04/12] KVM: x86/mmu: Use KVM honors guest MTRRs helper when update mtrr Yan Zhao
2023-07-14 6:52 ` [PATCH v4 05/12] KVM: x86/mmu: zap KVM TDP when noncoherent DMA assignment starts/stops Yan Zhao
2023-07-14 6:52 ` [PATCH v4 06/12] KVM: x86/mmu: move TDP zaps from guest MTRRs update to CR0.CD toggling Yan Zhao
2023-07-14 6:53 ` [PATCH v4 07/12] KVM: VMX: drop IPAT in memtype when CD=1 for KVM_X86_QUIRK_CD_NW_CLEARED Yan Zhao
2023-08-25 21:43 ` Sean Christopherson
2023-09-04 7:41 ` Yan Zhao
2023-07-14 6:53 ` [PATCH v4 08/12] KVM: x86: centralize code to get CD=1 memtype when guest MTRRs are honored Yan Zhao
2023-08-25 21:46 ` Sean Christopherson
2023-09-04 7:46 ` Yan Zhao
2023-07-14 6:54 ` [PATCH v4 09/12] KVM: x86/mmu: serialize vCPUs to zap gfn " Yan Zhao
2023-08-25 22:47 ` Sean Christopherson
2023-09-04 8:24 ` Yan Zhao
2023-07-14 6:55 ` [PATCH v4 10/12] KVM: x86/mmu: fine-grained gfn zap " Yan Zhao
2023-08-25 23:13 ` Sean Christopherson [this message]
2023-09-04 8:37 ` Yan Zhao
2023-07-14 6:56 ` [PATCH v4 11/12] KVM: x86/mmu: split a single gfn zap range " Yan Zhao
2023-08-25 23:15 ` Sean Christopherson
2023-09-04 8:39 ` Yan Zhao
2023-07-14 6:56 ` [PATCH v4 12/12] KVM: x86/mmu: convert kvm_zap_gfn_range() to use shared mmu_lock in TDP MMU Yan Zhao
2023-08-25 21:34 ` Sean Christopherson
2023-09-04 7:31 ` Yan Zhao
2023-09-05 22:31 ` Sean Christopherson
2023-09-06 0:50 ` Yan Zhao
2023-08-25 23:17 ` [PATCH v4 00/12] KVM: x86/mmu: refine memtype related mmu zap Sean Christopherson
2023-09-04 8:48 ` Yan Zhao
2023-10-05 1:29 ` Sean Christopherson
2023-10-05 2:19 ` Huang, Kai
2023-10-05 2:28 ` Sean Christopherson
2023-10-06 0:50 ` Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZOk1n3ssdU7bXalP@google.com \
--to=seanjc@google.com \
--cc=chao.gao@intel.com \
--cc=kai.huang@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=robert.hoo.linux@gmail.com \
--cc=yan.y.zhao@intel.com \
--cc=yuan.yao@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).