[PATCH v2 0/3] vmx: miscellaneous cleanups

[PATCH v2 0/3] vmx: miscellaneous cleanups

[Bandan Das]

v1 posted here https://lkml.org/lkml/2016/7/20/605

v2:
1/3 : Replacing BUG_ONs with WARN_ONs is not necessary
2/3 : No change
3/3 : Remove the kvm parameter from two other functions
4/3 : Removed, although the spec says to do it, it can't be triggered

These are some very minor vmx cleanups.
2/4 is necessary for nested esx to be able to
successfully launch a guest of its own. Without single context
invalidation present, it just disables ept altogether.

Bandan Das (3):
  nvmx: remove comment about missing nested vpid support
  nvmx: mark ept single context invalidation as supported
  mmu: don't pass *kvm to spte_write_protect and spte_*_dirty

 arch/x86/kvm/mmu.c | 12 ++++++------
 arch/x86/kvm/vmx.c | 15 +++++++--------
 2 files changed, 13 insertions(+), 14 deletions(-)

-- 
2.5.5

[PATCH v2 1/3] nvmx: remove comment about missing nested vpid support

[Bandan Das]

Nested vpid is already supported and both single/global
modes are advertised to the guest

Signed-off-by: Bandan Das <bsd@redhat.com>
---
 arch/x86/kvm/vmx.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index df07a0a..1d5a3be 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2853,7 +2853,6 @@ static int vmx_get_vmx_msr(struct kvm_vcpu *vcpu, u32 msr_index, u64 *pdata)
 			vmx->nested.nested_vmx_secondary_ctls_high);
 		break;
 	case MSR_IA32_VMX_EPT_VPID_CAP:
-		/* Currently, no nested vpid support */
 		*pdata = vmx->nested.nested_vmx_ept_caps |
 			((u64)vmx->nested.nested_vmx_vpid_caps << 32);
 		break;
-- 
2.5.5

[PATCH v2 2/3] nvmx: mark ept single context invalidation as supported

[Bandan Das]

Commit 4b855078601f ("KVM: nVMX: Don't advertise single
context invalidation for invept") removed advertising
single context invalidation since the spec does not mandate it.
However, some hypervisors (such as ESX) require it to be present
before willing to use ept in a nested environment. Advertise it
and fallback to the global case.

Signed-off-by: Bandan Das <bsd@redhat.com>
---
 arch/x86/kvm/vmx.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 1d5a3be..205c4bd 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2717,12 +2717,8 @@ static void nested_vmx_setup_ctls_msrs(struct vcpu_vmx *vmx)
 			 VMX_EPTP_WB_BIT | VMX_EPT_2MB_PAGE_BIT |
 			 VMX_EPT_INVEPT_BIT;
 		vmx->nested.nested_vmx_ept_caps &= vmx_capability.ept;
-		/*
-		 * For nested guests, we don't do anything specific
-		 * for single context invalidation. Hence, only advertise
-		 * support for global context invalidation.
-		 */
-		vmx->nested.nested_vmx_ept_caps |= VMX_EPT_EXTENT_GLOBAL_BIT;
+		vmx->nested.nested_vmx_ept_caps |= VMX_EPT_EXTENT_GLOBAL_BIT |
+			VMX_EPT_EXTENT_CONTEXT_BIT;
 	} else
 		vmx->nested.nested_vmx_ept_caps = 0;
 
@@ -7457,12 +7453,16 @@ static int handle_invept(struct kvm_vcpu *vcpu)
 
 	switch (type) {
 	case VMX_EPT_EXTENT_GLOBAL:
+	/*
+	 * TODO: track mappings and invalidate
+	 * single context requests appropriately
+	 */
+	case VMX_EPT_EXTENT_CONTEXT:
 		kvm_mmu_sync_roots(vcpu);
 		kvm_make_request(KVM_REQ_TLB_FLUSH, vcpu);
 		nested_vmx_succeed(vcpu);
 		break;
 	default:
-		/* Trap single context invalidation invept calls */
 		BUG_ON(1);
 		break;
 	}
-- 
2.5.5

[PATCH v2 3/3] mmu: don't pass *kvm to spte_write_protect and spte_*_dirty

[Bandan Das]

That parameter isn't used in these functions,
it's probably a historical artifact.

Signed-off-by: Bandan Das <bsd@redhat.com>
---
 arch/x86/kvm/mmu.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 745a5f4..d65b3fe 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1205,7 +1205,7 @@ static void drop_large_spte(struct kvm_vcpu *vcpu, u64 *sptep)
  *
  * Return true if tlb need be flushed.
  */
-static bool spte_write_protect(struct kvm *kvm, u64 *sptep, bool pt_protect)
+static bool spte_write_protect(u64 *sptep, bool pt_protect)
 {
 	u64 spte = *sptep;
 
@@ -1231,12 +1231,12 @@ static bool __rmap_write_protect(struct kvm *kvm,
 	bool flush = false;
 
 	for_each_rmap_spte(rmap_head, &iter, sptep)
-		flush |= spte_write_protect(kvm, sptep, pt_protect);
+		flush |= spte_write_protect(sptep, pt_protect);
 
 	return flush;
 }
 
-static bool spte_clear_dirty(struct kvm *kvm, u64 *sptep)
+static bool spte_clear_dirty(u64 *sptep)
 {
 	u64 spte = *sptep;
 
@@ -1254,12 +1254,12 @@ static bool __rmap_clear_dirty(struct kvm *kvm, struct kvm_rmap_head *rmap_head)
 	bool flush = false;
 
 	for_each_rmap_spte(rmap_head, &iter, sptep)
-		flush |= spte_clear_dirty(kvm, sptep);
+		flush |= spte_clear_dirty(sptep);
 
 	return flush;
 }
 
-static bool spte_set_dirty(struct kvm *kvm, u64 *sptep)
+static bool spte_set_dirty(u64 *sptep)
 {
 	u64 spte = *sptep;
 
@@ -1277,7 +1277,7 @@ static bool __rmap_set_dirty(struct kvm *kvm, struct kvm_rmap_head *rmap_head)
 	bool flush = false;
 
 	for_each_rmap_spte(rmap_head, &iter, sptep)
-		flush |= spte_set_dirty(kvm, sptep);
+		flush |= spte_set_dirty(sptep);
 
 	return flush;
 }
-- 
2.5.5

Re: [PATCH v2 0/3] vmx: miscellaneous cleanups

[Paolo Bonzini]

On 02/08/2016 22:32, Bandan Das wrote:
> v1 posted here https://lkml.org/lkml/2016/7/20/605
> 
> v2:
> 1/3 : Replacing BUG_ONs with WARN_ONs is not necessary
> 2/3 : No change
> 3/3 : Remove the kvm parameter from two other functions
> 4/3 : Removed, although the spec says to do it, it can't be triggered
> 
> These are some very minor vmx cleanups.
> 2/4 is necessary for nested esx to be able to
> successfully launch a guest of its own. Without single context
> invalidation present, it just disables ept altogether.
> 
> Bandan Das (3):
>   nvmx: remove comment about missing nested vpid support
>   nvmx: mark ept single context invalidation as supported
>   mmu: don't pass *kvm to spte_write_protect and spte_*_dirty
> 
>  arch/x86/kvm/mmu.c | 12 ++++++------
>  arch/x86/kvm/vmx.c | 15 +++++++--------
>  2 files changed, 13 insertions(+), 14 deletions(-)
> 

Applied patches 1-2, while 3 will wait for 4.9.

Paolo