nVMX: Fixes to run Xen as L1
v3 cover nVMX: Fixes to run Xen as L1
Minor changes to enable Xen as a L1 hypervisor.
Tested with a Haswell host, Xen-4.3 L1 and debian6 L2
v3:
* Add WARN_ON in nested_vmx_exit
* Rebase on top of 3.15-rc1
* Also noticed a new behavior which I think is related to
commit 36be0b9deb23161e KVM: x86: Add nested virtualization support for MPX On running L2, console gets filled up with -
vmwrite error: reg 2812 value 0 (err 12) ..
I will post a separate patch to get feedback, since these three patches have probably addressed all of reviewers' concerns
v2:
* Remove advertising single context invalidation for emulated invept Patch "KVM: nVMX: check for null vmcs12 when L1 does invept" from v1 is now obsolete and is removed
* Reorder patches "KVM: nVMX: Advertise support for interrupt acknowledgement" and "nVMX: Ack and write vector info to intr_info if L1 asks us to"
* Add commit description to 2/3 and change comment for nested_exit_intr_ack_set
Jan, I will send a separate unit-test patch
Bandan Das (3):
KVM: nVMX: Don't advertise single context invalidation for invept
KVM: nVMX: Ack and write vector info to intr_info if L1 asks us to
KVM: nVMX: Advertise support for interrupt acknowledgement
arch/x86/kvm/irq.c | 1 + arch/x86/kvm/vmx.c | 38 ++++++++++++++++++++++++++------------ 2 files changed, 27 insertions(+), 12 deletions(-)
Signature · 1 line
1.8.3.1
PATCH v3 1/3 KVM: nVMX: Don't advertise single context invalidation for invept
For single context invalidation, we fall through to global invalidation in handle_invept() except for one case - when the operand supplied by L1 is different from what we have in vmcs12. However, typically hypervisors will only call invept for the currently loaded eptp, so the condition will never be true.
--- arch/x86/kvm/vmx.c | 15 +++++---------- 1 file changed, 5 insertions(+), 10 deletions(-)
arch/x86/kvm/vmx.c +5 -10
@@ -2353,12 +2353,11 @@ static __init void nested_vmx_setup_ctls_msrs(void)VMX_EPT_INVEPT_BIT ; nested_vmx_ept_caps &= vmx_capability.ept;/* -* Since invept is completely emulated we support both global -* and context invalidation independent of what host cpu -* supports +* For nested guests, we don't do anything specific +* for single context invalidation. Hence, only advertise +* support for global context invalidation. */ - nested_vmx_ept_caps |=VMX_EPT_EXTENT_GLOBAL_BIT | -VMX_EPT_EXTENT_CONTEXT_BIT ; + nested_vmx_ept_caps |=VMX_EPT_EXTENT_GLOBAL_BIT ; }else nested_vmx_ept_caps =0 ;
@@ -6434,7 +6433,6 @@ static int handle_invept(struct kvm_vcpu *vcpu)struct {u64 eptp, gpa; } operand; -u64 eptp_mask = ((1ull <<51 ) -1 ) &PAGE_MASK ;if (!(nested_vmx_secondary_ctls_high &SECONDARY_EXEC_ENABLE_EPT ) || !(nested_vmx_ept_caps &VMX_EPT_INVEPT_BIT )) {
@@ -6474,16 +6472,13 @@ static int handle_invept(struct kvm_vcpu *vcpu) }switch (type) { -case VMX_EPT_EXTENT_CONTEXT : -if ((operand.eptp & eptp_mask) != - (nested_ept_get_cr3 (vcpu) & eptp_mask)) -break ;case VMX_EPT_EXTENT_GLOBAL :kvm_mmu_sync_roots (vcpu);kvm_mmu_flush_tlb (vcpu);nested_vmx_succeed (vcpu);break ;default : +/* Trap single context invalidation invept calls */ BUG_ON (1 );break ; }
Signature · 1 line
1.8.3.1
PATCH v3 2/3 KVM: nVMX: Ack and write vector info to intr_info if L1 asks us to
In reply to Bandan DasThis feature emulates the "Acknowledge interrupt on exit" behavior. We can safely emulate it for L1 to run L2 even if L0 itself has it disabled (to run L1).
--- arch/x86/kvm/irq.c | 1 + arch/x86/kvm/vmx.c | 18 ++++++++++++++++++ 2 files changed, 19 insertions(+)
arch/x86/kvm/irq.c +1 -0
@@ -113,6 +113,7 @@ int kvm_cpu_get_interrupt(struct kvm_vcpu *v)return kvm_get_apic_interrupt (v);/* APIC */ } +EXPORT_SYMBOL_GPL (kvm_cpu_get_interrupt);void kvm_inject_pending_timer_irqs (struct kvm_vcpu *vcpu) {
arch/x86/kvm/vmx.c +18 -0
@@ -4526,6 +4526,16 @@ static bool nested_exit_on_intr(struct kvm_vcpu *vcpu)PIN_BASED_EXT_INTR_MASK ; } +/* +* In nested virtualization, check if L1 has set +* VM_EXIT_ACK_INTR_ON_EXIT +*/ +static bool nested_exit_intr_ack_set (struct kvm_vcpu *vcpu) +{ +return get_vmcs12 (vcpu)->vm_exit_controls & +VM_EXIT_ACK_INTR_ON_EXIT ; +} +static bool nested_exit_on_nmi (struct kvm_vcpu *vcpu) { return get_vmcs12(vcpu)->pin_based_vm_exec_control &
@@ -8556,6 +8566,14 @@ static void nested_vmx_vmexit(struct kvm_vcpu *vcpu, u32 exit_reason,prepare_vmcs12 (vcpu, vmcs12, exit_reason, exit_intr_info, exit_qualification); +if ((exit_reason ==EXIT_REASON_EXTERNAL_INTERRUPT ) + &&nested_exit_intr_ack_set (vcpu)) { +int irq =kvm_cpu_get_interrupt (vcpu); +WARN_ON (irq <0 ); + vmcs12->vm_exit_intr_info = irq | +INTR_INFO_VALID_MASK |INTR_TYPE_EXT_INTR ; + } + trace_kvm_nested_vmexit_inject(vmcs12->vm_exit_reason, vmcs12->exit_qualification, vmcs12->idt_vectoring_info_field,
Signature · 1 line
1.8.3.1
PATCH v3 3/3 KVM: nVMX: Advertise support for interrupt acknowledgement
In reply to Bandan DasSome Type 1 hypervisors such as XEN won't enable VMX without it present
--- arch/x86/kvm/vmx.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
arch/x86/kvm/vmx.c +3 -2
@@ -2283,7 +2283,7 @@ static __init void nested_vmx_setup_ctls_msrs(void)rdmsr (MSR_IA32_VMX_EXIT_CTLS , nested_vmx_exit_ctls_low, nested_vmx_exit_ctls_high); nested_vmx_exit_ctls_low =VM_EXIT_ALWAYSON_WITHOUT_TRUE_MSR ; -/* Note that guest use of VM_EXIT_ACK_INTR_ON_EXIT is not supported. */ + nested_vmx_exit_ctls_high &=#ifdef CONFIG_X86_64 VM_EXIT_HOST_ADDR_SPACE_SIZE |
@@ -2291,7 +2291,8 @@ static __init void nested_vmx_setup_ctls_msrs(void)VM_EXIT_LOAD_IA32_PAT |VM_EXIT_SAVE_IA32_PAT ; nested_vmx_exit_ctls_high |=VM_EXIT_ALWAYSON_WITHOUT_TRUE_MSR |VM_EXIT_LOAD_IA32_EFER |VM_EXIT_SAVE_IA32_EFER | -VM_EXIT_SAVE_VMX_PREEMPTION_TIMER ; +VM_EXIT_SAVE_VMX_PREEMPTION_TIMER |VM_EXIT_ACK_INTR_ON_EXIT ; +if (vmx_mpx_supported ()) nested_vmx_exit_ctls_high |=VM_EXIT_CLEAR_BNDCFGS ;
Signature · 1 line
1.8.3.1
Marcelo Tosatti
AppliedQuoted 3 lines · Bandan Das
Minor changes to enable Xen as a L1 hypervisor.
Tested with a Haswell host, Xen-4.3 L1 and debian6 L2
Applied, thanks.