[RFC,01/13] kvm: Enable MTRR to work with GFNs with perm bits
diff mbox series

Message ID 20191003212400.31130-2-rick.p.edgecombe@intel.com
State New
Headers show
Series
  • XOM for KVM guest userspace
Related show

Commit Message

Edgecombe, Rick P Oct. 3, 2019, 9:23 p.m. UTC
Mask gfn by maxphyaddr in kvm_mtrr_get_guest_memory_type so that the
guests view of gfn is used when high bits of the physical memory are
used as extra permissions bits. This supports the KVM XO feature.

TODO: Since MTRR is emulated using EPT permissions, the XO version of
the gpa range will not inherrit the MTRR type with this implementation.
There shouldn't be any legacy use of KVM XO, but hypothetically it could
interfere with the uncacheable MTRR type.

Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
---
 arch/x86/kvm/mtrr.c | 8 ++++++++
 1 file changed, 8 insertions(+)

Comments

Yu Zhang Oct. 14, 2019, 6:47 a.m. UTC | #1
On Thu, Oct 03, 2019 at 02:23:48PM -0700, Rick Edgecombe wrote:
> Mask gfn by maxphyaddr in kvm_mtrr_get_guest_memory_type so that the
> guests view of gfn is used when high bits of the physical memory are
> used as extra permissions bits. This supports the KVM XO feature.
> 
> TODO: Since MTRR is emulated using EPT permissions, the XO version of
> the gpa range will not inherrit the MTRR type with this implementation.
> There shouldn't be any legacy use of KVM XO, but hypothetically it could
> interfere with the uncacheable MTRR type.
> 
> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> ---
>  arch/x86/kvm/mtrr.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
> index 25ce3edd1872..da38f3b83e51 100644
> --- a/arch/x86/kvm/mtrr.c
> +++ b/arch/x86/kvm/mtrr.c
> @@ -621,6 +621,14 @@ u8 kvm_mtrr_get_guest_memory_type(struct kvm_vcpu *vcpu, gfn_t gfn)
>  	const int wt_wb_mask = (1 << MTRR_TYPE_WRBACK)
>  			       | (1 << MTRR_TYPE_WRTHROUGH);
>  
> +	/*
> +	 * Handle situations where gfn bits are used as permissions bits by
> +	 * masking KVMs view of the gfn with the guests physical address bits
> +	 * in order to match the guests view of physical address. For normal
> +	 * situations this will have no effect.
> +	 */
> +	gfn &= (1ULL << (cpuid_maxphyaddr(vcpu) - PAGE_SHIFT));
> +

Won't this break the MTRR calculation for normal gfns?
Are you suggesting use the same MTRR value for the XO range as the normal one's?
If so, may be we should use:

	if (guest_cpuid_has(vcpu, X86_FEATURE_KVM_XO))
		gfn &= ~(1ULL << (cpuid_maxphyaddr(vcpu) - PAGE_SHIFT));


>  	start = gfn_to_gpa(gfn);
>  	end = start + PAGE_SIZE;
>  
> -- 
> 2.17.1
> 

B.R.
Yu
Edgecombe, Rick P Oct. 14, 2019, 6:44 p.m. UTC | #2
On Mon, 2019-10-14 at 14:47 +0800, Yu Zhang wrote:
> On Thu, Oct 03, 2019 at 02:23:48PM -0700, Rick Edgecombe wrote:
> > Mask gfn by maxphyaddr in kvm_mtrr_get_guest_memory_type so that the
> > guests view of gfn is used when high bits of the physical memory are
> > used as extra permissions bits. This supports the KVM XO feature.
> > 
> > TODO: Since MTRR is emulated using EPT permissions, the XO version of
> > the gpa range will not inherrit the MTRR type with this implementation.
> > There shouldn't be any legacy use of KVM XO, but hypothetically it could
> > interfere with the uncacheable MTRR type.
> > 
> > Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> > ---
> >  arch/x86/kvm/mtrr.c | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
> > index 25ce3edd1872..da38f3b83e51 100644
> > --- a/arch/x86/kvm/mtrr.c
> > +++ b/arch/x86/kvm/mtrr.c
> > @@ -621,6 +621,14 @@ u8 kvm_mtrr_get_guest_memory_type(struct kvm_vcpu
> > *vcpu, gfn_t gfn)
> >  	const int wt_wb_mask = (1 << MTRR_TYPE_WRBACK)
> >  			       | (1 << MTRR_TYPE_WRTHROUGH);
> >  
> > +	/*
> > +	 * Handle situations where gfn bits are used as permissions bits by
> > +	 * masking KVMs view of the gfn with the guests physical address bits
> > +	 * in order to match the guests view of physical address. For normal
> > +	 * situations this will have no effect.
> > +	 */
> > +	gfn &= (1ULL << (cpuid_maxphyaddr(vcpu) - PAGE_SHIFT));
> > +
> 
> Won't this break the MTRR calculation for normal gfns?
> Are you suggesting use the same MTRR value for the XO range as the normal
> one's?
> If so, may be we should use:
> 
> 	if (guest_cpuid_has(vcpu, X86_FEATURE_KVM_XO))
> 		gfn &= ~(1ULL << (cpuid_maxphyaddr(vcpu) - PAGE_SHIFT));
> 
Yes you're right this is broken, but zeroing a bit beyond the max physical
address address should be ok here I think, so you shouldn't need the feature
check.

In any case, this logic will go away anyway after the suggestions to mask the
GPA soon after the exit. Then most of KVM can just operate on the guest view of
the GPA as normal.

Design wise, I think MTRR should affect the XO GPA's as well because if we are
going to pretend the XO bit is not a PFN bit, that would be expected. I am not
sure if it would actually break anything though unless someone did uncacheable
XO, so that could maybe also just be declared illegal.

> >  	start = gfn_to_gpa(gfn);
> >  	end = start + PAGE_SIZE;
> >  
> > -- 
> > 2.17.1
> > 
> 
> B.R.
> Yu

Patch
diff mbox series

diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kvm/mtrr.c
index 25ce3edd1872..da38f3b83e51 100644
--- a/arch/x86/kvm/mtrr.c
+++ b/arch/x86/kvm/mtrr.c
@@ -621,6 +621,14 @@  u8 kvm_mtrr_get_guest_memory_type(struct kvm_vcpu *vcpu, gfn_t gfn)
 	const int wt_wb_mask = (1 << MTRR_TYPE_WRBACK)
 			       | (1 << MTRR_TYPE_WRTHROUGH);
 
+	/*
+	 * Handle situations where gfn bits are used as permissions bits by
+	 * masking KVMs view of the gfn with the guests physical address bits
+	 * in order to match the guests view of physical address. For normal
+	 * situations this will have no effect.
+	 */
+	gfn &= (1ULL << (cpuid_maxphyaddr(vcpu) - PAGE_SHIFT));
+
 	start = gfn_to_gpa(gfn);
 	end = start + PAGE_SIZE;