On Fri, Jun 16, 2023, Yan Zhao wrote:
> Move code in vmx.c to get cache disabled memtype when non-coherent DMA
> present to x86 common code.
>
> This is the preparation patch for later implementation of fine-grained gfn
> zap for CR0.CD toggles when guest MTRRs are honored.
>
> No functional change intended.
>
> Signed-off-by: Yan Zhao <yan.y.zhao@xxxxxxxxx>
> ---
> arch/x86/kvm/mtrr.c | 19 +++++++++++++++++++
> arch/x86/kvm/vmx/vmx.c | 10 +++++-----
> arch/x86/kvm/x86.h | 1 +
> 3 files changed, 25 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
> index 3ce58734ad22..b35dd0bc9cad 100644
> --- a/arch/x86/kvm/mtrr.c
> +++ b/arch/x86/kvm/mtrr.c
> @@ -721,3 +721,22 @@ bool kvm_mtrr_check_gfn_range_consistency(struct kvm_vcpu *vcpu, gfn_t gfn,
>
> return type == mtrr_default_type(mtrr_state);
> }
> +
> +void kvm_mtrr_get_cd_memory_type(struct kvm_vcpu *vcpu, u8 *type, bool *ipat)
Hmm, I'm not convinced that this logic is subtle enough to warrant a common
helper with out params (I *really* don't like out params :-) ).
UC, or more specifically CR0.CD=1 on VMX without the quirk, is a super special case,
because to faithfully emulatee "No Fill" mode, KVM needs to ignore guest PAT (stupid WC).
I don't love having the same logic/assumptions in multiple places, but the CR0.CD=1
behavior is so rigidly tied to what KVM must do to that I think trying to provide a
common helper makes the code more complex than it needs to be.
If we open code the logic in the MTRR helper, than I think it can be distilled
down to:
struct kvm_mtrr *mtrr_state = &vcpu->arch.mtrr_state;
bool mtrr_enabled = mtrr_is_enabled(mtrr_state);
u8 default_type;
/*
* Faithfully emulating CR0.CD=1 on VMX requires ignoring guest PAT, as
* WC in the PAT overrides UC in the MTRRs. Zap all SPTEs so that KVM
* will once again start honoring guest PAT.
*/
if (!kvm_check_has_quirk(vcpu->kvm, KVM_X86_QUIRK_CD_NW_CLEARED))
return kvm_mtrr_zap_gfn_range(vcpu, gpa_to_gfn(0), gpa_to_gfn(~0ULL));
default_type = mtrr_enabled ? mtrr_default_type(mtrr_state) :
mtrr_disabled_type(vcpu);
if (default_type != MTRR_TYPE_WRBACK)
return kvm_mtrr_zap_gfn_range(vcpu, gpa_to_gfn(0), gpa_to_gfn(~0ULL));
if (mtrr_enabled) {
if (gather_non_wb_fixed_mtrrs(vcpu, MTRR_TYPE_WRBACK))
goto fail;
if (gather_non_wb_var_mtrrs(vcpu, MTRR_TYPE_WRBACK))
goto fail;
kvm_zap_or_wait_mtrrs(vcpu->kvm);
}
and this patch goes away.
> +{
> + /*
> + * this routine is supposed to be called when guest mtrrs are honored
> + */
> + if (unlikely(!kvm_mmu_honors_guest_mtrrs(vcpu->kvm))) {
I don't think this is worth checking, e.g. this would be WARN-worthy if it weren't
for an otherwise benign race with device (un)assignment.
> + *type = MTRR_TYPE_WRBACK;
> + *ipat = true;
> + } else if (unlikely(!kvm_check_has_quirk(vcpu->kvm,
Eh, drop the "unlikely()" annotations. AIUI, they almost never provide actual
performance benefits, and I dislike unnecessarily speculating on what userspace
is doing when it comes to code (though I 100% agree that this definitely unlikely)
