On Thu, May 11, 2023 at 10:42:13AM +0800, Huang, Kai wrote:
> > >
> >
> > I agree shadow_memtype_mask is the right value to check but it's indeed
> > internal to kvm mmu.
> > Including "mmu/spte.h" will further include "mmu/mmu_internal.h"
> >
> > What about introduce kvm_mmu_memtye_effective() instead as below?
> >
>
> [...]
>
> >
> > +bool kvm_mmu_memtye_effective(struct kvm *kvm)
> > +{
> > + return shadow_memtype_mask;
> > +}
>
> I don't think it's a good name. shadow_memtype_mask doesn't mean any actual
> effective memtype, but just represent those bits that KVM can manipulate to get
> an effective memtype for the guest access.
>
> Instead, it should represent the hardware capability to be able to emulate
> guest's MTRR independent from host's MTRR. So, perhaps something like:
>
> bool kvm_mmu_guest_mtrr_emulatable();
What about kvm_mmu_cap_effective_guest_mtrr()?
Guest MTRR is always emulated with vMTRR.
>
> It's better if Sean can provide input here.
>
> (Btw, off this topic, I think it's even more reasonable to make
> shadow_memtype_mask only be meaningful when tdp_enabled is true, because the
> capability to override host MTRR and emulate guest MTRR should be only available
> when secondary MMU is turned on).
>
