On Wed, Jun 28, 2023 at 03:57:09PM -0700, Sean Christopherson wrote:
> 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
I added this patch because the memtype to use under CR0.CD=1 is determined by
vmx specific code (i.e. vmx.c), while mtrr.c is a common code for x86.
I don't know if it's good to assume what vmx.c will return as in below open code.
(e.g. if someone added IPAT bit for CR0.CD=1 under the quirk, and forgot
to update the code here, we actually need to zap everything rather than
zap only non-WB ranges).
That's why I want to introduce a helper and let vmx.c call into it.
(sorry, I didn't write a good commit message to explain the real intent).
> helper with out params (I *really* don't like out params :-) ).
I don't like the out params either. :)
I just don't know a better way to return the ipat in the helper.
>
> 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.
Yes, WANR_ON is a better way.
>
> > + *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)
It makes sence!
Thanks!
