Tim/Keir: This patch series enable the nestedvmx support with all fixes to comments. patch 1-2 is a pre-cleanup. patch 3 is for nested vmx data structure patch 4 for nestedhvm ops patch 5, 7,8,9, 10, 11 is for VMX instruction emulation patch 6 for virtual VMCS data structure and access APIs. patch 12 for VMCS switching Patch 13 for vmreseume/launch emulation patch 14 for shadow control VMCS fields patch 15 for n1/n2 guest VMCS switch patch 16 for interrupt/exceptions patch 17 for nested vm exit patch 18 for lazy FPU and patch 19 VMXE bits in CR4 patch 20 for MSR handling and capability Thanks, Eddie _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Eddie Dong
2011-Jun-09 08:25 UTC
[Xen-devel] [PATCH 01 of 20] pre-cleanup1: Extend nhvm_vmcx_guest_intercepts_trap to include errcode to
# HG changeset patch
# User Eddie Dong <eddie.dong@intel.com>
# Date 1307607849 -28800
# Node ID 722771a2d429bbf5ab15e2979c0aa767a97caabe
# Parent 0c446850d85e654dfde039a0a1a5acd4e6b3c278
pre-cleanup1: Extend nhvm_vmcx_guest_intercepts_trap to include errcode to
assist decision of TRAP_page_fault in VMX.
Signed-off-by: Qing He <qing.he@intel.com>
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
diff -r 0c446850d85e -r 722771a2d429 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c Wed May 11 12:58:04 2011 +0100
+++ b/xen/arch/x86/hvm/hvm.c Thu Jun 09 16:24:09 2011 +0800
@@ -1152,7 +1152,7 @@ void hvm_inject_exception(unsigned int t
return;
}
- if ( nhvm_vmcx_guest_intercepts_trap(v, trapnr) )
+ if ( nhvm_vmcx_guest_intercepts_trap(v, trapnr, errcode) )
{
enum nestedhvm_vmexits nsret;
@@ -4175,10 +4175,10 @@ uint32_t nhvm_vcpu_asid(struct vcpu *v)
return -EOPNOTSUPP;
}
-int nhvm_vmcx_guest_intercepts_trap(struct vcpu *v, unsigned int trap)
+int nhvm_vmcx_guest_intercepts_trap(struct vcpu *v, unsigned int trap, int
errcode)
{
if (hvm_funcs.nhvm_vmcx_guest_intercepts_trap)
- return hvm_funcs.nhvm_vmcx_guest_intercepts_trap(v, trap);
+ return hvm_funcs.nhvm_vmcx_guest_intercepts_trap(v, trap, errcode);
return -EOPNOTSUPP;
}
diff -r 0c446850d85e -r 722771a2d429 xen/arch/x86/hvm/svm/nestedsvm.c
--- a/xen/arch/x86/hvm/svm/nestedsvm.c Wed May 11 12:58:04 2011 +0100
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c Thu Jun 09 16:24:09 2011 +0800
@@ -895,7 +895,7 @@ nsvm_vmcb_guest_intercepts_exitcode(stru
}
int
-nsvm_vmcb_guest_intercepts_trap(struct vcpu *v, unsigned int trapnr)
+nsvm_vmcb_guest_intercepts_trap(struct vcpu *v, unsigned int trapnr, int
errcode)
{
return nsvm_vmcb_guest_intercepts_exitcode(v,
guest_cpu_user_regs(), VMEXIT_EXCEPTION_DE + trapnr);
diff -r 0c446850d85e -r 722771a2d429 xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h Wed May 11 12:58:04 2011 +0100
+++ b/xen/include/asm-x86/hvm/hvm.h Thu Jun 09 16:24:09 2011 +0800
@@ -164,7 +164,8 @@ struct hvm_function_table {
uint64_t (*nhvm_vcpu_guestcr3)(struct vcpu *v);
uint64_t (*nhvm_vcpu_hostcr3)(struct vcpu *v);
uint32_t (*nhvm_vcpu_asid)(struct vcpu *v);
- int (*nhvm_vmcx_guest_intercepts_trap)(struct vcpu *v, unsigned int
trapnr);
+ int (*nhvm_vmcx_guest_intercepts_trap)(struct vcpu *v,
+ unsigned int trapnr, int errcode);
bool_t (*nhvm_vmcx_hap_enabled)(struct vcpu *v);
@@ -443,7 +444,8 @@ uint64_t nhvm_vcpu_hostcr3(struct vcpu *
uint32_t nhvm_vcpu_asid(struct vcpu *v);
/* returns true, when l1 guest intercepts the specified trap */
-int nhvm_vmcx_guest_intercepts_trap(struct vcpu *v, unsigned int trapnr);
+int nhvm_vmcx_guest_intercepts_trap(struct vcpu *v,
+ unsigned int trapnr, int errcode);
/* returns true when l1 guest wants to use hap to run l2 guest */
bool_t nhvm_vmcx_hap_enabled(struct vcpu *v);
diff -r 0c446850d85e -r 722771a2d429 xen/include/asm-x86/hvm/svm/nestedsvm.h
--- a/xen/include/asm-x86/hvm/svm/nestedsvm.h Wed May 11 12:58:04 2011 +0100
+++ b/xen/include/asm-x86/hvm/svm/nestedsvm.h Thu Jun 09 16:24:09 2011 +0800
@@ -114,7 +114,8 @@ uint64_t nsvm_vcpu_hostcr3(struct vcpu *
uint32_t nsvm_vcpu_asid(struct vcpu *v);
int nsvm_vmcb_guest_intercepts_exitcode(struct vcpu *v,
struct cpu_user_regs *regs, uint64_t exitcode);
-int nsvm_vmcb_guest_intercepts_trap(struct vcpu *v, unsigned int trapnr);
+int nsvm_vmcb_guest_intercepts_trap(struct vcpu *v, unsigned int trapnr,
+ int errcode);
bool_t nsvm_vmcb_hap_enabled(struct vcpu *v);
enum hvm_intblk nsvm_intr_blocked(struct vcpu *v);
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Eddie Dong
2011-Jun-09 08:25 UTC
[Xen-devel] [PATCH 02 of 20] pre-cleanup2: Move IDT_VECTORING processing code out of intr_assist
# HG changeset patch
# User Eddie Dong <eddie.dong@intel.com>
# Date 1307607849 -28800
# Node ID dbf54a855530dc831ee975d8f090b1f06dbd62b1
# Parent 722771a2d429bbf5ab15e2979c0aa767a97caabe
pre-cleanup2: Move IDT_VECTORING processing code out of intr_assist.
Signed-off-by: Qing He <qing.he@intel.com>
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
diff -r 722771a2d429 -r dbf54a855530 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vmx.c Thu Jun 09 16:24:09 2011 +0800
@@ -2098,6 +2098,33 @@ static int vmx_handle_eoi_write(void)
return 0;
}
+static void vmx_idtv_reinject(unsigned long idtv_info)
+{
+
+ /* Event delivery caused this intercept? Queue for redelivery. */
+ if ( unlikely(idtv_info & INTR_INFO_VALID_MASK) )
+ {
+ if ( hvm_event_needs_reinjection((idtv_info>>8)&7,
idtv_info&0xff) )
+ {
+ /* See SDM 3B 25.7.1.1 and .2 for info about masking resvd bits. */
+ __vmwrite(VM_ENTRY_INTR_INFO,
+ idtv_info & ~INTR_INFO_RESVD_BITS_MASK);
+ if ( idtv_info & INTR_INFO_DELIVER_CODE_MASK )
+ __vmwrite(VM_ENTRY_EXCEPTION_ERROR_CODE,
+ __vmread(IDT_VECTORING_ERROR_CODE));
+ }
+
+ /*
+ * Clear NMI-blocking interruptibility info if an NMI delivery faulted.
+ * Re-delivery will re-set it (see SDM 3B 25.7.1.2).
+ */
+ if ( (idtv_info & INTR_INFO_INTR_TYPE_MASK) ==
(X86_EVENTTYPE_NMI<<8) )
+ __vmwrite(GUEST_INTERRUPTIBILITY_INFO,
+ __vmread(GUEST_INTERRUPTIBILITY_INFO) &
+ ~VMX_INTR_SHADOW_NMI);
+ }
+}
+
asmlinkage void vmx_vmexit_handler(struct cpu_user_regs *regs)
{
unsigned int exit_reason, idtv_info, intr_info = 0, vector = 0;
@@ -2187,30 +2214,9 @@ asmlinkage void vmx_vmexit_handler(struc
hvm_maybe_deassert_evtchn_irq();
- /* Event delivery caused this intercept? Queue for redelivery. */
idtv_info = __vmread(IDT_VECTORING_INFO);
- if ( unlikely(idtv_info & INTR_INFO_VALID_MASK) &&
- (exit_reason != EXIT_REASON_TASK_SWITCH) )
- {
- if ( hvm_event_needs_reinjection((idtv_info>>8)&7,
idtv_info&0xff) )
- {
- /* See SDM 3B 25.7.1.1 and .2 for info about masking resvd bits. */
- __vmwrite(VM_ENTRY_INTR_INFO,
- idtv_info & ~INTR_INFO_RESVD_BITS_MASK);
- if ( idtv_info & INTR_INFO_DELIVER_CODE_MASK )
- __vmwrite(VM_ENTRY_EXCEPTION_ERROR_CODE,
- __vmread(IDT_VECTORING_ERROR_CODE));
- }
-
- /*
- * Clear NMI-blocking interruptibility info if an NMI delivery faulted.
- * Re-delivery will re-set it (see SDM 3B 25.7.1.2).
- */
- if ( (idtv_info & INTR_INFO_INTR_TYPE_MASK) ==
(X86_EVENTTYPE_NMI<<8) )
- __vmwrite(GUEST_INTERRUPTIBILITY_INFO,
- __vmread(GUEST_INTERRUPTIBILITY_INFO) &
- ~VMX_INTR_SHADOW_NMI);
- }
+ if ( exit_reason != EXIT_REASON_TASK_SWITCH )
+ vmx_idtv_reinject(idtv_info);
switch ( exit_reason )
{
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Eddie Dong
2011-Jun-09 08:25 UTC
[Xen-devel] [PATCH 03 of 20] Add data structure for nestedvmx
# HG changeset patch
# User Eddie Dong <eddie.dong@intel.com>
# Date 1307607849 -28800
# Node ID 0a3635cac6330fbb3577fdc575abca1677cd6492
# Parent dbf54a855530dc831ee975d8f090b1f06dbd62b1
Add data structure for nestedvmx
Signed-off-by: Qing He <qing.he@intel.com>
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
diff -r dbf54a855530 -r 0a3635cac633 xen/include/asm-x86/hvm/vcpu.h
--- a/xen/include/asm-x86/hvm/vcpu.h Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/include/asm-x86/hvm/vcpu.h Thu Jun 09 16:24:09 2011 +0800
@@ -24,6 +24,7 @@
#include <asm/hvm/io.h>
#include <asm/hvm/vlapic.h>
#include <asm/hvm/vmx/vmcs.h>
+#include <asm/hvm/vmx/vvmx.h>
#include <asm/hvm/svm/vmcb.h>
#include <asm/hvm/svm/nestedsvm.h>
#include <asm/mtrr.h>
@@ -57,6 +58,7 @@ struct nestedvcpu {
/* SVM/VMX arch specific */
union {
struct nestedsvm nsvm;
+ struct nestedvmx nvmx;
} u;
bool_t nv_flushp2m; /* True, when p2m table must be flushed */
diff -r dbf54a855530 -r 0a3635cac633 xen/include/asm-x86/hvm/vmx/vvmx.h
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800
@@ -0,0 +1,38 @@
+
+/*
+ * vvmx.h: Support virtual VMX for nested virtualization.
+ *
+ * Copyright (c) 2010, Intel Corporation.
+ * Author: Qing He <qing.he@intel.com>
+ * Eddie Dong <eddie.dong@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ *
+ */
+#ifndef __ASM_X86_HVM_VVMX_H__
+#define __ASM_X86_HVM_VVMX_H__
+
+struct nestedvmx {
+ paddr_t vmxon_region_pa;
+ void *iobitmap[2]; /* map (va) of L1 guest I/O bitmap */
+ /* deferred nested interrupt */
+ struct {
+ unsigned long intr_info;
+ u32 error_code;
+ } intr;
+};
+
+#define vcpu_2_nvmx(v) (vcpu_nestedhvm(v).u.nvmx)
+#endif /* __ASM_X86_HVM_VVMX_H__ */
+
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
# HG changeset patch
# User Eddie Dong <eddie.dong@intel.com>
# Date 1307607849 -28800
# Node ID fc714c0def41317e7aad3dc6e675be7d6d61600f
# Parent 0a3635cac6330fbb3577fdc575abca1677cd6492
Add APIs for nestedhvm_ops.
Signed-off-by: Qing He <qing.he@intel.com>
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
diff -r 0a3635cac633 -r fc714c0def41 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/hvm.c Thu Jun 09 16:24:09 2011 +0800
@@ -3502,7 +3502,7 @@ long do_hvm_op(unsigned long op, XEN_GUE
/* Remove the check below once we have
* shadow-on-shadow.
*/
- if ( !paging_mode_hap(d) && a.value )
+ if ( cpu_has_svm && !paging_mode_hap(d) &&
a.value )
rc = -EINVAL;
/* Set up NHVM state for any vcpus that are already up */
if ( !d->arch.hvm_domain.params[HVM_PARAM_NESTEDHVM] )
diff -r 0a3635cac633 -r fc714c0def41 xen/arch/x86/hvm/vmx/Makefile
--- a/xen/arch/x86/hvm/vmx/Makefile Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/Makefile Thu Jun 09 16:24:09 2011 +0800
@@ -4,3 +4,4 @@ obj-y += realmode.o
obj-y += vmcs.o
obj-y += vmx.o
obj-y += vpmu_core2.o
+obj-y += vvmx.o
diff -r 0a3635cac633 -r fc714c0def41 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vmx.c Thu Jun 09 16:24:09 2011 +0800
@@ -1407,7 +1407,13 @@ static struct hvm_function_table __read_
.invlpg_intercept = vmx_invlpg_intercept,
.set_uc_mode = vmx_set_uc_mode,
.set_info_guest = vmx_set_info_guest,
- .set_rdtsc_exiting = vmx_set_rdtsc_exiting
+ .set_rdtsc_exiting = vmx_set_rdtsc_exiting,
+ .nhvm_vcpu_initialise = nvmx_vcpu_initialise,
+ .nhvm_vcpu_destroy = nvmx_vcpu_destroy,
+ .nhvm_vcpu_reset = nvmx_vcpu_reset,
+ .nhvm_vcpu_guestcr3 = nvmx_vcpu_guestcr3,
+ .nhvm_vcpu_hostcr3 = nvmx_vcpu_hostcr3,
+ .nhvm_vcpu_asid = nvmx_vcpu_asid
};
struct hvm_function_table * __init start_vmx(void)
diff -r 0a3635cac633 -r fc714c0def41 xen/arch/x86/hvm/vmx/vvmx.c
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/arch/x86/hvm/vmx/vvmx.c Thu Jun 09 16:24:09 2011 +0800
@@ -0,0 +1,88 @@
+/*
+ * vvmx.c: Support virtual VMX for nested virtualization.
+ *
+ * Copyright (c) 2010, Intel Corporation.
+ * Author: Qing He <qing.he@intel.com>
+ * Eddie Dong <eddie.dong@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ *
+ */
+
+#include <xen/config.h>
+#include <asm/types.h>
+#include <asm/p2m.h>
+#include <asm/hvm/vmx/vmx.h>
+#include <asm/hvm/vmx/vvmx.h>
+
+int nvmx_vcpu_initialise(struct vcpu *v)
+{
+ struct nestedvmx *nvmx = &vcpu_2_nvmx(v);
+ struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
+
+ nvcpu->nv_n2vmcx = alloc_xenheap_page();
+ if ( !nvcpu->nv_n2vmcx )
+ {
+ gdprintk(XENLOG_ERR, "nest: allocation for shadow vmcs
failed\n");
+ goto out;
+ }
+ nvmx->vmxon_region_pa = 0;
+ nvcpu->nv_vvmcx = NULL;
+ nvcpu->nv_vvmcxaddr = VMCX_EADDR;
+ nvmx->intr.intr_info = 0;
+ nvmx->intr.error_code = 0;
+ nvmx->iobitmap[0] = NULL;
+ nvmx->iobitmap[1] = NULL;
+ return 0;
+out:
+ return -ENOMEM;
+}
+
+void nvmx_vcpu_destroy(struct vcpu *v)
+{
+ struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
+
+ if ( nvcpu->nv_n2vmcx ) {
+ __vmpclear(virt_to_maddr(nvcpu->nv_n2vmcx));
+ free_xenheap_page(nvcpu->nv_n2vmcx);
+ nvcpu->nv_n2vmcx = NULL;
+ }
+}
+
+int nvmx_vcpu_reset(struct vcpu *v)
+{
+ return 0;
+}
+
+uint64_t nvmx_vcpu_guestcr3(struct vcpu *v)
+{
+ /* TODO */
+ ASSERT(0);
+ return 0;
+}
+
+uint64_t nvmx_vcpu_hostcr3(struct vcpu *v)
+{
+ /* TODO */
+ ASSERT(0);
+ return 0;
+}
+
+uint32_t nvmx_vcpu_asid(struct vcpu *v)
+{
+ /* TODO */
+ ASSERT(0);
+ return 0;
+}
+
diff -r 0a3635cac633 -r fc714c0def41 xen/include/asm-x86/hvm/vmx/vvmx.h
--- a/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800
@@ -34,5 +34,13 @@ struct nestedvmx {
};
#define vcpu_2_nvmx(v) (vcpu_nestedhvm(v).u.nvmx)
+
+int nvmx_vcpu_initialise(struct vcpu *v);
+void nvmx_vcpu_destroy(struct vcpu *v);
+int nvmx_vcpu_reset(struct vcpu *v);
+uint64_t nvmx_vcpu_guestcr3(struct vcpu *v);
+uint64_t nvmx_vcpu_hostcr3(struct vcpu *v);
+uint32_t nvmx_vcpu_asid(struct vcpu *v);
+
#endif /* __ASM_X86_HVM_VVMX_H__ */
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Eddie Dong
2011-Jun-09 08:25 UTC
[Xen-devel] [PATCH 05 of 20] Emulation of guest VMXON/OFF instruction
# HG changeset patch
# User Eddie Dong <eddie.dong@intel.com>
# Date 1307607849 -28800
# Node ID 5bf2e7013d33cd5872ba2a4c18f663dc03eb94a9
# Parent fc714c0def41317e7aad3dc6e675be7d6d61600f
Emulation of guest VMXON/OFF instruction.
Signed-off-by: Qing He <qing.he@intel.com>
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
diff -r fc714c0def41 -r 5bf2e7013d33 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vmx.c Thu Jun 09 16:24:09 2011 +0800
@@ -2434,6 +2434,16 @@ asmlinkage void vmx_vmexit_handler(struc
break;
}
+ case EXIT_REASON_VMXOFF:
+ if ( nvmx_handle_vmxoff(regs) == X86EMUL_OKAY )
+ update_guest_eip();
+ break;
+
+ case EXIT_REASON_VMXON:
+ if ( nvmx_handle_vmxon(regs) == X86EMUL_OKAY )
+ update_guest_eip();
+ break;
+
case EXIT_REASON_MWAIT_INSTRUCTION:
case EXIT_REASON_MONITOR_INSTRUCTION:
case EXIT_REASON_VMCLEAR:
@@ -2443,8 +2453,6 @@ asmlinkage void vmx_vmexit_handler(struc
case EXIT_REASON_VMREAD:
case EXIT_REASON_VMRESUME:
case EXIT_REASON_VMWRITE:
- case EXIT_REASON_VMXOFF:
- case EXIT_REASON_VMXON:
case EXIT_REASON_GETSEC:
case EXIT_REASON_INVEPT:
case EXIT_REASON_INVVPID:
diff -r fc714c0def41 -r 5bf2e7013d33 xen/arch/x86/hvm/vmx/vvmx.c
--- a/xen/arch/x86/hvm/vmx/vvmx.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vvmx.c Thu Jun 09 16:24:09 2011 +0800
@@ -86,3 +86,229 @@ uint32_t nvmx_vcpu_asid(struct vcpu *v)
return 0;
}
+enum x86_segment sreg_to_index[] = {
+ [VMX_SREG_ES] = x86_seg_es,
+ [VMX_SREG_CS] = x86_seg_cs,
+ [VMX_SREG_SS] = x86_seg_ss,
+ [VMX_SREG_DS] = x86_seg_ds,
+ [VMX_SREG_FS] = x86_seg_fs,
+ [VMX_SREG_GS] = x86_seg_gs,
+};
+
+struct vmx_inst_decoded {
+#define VMX_INST_MEMREG_TYPE_MEMORY 0
+#define VMX_INST_MEMREG_TYPE_REG 1
+ int type;
+ union {
+ struct {
+ unsigned long mem;
+ unsigned int len;
+ };
+ enum vmx_regs_enc reg1;
+ };
+
+ enum vmx_regs_enc reg2;
+};
+
+enum vmx_ops_result {
+ VMSUCCEED,
+ VMFAIL_VALID,
+ VMFAIL_INVALID,
+};
+
+#define CASE_GET_REG(REG, reg) \
+ case VMX_REG_ ## REG: value = regs->reg; break
+
+static unsigned long reg_read(struct cpu_user_regs *regs,
+ enum vmx_regs_enc index)
+{
+ unsigned long value = 0;
+
+ switch ( index ) {
+ CASE_GET_REG(RAX, eax);
+ CASE_GET_REG(RCX, ecx);
+ CASE_GET_REG(RDX, edx);
+ CASE_GET_REG(RBX, ebx);
+ CASE_GET_REG(RBP, ebp);
+ CASE_GET_REG(RSI, esi);
+ CASE_GET_REG(RDI, edi);
+ CASE_GET_REG(RSP, esp);
+#ifdef CONFIG_X86_64
+ CASE_GET_REG(R8, r8);
+ CASE_GET_REG(R9, r9);
+ CASE_GET_REG(R10, r10);
+ CASE_GET_REG(R11, r11);
+ CASE_GET_REG(R12, r12);
+ CASE_GET_REG(R13, r13);
+ CASE_GET_REG(R14, r14);
+ CASE_GET_REG(R15, r15);
+#endif
+ default:
+ break;
+ }
+
+ return value;
+}
+
+static int vmx_inst_check_privilege(struct cpu_user_regs *regs, int
vmxop_check)
+{
+ struct vcpu *v = current;
+ struct segment_register cs;
+
+ hvm_get_segment_register(v, x86_seg_cs, &cs);
+
+ if ( vmxop_check )
+ {
+ if ( !(v->arch.hvm_vcpu.guest_cr[0] & X86_CR0_PE) ||
+ !(v->arch.hvm_vcpu.guest_cr[4] & X86_CR4_VMXE) )
+ goto invalid_op;
+ }
+ else if ( !vcpu_2_nvmx(v).vmxon_region_pa )
+ goto invalid_op;
+
+ if ( (regs->eflags & X86_EFLAGS_VM) ||
+ (hvm_long_mode_enabled(v) && cs.attr.fields.l == 0) )
+ goto invalid_op;
+ /* TODO: check vmx operation mode */
+
+ if ( (cs.sel & 3) > 0 )
+ goto gp_fault;
+
+ return X86EMUL_OKAY;
+
+invalid_op:
+ gdprintk(XENLOG_ERR, "vmx_inst_check_privilege: invalid_op\n");
+ hvm_inject_exception(TRAP_invalid_op, 0, 0);
+ return X86EMUL_EXCEPTION;
+
+gp_fault:
+ gdprintk(XENLOG_ERR, "vmx_inst_check_privilege: gp_fault\n");
+ hvm_inject_exception(TRAP_gp_fault, 0, 0);
+ return X86EMUL_EXCEPTION;
+}
+
+static int decode_vmx_inst(struct cpu_user_regs *regs,
+ struct vmx_inst_decoded *decode,
+ unsigned long *poperandS, int vmxon_check)
+{
+ struct vcpu *v = current;
+ union vmx_inst_info info;
+ struct segment_register seg;
+ unsigned long base, index, seg_base, disp, offset;
+ int scale, size;
+
+ if ( vmx_inst_check_privilege(regs, vmxon_check) != X86EMUL_OKAY )
+ return X86EMUL_EXCEPTION;
+
+ info.word = __vmread(VMX_INSTRUCTION_INFO);
+
+ if ( info.fields.memreg ) {
+ decode->type = VMX_INST_MEMREG_TYPE_REG;
+ decode->reg1 = info.fields.reg1;
+ if ( poperandS != NULL )
+ *poperandS = reg_read(regs, decode->reg1);
+ }
+ else
+ {
+ decode->type = VMX_INST_MEMREG_TYPE_MEMORY;
+ if ( info.fields.segment > 5 )
+ goto gp_fault;
+ hvm_get_segment_register(v, sreg_to_index[info.fields.segment],
&seg);
+ seg_base = seg.base;
+
+ base = info.fields.base_reg_invalid ? 0 :
+ reg_read(regs, info.fields.base_reg);
+
+ index = info.fields.index_reg_invalid ? 0 :
+ reg_read(regs, info.fields.index_reg);
+
+ scale = 1 << info.fields.scaling;
+
+ disp = __vmread(EXIT_QUALIFICATION);
+
+ size = 1 << (info.fields.addr_size + 1);
+
+ offset = base + index * scale + disp;
+ if ( (offset > seg.limit || offset + size > seg.limit) &&
+ (!hvm_long_mode_enabled(v) || info.fields.segment == VMX_SREG_GS) )
+ goto gp_fault;
+
+ if ( poperandS != NULL &&
+ hvm_copy_from_guest_virt(poperandS, seg_base + offset, size, 0)
+ != HVMCOPY_okay )
+ return X86EMUL_EXCEPTION;
+ decode->mem = seg_base + offset;
+ decode->len = size;
+ }
+
+ decode->reg2 = info.fields.reg2;
+
+ return X86EMUL_OKAY;
+
+gp_fault:
+ hvm_inject_exception(TRAP_gp_fault, 0, 0);
+ return X86EMUL_EXCEPTION;
+}
+
+static void vmreturn(struct cpu_user_regs *regs, enum vmx_ops_result ops_res)
+{
+ unsigned long eflags = regs->eflags;
+ unsigned long mask = X86_EFLAGS_CF | X86_EFLAGS_PF | X86_EFLAGS_AF |
+ X86_EFLAGS_ZF | X86_EFLAGS_SF | X86_EFLAGS_OF;
+
+ eflags &= ~mask;
+
+ switch ( ops_res ) {
+ case VMSUCCEED:
+ break;
+ case VMFAIL_VALID:
+ /* TODO: error number, useful for guest VMM debugging */
+ eflags |= X86_EFLAGS_ZF;
+ break;
+ case VMFAIL_INVALID:
+ default:
+ eflags |= X86_EFLAGS_CF;
+ break;
+ }
+
+ regs->eflags = eflags;
+}
+
+/*
+ * VMX instructions handling
+ */
+
+int nvmx_handle_vmxon(struct cpu_user_regs *regs)
+{
+ struct vcpu *v=current;
+ struct nestedvmx *nvmx = &vcpu_2_nvmx(v);
+ struct vmx_inst_decoded decode;
+ unsigned long gpa = 0;
+ int rc;
+
+ rc = decode_vmx_inst(regs, &decode, &gpa, 1);
+ if ( rc != X86EMUL_OKAY )
+ return rc;
+
+ nvmx->vmxon_region_pa = gpa;
+ vmreturn(regs, VMSUCCEED);
+
+ return X86EMUL_OKAY;
+}
+
+int nvmx_handle_vmxoff(struct cpu_user_regs *regs)
+{
+ struct vcpu *v=current;
+ struct nestedvmx *nvmx = &vcpu_2_nvmx(v);
+ int rc;
+
+ rc = vmx_inst_check_privilege(regs, 0);
+ if ( rc != X86EMUL_OKAY )
+ return rc;
+
+ nvmx->vmxon_region_pa = 0;
+
+ vmreturn(regs, VMSUCCEED);
+ return X86EMUL_OKAY;
+}
+
diff -r fc714c0def41 -r 5bf2e7013d33 xen/include/asm-x86/hvm/vmx/vvmx.h
--- a/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800
@@ -35,6 +35,58 @@ struct nestedvmx {
#define vcpu_2_nvmx(v) (vcpu_nestedhvm(v).u.nvmx)
+/*
+ * Encode of VMX instructions base on Table 24-11 & 24-12 of SDM 3B
+ */
+
+enum vmx_regs_enc {
+ VMX_REG_RAX,
+ VMX_REG_RCX,
+ VMX_REG_RDX,
+ VMX_REG_RBX,
+ VMX_REG_RSP,
+ VMX_REG_RBP,
+ VMX_REG_RSI,
+ VMX_REG_RDI,
+#ifdef CONFIG_X86_64
+ VMX_REG_R8,
+ VMX_REG_R9,
+ VMX_REG_R10,
+ VMX_REG_R11,
+ VMX_REG_R12,
+ VMX_REG_R13,
+ VMX_REG_R14,
+ VMX_REG_R15,
+#endif
+};
+
+enum vmx_sregs_enc {
+ VMX_SREG_ES,
+ VMX_SREG_CS,
+ VMX_SREG_SS,
+ VMX_SREG_DS,
+ VMX_SREG_FS,
+ VMX_SREG_GS,
+};
+
+union vmx_inst_info {
+ struct {
+ unsigned int scaling :2; /* bit 0-1 */
+ unsigned int __rsvd0 :1; /* bit 2 */
+ unsigned int reg1 :4; /* bit 3-6 */
+ unsigned int addr_size :3; /* bit 7-9 */
+ unsigned int memreg :1; /* bit 10 */
+ unsigned int __rsvd1 :4; /* bit 11-14 */
+ unsigned int segment :3; /* bit 15-17 */
+ unsigned int index_reg :4; /* bit 18-21 */
+ unsigned int index_reg_invalid :1; /* bit 22 */
+ unsigned int base_reg :4; /* bit 23-26 */
+ unsigned int base_reg_invalid :1; /* bit 27 */
+ unsigned int reg2 :4; /* bit 28-31 */
+ } fields;
+ u32 word;
+};
+
int nvmx_vcpu_initialise(struct vcpu *v);
void nvmx_vcpu_destroy(struct vcpu *v);
int nvmx_vcpu_reset(struct vcpu *v);
@@ -42,5 +94,7 @@ uint64_t nvmx_vcpu_guestcr3(struct vcpu
uint64_t nvmx_vcpu_hostcr3(struct vcpu *v);
uint32_t nvmx_vcpu_asid(struct vcpu *v);
+int nvmx_handle_vmxon(struct cpu_user_regs *regs);
+int nvmx_handle_vmxoff(struct cpu_user_regs *regs);
#endif /* __ASM_X86_HVM_VVMX_H__ */
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Eddie Dong
2011-Jun-09 08:25 UTC
[Xen-devel] [PATCH 06 of 20] Define structure and access APIs for virtual VMCS
# HG changeset patch
# User Eddie Dong <eddie.dong@intel.com>
# Date 1307607849 -28800
# Node ID fcdfd43259d6f6d25ba80d0480bdf3d9cc2ddb87
# Parent 5bf2e7013d33cd5872ba2a4c18f663dc03eb94a9
Define structure and access APIs for virtual VMCS.
Signed-off-by: Qing He <qing.he@intel.com>
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
diff -r 5bf2e7013d33 -r fcdfd43259d6 xen/arch/x86/hvm/vmx/vvmx.c
--- a/xen/arch/x86/hvm/vmx/vvmx.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vvmx.c Thu Jun 09 16:24:09 2011 +0800
@@ -119,6 +119,84 @@ enum vmx_ops_result {
#define CASE_GET_REG(REG, reg) \
case VMX_REG_ ## REG: value = regs->reg; break
+static int vvmcs_offset(u32 width, u32 type, u32 index)
+{
+ int offset;
+
+ offset = (index & 0x1f) | type << 5 | width << 7;
+
+ if ( offset == 0 ) /* vpid */
+ offset = 0x3f;
+
+ return offset;
+}
+
+u64 __get_vvmcs(void *vvmcs, u32 vmcs_encoding)
+{
+ union vmcs_encoding enc;
+ u64 *content = (u64 *) vvmcs;
+ int offset;
+ u64 res;
+
+ enc.word = vmcs_encoding;
+ offset = vvmcs_offset(enc.width, enc.type, enc.index);
+ res = content[offset];
+
+ switch ( enc.width ) {
+ case VVMCS_WIDTH_16:
+ res &= 0xffff;
+ break;
+ case VVMCS_WIDTH_64:
+ if ( enc.access_type )
+ res >>= 32;
+ break;
+ case VVMCS_WIDTH_32:
+ res &= 0xffffffff;
+ break;
+ case VVMCS_WIDTH_NATURAL:
+ default:
+ break;
+ }
+
+ return res;
+}
+
+void __set_vvmcs(void *vvmcs, u32 vmcs_encoding, u64 val)
+{
+ union vmcs_encoding enc;
+ u64 *content = (u64 *) vvmcs;
+ int offset;
+ u64 res;
+
+ enc.word = vmcs_encoding;
+ offset = vvmcs_offset(enc.width, enc.type, enc.index);
+ res = content[offset];
+
+ switch ( enc.width ) {
+ case VVMCS_WIDTH_16:
+ res = val & 0xffff;
+ break;
+ case VVMCS_WIDTH_64:
+ if ( enc.access_type )
+ {
+ res &= 0xffffffff;
+ res |= val << 32;
+ }
+ else
+ res = val;
+ break;
+ case VVMCS_WIDTH_32:
+ res = val & 0xffffffff;
+ break;
+ case VVMCS_WIDTH_NATURAL:
+ default:
+ res = val;
+ break;
+ }
+
+ content[offset] = res;
+}
+
static unsigned long reg_read(struct cpu_user_regs *regs,
enum vmx_regs_enc index)
{
diff -r 5bf2e7013d33 -r fcdfd43259d6 xen/include/asm-x86/hvm/vmx/vvmx.h
--- a/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800
@@ -96,5 +96,61 @@ uint32_t nvmx_vcpu_asid(struct vcpu *v);
int nvmx_handle_vmxon(struct cpu_user_regs *regs);
int nvmx_handle_vmxoff(struct cpu_user_regs *regs);
+/*
+ * Virtual VMCS layout
+ *
+ * Since physical VMCS layout is unknown, a custom layout is used
+ * for virtual VMCS seen by guest. It occupies a 4k page, and the
+ * field is offset by an 9-bit offset into u64[], The offset is as
+ * follow, which means every <width, type> pair has a max of 32
+ * fields available.
+ *
+ * 9 7 5 0
+ * --------------------------------
+ * offset: | width | type | index |
+ * --------------------------------
+ *
+ * Also, since the lower range <width=0, type={0,1}> has only one
+ * field: VPID, it is moved to a higher offset (63), and leaves the
+ * lower range to non-indexed field like VMCS revision.
+ *
+ */
+
+#define VVMCS_REVISION 0x40000001u
+
+struct vvmcs_header {
+ u32 revision;
+ u32 abort;
+};
+
+union vmcs_encoding {
+ struct {
+ u32 access_type : 1;
+ u32 index : 9;
+ u32 type : 2;
+ u32 rsv1 : 1;
+ u32 width : 2;
+ u32 rsv2 : 17;
+ };
+ u32 word;
+};
+
+enum vvmcs_encoding_width {
+ VVMCS_WIDTH_16 = 0,
+ VVMCS_WIDTH_64,
+ VVMCS_WIDTH_32,
+ VVMCS_WIDTH_NATURAL,
+};
+
+enum vvmcs_encoding_type {
+ VVMCS_TYPE_CONTROL = 0,
+ VVMCS_TYPE_RO,
+ VVMCS_TYPE_GSTATE,
+ VVMCS_TYPE_HSTATE,
+};
+
+u64 __get_vvmcs(void *vvmcs, u32 vmcs_encoding);
+void __set_vvmcs(void *vvmcs, u32 vmcs_encoding, u64 val);
+
#endif /* __ASM_X86_HVM_VVMX_H__ */
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
# HG changeset patch
# User Eddie Dong <eddie.dong@intel.com>
# Date 1307607849 -28800
# Node ID c880f0642b4014b1f13b3a05ddc8ebb140c8c1a1
# Parent fcdfd43259d6f6d25ba80d0480bdf3d9cc2ddb87
Emulation of guest vmptrld
Signed-off-by: Qing He <qing.he@intel.com>
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
diff -r fcdfd43259d6 -r c880f0642b40 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vmx.c Thu Jun 09 16:24:09 2011 +0800
@@ -2444,11 +2444,15 @@ asmlinkage void vmx_vmexit_handler(struc
update_guest_eip();
break;
+ case EXIT_REASON_VMPTRLD:
+ if ( nvmx_handle_vmptrld(regs) == X86EMUL_OKAY )
+ update_guest_eip();
+ break;
+
case EXIT_REASON_MWAIT_INSTRUCTION:
case EXIT_REASON_MONITOR_INSTRUCTION:
case EXIT_REASON_VMCLEAR:
case EXIT_REASON_VMLAUNCH:
- case EXIT_REASON_VMPTRLD:
case EXIT_REASON_VMPTRST:
case EXIT_REASON_VMREAD:
case EXIT_REASON_VMRESUME:
diff -r fcdfd43259d6 -r c880f0642b40 xen/arch/x86/hvm/vmx/vvmx.c
--- a/xen/arch/x86/hvm/vmx/vvmx.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vvmx.c Thu Jun 09 16:24:09 2011 +0800
@@ -352,6 +352,25 @@ static void vmreturn(struct cpu_user_reg
regs->eflags = eflags;
}
+static void __map_io_bitmap(struct vcpu *v, u64 vmcs_reg)
+{
+ struct nestedvmx *nvmx = &vcpu_2_nvmx(v);
+ unsigned long gpa;
+ int index;
+
+ index = vmcs_reg == IO_BITMAP_A ? 0 : 1;
+ if (nvmx->iobitmap[index])
+ hvm_unmap_guest_frame (nvmx->iobitmap[index]);
+ gpa = __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx, vmcs_reg);
+ nvmx->iobitmap[index] = hvm_map_guest_frame_ro (gpa >>
PAGE_SHIFT);
+}
+
+static inline void map_io_bitmap_all(struct vcpu *v)
+{
+ __map_io_bitmap (v, IO_BITMAP_A);
+ __map_io_bitmap (v, IO_BITMAP_B);
+}
+
/*
* VMX instructions handling
*/
@@ -360,6 +379,7 @@ int nvmx_handle_vmxon(struct cpu_user_re
{
struct vcpu *v=current;
struct nestedvmx *nvmx = &vcpu_2_nvmx(v);
+ struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
struct vmx_inst_decoded decode;
unsigned long gpa = 0;
int rc;
@@ -368,7 +388,22 @@ int nvmx_handle_vmxon(struct cpu_user_re
if ( rc != X86EMUL_OKAY )
return rc;
+ if ( nvmx->vmxon_region_pa )
+ gdprintk(XENLOG_WARNING,
+ "vmxon again: orig %lx new %lx\n",
+ nvmx->vmxon_region_pa, gpa);
+
nvmx->vmxon_region_pa = gpa;
+
+ /*
+ * `fork'' the host vmcs to shadow_vmcs
+ * vmcs_lock is not needed since we are on current
+ */
+ nvcpu->nv_n1vmcx = v->arch.hvm_vmx.vmcs;
+ __vmpclear(virt_to_maddr(v->arch.hvm_vmx.vmcs));
+ memcpy(nvcpu->nv_n2vmcx, v->arch.hvm_vmx.vmcs, PAGE_SIZE);
+ __vmptrld(virt_to_maddr(v->arch.hvm_vmx.vmcs));
+ v->arch.hvm_vmx.launched = 0;
vmreturn(regs, VMSUCCEED);
return X86EMUL_OKAY;
@@ -390,3 +425,34 @@ int nvmx_handle_vmxoff(struct cpu_user_r
return X86EMUL_OKAY;
}
+int nvmx_handle_vmptrld(struct cpu_user_regs *regs)
+{
+ struct vcpu *v = current;
+ struct vmx_inst_decoded decode;
+ struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
+ unsigned long gpa = 0;
+ int rc;
+
+ rc = decode_vmx_inst(regs, &decode, &gpa, 0);
+ if ( rc != X86EMUL_OKAY )
+ return rc;
+
+ if ( gpa == vcpu_2_nvmx(v).vmxon_region_pa || gpa & 0xfff )
+ {
+ vmreturn(regs, VMFAIL_INVALID);
+ goto out;
+ }
+
+ if ( nvcpu->nv_vvmcxaddr == VMCX_EADDR )
+ {
+ nvcpu->nv_vvmcx = hvm_map_guest_frame_rw (gpa >> PAGE_SHIFT);
+ nvcpu->nv_vvmcxaddr = gpa;
+ map_io_bitmap_all (v);
+ }
+
+ vmreturn(regs, VMSUCCEED);
+
+out:
+ return X86EMUL_OKAY;
+}
+
diff -r fcdfd43259d6 -r c880f0642b40 xen/include/asm-x86/hvm/vmx/vvmx.h
--- a/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800
@@ -152,5 +152,8 @@ enum vvmcs_encoding_type {
u64 __get_vvmcs(void *vvmcs, u32 vmcs_encoding);
void __set_vvmcs(void *vvmcs, u32 vmcs_encoding, u64 val);
+void nvmx_destroy_vmcs(struct vcpu *v);
+int nvmx_handle_vmptrld(struct cpu_user_regs *regs);
+
#endif /* __ASM_X86_HVM_VVMX_H__ */
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
# HG changeset patch
# User Eddie Dong <eddie.dong@intel.com>
# Date 1307607849 -28800
# Node ID 002f9d4c15841dc0b98b0427a480202b7117fdcd
# Parent c880f0642b4014b1f13b3a05ddc8ebb140c8c1a1
Emulation of guest VMPTRST
Signed-off-by: Qing He <qing.he@intel.com>
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
diff -r c880f0642b40 -r 002f9d4c1584 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vmx.c Thu Jun 09 16:24:09 2011 +0800
@@ -2449,11 +2449,15 @@ asmlinkage void vmx_vmexit_handler(struc
update_guest_eip();
break;
+ case EXIT_REASON_VMPTRST:
+ if ( nvmx_handle_vmptrst(regs) == X86EMUL_OKAY )
+ update_guest_eip();
+ break;
+
case EXIT_REASON_MWAIT_INSTRUCTION:
case EXIT_REASON_MONITOR_INSTRUCTION:
case EXIT_REASON_VMCLEAR:
case EXIT_REASON_VMLAUNCH:
- case EXIT_REASON_VMPTRST:
case EXIT_REASON_VMREAD:
case EXIT_REASON_VMRESUME:
case EXIT_REASON_VMWRITE:
diff -r c880f0642b40 -r 002f9d4c1584 xen/arch/x86/hvm/vmx/vvmx.c
--- a/xen/arch/x86/hvm/vmx/vvmx.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vvmx.c Thu Jun 09 16:24:09 2011 +0800
@@ -456,3 +456,25 @@ out:
return X86EMUL_OKAY;
}
+int nvmx_handle_vmptrst(struct cpu_user_regs *regs)
+{
+ struct vcpu *v = current;
+ struct vmx_inst_decoded decode;
+ struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
+ unsigned long gpa = 0;
+ int rc;
+
+ rc = decode_vmx_inst(regs, &decode, &gpa, 0);
+ if ( rc != X86EMUL_OKAY )
+ return rc;
+
+ gpa = nvcpu->nv_vvmcxaddr;
+
+ rc = hvm_copy_to_guest_virt(decode.mem, &gpa, decode.len, 0);
+ if ( rc != HVMCOPY_okay )
+ return X86EMUL_EXCEPTION;
+
+ vmreturn(regs, VMSUCCEED);
+ return X86EMUL_OKAY;
+}
+
diff -r c880f0642b40 -r 002f9d4c1584 xen/include/asm-x86/hvm/vmx/vvmx.h
--- a/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800
@@ -154,6 +154,7 @@ void __set_vvmcs(void *vvmcs, u32 vmcs_e
void nvmx_destroy_vmcs(struct vcpu *v);
int nvmx_handle_vmptrld(struct cpu_user_regs *regs);
+int nvmx_handle_vmptrst(struct cpu_user_regs *regs);
#endif /* __ASM_X86_HVM_VVMX_H__ */
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
# HG changeset patch
# User Eddie Dong <eddie.dong@intel.com>
# Date 1307607849 -28800
# Node ID 642c9ab2a829e8f1e5997bd8ea740a0306cb5521
# Parent 002f9d4c15841dc0b98b0427a480202b7117fdcd
Emulation of guest VMCLEAR
Signed-off-by: Qing He <qing.he@intel.com>
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
diff -r 002f9d4c1584 -r 642c9ab2a829 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vmx.c Thu Jun 09 16:24:09 2011 +0800
@@ -2444,6 +2444,11 @@ asmlinkage void vmx_vmexit_handler(struc
update_guest_eip();
break;
+ case EXIT_REASON_VMCLEAR:
+ if ( nvmx_handle_vmclear(regs) == X86EMUL_OKAY )
+ update_guest_eip();
+ break;
+
case EXIT_REASON_VMPTRLD:
if ( nvmx_handle_vmptrld(regs) == X86EMUL_OKAY )
update_guest_eip();
@@ -2456,7 +2461,6 @@ asmlinkage void vmx_vmexit_handler(struc
case EXIT_REASON_MWAIT_INSTRUCTION:
case EXIT_REASON_MONITOR_INSTRUCTION:
- case EXIT_REASON_VMCLEAR:
case EXIT_REASON_VMLAUNCH:
case EXIT_REASON_VMREAD:
case EXIT_REASON_VMRESUME:
diff -r 002f9d4c1584 -r 642c9ab2a829 xen/arch/x86/hvm/vmx/vvmx.c
--- a/xen/arch/x86/hvm/vmx/vvmx.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vvmx.c Thu Jun 09 16:24:09 2011 +0800
@@ -26,6 +26,8 @@
#include <asm/hvm/vmx/vmx.h>
#include <asm/hvm/vmx/vvmx.h>
+static void nvmx_purge_vvmcs(struct vcpu *v);
+
int nvmx_vcpu_initialise(struct vcpu *v)
{
struct nestedvmx *nvmx = &vcpu_2_nvmx(v);
@@ -53,6 +55,7 @@ void nvmx_vcpu_destroy(struct vcpu *v)
{
struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
+ nvmx_purge_vvmcs(v);
if ( nvcpu->nv_n2vmcx ) {
__vmpclear(virt_to_maddr(nvcpu->nv_n2vmcx));
free_xenheap_page(nvcpu->nv_n2vmcx);
@@ -352,6 +355,14 @@ static void vmreturn(struct cpu_user_reg
regs->eflags = eflags;
}
+static void __clear_current_vvmcs(struct vcpu *v)
+{
+ struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
+
+ if ( nvcpu->nv_n2vmcx )
+ __vmpclear(virt_to_maddr(nvcpu->nv_n2vmcx));
+}
+
static void __map_io_bitmap(struct vcpu *v, u64 vmcs_reg)
{
struct nestedvmx *nvmx = &vcpu_2_nvmx(v);
@@ -371,6 +382,25 @@ static inline void map_io_bitmap_all(str
__map_io_bitmap (v, IO_BITMAP_B);
}
+static void nvmx_purge_vvmcs(struct vcpu *v)
+{
+ struct nestedvmx *nvmx = &vcpu_2_nvmx(v);
+ struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
+ int i;
+
+ __clear_current_vvmcs(v);
+ if ( nvcpu->nv_vvmcxaddr != VMCX_EADDR )
+ hvm_unmap_guest_frame (nvcpu->nv_vvmcx);
+ nvcpu->nv_vvmcx == NULL;
+ nvcpu->nv_vvmcxaddr = VMCX_EADDR;
+ for (i=0; i<2; i++) {
+ if ( nvmx->iobitmap[i] ) {
+ hvm_unmap_guest_frame (nvmx->iobitmap[i]);
+ nvmx->iobitmap[i] = NULL;
+ }
+ }
+}
+
/*
* VMX instructions handling
*/
@@ -419,6 +449,7 @@ int nvmx_handle_vmxoff(struct cpu_user_r
if ( rc != X86EMUL_OKAY )
return rc;
+ nvmx_purge_vvmcs(v);
nvmx->vmxon_region_pa = 0;
vmreturn(regs, VMSUCCEED);
@@ -443,6 +474,9 @@ int nvmx_handle_vmptrld(struct cpu_user_
goto out;
}
+ if ( nvcpu->nv_vvmcxaddr != gpa )
+ nvmx_purge_vvmcs(v);
+
if ( nvcpu->nv_vvmcxaddr == VMCX_EADDR )
{
nvcpu->nv_vvmcx = hvm_map_guest_frame_rw (gpa >> PAGE_SHIFT);
@@ -478,3 +512,39 @@ int nvmx_handle_vmptrst(struct cpu_user_
return X86EMUL_OKAY;
}
+int nvmx_handle_vmclear(struct cpu_user_regs *regs)
+{
+ struct vcpu *v = current;
+ struct vmx_inst_decoded decode;
+ struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
+ unsigned long gpa = 0;
+ int rc;
+
+ rc = decode_vmx_inst(regs, &decode, &gpa, 0);
+ if ( rc != X86EMUL_OKAY )
+ return rc;
+
+ if ( gpa & 0xfff )
+ {
+ vmreturn(regs, VMFAIL_INVALID);
+ goto out;
+ }
+
+ if ( gpa != nvcpu->nv_vvmcxaddr && nvcpu->nv_vvmcxaddr !=
VMCX_EADDR )
+ {
+ gdprintk(XENLOG_WARNING,
+ "vmclear gpa %lx not the same with current vmcs
%lx\n",
+ gpa, nvcpu->nv_vvmcxaddr);
+ vmreturn(regs, VMSUCCEED);
+ goto out;
+ }
+ if ( nvcpu->nv_vvmcxaddr != VMCX_EADDR )
+ __set_vvmcs(nvcpu->nv_vvmcx, NVMX_LAUNCH_STATE, 0);
+ nvmx_purge_vvmcs(v);
+
+ vmreturn(regs, VMSUCCEED);
+
+out:
+ return X86EMUL_OKAY;
+}
+
diff -r 002f9d4c1584 -r 642c9ab2a829 xen/include/asm-x86/hvm/vmx/vmcs.h
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h Thu Jun 09 16:24:09 2011 +0800
@@ -381,6 +381,8 @@ enum vmcs_field {
HOST_SYSENTER_EIP = 0x00006c12,
HOST_RSP = 0x00006c14,
HOST_RIP = 0x00006c16,
+ /* A virtual VMCS field used for nestedvmx only */
+ NVMX_LAUNCH_STATE = 0x00006c20,
};
#define VMCS_VPID_WIDTH 16
diff -r 002f9d4c1584 -r 642c9ab2a829 xen/include/asm-x86/hvm/vmx/vvmx.h
--- a/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800
@@ -155,6 +155,7 @@ void __set_vvmcs(void *vvmcs, u32 vmcs_e
void nvmx_destroy_vmcs(struct vcpu *v);
int nvmx_handle_vmptrld(struct cpu_user_regs *regs);
int nvmx_handle_vmptrst(struct cpu_user_regs *regs);
+int nvmx_handle_vmclear(struct cpu_user_regs *regs);
#endif /* __ASM_X86_HVM_VVMX_H__ */
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
# HG changeset patch
# User Eddie Dong <eddie.dong@intel.com>
# Date 1307607849 -28800
# Node ID 746c4af7fb75e7c54d9d610acd0d2be2f27fe4dc
# Parent 642c9ab2a829e8f1e5997bd8ea740a0306cb5521
Emulation of guest VMWRITE
Signed-off-by: Qing He <qing.he@intel.com>
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
diff -r 642c9ab2a829 -r 746c4af7fb75 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vmx.c Thu Jun 09 16:24:09 2011 +0800
@@ -2459,12 +2459,16 @@ asmlinkage void vmx_vmexit_handler(struc
update_guest_eip();
break;
+ case EXIT_REASON_VMWRITE:
+ if ( nvmx_handle_vmwrite(regs) == X86EMUL_OKAY )
+ update_guest_eip();
+ break;
+
case EXIT_REASON_MWAIT_INSTRUCTION:
case EXIT_REASON_MONITOR_INSTRUCTION:
case EXIT_REASON_VMLAUNCH:
case EXIT_REASON_VMREAD:
case EXIT_REASON_VMRESUME:
- case EXIT_REASON_VMWRITE:
case EXIT_REASON_GETSEC:
case EXIT_REASON_INVEPT:
case EXIT_REASON_INVVPID:
diff -r 642c9ab2a829 -r 746c4af7fb75 xen/arch/x86/hvm/vmx/vvmx.c
--- a/xen/arch/x86/hvm/vmx/vvmx.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vvmx.c Thu Jun 09 16:24:09 2011 +0800
@@ -548,3 +548,27 @@ out:
return X86EMUL_OKAY;
}
+int nvmx_handle_vmwrite(struct cpu_user_regs *regs)
+{
+ struct vcpu *v = current;
+ struct vmx_inst_decoded decode;
+ struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
+ u64 operandS, vmcs_encoding;
+
+ if ( decode_vmx_inst(regs, &decode, &operandS, 0)
+ != X86EMUL_OKAY )
+ return X86EMUL_EXCEPTION;
+
+ vmcs_encoding = reg_read(regs, decode.reg2);
+ __set_vvmcs(nvcpu->nv_vvmcx, vmcs_encoding, operandS);
+
+ if ( vmcs_encoding == IO_BITMAP_A || vmcs_encoding == IO_BITMAP_A_HIGH )
+ __map_io_bitmap (v, IO_BITMAP_A);
+ else if ( vmcs_encoding == IO_BITMAP_B ||
+ vmcs_encoding == IO_BITMAP_B_HIGH )
+ __map_io_bitmap (v, IO_BITMAP_B);
+
+ vmreturn(regs, VMSUCCEED);
+ return X86EMUL_OKAY;
+}
+
diff -r 642c9ab2a829 -r 746c4af7fb75 xen/include/asm-x86/hvm/vmx/vvmx.h
--- a/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800
@@ -156,6 +156,7 @@ void nvmx_destroy_vmcs(struct vcpu *v);
int nvmx_handle_vmptrld(struct cpu_user_regs *regs);
int nvmx_handle_vmptrst(struct cpu_user_regs *regs);
int nvmx_handle_vmclear(struct cpu_user_regs *regs);
+int nvmx_handle_vmwrite(struct cpu_user_regs *regs);
#endif /* __ASM_X86_HVM_VVMX_H__ */
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
# HG changeset patch
# User Eddie Dong <eddie.dong@intel.com>
# Date 1307607849 -28800
# Node ID c9f43a690ed89169aecbf85940bd7fff390e7497
# Parent 746c4af7fb75e7c54d9d610acd0d2be2f27fe4dc
Emulation of guest VMREAD
Signed-off-by: Qing He <qing.he@intel.com>
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
diff -r 746c4af7fb75 -r c9f43a690ed8 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vmx.c Thu Jun 09 16:24:09 2011 +0800
@@ -2459,6 +2459,11 @@ asmlinkage void vmx_vmexit_handler(struc
update_guest_eip();
break;
+ case EXIT_REASON_VMREAD:
+ if ( nvmx_handle_vmread(regs) == X86EMUL_OKAY )
+ update_guest_eip();
+ break;
+
case EXIT_REASON_VMWRITE:
if ( nvmx_handle_vmwrite(regs) == X86EMUL_OKAY )
update_guest_eip();
@@ -2467,7 +2472,6 @@ asmlinkage void vmx_vmexit_handler(struc
case EXIT_REASON_MWAIT_INSTRUCTION:
case EXIT_REASON_MONITOR_INSTRUCTION:
case EXIT_REASON_VMLAUNCH:
- case EXIT_REASON_VMREAD:
case EXIT_REASON_VMRESUME:
case EXIT_REASON_GETSEC:
case EXIT_REASON_INVEPT:
diff -r 746c4af7fb75 -r c9f43a690ed8 xen/arch/x86/hvm/vmx/vvmx.c
--- a/xen/arch/x86/hvm/vmx/vvmx.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vvmx.c Thu Jun 09 16:24:09 2011 +0800
@@ -119,6 +119,8 @@ enum vmx_ops_result {
VMFAIL_INVALID,
};
+#define CASE_SET_REG(REG, reg) \
+ case VMX_REG_ ## REG: regs->reg = value; break
#define CASE_GET_REG(REG, reg) \
case VMX_REG_ ## REG: value = regs->reg; break
@@ -231,6 +233,32 @@ static unsigned long reg_read(struct cpu
return value;
}
+static void reg_write(struct cpu_user_regs *regs,
+ enum vmx_regs_enc index,
+ unsigned long value)
+{
+ switch ( index ) {
+ CASE_SET_REG(RAX, eax);
+ CASE_SET_REG(RCX, ecx);
+ CASE_SET_REG(RDX, edx);
+ CASE_SET_REG(RBX, ebx);
+ CASE_SET_REG(RBP, ebp);
+ CASE_SET_REG(RSI, esi);
+ CASE_SET_REG(RDI, edi);
+ CASE_SET_REG(RSP, esp);
+ CASE_SET_REG(R8, r8);
+ CASE_SET_REG(R9, r9);
+ CASE_SET_REG(R10, r10);
+ CASE_SET_REG(R11, r11);
+ CASE_SET_REG(R12, r12);
+ CASE_SET_REG(R13, r13);
+ CASE_SET_REG(R14, r14);
+ CASE_SET_REG(R15, r15);
+ default:
+ break;
+ }
+}
+
static int vmx_inst_check_privilege(struct cpu_user_regs *regs, int
vmxop_check)
{
struct vcpu *v = current;
@@ -548,6 +576,35 @@ out:
return X86EMUL_OKAY;
}
+int nvmx_handle_vmread(struct cpu_user_regs *regs)
+{
+ struct vcpu *v = current;
+ struct vmx_inst_decoded decode;
+ struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
+ u64 value = 0;
+ int rc;
+
+ rc = decode_vmx_inst(regs, &decode, NULL, 0);
+ if ( rc != X86EMUL_OKAY )
+ return rc;
+
+ value = __get_vvmcs(nvcpu->nv_vvmcx, reg_read(regs, decode.reg2));
+
+ switch ( decode.type ) {
+ case VMX_INST_MEMREG_TYPE_MEMORY:
+ rc = hvm_copy_to_guest_virt(decode.mem, &value, decode.len, 0);
+ if ( rc != HVMCOPY_okay )
+ return X86EMUL_EXCEPTION;
+ break;
+ case VMX_INST_MEMREG_TYPE_REG:
+ reg_write(regs, decode.reg1, value);
+ break;
+ }
+
+ vmreturn(regs, VMSUCCEED);
+ return X86EMUL_OKAY;
+}
+
int nvmx_handle_vmwrite(struct cpu_user_regs *regs)
{
struct vcpu *v = current;
diff -r 746c4af7fb75 -r c9f43a690ed8 xen/include/asm-x86/hvm/vmx/vvmx.h
--- a/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800
@@ -156,6 +156,7 @@ void nvmx_destroy_vmcs(struct vcpu *v);
int nvmx_handle_vmptrld(struct cpu_user_regs *regs);
int nvmx_handle_vmptrst(struct cpu_user_regs *regs);
int nvmx_handle_vmclear(struct cpu_user_regs *regs);
+int nvmx_handle_vmread(struct cpu_user_regs *regs);
int nvmx_handle_vmwrite(struct cpu_user_regs *regs);
#endif /* __ASM_X86_HVM_VVMX_H__ */
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Eddie Dong
2011-Jun-09 08:25 UTC
[Xen-devel] [PATCH 12 of 20] Add APIs to switch n1/n2 VMCS
# HG changeset patch
# User Eddie Dong <eddie.dong@intel.com>
# Date 1307607849 -28800
# Node ID 549f110b69dc235e8159079f38d8225ccd1db649
# Parent c9f43a690ed89169aecbf85940bd7fff390e7497
Add APIs to switch n1/n2 VMCS.
Signed-off-by: Qing He <qing.he@intel.com>
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
diff -r c9f43a690ed8 -r 549f110b69dc xen/arch/x86/hvm/vmx/vmcs.c
--- a/xen/arch/x86/hvm/vmx/vmcs.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vmcs.c Thu Jun 09 16:24:09 2011 +0800
@@ -669,6 +669,31 @@ void vmx_disable_intercept_for_msr(struc
}
}
+/*
+ * Switch VMCS between layer 1 & 2 guest
+ */
+void vmx_vmcs_switch(struct vcpu *v,
+ struct vmcs_struct *from,
+ struct vmcs_struct *to)
+{
+ spin_lock(&v->arch.hvm_vmx.vmcs_lock);
+
+ __vmpclear(virt_to_maddr(from));
+ __vmptrld(virt_to_maddr(to));
+
+ v->arch.hvm_vmx.vmcs = to;
+ v->arch.hvm_vmx.launched = 0;
+ this_cpu(current_vmcs) = to;
+
+ if ( v->arch.hvm_vmx.hostenv_migrated )
+ {
+ v->arch.hvm_vmx.hostenv_migrated = 0;
+ vmx_set_host_env(v);
+ }
+
+ spin_unlock(&v->arch.hvm_vmx.vmcs_lock);
+}
+
static int construct_vmcs(struct vcpu *v)
{
struct domain *d = v->domain;
@@ -1078,6 +1103,13 @@ void vmx_do_resume(struct vcpu *v)
hvm_migrate_timers(v);
hvm_migrate_pirqs(v);
vmx_set_host_env(v);
+ /*
+ * Both n1 VMCS and n2 VMCS need to update the host environment after
+ * VCPU migration. The environment of current VMCS is updated in place,
+ * but the action of another VMCS is deferred till it is switched in.
+ */
+ v->arch.hvm_vmx.hostenv_migrated = 1;
+
hvm_asid_flush_vcpu(v);
}
diff -r c9f43a690ed8 -r 549f110b69dc xen/include/asm-x86/hvm/vmx/vmcs.h
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h Thu Jun 09 16:24:09 2011 +0800
@@ -123,6 +123,7 @@ struct arch_vmx_struct {
struct segment_register vm86_saved_seg[x86_seg_tr + 1];
/* Remember EFLAGS while in virtual 8086 mode */
uint32_t vm86_saved_eflags;
+ int hostenv_migrated;
};
int vmx_create_vmcs(struct vcpu *v);
@@ -392,6 +393,9 @@ int vmx_read_guest_msr(u32 msr, u64 *val
int vmx_write_guest_msr(u32 msr, u64 val);
int vmx_add_guest_msr(u32 msr);
int vmx_add_host_load_msr(u32 msr);
+void vmx_vmcs_switch(struct vcpu *v,
+ struct vmcs_struct *from,
+ struct vmcs_struct *to);
#endif /* ASM_X86_HVM_VMX_VMCS_H__ */
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Eddie Dong
2011-Jun-09 08:25 UTC
[Xen-devel] [PATCH 13 of 20] Emulation of VMRESUME/VMLAUNCH
# HG changeset patch
# User Eddie Dong <eddie.dong@intel.com>
# Date 1307607849 -28800
# Node ID a6f9b015835e503474c4a258e5c03178358c68e8
# Parent 549f110b69dc235e8159079f38d8225ccd1db649
Emulation of VMRESUME/VMLAUNCH
Signed-off-by: Qing He <qing.he@intel.com>
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
diff -r 549f110b69dc -r a6f9b015835e xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vmx.c Thu Jun 09 16:24:09 2011 +0800
@@ -2175,6 +2175,11 @@ asmlinkage void vmx_vmexit_handler(struc
/* Now enable interrupts so it''s safe to take locks. */
local_irq_enable();
+ /* XXX: This looks ugly, but we need a mechanism to ensure
+ * any pending vmresume has really happened
+ */
+ vcpu_nestedhvm(v).nv_vmswitch_in_progress = 0;
+
if ( unlikely(exit_reason & VMX_EXIT_REASONS_FAILED_VMENTRY) )
return vmx_failed_vmentry(exit_reason, regs);
@@ -2469,10 +2474,18 @@ asmlinkage void vmx_vmexit_handler(struc
update_guest_eip();
break;
+ case EXIT_REASON_VMLAUNCH:
+ if ( nvmx_handle_vmlaunch(regs) == X86EMUL_OKAY )
+ update_guest_eip();
+ break;
+
+ case EXIT_REASON_VMRESUME:
+ if ( nvmx_handle_vmresume(regs) == X86EMUL_OKAY )
+ update_guest_eip();
+ break;
+
case EXIT_REASON_MWAIT_INSTRUCTION:
case EXIT_REASON_MONITOR_INSTRUCTION:
- case EXIT_REASON_VMLAUNCH:
- case EXIT_REASON_VMRESUME:
case EXIT_REASON_GETSEC:
case EXIT_REASON_INVEPT:
case EXIT_REASON_INVVPID:
diff -r 549f110b69dc -r a6f9b015835e xen/arch/x86/hvm/vmx/vvmx.c
--- a/xen/arch/x86/hvm/vmx/vvmx.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vvmx.c Thu Jun 09 16:24:09 2011 +0800
@@ -259,6 +259,13 @@ static void reg_write(struct cpu_user_re
}
}
+static inline u32 __n2_exec_control(struct vcpu *v)
+{
+ struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
+
+ return __get_vvmcs(nvcpu->nv_vvmcx, CPU_BASED_VM_EXEC_CONTROL);
+}
+
static int vmx_inst_check_privilege(struct cpu_user_regs *regs, int
vmxop_check)
{
struct vcpu *v = current;
@@ -484,6 +491,62 @@ int nvmx_handle_vmxoff(struct cpu_user_r
return X86EMUL_OKAY;
}
+int nvmx_vmresume(struct vcpu *v, struct cpu_user_regs *regs)
+{
+ struct nestedvmx *nvmx = &vcpu_2_nvmx(v);
+ struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
+ int rc;
+
+ rc = vmx_inst_check_privilege(regs, 0);
+ if ( rc != X86EMUL_OKAY )
+ return rc;
+
+ /* check VMCS is valid and IO BITMAP is set */
+ if ( (nvcpu->nv_vvmcxaddr != VMCX_EADDR) &&
+ ((nvmx->iobitmap[0] && nvmx->iobitmap[1]) ||
+ !(__n2_exec_control(v) & CPU_BASED_ACTIVATE_IO_BITMAP) ) )
+ nvcpu->nv_vmentry_pending = 1;
+ else
+ vmreturn(regs, VMFAIL_INVALID);
+
+ return X86EMUL_OKAY;
+}
+
+int nvmx_handle_vmresume(struct cpu_user_regs *regs)
+{
+ int launched;
+ struct vcpu *v = current;
+
+ launched = __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx,
+ NVMX_LAUNCH_STATE);
+ if ( !launched ) {
+ vmreturn (regs, VMFAIL_VALID);
+ return X86EMUL_EXCEPTION;
+ }
+ return nvmx_vmresume(v,regs);
+}
+
+int nvmx_handle_vmlaunch(struct cpu_user_regs *regs)
+{
+ int launched;
+ int rc;
+ struct vcpu *v = current;
+
+ launched = __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx,
+ NVMX_LAUNCH_STATE);
+ if ( launched ) {
+ vmreturn (regs, VMFAIL_VALID);
+ rc = X86EMUL_EXCEPTION;
+ }
+ else {
+ rc = nvmx_vmresume(v,regs);
+ if ( rc == X86EMUL_OKAY )
+ __set_vvmcs(vcpu_nestedhvm(v).nv_vvmcx,
+ NVMX_LAUNCH_STATE, 1);
+ }
+ return rc;
+}
+
int nvmx_handle_vmptrld(struct cpu_user_regs *regs)
{
struct vcpu *v = current;
diff -r 549f110b69dc -r a6f9b015835e xen/include/asm-x86/hvm/vmx/vvmx.h
--- a/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800
@@ -158,6 +158,8 @@ int nvmx_handle_vmptrst(struct cpu_user_
int nvmx_handle_vmclear(struct cpu_user_regs *regs);
int nvmx_handle_vmread(struct cpu_user_regs *regs);
int nvmx_handle_vmwrite(struct cpu_user_regs *regs);
+int nvmx_handle_vmresume(struct cpu_user_regs *regs);
+int nvmx_handle_vmlaunch(struct cpu_user_regs *regs);
#endif /* __ASM_X86_HVM_VVMX_H__ */
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Eddie Dong
2011-Jun-09 08:25 UTC
[Xen-devel] [PATCH 14 of 20] Extend VMCS control fields for n2 guest
# HG changeset patch
# User Eddie Dong <eddie.dong@intel.com>
# Date 1307607849 -28800
# Node ID fc6a432d6c6367acaee71526556e1feeece4d34c
# Parent a6f9b015835e503474c4a258e5c03178358c68e8
Extend VMCS control fields for n2 guest
Signed-off-by: Qing He <qing.he@intel.com>
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
diff -r a6f9b015835e -r fc6a432d6c63 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vmx.c Thu Jun 09 16:24:09 2011 +0800
@@ -54,6 +54,7 @@
#include <asm/xenoprof.h>
#include <asm/debugger.h>
#include <asm/apic.h>
+#include <asm/hvm/nestedhvm.h>
enum handler_return { HNDL_done, HNDL_unhandled, HNDL_exception_raised };
@@ -361,18 +362,28 @@ long_mode_do_msr_write(unsigned int msr,
void vmx_update_cpu_exec_control(struct vcpu *v)
{
- __vmwrite(CPU_BASED_VM_EXEC_CONTROL, v->arch.hvm_vmx.exec_control);
+ if ( nestedhvm_vcpu_in_guestmode(v) )
+ nvmx_update_exec_control(v, v->arch.hvm_vmx.exec_control);
+ else
+ __vmwrite(CPU_BASED_VM_EXEC_CONTROL, v->arch.hvm_vmx.exec_control);
}
static void vmx_update_secondary_exec_control(struct vcpu *v)
{
- __vmwrite(SECONDARY_VM_EXEC_CONTROL,
- v->arch.hvm_vmx.secondary_exec_control);
+ if ( nestedhvm_vcpu_in_guestmode(v) )
+ nvmx_update_secondary_exec_control(v,
+ v->arch.hvm_vmx.secondary_exec_control);
+ else
+ __vmwrite(SECONDARY_VM_EXEC_CONTROL,
+ v->arch.hvm_vmx.secondary_exec_control);
}
void vmx_update_exception_bitmap(struct vcpu *v)
{
- __vmwrite(EXCEPTION_BITMAP, v->arch.hvm_vmx.exception_bitmap);
+ if ( nestedhvm_vcpu_in_guestmode(v) )
+ nvmx_update_exception_bitmap(v, v->arch.hvm_vmx.exception_bitmap);
+ else
+ __vmwrite(EXCEPTION_BITMAP, v->arch.hvm_vmx.exception_bitmap);
}
static int vmx_guest_x86_mode(struct vcpu *v)
diff -r a6f9b015835e -r fc6a432d6c63 xen/arch/x86/hvm/vmx/vvmx.c
--- a/xen/arch/x86/hvm/vmx/vvmx.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vvmx.c Thu Jun 09 16:24:09 2011 +0800
@@ -25,6 +25,7 @@
#include <asm/p2m.h>
#include <asm/hvm/vmx/vmx.h>
#include <asm/hvm/vmx/vvmx.h>
+#include <asm/hvm/nestedhvm.h>
static void nvmx_purge_vvmcs(struct vcpu *v);
@@ -390,6 +391,93 @@ static void vmreturn(struct cpu_user_reg
regs->eflags = eflags;
}
+/*
+ * Nested VMX uses "strict" condition to exit from
+ * L2 guest if either L1 VMM or L0 VMM expect to exit.
+ */
+static inline u32 __shadow_control(struct vcpu *v,
+ unsigned int field,
+ u32 host_value)
+{
+ struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
+
+ return (u32) __get_vvmcs(nvcpu->nv_vvmcx, field) | host_value;
+}
+
+static void set_shadow_control(struct vcpu *v,
+ unsigned int field,
+ u32 host_value)
+{
+ __vmwrite(field, __shadow_control(v, field, host_value));
+}
+
+unsigned long *_shadow_io_bitmap(struct vcpu *v)
+{
+ struct nestedvmx *nvmx = &vcpu_2_nvmx(v);
+ int port80, portED;
+ u8 *bitmap;
+
+ bitmap = nvmx->iobitmap[0];
+ port80 = bitmap[0x80 >> 3] & (1 << (0x80 & 0x7)) ? 1 :
0;
+ portED = bitmap[0xed >> 3] & (1 << (0xed & 0x7)) ? 1 :
0;
+
+ return nestedhvm_vcpu_iomap_get(port80, portED);
+}
+
+void nvmx_update_exec_control(struct vcpu *v, u32 host_cntrl)
+{
+#define PIO_CNTRL_BITS ( CPU_BASED_ACTIVATE_IO_BITMAP \
+ | CPU_BASED_UNCOND_IO_EXITING)
+ u32 pio_cntrl = PIO_CNTRL_BITS;
+ unsigned long *bitmap;
+ u32 shadow_cntrl;
+
+ shadow_cntrl = __n2_exec_control(v);
+ pio_cntrl &= shadow_cntrl;
+ /* Enforce the removed features */
+#define REMOVED_EXEC_CONTROL_BITS (CPU_BASED_TPR_SHADOW \
+ | CPU_BASED_ACTIVATE_MSR_BITMAP \
+ | CPU_BASED_ACTIVATE_SECONDARY_CONTROLS \
+ | CPU_BASED_ACTIVATE_IO_BITMAP \
+ | CPU_BASED_UNCOND_IO_EXITING)
+ shadow_cntrl &= ~REMOVED_EXEC_CONTROL_BITS;
+ shadow_cntrl |= host_cntrl;
+ if ( pio_cntrl == CPU_BASED_UNCOND_IO_EXITING ) {
+ /* L1 VMM intercepts all I/O instructions */
+ shadow_cntrl |= CPU_BASED_UNCOND_IO_EXITING;
+ shadow_cntrl &= ~CPU_BASED_ACTIVATE_IO_BITMAP;
+ }
+ else {
+ /* Use IO_BITMAP in shadow */
+ if ( pio_cntrl == 0 ) {
+ /*
+ * L1 VMM doesn''t intercept IO instruction.
+ * Use host configuration and reset IO_BITMAP
+ */
+ bitmap = hvm_io_bitmap;
+ }
+ else {
+ /* use IO bitmap */
+ bitmap = _shadow_io_bitmap(v);
+ }
+ __vmwrite(IO_BITMAP_A, virt_to_maddr(bitmap));
+ __vmwrite(IO_BITMAP_B, virt_to_maddr(bitmap) + PAGE_SIZE);
+ }
+
+ __vmwrite(CPU_BASED_VM_EXEC_CONTROL, shadow_cntrl);
+}
+
+void nvmx_update_secondary_exec_control(struct vcpu *v,
+ unsigned long value)
+{
+ set_shadow_control(v, SECONDARY_VM_EXEC_CONTROL, value);
+}
+
+void nvmx_update_exception_bitmap(struct vcpu *v, unsigned long value)
+{
+ set_shadow_control(v, EXCEPTION_BITMAP, value);
+}
+
static void __clear_current_vvmcs(struct vcpu *v)
{
struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
diff -r a6f9b015835e -r fc6a432d6c63 xen/include/asm-x86/hvm/vmx/vvmx.h
--- a/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800
@@ -161,5 +161,10 @@ int nvmx_handle_vmwrite(struct cpu_user_
int nvmx_handle_vmresume(struct cpu_user_regs *regs);
int nvmx_handle_vmlaunch(struct cpu_user_regs *regs);
+void nvmx_update_exec_control(struct vcpu *v, u32 value);
+void nvmx_update_secondary_exec_control(struct vcpu *v,
+ unsigned long value);
+void nvmx_update_exception_bitmap(struct vcpu *v, unsigned long value);
+
#endif /* __ASM_X86_HVM_VVMX_H__ */
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Eddie Dong
2011-Jun-09 08:25 UTC
[Xen-devel] [PATCH 15 of 20] Switch shadow/virtual VMCS between n1/n2 guests
# HG changeset patch
# User Eddie Dong <eddie.dong@intel.com>
# Date 1307607849 -28800
# Node ID 04f112e54debd7ac0832b12d3258d8eb557ae7eb
# Parent fc6a432d6c6367acaee71526556e1feeece4d34c
Switch shadow/virtual VMCS between n1/n2 guests.
Signed-off-by: Qing He <qing.he@intel.com>
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
diff -r fc6a432d6c63 -r 04f112e54deb xen/arch/x86/hvm/vmx/entry.S
--- a/xen/arch/x86/hvm/vmx/entry.S Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/entry.S Thu Jun 09 16:24:09 2011 +0800
@@ -119,6 +119,7 @@ vmx_asm_vmexit_handler:
.globl vmx_asm_do_vmentry
vmx_asm_do_vmentry:
call vmx_intr_assist
+ call nvmx_switch_guest
get_current(bx)
cli
diff -r fc6a432d6c63 -r 04f112e54deb xen/arch/x86/hvm/vmx/vvmx.c
--- a/xen/arch/x86/hvm/vmx/vvmx.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vvmx.c Thu Jun 09 16:24:09 2011 +0800
@@ -473,6 +473,49 @@ void nvmx_update_secondary_exec_control(
set_shadow_control(v, SECONDARY_VM_EXEC_CONTROL, value);
}
+static void nvmx_update_pin_control(struct vcpu *v,
+ unsigned long host_cntrl)
+{
+ u32 shadow_cntrl;
+ struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
+
+#define REMOVED_PIN_CONTROL_BITS (PIN_BASED_PREEMPT_TIMER)
+ shadow_cntrl = __get_vvmcs(nvcpu->nv_vvmcx, PIN_BASED_VM_EXEC_CONTROL);
+ shadow_cntrl &= ~REMOVED_PIN_CONTROL_BITS;
+ shadow_cntrl |= host_cntrl;
+ __vmwrite(PIN_BASED_VM_EXEC_CONTROL, shadow_cntrl);
+}
+
+static void nvmx_update_exit_control(struct vcpu *v,
+ unsigned long host_cntrl)
+{
+ u32 shadow_cntrl;
+ struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
+
+#define REMOVED_EXIT_CONTROL_BITS ( \
+ (VM_EXIT_SAVE_DEBUG_CNTRLS) | \
+ (VM_EXIT_SAVE_GUEST_PAT) | \
+ (VM_EXIT_SAVE_GUEST_EFER) | \
+ (VM_EXIT_SAVE_PREEMPT_TIMER))
+ shadow_cntrl = __get_vvmcs(nvcpu->nv_vvmcx, VM_EXIT_CONTROLS);
+ shadow_cntrl &= ~REMOVED_EXIT_CONTROL_BITS;
+ shadow_cntrl |= host_cntrl;
+ __vmwrite(VM_EXIT_CONTROLS, shadow_cntrl);
+}
+
+static void nvmx_update_entry_control(struct vcpu *v)
+{
+ u32 shadow_cntrl;
+ struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
+
+ /* VM_ENTRY_CONTROLS: enforce removed features */
+#define REMOVED_ENTRY_CONTROL_BITS (VM_ENTRY_LOAD_GUEST_PAT \
+ | VM_ENTRY_LOAD_GUEST_EFER)
+ shadow_cntrl = __get_vvmcs(nvcpu->nv_vvmcx, VM_ENTRY_CONTROLS);
+ shadow_cntrl &= ~REMOVED_ENTRY_CONTROL_BITS;
+ __vmwrite(VM_ENTRY_CONTROLS, shadow_cntrl);
+}
+
void nvmx_update_exception_bitmap(struct vcpu *v, unsigned long value)
{
set_shadow_control(v, EXCEPTION_BITMAP, value);
@@ -525,6 +568,350 @@ static void nvmx_purge_vvmcs(struct vcpu
}
/*
+ * Context synchronized between shadow and virtual VMCS.
+ */
+static unsigned long vmcs_gstate_field[] = {
+ /* 16 BITS */
+ GUEST_ES_SELECTOR,
+ GUEST_CS_SELECTOR,
+ GUEST_SS_SELECTOR,
+ GUEST_DS_SELECTOR,
+ GUEST_FS_SELECTOR,
+ GUEST_GS_SELECTOR,
+ GUEST_LDTR_SELECTOR,
+ GUEST_TR_SELECTOR,
+ /* 64 BITS */
+ VMCS_LINK_POINTER,
+ GUEST_IA32_DEBUGCTL,
+#ifndef CONFIG_X86_64
+ VMCS_LINK_POINTER_HIGH,
+ GUEST_IA32_DEBUGCTL_HIGH,
+#endif
+ /* 32 BITS */
+ GUEST_ES_LIMIT,
+ GUEST_CS_LIMIT,
+ GUEST_SS_LIMIT,
+ GUEST_DS_LIMIT,
+ GUEST_FS_LIMIT,
+ GUEST_GS_LIMIT,
+ GUEST_LDTR_LIMIT,
+ GUEST_TR_LIMIT,
+ GUEST_GDTR_LIMIT,
+ GUEST_IDTR_LIMIT,
+ GUEST_ES_AR_BYTES,
+ GUEST_CS_AR_BYTES,
+ GUEST_SS_AR_BYTES,
+ GUEST_DS_AR_BYTES,
+ GUEST_FS_AR_BYTES,
+ GUEST_GS_AR_BYTES,
+ GUEST_LDTR_AR_BYTES,
+ GUEST_TR_AR_BYTES,
+ GUEST_INTERRUPTIBILITY_INFO,
+ GUEST_ACTIVITY_STATE,
+ GUEST_SYSENTER_CS,
+ /* natural */
+ GUEST_ES_BASE,
+ GUEST_CS_BASE,
+ GUEST_SS_BASE,
+ GUEST_DS_BASE,
+ GUEST_FS_BASE,
+ GUEST_GS_BASE,
+ GUEST_LDTR_BASE,
+ GUEST_TR_BASE,
+ GUEST_GDTR_BASE,
+ GUEST_IDTR_BASE,
+ GUEST_DR7,
+ /*
+ * Following guest states are in local cache (cpu_user_regs)
+ GUEST_RSP,
+ GUEST_RIP,
+ */
+ GUEST_RFLAGS,
+ GUEST_PENDING_DBG_EXCEPTIONS,
+ GUEST_SYSENTER_ESP,
+ GUEST_SYSENTER_EIP,
+};
+
+/*
+ * Context: shadow -> virtual VMCS
+ */
+static unsigned long vmcs_ro_field[] = {
+ GUEST_PHYSICAL_ADDRESS,
+ VM_INSTRUCTION_ERROR,
+ VM_EXIT_REASON,
+ VM_EXIT_INTR_INFO,
+ VM_EXIT_INTR_ERROR_CODE,
+ IDT_VECTORING_INFO,
+ IDT_VECTORING_ERROR_CODE,
+ VM_EXIT_INSTRUCTION_LEN,
+ VMX_INSTRUCTION_INFO,
+ EXIT_QUALIFICATION,
+ GUEST_LINEAR_ADDRESS
+};
+
+static struct vmcs_host_to_guest {
+ unsigned long host_field;
+ unsigned long guest_field;
+} vmcs_h2g_field[] = {
+ {HOST_ES_SELECTOR, GUEST_ES_SELECTOR},
+ {HOST_CS_SELECTOR, GUEST_CS_SELECTOR},
+ {HOST_SS_SELECTOR, GUEST_SS_SELECTOR},
+ {HOST_DS_SELECTOR, GUEST_DS_SELECTOR},
+ {HOST_FS_SELECTOR, GUEST_FS_SELECTOR},
+ {HOST_GS_SELECTOR, GUEST_GS_SELECTOR},
+ {HOST_TR_SELECTOR, GUEST_TR_SELECTOR},
+ {HOST_SYSENTER_CS, GUEST_SYSENTER_CS},
+ {HOST_FS_BASE, GUEST_FS_BASE},
+ {HOST_GS_BASE, GUEST_GS_BASE},
+ {HOST_TR_BASE, GUEST_TR_BASE},
+ {HOST_GDTR_BASE, GUEST_GDTR_BASE},
+ {HOST_IDTR_BASE, GUEST_IDTR_BASE},
+ {HOST_SYSENTER_ESP, GUEST_SYSENTER_ESP},
+ {HOST_SYSENTER_EIP, GUEST_SYSENTER_EIP},
+};
+
+static void vvmcs_to_shadow(void *vvmcs, unsigned int field)
+{
+ u64 value;
+
+ value = __get_vvmcs(vvmcs, field);
+ __vmwrite(field, value);
+}
+
+static void shadow_to_vvmcs(void *vvmcs, unsigned int field)
+{
+ u64 value;
+ int rc;
+
+ value = __vmread_safe(field, &rc);
+ if ( !rc )
+ __set_vvmcs(vvmcs, field, value);
+}
+
+static void load_shadow_control(struct vcpu *v)
+{
+ /*
+ * Set shadow controls: PIN_BASED, CPU_BASED, EXIT, ENTRY
+ * and EXCEPTION
+ * Enforce the removed features
+ */
+ nvmx_update_pin_control(v, vmx_pin_based_exec_control);
+ vmx_update_cpu_exec_control(v);
+ nvmx_update_exit_control(v, vmx_vmexit_control);
+ nvmx_update_entry_control(v);
+ vmx_update_exception_bitmap(v);
+}
+
+static void load_shadow_guest_state(struct vcpu *v)
+{
+ struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
+ void *vvmcs = nvcpu->nv_vvmcx;
+ int i;
+
+ /* vvmcs.gstate to shadow vmcs.gstate */
+ for ( i = 0; i < ARRAY_SIZE(vmcs_gstate_field); i++ )
+ vvmcs_to_shadow(vvmcs, vmcs_gstate_field[i]);
+
+ hvm_set_cr0(__get_vvmcs(vvmcs, GUEST_CR0));
+ hvm_set_cr4(__get_vvmcs(vvmcs, GUEST_CR4));
+ hvm_set_cr3(__get_vvmcs(vvmcs, GUEST_CR3));
+
+ vvmcs_to_shadow(vvmcs, VM_ENTRY_INTR_INFO);
+ vvmcs_to_shadow(vvmcs, VM_ENTRY_EXCEPTION_ERROR_CODE);
+ vvmcs_to_shadow(vvmcs, VM_ENTRY_INSTRUCTION_LEN);
+
+ vvmcs_to_shadow(vvmcs, CR0_READ_SHADOW);
+ vvmcs_to_shadow(vvmcs, CR4_READ_SHADOW);
+ vvmcs_to_shadow(vvmcs, CR0_GUEST_HOST_MASK);
+ vvmcs_to_shadow(vvmcs, CR4_GUEST_HOST_MASK);
+
+ /* TODO: PDPTRs for nested ept */
+ /* TODO: CR3 target control */
+}
+
+static void virtual_vmentry(struct cpu_user_regs *regs)
+{
+ struct vcpu *v = current;
+ struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
+ void *vvmcs = nvcpu->nv_vvmcx;
+#ifdef __x86_64__
+ unsigned long lm_l1, lm_l2;
+#endif
+
+ vmx_vmcs_switch(v, v->arch.hvm_vmx.vmcs, nvcpu->nv_n2vmcx);
+
+ nestedhvm_vcpu_enter_guestmode(v);
+ nvcpu->nv_vmentry_pending = 0;
+ nvcpu->nv_vmswitch_in_progress = 1;
+
+#ifdef __x86_64__
+ /*
+ * EFER handling:
+ * hvm_set_efer won''t work if CR0.PG = 1, so we change the value
+ * directly to make hvm_long_mode_enabled(v) work in L2.
+ * An additional update_paging_modes is also needed if
+ * there is 32/64 switch. v->arch.hvm_vcpu.guest_efer doesn''t
+ * need to be saved, since its value on vmexit is determined by
+ * L1 exit_controls
+ */
+ lm_l1 = !!hvm_long_mode_enabled(v);
+ lm_l2 = !!(__get_vvmcs(vvmcs, VM_ENTRY_CONTROLS) &
+ VM_ENTRY_IA32E_MODE);
+
+ if ( lm_l2 )
+ v->arch.hvm_vcpu.guest_efer |= EFER_LMA | EFER_LME;
+ else
+ v->arch.hvm_vcpu.guest_efer &= ~(EFER_LMA | EFER_LME);
+#endif
+
+ load_shadow_control(v);
+ load_shadow_guest_state(v);
+
+#ifdef __x86_64__
+ if ( lm_l1 != lm_l2 )
+ {
+ paging_update_paging_modes(v);
+ }
+#endif
+
+ regs->rip = __get_vvmcs(vvmcs, GUEST_RIP);
+ regs->rsp = __get_vvmcs(vvmcs, GUEST_RSP);
+ regs->rflags = __get_vvmcs(vvmcs, GUEST_RFLAGS);
+
+ /* TODO: EPT_POINTER */
+}
+
+static void sync_vvmcs_guest_state(struct vcpu *v, struct cpu_user_regs *regs)
+{
+ int i;
+ unsigned long mask;
+ unsigned long cr;
+ struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
+ void *vvmcs = nvcpu->nv_vvmcx;
+
+ /* copy shadow vmcs.gstate back to vvmcs.gstate */
+ for ( i = 0; i < ARRAY_SIZE(vmcs_gstate_field); i++ )
+ shadow_to_vvmcs(vvmcs, vmcs_gstate_field[i]);
+ /* RIP, RSP are in user regs */
+ __set_vvmcs(vvmcs, GUEST_RIP, regs->rip);
+ __set_vvmcs(vvmcs, GUEST_RSP, regs->rsp);
+
+ /* SDM 20.6.6: L2 guest execution may change GUEST CR0/CR4 */
+ mask = __get_vvmcs(vvmcs, CR0_GUEST_HOST_MASK);
+ if ( ~mask )
+ {
+ cr = __get_vvmcs(vvmcs, GUEST_CR0);
+ cr = (cr & mask) | (__vmread(GUEST_CR0) & ~mask);
+ __set_vvmcs(vvmcs, GUEST_CR0, cr);
+ }
+
+ mask = __get_vvmcs(vvmcs, CR4_GUEST_HOST_MASK);
+ if ( ~mask )
+ {
+ cr = __get_vvmcs(vvmcs, GUEST_CR4);
+ cr = (cr & mask) | (__vmread(GUEST_CR4) & ~mask);
+ __set_vvmcs(vvmcs, GUEST_CR4, cr);
+ }
+
+ /* CR3 sync if exec doesn''t want cr3 load exiting: i.e. nested EPT
*/
+ if ( !(__n2_exec_control(v) & CPU_BASED_CR3_LOAD_EXITING) )
+ shadow_to_vvmcs(vvmcs, GUEST_CR3);
+}
+
+static void sync_vvmcs_ro(struct vcpu *v)
+{
+ int i;
+ struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
+
+ for ( i = 0; i < ARRAY_SIZE(vmcs_ro_field); i++ )
+ shadow_to_vvmcs(nvcpu->nv_vvmcx, vmcs_ro_field[i]);
+}
+
+static void load_vvmcs_host_state(struct vcpu *v)
+{
+ int i;
+ u64 r;
+ void *vvmcs = vcpu_nestedhvm(v).nv_vvmcx;
+
+ for ( i = 0; i < ARRAY_SIZE(vmcs_h2g_field); i++ )
+ {
+ r = __get_vvmcs(vvmcs, vmcs_h2g_field[i].host_field);
+ __vmwrite(vmcs_h2g_field[i].guest_field, r);
+ }
+
+ hvm_set_cr0(__get_vvmcs(vvmcs, HOST_CR0));
+ hvm_set_cr4(__get_vvmcs(vvmcs, HOST_CR4));
+ hvm_set_cr3(__get_vvmcs(vvmcs, HOST_CR3));
+
+ __set_vvmcs(vvmcs, VM_ENTRY_INTR_INFO, 0);
+}
+
+static void virtual_vmexit(struct cpu_user_regs *regs)
+{
+ struct vcpu *v = current;
+ struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
+#ifdef __x86_64__
+ unsigned long lm_l1, lm_l2;
+#endif
+
+ sync_vvmcs_ro(v);
+ sync_vvmcs_guest_state(v, regs);
+
+ vmx_vmcs_switch(v, v->arch.hvm_vmx.vmcs, nvcpu->nv_n1vmcx);
+
+ nestedhvm_vcpu_exit_guestmode(v);
+ nvcpu->nv_vmexit_pending = 0;
+
+#ifdef __x86_64__
+ lm_l2 = !!hvm_long_mode_enabled(v);
+ lm_l1 = !!(__get_vvmcs(nvcpu->nv_vvmcx, VM_EXIT_CONTROLS) &
+ VM_EXIT_IA32E_MODE);
+
+ if ( lm_l1 )
+ v->arch.hvm_vcpu.guest_efer |= EFER_LMA | EFER_LME;
+ else
+ v->arch.hvm_vcpu.guest_efer &= ~(EFER_LMA | EFER_LME);
+#endif
+
+ vmx_update_cpu_exec_control(v);
+ vmx_update_exception_bitmap(v);
+
+ load_vvmcs_host_state(v);
+
+#ifdef __x86_64__
+ if ( lm_l1 != lm_l2 )
+ paging_update_paging_modes(v);
+#endif
+
+ regs->rip = __get_vvmcs(nvcpu->nv_vvmcx, HOST_RIP);
+ regs->rsp = __get_vvmcs(nvcpu->nv_vvmcx, HOST_RSP);
+ regs->rflags = __vmread(GUEST_RFLAGS);
+
+ vmreturn(regs, VMSUCCEED);
+}
+
+asmlinkage void nvmx_switch_guest(void)
+{
+ struct vcpu *v = current;
+ struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
+ struct cpu_user_regs *regs = guest_cpu_user_regs();
+
+ /*
+ * a softirq may interrupt us between a virtual vmentry is
+ * just handled and the true vmentry. If during this window,
+ * a L1 virtual interrupt causes another virtual vmexit, we
+ * cannot let that happen or VM_ENTRY_INTR_INFO will be lost.
+ */
+ if ( unlikely(nvcpu->nv_vmswitch_in_progress) )
+ return;
+
+ if ( nestedhvm_vcpu_in_guestmode(v) && nvcpu->nv_vmexit_pending
)
+ virtual_vmexit(regs);
+ else if ( !nestedhvm_vcpu_in_guestmode(v) &&
nvcpu->nv_vmentry_pending )
+ virtual_vmentry(regs);
+}
+
+/*
* VMX instructions handling
*/
diff -r fc6a432d6c63 -r 04f112e54deb xen/include/asm-x86/hvm/vmx/vmcs.h
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h Thu Jun 09 16:24:09 2011 +0800
@@ -160,6 +160,7 @@ extern u32 vmx_cpu_based_exec_control;
#define PIN_BASED_PREEMPT_TIMER 0x00000040
extern u32 vmx_pin_based_exec_control;
+#define VM_EXIT_SAVE_DEBUG_CNTRLS 0x00000004
#define VM_EXIT_IA32E_MODE 0x00000200
#define VM_EXIT_ACK_INTR_ON_EXIT 0x00008000
#define VM_EXIT_SAVE_GUEST_PAT 0x00040000
diff -r fc6a432d6c63 -r 04f112e54deb xen/include/asm-x86/hvm/vmx/vvmx.h
--- a/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800
@@ -165,6 +165,7 @@ void nvmx_update_exec_control(struct vcp
void nvmx_update_secondary_exec_control(struct vcpu *v,
unsigned long value);
void nvmx_update_exception_bitmap(struct vcpu *v, unsigned long value);
+asmlinkage void nvmx_switch_guest(void);
#endif /* __ASM_X86_HVM_VVMX_H__ */
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Eddie Dong
2011-Jun-09 08:25 UTC
[Xen-devel] [PATCH 16 of 20] interrupt/exception handling for n2 guest
# HG changeset patch
# User Eddie Dong <eddie.dong@intel.com>
# Date 1307607849 -28800
# Node ID 4496678bbb000792aafa7e34a14ab893f5a32b8e
# Parent 04f112e54debd7ac0832b12d3258d8eb557ae7eb
interrupt/exception handling for n2 guest
Signed-off-by: Qing He <qing.he@intel.com>
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
diff -r 04f112e54deb -r 4496678bbb00 xen/arch/x86/hvm/vmx/intr.c
--- a/xen/arch/x86/hvm/vmx/intr.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/intr.c Thu Jun 09 16:24:09 2011 +0800
@@ -35,6 +35,7 @@
#include <asm/hvm/vmx/vmcs.h>
#include <asm/hvm/vpic.h>
#include <asm/hvm/vlapic.h>
+#include <asm/hvm/nestedhvm.h>
#include <public/hvm/ioreq.h>
#include <asm/hvm/trace.h>
@@ -109,6 +110,96 @@ static void enable_intr_window(struct vc
}
}
+/*
+ * Injecting interrupts for nested virtualization
+ *
+ * When injecting virtual interrupts (originated from L0), there are
+ * two major possibilities, within L1 context and within L2 context
+ * 1. L1 context (in_nesting == 0)
+ * Everything is the same as without nested, check RFLAGS.IF to
+ * see if the injection can be done, using VMCS to inject the
+ * interrupt
+ *
+ * 2. L2 context (in_nesting == 1)
+ * Causes a virtual VMExit, RFLAGS.IF is ignored, whether to ack
+ * irq according to intr_ack_on_exit, shouldn''t block normally,
+ * except for:
+ * a. context transition
+ * interrupt needs to be blocked at virtual VMEntry time
+ * b. L2 idtv reinjection
+ * if L2 idtv is handled within L0 (e.g. L0 shadow page fault),
+ * it needs to be reinjected without exiting to L1, interrupt
+ * injection should be blocked as well at this point.
+ *
+ * Unfortunately, interrupt blocking in L2 won''t work with simple
+ * intr_window_open (which depends on L2''s IF). To solve this,
+ * the following algorithm can be used:
+ * v->arch.hvm_vmx.exec_control.VIRTUAL_INTR_PENDING now denotes
+ * only L0 control, physical control may be different from it.
+ * - if in L1, it behaves normally, intr window is written
+ * to physical control as it is
+ * - if in L2, replace it to MTF (or NMI window) if possible
+ * - if MTF/NMI window is not used, intr window can still be
+ * used but may have negative impact on interrupt performance.
+ */
+
+enum hvm_intblk nvmx_intr_blocked(struct vcpu *v)
+{
+ int r = hvm_intblk_none;
+ struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
+
+ if ( nestedhvm_vcpu_in_guestmode(v) )
+ {
+ if ( nvcpu->nv_vmexit_pending ||
+ nvcpu->nv_vmswitch_in_progress ||
+ (__vmread(VM_ENTRY_INTR_INFO) & INTR_INFO_VALID_MASK) )
+ r = hvm_intblk_rflags_ie;
+ }
+ else if ( nvcpu->nv_vmentry_pending )
+ r = hvm_intblk_rflags_ie;
+
+ return r;
+}
+
+static int nvmx_intr_intercept(struct vcpu *v, struct hvm_intack intack)
+{
+ u32 exit_ctrl;
+
+ if ( nvmx_intr_blocked(v) != hvm_intblk_none )
+ {
+ enable_intr_window(v, intack);
+ return 1;
+ }
+
+ if ( nestedhvm_vcpu_in_guestmode(v) )
+ {
+ if ( intack.source == hvm_intsrc_pic ||
+ intack.source == hvm_intsrc_lapic )
+ {
+ vmx_inject_extint(intack.vector);
+
+ exit_ctrl = __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx,
+ VM_EXIT_CONTROLS);
+ if ( exit_ctrl & VM_EXIT_ACK_INTR_ON_EXIT )
+ {
+ /* for now, duplicate the ack path in vmx_intr_assist */
+ hvm_vcpu_ack_pending_irq(v, intack);
+ pt_intr_post(v, intack);
+
+ intack = hvm_vcpu_has_pending_irq(v);
+ if ( unlikely(intack.source != hvm_intsrc_none) )
+ enable_intr_window(v, intack);
+ }
+ else
+ enable_intr_window(v, intack);
+
+ return 1;
+ }
+ }
+
+ return 0;
+}
+
asmlinkage void vmx_intr_assist(void)
{
struct hvm_intack intack;
@@ -132,6 +223,9 @@ asmlinkage void vmx_intr_assist(void)
if ( likely(intack.source == hvm_intsrc_none) )
goto out;
+ if ( unlikely(nvmx_intr_intercept(v, intack)) )
+ goto out;
+
intblk = hvm_interrupt_blocked(v, intack);
if ( intblk == hvm_intblk_tpr )
{
diff -r 04f112e54deb -r 4496678bbb00 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vmx.c Thu Jun 09 16:24:09 2011 +0800
@@ -1243,6 +1243,31 @@ void ept_sync_domain(struct domain *d)
__ept_sync_domain, d, 1);
}
+void nvmx_enqueue_n2_exceptions(struct vcpu *v,
+ unsigned long intr_fields, int error_code)
+{
+ struct nestedvmx *nvmx = &vcpu_2_nvmx(v);
+
+ if ( !(nvmx->intr.intr_info & INTR_INFO_VALID_MASK) ) {
+ /* enqueue the exception till the VMCS switch back to L1 */
+ nvmx->intr.intr_info = intr_fields;
+ nvmx->intr.error_code = error_code;
+ vcpu_nestedhvm(v).nv_vmexit_pending = 1;
+ return;
+ }
+ else
+ gdprintk(XENLOG_ERR, "Double Fault on Nested Guest: exception %lx
%x"
+ "on %lx %x\n", intr_fields, error_code,
+ nvmx->intr.intr_info, nvmx->intr.error_code);
+}
+
+static int nvmx_vmexit_exceptions(struct vcpu *v, unsigned int trapnr,
+ int errcode, unsigned long cr2)
+{
+ nvmx_enqueue_n2_exceptions(v, trapnr, errcode);
+ return NESTEDHVM_VMEXIT_DONE;
+}
+
static void __vmx_inject_exception(int trap, int type, int error_code)
{
unsigned long intr_fields;
@@ -1272,11 +1297,16 @@ static void __vmx_inject_exception(int t
void vmx_inject_hw_exception(int trap, int error_code)
{
- unsigned long intr_info = __vmread(VM_ENTRY_INTR_INFO);
+ unsigned long intr_info;
struct vcpu *curr = current;
int type = X86_EVENTTYPE_HW_EXCEPTION;
+ if ( nestedhvm_vcpu_in_guestmode(curr) )
+ intr_info = vcpu_2_nvmx(curr).intr.intr_info;
+ else
+ intr_info = __vmread(VM_ENTRY_INTR_INFO);
+
switch ( trap )
{
case TRAP_debug:
@@ -1308,7 +1338,16 @@ void vmx_inject_hw_exception(int trap, i
error_code = 0;
}
- __vmx_inject_exception(trap, type, error_code);
+ if ( nestedhvm_vcpu_in_guestmode(curr) &&
+ nvmx_intercepts_exception(curr, trap, error_code) )
+ {
+ nvmx_enqueue_n2_exceptions (curr,
+ INTR_INFO_VALID_MASK | (type<<8) | trap,
+ error_code);
+ return;
+ }
+ else
+ __vmx_inject_exception(trap, type, error_code);
if ( trap == TRAP_page_fault )
HVMTRACE_LONG_2D(PF_INJECT, error_code,
@@ -1319,12 +1358,38 @@ void vmx_inject_hw_exception(int trap, i
void vmx_inject_extint(int trap)
{
+ struct vcpu *v = current;
+ u32 pin_based_cntrl;
+
+ if ( nestedhvm_vcpu_in_guestmode(v) ) {
+ pin_based_cntrl = __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx,
+ PIN_BASED_VM_EXEC_CONTROL);
+ if ( pin_based_cntrl && PIN_BASED_EXT_INTR_MASK ) {
+ nvmx_enqueue_n2_exceptions (v,
+ INTR_INFO_VALID_MASK | (X86_EVENTTYPE_EXT_INTR<<8) | trap,
+ HVM_DELIVER_NO_ERROR_CODE);
+ return;
+ }
+ }
__vmx_inject_exception(trap, X86_EVENTTYPE_EXT_INTR,
HVM_DELIVER_NO_ERROR_CODE);
}
void vmx_inject_nmi(void)
{
+ struct vcpu *v = current;
+ u32 pin_based_cntrl;
+
+ if ( nestedhvm_vcpu_in_guestmode(v) ) {
+ pin_based_cntrl = __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx,
+ PIN_BASED_VM_EXEC_CONTROL);
+ if ( pin_based_cntrl && PIN_BASED_NMI_EXITING ) {
+ nvmx_enqueue_n2_exceptions (v,
+ INTR_INFO_VALID_MASK | (X86_EVENTTYPE_NMI<<8) | TRAP_nmi,
+ HVM_DELIVER_NO_ERROR_CODE);
+ return;
+ }
+ }
__vmx_inject_exception(2, X86_EVENTTYPE_NMI,
HVM_DELIVER_NO_ERROR_CODE);
}
@@ -1424,7 +1489,10 @@ static struct hvm_function_table __read_
.nhvm_vcpu_reset = nvmx_vcpu_reset,
.nhvm_vcpu_guestcr3 = nvmx_vcpu_guestcr3,
.nhvm_vcpu_hostcr3 = nvmx_vcpu_hostcr3,
- .nhvm_vcpu_asid = nvmx_vcpu_asid
+ .nhvm_vcpu_asid = nvmx_vcpu_asid,
+ .nhvm_vmcx_guest_intercepts_trap = nvmx_intercepts_exception,
+ .nhvm_vcpu_vmexit_trap = nvmx_vmexit_exceptions,
+ .nhvm_intr_blocked = nvmx_intr_blocked
};
struct hvm_function_table * __init start_vmx(void)
@@ -2237,7 +2305,8 @@ asmlinkage void vmx_vmexit_handler(struc
hvm_maybe_deassert_evtchn_irq();
idtv_info = __vmread(IDT_VECTORING_INFO);
- if ( exit_reason != EXIT_REASON_TASK_SWITCH )
+ if ( !nestedhvm_vcpu_in_guestmode(v) &&
+ exit_reason != EXIT_REASON_TASK_SWITCH )
vmx_idtv_reinject(idtv_info);
switch ( exit_reason )
@@ -2585,6 +2654,9 @@ asmlinkage void vmx_vmexit_handler(struc
domain_crash(v->domain);
break;
}
+
+ if ( nestedhvm_vcpu_in_guestmode(v) )
+ nvmx_idtv_handling();
}
asmlinkage void vmx_vmenter_helper(void)
diff -r 04f112e54deb -r 4496678bbb00 xen/arch/x86/hvm/vmx/vvmx.c
--- a/xen/arch/x86/hvm/vmx/vvmx.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vvmx.c Thu Jun 09 16:24:09 2011 +0800
@@ -391,6 +391,27 @@ static void vmreturn(struct cpu_user_reg
regs->eflags = eflags;
}
+int nvmx_intercepts_exception(struct vcpu *v, unsigned int trap,
+ int error_code)
+{
+ struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
+ u32 exception_bitmap, pfec_match=0, pfec_mask=0;
+ int r;
+
+ ASSERT ( trap < 32 );
+
+ exception_bitmap = __get_vvmcs(nvcpu->nv_vvmcx, EXCEPTION_BITMAP);
+ r = exception_bitmap & (1 << trap) ? 1: 0;
+
+ if ( trap == TRAP_page_fault ) {
+ pfec_match = __get_vvmcs(nvcpu->nv_vvmcx,
PAGE_FAULT_ERROR_CODE_MATCH);
+ pfec_mask = __get_vvmcs(nvcpu->nv_vvmcx,
PAGE_FAULT_ERROR_CODE_MASK);
+ if ( (error_code & pfec_mask) != pfec_match )
+ r = !r;
+ }
+ return r;
+}
+
/*
* Nested VMX uses "strict" condition to exit from
* L2 guest if either L1 VMM or L0 VMM expect to exit.
@@ -464,6 +485,7 @@ void nvmx_update_exec_control(struct vcp
__vmwrite(IO_BITMAP_B, virt_to_maddr(bitmap) + PAGE_SIZE);
}
+ /* TODO: change L0 intr window to MTF or NMI window */
__vmwrite(CPU_BASED_VM_EXEC_CONTROL, shadow_cntrl);
}
@@ -846,6 +868,42 @@ static void load_vvmcs_host_state(struct
__set_vvmcs(vvmcs, VM_ENTRY_INTR_INFO, 0);
}
+static void sync_exception_state(struct vcpu *v)
+{
+ struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
+ struct nestedvmx *nvmx = &vcpu_2_nvmx(v);
+
+ if ( !(nvmx->intr.intr_info & INTR_INFO_VALID_MASK) )
+ return;
+
+ switch ( (nvmx->intr.intr_info & INTR_INFO_INTR_TYPE_MASK) >>
8 )
+ {
+ case X86_EVENTTYPE_EXT_INTR:
+ /* rename exit_reason to EXTERNAL_INTERRUPT */
+ __set_vvmcs(nvcpu->nv_vvmcx, VM_EXIT_REASON,
+ EXIT_REASON_EXTERNAL_INTERRUPT);
+ __set_vvmcs(nvcpu->nv_vvmcx, EXIT_QUALIFICATION, 0);
+ __set_vvmcs(nvcpu->nv_vvmcx, VM_EXIT_INTR_INFO,
+ nvmx->intr.intr_info);
+ break;
+
+ case X86_EVENTTYPE_HW_EXCEPTION:
+ case X86_EVENTTYPE_SW_INTERRUPT:
+ case X86_EVENTTYPE_SW_EXCEPTION:
+ /* throw to L1 */
+ __set_vvmcs(nvcpu->nv_vvmcx, VM_EXIT_INTR_INFO,
+ nvmx->intr.intr_info);
+ __set_vvmcs(nvcpu->nv_vvmcx, VM_EXIT_INTR_ERROR_CODE,
+ nvmx->intr.error_code);
+ break;
+ case X86_EVENTTYPE_NMI:
+ default:
+ gdprintk(XENLOG_ERR, "Exception state %lx not handled\n",
+ nvmx->intr.intr_info);
+ break;
+ }
+}
+
static void virtual_vmexit(struct cpu_user_regs *regs)
{
struct vcpu *v = current;
@@ -856,6 +914,7 @@ static void virtual_vmexit(struct cpu_us
sync_vvmcs_ro(v);
sync_vvmcs_guest_state(v, regs);
+ sync_exception_state(v);
vmx_vmcs_switch(v, v->arch.hvm_vmx.vmcs, nvcpu->nv_n1vmcx);
@@ -1167,3 +1226,38 @@ int nvmx_handle_vmwrite(struct cpu_user_
return X86EMUL_OKAY;
}
+void nvmx_idtv_handling(void)
+{
+ struct vcpu *v = current;
+ struct nestedvmx *nvmx = &vcpu_2_nvmx(v);
+ struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
+ unsigned int idtv_info = __vmread(IDT_VECTORING_INFO);
+
+ if ( likely(!(idtv_info & INTR_INFO_VALID_MASK)) )
+ return;
+
+ /*
+ * If L0 can solve the fault that causes idt vectoring, it should
+ * be reinjected, otherwise, pass to L1.
+ */
+ if ( (__vmread(VM_EXIT_REASON) != EXIT_REASON_EPT_VIOLATION &&
+ !(nvmx->intr.intr_info & INTR_INFO_VALID_MASK)) ||
+ (__vmread(VM_EXIT_REASON) == EXIT_REASON_EPT_VIOLATION &&
+ !nvcpu->nv_vmexit_pending) )
+ {
+ __vmwrite(VM_ENTRY_INTR_INFO, idtv_info &
~INTR_INFO_RESVD_BITS_MASK);
+ if ( idtv_info & INTR_INFO_DELIVER_CODE_MASK )
+ __vmwrite(VM_ENTRY_EXCEPTION_ERROR_CODE,
+ __vmread(IDT_VECTORING_ERROR_CODE));
+ /*
+ * SDM 23.2.4, if L1 tries to inject a software interrupt
+ * and the delivery fails, VM_EXIT_INSTRUCTION_LEN receives
+ * the value of previous VM_ENTRY_INSTRUCTION_LEN.
+ *
+ * This means EXIT_INSTRUCTION_LEN is always valid here, for
+ * software interrupts both injected by L1, and generated in L2.
+ */
+ __vmwrite(VM_ENTRY_INSTRUCTION_LEN, __vmread(VM_EXIT_INSTRUCTION_LEN));
+ }
+}
+
diff -r 04f112e54deb -r 4496678bbb00 xen/include/asm-x86/hvm/vmx/vvmx.h
--- a/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800
@@ -93,6 +93,9 @@ int nvmx_vcpu_reset(struct vcpu *v);
uint64_t nvmx_vcpu_guestcr3(struct vcpu *v);
uint64_t nvmx_vcpu_hostcr3(struct vcpu *v);
uint32_t nvmx_vcpu_asid(struct vcpu *v);
+enum hvm_intblk nvmx_intr_blocked(struct vcpu *v);
+int nvmx_intercepts_exception(struct vcpu *v,
+ unsigned int trap, int error_code);
int nvmx_handle_vmxon(struct cpu_user_regs *regs);
int nvmx_handle_vmxoff(struct cpu_user_regs *regs);
@@ -166,6 +169,7 @@ void nvmx_update_secondary_exec_control(
unsigned long value);
void nvmx_update_exception_bitmap(struct vcpu *v, unsigned long value);
asmlinkage void nvmx_switch_guest(void);
+void nvmx_idtv_handling(void);
#endif /* __ASM_X86_HVM_VVMX_H__ */
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
# HG changeset patch
# User Eddie Dong <eddie.dong@intel.com>
# Date 1307607849 -28800
# Node ID 5c3ab1e07ab1c1a903660f1c48a54aa67f738a7e
# Parent 4496678bbb000792aafa7e34a14ab893f5a32b8e
VM exit handler of n2-guest
Signed-off-by: Qing He <qing.he@intel.com>
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
diff -r 4496678bbb00 -r 5c3ab1e07ab1 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vmx.c Thu Jun 09 16:24:09 2011 +0800
@@ -943,6 +943,10 @@ static void vmx_set_segment_register(str
static void vmx_set_tsc_offset(struct vcpu *v, u64 offset)
{
vmx_vmcs_enter(v);
+
+ if ( nestedhvm_vcpu_in_guestmode(v) )
+ offset += nvmx_get_tsc_offset(v);
+
__vmwrite(TSC_OFFSET, offset);
#if defined (__i386__)
__vmwrite(TSC_OFFSET_HIGH, offset >> 32);
@@ -2258,6 +2262,11 @@ asmlinkage void vmx_vmexit_handler(struc
* any pending vmresume has really happened
*/
vcpu_nestedhvm(v).nv_vmswitch_in_progress = 0;
+ if ( nestedhvm_vcpu_in_guestmode(v) )
+ {
+ if ( nvmx_n2_vmexit_handler(regs, exit_reason) )
+ goto out;
+ }
if ( unlikely(exit_reason & VMX_EXIT_REASONS_FAILED_VMENTRY) )
return vmx_failed_vmentry(exit_reason, regs);
@@ -2655,6 +2664,7 @@ asmlinkage void vmx_vmexit_handler(struc
break;
}
+out:
if ( nestedhvm_vcpu_in_guestmode(v) )
nvmx_idtv_handling();
}
diff -r 4496678bbb00 -r 5c3ab1e07ab1 xen/arch/x86/hvm/vmx/vvmx.c
--- a/xen/arch/x86/hvm/vmx/vvmx.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vvmx.c Thu Jun 09 16:24:09 2011 +0800
@@ -286,13 +286,19 @@ static int vmx_inst_check_privilege(stru
if ( (regs->eflags & X86_EFLAGS_VM) ||
(hvm_long_mode_enabled(v) && cs.attr.fields.l == 0) )
goto invalid_op;
- /* TODO: check vmx operation mode */
+ else if ( nestedhvm_vcpu_in_guestmode(v) )
+ goto vmexit;
if ( (cs.sel & 3) > 0 )
goto gp_fault;
return X86EMUL_OKAY;
+vmexit:
+ gdprintk(XENLOG_ERR, "vmx_inst_check_privilege: vmexit\n");
+ vcpu_nestedhvm(v).nv_vmexit_pending = 1;
+ return X86EMUL_EXCEPTION;
+
invalid_op:
gdprintk(XENLOG_ERR, "vmx_inst_check_privilege: invalid_op\n");
hvm_inject_exception(TRAP_invalid_op, 0, 0);
@@ -589,6 +595,18 @@ static void nvmx_purge_vvmcs(struct vcpu
}
}
+u64 nvmx_get_tsc_offset(struct vcpu *v)
+{
+ u64 offset = 0;
+ struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
+
+ if ( __get_vvmcs(nvcpu->nv_vvmcx, CPU_BASED_VM_EXEC_CONTROL) &
+ CPU_BASED_USE_TSC_OFFSETING )
+ offset = __get_vvmcs(nvcpu->nv_vvmcx, TSC_OFFSET);
+
+ return offset;
+}
+
/*
* Context synchronized between shadow and virtual VMCS.
*/
@@ -738,6 +756,8 @@ static void load_shadow_guest_state(stru
hvm_set_cr4(__get_vvmcs(vvmcs, GUEST_CR4));
hvm_set_cr3(__get_vvmcs(vvmcs, GUEST_CR3));
+ hvm_funcs.set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset);
+
vvmcs_to_shadow(vvmcs, VM_ENTRY_INTR_INFO);
vvmcs_to_shadow(vvmcs, VM_ENTRY_EXCEPTION_ERROR_CODE);
vvmcs_to_shadow(vvmcs, VM_ENTRY_INSTRUCTION_LEN);
@@ -865,6 +885,8 @@ static void load_vvmcs_host_state(struct
hvm_set_cr4(__get_vvmcs(vvmcs, HOST_CR4));
hvm_set_cr3(__get_vvmcs(vvmcs, HOST_CR3));
+ hvm_funcs.set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset);
+
__set_vvmcs(vvmcs, VM_ENTRY_INTR_INFO, 0);
}
@@ -1261,3 +1283,195 @@ void nvmx_idtv_handling(void)
}
}
+/*
+ * L2 VMExit handling
+ * return 1: Done or skip the normal layer 0 hypervisor process.
+ * Typically it requires layer 1 hypervisor processing
+ * or it may be already processed here.
+ * 0: Require the normal layer 0 process.
+ */
+int nvmx_n2_vmexit_handler(struct cpu_user_regs *regs,
+ unsigned int exit_reason)
+{
+ struct vcpu *v = current;
+ struct nestedvcpu *nvcpu = &vcpu_nestedhvm(v);
+ struct nestedvmx *nvmx = &vcpu_2_nvmx(v);
+ u32 ctrl;
+ u16 port;
+ u8 *bitmap;
+
+ nvcpu->nv_vmexit_pending = 0;
+ nvmx->intr.intr_info = 0;
+ nvmx->intr.error_code = 0;
+
+ switch (exit_reason) {
+ case EXIT_REASON_EXCEPTION_NMI:
+ {
+ u32 intr_info = __vmread(VM_EXIT_INTR_INFO);
+ u32 valid_mask = (X86_EVENTTYPE_HW_EXCEPTION << 8) |
+ INTR_INFO_VALID_MASK;
+ u64 exec_bitmap;
+ int vector = intr_info & INTR_INFO_VECTOR_MASK;
+
+ /*
+ * decided by L0 and L1 exception bitmap, if the vetor is set by
+ * both, L0 has priority on #PF, L1 has priority on others
+ */
+ if ( vector == TRAP_page_fault )
+ {
+ if ( paging_mode_hap(v->domain) )
+ nvcpu->nv_vmexit_pending = 1;
+ }
+ else if ( (intr_info & valid_mask) == valid_mask )
+ {
+ exec_bitmap =__get_vvmcs(nvcpu->nv_vvmcx, EXCEPTION_BITMAP);
+
+ if ( exec_bitmap & (1 << vector) )
+ nvcpu->nv_vmexit_pending = 1;
+ }
+ break;
+ }
+ case EXIT_REASON_WBINVD:
+ case EXIT_REASON_EPT_VIOLATION:
+ case EXIT_REASON_EPT_MISCONFIG:
+ case EXIT_REASON_EXTERNAL_INTERRUPT:
+ /* pass to L0 handler */
+ break;
+ case VMX_EXIT_REASONS_FAILED_VMENTRY:
+ case EXIT_REASON_TRIPLE_FAULT:
+ case EXIT_REASON_TASK_SWITCH:
+ case EXIT_REASON_CPUID:
+ case EXIT_REASON_MSR_READ:
+ case EXIT_REASON_MSR_WRITE:
+ case EXIT_REASON_VMCALL:
+ case EXIT_REASON_VMCLEAR:
+ case EXIT_REASON_VMLAUNCH:
+ case EXIT_REASON_VMPTRLD:
+ case EXIT_REASON_VMPTRST:
+ case EXIT_REASON_VMREAD:
+ case EXIT_REASON_VMRESUME:
+ case EXIT_REASON_VMWRITE:
+ case EXIT_REASON_VMXOFF:
+ case EXIT_REASON_VMXON:
+ case EXIT_REASON_INVEPT:
+ /* inject to L1 */
+ nvcpu->nv_vmexit_pending = 1;
+ break;
+ case EXIT_REASON_IO_INSTRUCTION:
+ ctrl = __n2_exec_control(v);
+ if ( ctrl & CPU_BASED_ACTIVATE_IO_BITMAP )
+ {
+ port = __vmread(EXIT_QUALIFICATION) >> 16;
+ bitmap = nvmx->iobitmap[port >> 15];
+ if ( bitmap[(port <<1) >> 4] & (1 << (port
& 0x7)) )
+ nvcpu->nv_vmexit_pending = 1;
+ if ( !nvcpu->nv_vmexit_pending )
+ gdprintk(XENLOG_WARNING, "L0 PIO %x.\n", port);
+ }
+ else if ( ctrl & CPU_BASED_UNCOND_IO_EXITING )
+ nvcpu->nv_vmexit_pending = 1;
+ break;
+
+ case EXIT_REASON_PENDING_VIRT_INTR:
+ ctrl = __n2_exec_control(v);
+ if ( ctrl & CPU_BASED_VIRTUAL_INTR_PENDING )
+ nvcpu->nv_vmexit_pending = 1;
+ break;
+ case EXIT_REASON_PENDING_VIRT_NMI:
+ ctrl = __n2_exec_control(v);
+ if ( ctrl & CPU_BASED_VIRTUAL_NMI_PENDING )
+ nvcpu->nv_vmexit_pending = 1;
+ break;
+ /* L1 has priority handling several other types of exits */
+ case EXIT_REASON_HLT:
+ ctrl = __n2_exec_control(v);
+ if ( ctrl & CPU_BASED_HLT_EXITING )
+ nvcpu->nv_vmexit_pending = 1;
+ break;
+ case EXIT_REASON_RDTSC:
+ ctrl = __n2_exec_control(v);
+ if ( ctrl & CPU_BASED_RDTSC_EXITING )
+ nvcpu->nv_vmexit_pending = 1;
+ else
+ {
+ uint64_t tsc;
+
+ /*
+ * special handler is needed if L1 doesn''t intercept
rdtsc,
+ * avoiding changing guest_tsc and messing up timekeeping in L1
+ */
+ tsc = hvm_get_guest_tsc(v);
+ tsc += __get_vvmcs(nvcpu->nv_vvmcx, TSC_OFFSET);
+ regs->eax = (uint32_t)tsc;
+ regs->edx = (uint32_t)(tsc >> 32);
+
+ return 1;
+ }
+ break;
+ case EXIT_REASON_RDPMC:
+ ctrl = __n2_exec_control(v);
+ if ( ctrl & CPU_BASED_RDPMC_EXITING )
+ nvcpu->nv_vmexit_pending = 1;
+ break;
+ case EXIT_REASON_MWAIT_INSTRUCTION:
+ ctrl = __n2_exec_control(v);
+ if ( ctrl & CPU_BASED_MWAIT_EXITING )
+ nvcpu->nv_vmexit_pending = 1;
+ break;
+ case EXIT_REASON_PAUSE_INSTRUCTION:
+ ctrl = __n2_exec_control(v);
+ if ( ctrl & CPU_BASED_PAUSE_EXITING )
+ nvcpu->nv_vmexit_pending = 1;
+ break;
+ case EXIT_REASON_MONITOR_INSTRUCTION:
+ ctrl = __n2_exec_control(v);
+ if ( ctrl & CPU_BASED_MONITOR_EXITING )
+ nvcpu->nv_vmexit_pending = 1;
+ break;
+ case EXIT_REASON_DR_ACCESS:
+ ctrl = __n2_exec_control(v);
+ if ( ctrl & CPU_BASED_MOV_DR_EXITING )
+ nvcpu->nv_vmexit_pending = 1;
+ break;
+ case EXIT_REASON_INVLPG:
+ ctrl = __n2_exec_control(v);
+ if ( ctrl & CPU_BASED_INVLPG_EXITING )
+ nvcpu->nv_vmexit_pending = 1;
+ break;
+ case EXIT_REASON_CR_ACCESS:
+ {
+ u64 exit_qualification = __vmread(EXIT_QUALIFICATION);
+ int cr = exit_qualification & 15;
+ int write = (exit_qualification >> 4) & 3;
+ u32 mask = 0;
+
+ /* also according to guest exec_control */
+ ctrl = __n2_exec_control(v);
+
+ if ( cr == 3 )
+ {
+ mask = write? CPU_BASED_CR3_STORE_EXITING:
+ CPU_BASED_CR3_LOAD_EXITING;
+ if ( ctrl & mask )
+ nvcpu->nv_vmexit_pending = 1;
+ }
+ else if ( cr == 8 )
+ {
+ mask = write? CPU_BASED_CR8_STORE_EXITING:
+ CPU_BASED_CR8_LOAD_EXITING;
+ if ( ctrl & mask )
+ nvcpu->nv_vmexit_pending = 1;
+ }
+ else /* CR0, CR4, CLTS, LMSW */
+ nvcpu->nv_vmexit_pending = 1;
+
+ break;
+ }
+ default:
+ gdprintk(XENLOG_WARNING, "Unknown nested vmexit reason
%x.\n",
+ exit_reason);
+ }
+
+ return ( nvcpu->nv_vmexit_pending == 1 );
+}
+
diff -r 4496678bbb00 -r 5c3ab1e07ab1 xen/include/asm-x86/hvm/vmx/vvmx.h
--- a/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800
@@ -170,6 +170,9 @@ void nvmx_update_secondary_exec_control(
void nvmx_update_exception_bitmap(struct vcpu *v, unsigned long value);
asmlinkage void nvmx_switch_guest(void);
void nvmx_idtv_handling(void);
+u64 nvmx_get_tsc_offset(struct vcpu *v);
+int nvmx_n2_vmexit_handler(struct cpu_user_regs *regs,
+ unsigned int exit_reason);
#endif /* __ASM_X86_HVM_VVMX_H__ */
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
# HG changeset patch
# User Eddie Dong <eddie.dong@intel.com>
# Date 1307607849 -28800
# Node ID 187ed9f1603db8a09f465cc67a8febce716d4744
# Parent 5c3ab1e07ab1c1a903660f1c48a54aa67f738a7e
Lazy FPU for n2 guest
Signed-off-by: Qing He <qing.he@intel.com>
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
diff -r 5c3ab1e07ab1 -r 187ed9f1603d xen/arch/x86/hvm/vmx/vvmx.c
--- a/xen/arch/x86/hvm/vmx/vvmx.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vvmx.c Thu Jun 09 16:24:09 2011 +0800
@@ -820,6 +820,9 @@ static void virtual_vmentry(struct cpu_u
regs->rsp = __get_vvmcs(vvmcs, GUEST_RSP);
regs->rflags = __get_vvmcs(vvmcs, GUEST_RFLAGS);
+ /* updating host cr0 to sync TS bit */
+ __vmwrite(HOST_CR0, v->arch.hvm_vmx.host_cr0);
+
/* TODO: EPT_POINTER */
}
@@ -968,6 +971,9 @@ static void virtual_vmexit(struct cpu_us
regs->rsp = __get_vvmcs(nvcpu->nv_vvmcx, HOST_RSP);
regs->rflags = __vmread(GUEST_RFLAGS);
+ /* updating host cr0 to sync TS bit */
+ __vmwrite(HOST_CR0, v->arch.hvm_vmx.host_cr0);
+
vmreturn(regs, VMSUCCEED);
}
@@ -1315,13 +1321,18 @@ int nvmx_n2_vmexit_handler(struct cpu_us
/*
* decided by L0 and L1 exception bitmap, if the vetor is set by
- * both, L0 has priority on #PF, L1 has priority on others
+ * both, L0 has priority on #PF and #NM, L1 has priority on others
*/
if ( vector == TRAP_page_fault )
{
if ( paging_mode_hap(v->domain) )
nvcpu->nv_vmexit_pending = 1;
}
+ else if ( vector == TRAP_no_device )
+ {
+ if ( v->fpu_dirtied )
+ nvcpu->nv_vmexit_pending = 1;
+ }
else if ( (intr_info & valid_mask) == valid_mask )
{
exec_bitmap =__get_vvmcs(nvcpu->nv_vvmcx, EXCEPTION_BITMAP);
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Eddie Dong
2011-Jun-09 08:25 UTC
[Xen-devel] [PATCH 19 of 20] Add VMXE bits in virtual CR4
# HG changeset patch
# User Eddie Dong <eddie.dong@intel.com>
# Date 1307607849 -28800
# Node ID 3189a3e6f05ecc7e14bc55e944c48d7e50613a96
# Parent 187ed9f1603db8a09f465cc67a8febce716d4744
Add VMXE bits in virtual CR4
Signed-off-by: Qing He <qing.he@intel.com>
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
diff -r 187ed9f1603d -r 3189a3e6f05e xen/include/asm-x86/cpufeature.h
--- a/xen/include/asm-x86/cpufeature.h Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/include/asm-x86/cpufeature.h Thu Jun 09 16:24:09 2011 +0800
@@ -216,6 +216,8 @@
#define cpu_has_svm boot_cpu_has(X86_FEATURE_SVM)
+#define cpu_has_vmx boot_cpu_has(X86_FEATURE_VMXE)
+
#endif /* __ASM_I386_CPUFEATURE_H */
/*
diff -r 187ed9f1603d -r 3189a3e6f05e xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/include/asm-x86/hvm/hvm.h Thu Jun 09 16:24:09 2011 +0800
@@ -313,6 +313,7 @@ static inline int hvm_do_pmu_interrupt(s
X86_CR4_DE | X86_CR4_PSE | X86_CR4_PAE | \
X86_CR4_MCE | X86_CR4_PGE | X86_CR4_PCE | \
X86_CR4_OSFXSR | X86_CR4_OSXMMEXCPT | \
+ (cpu_has_vmx ? X86_CR4_VMXE : 0) | \
(xsave_enabled(_v) ? X86_CR4_OSXSAVE : 0))))
/* These exceptions must always be intercepted. */
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Eddie Dong
2011-Jun-09 08:25 UTC
[Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
# HG changeset patch
# User Eddie Dong <eddie.dong@intel.com>
# Date 1307607849 -28800
# Node ID 480cfcea095bddb2e7c495a092632e80d552332d
# Parent 3189a3e6f05ecc7e14bc55e944c48d7e50613a96
n2 MSR handling and capability exposure
Signed-off-by: Qing He <qing.he@intel.com>
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
diff -r 3189a3e6f05e -r 480cfcea095b xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vmx.c Thu Jun 09 16:24:09 2011 +0800
@@ -1778,8 +1778,11 @@ static int vmx_msr_read_intercept(unsign
*msr_content |= (u64)__vmread(GUEST_IA32_DEBUGCTL_HIGH) << 32;
#endif
break;
- case MSR_IA32_VMX_BASIC...MSR_IA32_VMX_PROCBASED_CTLS2:
- goto gp_fault;
+ case IA32_FEATURE_CONTROL_MSR:
+ case MSR_IA32_VMX_BASIC...MSR_IA32_VMX_TRUE_ENTRY_CTLS:
+ if ( !nvmx_msr_read_intercept(msr, msr_content) )
+ goto gp_fault;
+ break;
case MSR_IA32_MISC_ENABLE:
rdmsrl(MSR_IA32_MISC_ENABLE, *msr_content);
/* Debug Trace Store is not supported. */
@@ -1940,8 +1943,11 @@ static int vmx_msr_write_intercept(unsig
break;
}
- case MSR_IA32_VMX_BASIC...MSR_IA32_VMX_PROCBASED_CTLS2:
- goto gp_fault;
+ case IA32_FEATURE_CONTROL_MSR:
+ case MSR_IA32_VMX_BASIC...MSR_IA32_VMX_TRUE_ENTRY_CTLS:
+ if ( !nvmx_msr_write_intercept(msr, msr_content) )
+ goto gp_fault;
+ break;
default:
if ( vpmu_do_wrmsr(msr, msr_content) )
return X86EMUL_OKAY;
diff -r 3189a3e6f05e -r 480cfcea095b xen/arch/x86/hvm/vmx/vvmx.c
--- a/xen/arch/x86/hvm/vmx/vvmx.c Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vvmx.c Thu Jun 09 16:24:09 2011 +0800
@@ -22,6 +22,7 @@
#include <xen/config.h>
#include <asm/types.h>
+#include <asm/mtrr.h>
#include <asm/p2m.h>
#include <asm/hvm/vmx/vmx.h>
#include <asm/hvm/vmx/vvmx.h>
@@ -1254,6 +1255,100 @@ int nvmx_handle_vmwrite(struct cpu_user_
return X86EMUL_OKAY;
}
+/*
+ * Capability reporting
+ */
+int nvmx_msr_read_intercept(unsigned int msr, u64 *msr_content)
+{
+ u64 data = 0, tmp;
+ int r = 1;
+
+ if ( !nestedhvm_enabled(current->domain) )
+ return 0;
+
+ /*
+ * Remove unsupport features from n1 guest capability MSR
+ */
+ switch (msr) {
+ case MSR_IA32_VMX_BASIC:
+ data = VVMCS_REVISION | (PAGE_SIZE) << 32 |
+ ((u64)MTRR_TYPE_WRBACK) << 50 | (1L << 55);
+ break;
+ case MSR_IA32_VMX_PINBASED_CTLS:
+ /* 1-seetings */
+ data = PIN_BASED_EXT_INTR_MASK | PIN_BASED_NMI_EXITING;
+ data <<= 32;
+ /* 0-settings */
+ data |= 0;
+ break;
+ case MSR_IA32_VMX_PROCBASED_CTLS:
+ /* 1-seetings */
+ data = (CPU_BASED_HLT_EXITING |
+ CPU_BASED_VIRTUAL_INTR_PENDING |
+ CPU_BASED_CR8_LOAD_EXITING |
+ CPU_BASED_CR8_STORE_EXITING |
+ CPU_BASED_INVLPG_EXITING |
+ CPU_BASED_CR3_LOAD_EXITING |
+ CPU_BASED_CR3_STORE_EXITING |
+ CPU_BASED_MONITOR_EXITING |
+ CPU_BASED_MWAIT_EXITING |
+ CPU_BASED_MOV_DR_EXITING |
+ CPU_BASED_ACTIVATE_IO_BITMAP |
+ CPU_BASED_USE_TSC_OFFSETING |
+ CPU_BASED_UNCOND_IO_EXITING |
+ CPU_BASED_RDTSC_EXITING);
+ /* bit 1, 4-6,8,13-16,26 must be 1 (refer G4 of SDM) */
+ tmp = ( (1<<26) | (0xf << 13) | 0x100 | (0x7 << 4) |
0x2);
+ /* 0-settings */
+ data = ((data | tmp) << 32) | (tmp);
+ break;
+ case MSR_IA32_VMX_EXIT_CTLS:
+ /* 1-seetings */
+ /* bit 0-8, 10,11,13,14,16,17 must be 1 (refer G4 of SDM) */
+ tmp = 0x36dff;
+ data = VM_EXIT_ACK_INTR_ON_EXIT;
+#ifdef __x86_64__
+ data |= VM_EXIT_IA32E_MODE;
+#endif
+ /* 0-settings */
+ data = ((data | tmp) << 32) | tmp;
+ break;
+ case MSR_IA32_VMX_ENTRY_CTLS:
+ /* bit 0-8, and 12 must be 1 (refer G5 of SDM) */
+ data = 0x11ff;
+ data |= VM_ENTRY_IA32E_MODE;
+ data = (data << 32) | data;
+ break;
+
+ case IA32_FEATURE_CONTROL_MSR:
+ data = IA32_FEATURE_CONTROL_MSR_LOCK |
+ IA32_FEATURE_CONTROL_MSR_ENABLE_VMXON_OUTSIDE_SMX;
+ break;
+ /* pass through MSRs */
+ case MSR_IA32_VMX_MISC:
+ case MSR_IA32_VMX_CR0_FIXED0:
+ case MSR_IA32_VMX_CR0_FIXED1:
+ case MSR_IA32_VMX_CR4_FIXED0:
+ case MSR_IA32_VMX_CR4_FIXED1:
+ case MSR_IA32_VMX_VMCS_ENUM:
+ gdprintk(XENLOG_WARNING, "VMX MSR %x not fully supported
yet.\n", msr);
+ break;
+
+ default:
+ r = 0;
+ break;
+ }
+
+ *msr_content = data;
+ return r;
+}
+
+int nvmx_msr_write_intercept(unsigned int msr, u64 msr_content)
+{
+ /* silently ignore for now */
+ return 1;
+}
+
void nvmx_idtv_handling(void)
{
struct vcpu *v = current;
diff -r 3189a3e6f05e -r 480cfcea095b xen/include/asm-x86/hvm/vmx/vvmx.h
--- a/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800
@@ -163,6 +163,10 @@ int nvmx_handle_vmread(struct cpu_user_r
int nvmx_handle_vmwrite(struct cpu_user_regs *regs);
int nvmx_handle_vmresume(struct cpu_user_regs *regs);
int nvmx_handle_vmlaunch(struct cpu_user_regs *regs);
+int nvmx_msr_read_intercept(unsigned int msr,
+ u64 *msr_content);
+int nvmx_msr_write_intercept(unsigned int msr,
+ u64 msr_content);
void nvmx_update_exec_control(struct vcpu *v, u32 value);
void nvmx_update_secondary_exec_control(struct vcpu *v,
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Christoph Egger
2011-Jun-09 09:46 UTC
Re: [Xen-devel] [PATCH 01 of 20] pre-cleanup1: Extend nhvm_vmcx_guest_intercepts_trap to include errcode to
Acked-by: Christoph Egger <Christoph.Egger@amd.com> On 06/09/11 10:25, Eddie Dong wrote:> # HG changeset patch > # User Eddie Dong<eddie.dong@intel.com> > # Date 1307607849 -28800 > # Node ID 722771a2d429bbf5ab15e2979c0aa767a97caabe > # Parent 0c446850d85e654dfde039a0a1a5acd4e6b3c278 > pre-cleanup1: Extend nhvm_vmcx_guest_intercepts_trap to include errcode to > assist decision of TRAP_page_fault in VMX. > > Signed-off-by: Qing He<qing.he@intel.com> > Signed-off-by: Eddie Dong<eddie.dong@intel.com> > > diff -r 0c446850d85e -r 722771a2d429 xen/arch/x86/hvm/hvm.c > --- a/xen/arch/x86/hvm/hvm.c Wed May 11 12:58:04 2011 +0100 > +++ b/xen/arch/x86/hvm/hvm.c Thu Jun 09 16:24:09 2011 +0800 > @@ -1152,7 +1152,7 @@ void hvm_inject_exception(unsigned int t > return; > } > > - if ( nhvm_vmcx_guest_intercepts_trap(v, trapnr) ) > + if ( nhvm_vmcx_guest_intercepts_trap(v, trapnr, errcode) ) > { > enum nestedhvm_vmexits nsret; > > @@ -4175,10 +4175,10 @@ uint32_t nhvm_vcpu_asid(struct vcpu *v) > return -EOPNOTSUPP; > } > > -int nhvm_vmcx_guest_intercepts_trap(struct vcpu *v, unsigned int trap) > +int nhvm_vmcx_guest_intercepts_trap(struct vcpu *v, unsigned int trap, int errcode) > { > if (hvm_funcs.nhvm_vmcx_guest_intercepts_trap) > - return hvm_funcs.nhvm_vmcx_guest_intercepts_trap(v, trap); > + return hvm_funcs.nhvm_vmcx_guest_intercepts_trap(v, trap, errcode); > return -EOPNOTSUPP; > } > > diff -r 0c446850d85e -r 722771a2d429 xen/arch/x86/hvm/svm/nestedsvm.c > --- a/xen/arch/x86/hvm/svm/nestedsvm.c Wed May 11 12:58:04 2011 +0100 > +++ b/xen/arch/x86/hvm/svm/nestedsvm.c Thu Jun 09 16:24:09 2011 +0800 > @@ -895,7 +895,7 @@ nsvm_vmcb_guest_intercepts_exitcode(stru > } > > int > -nsvm_vmcb_guest_intercepts_trap(struct vcpu *v, unsigned int trapnr) > +nsvm_vmcb_guest_intercepts_trap(struct vcpu *v, unsigned int trapnr, int errcode) > { > return nsvm_vmcb_guest_intercepts_exitcode(v, > guest_cpu_user_regs(), VMEXIT_EXCEPTION_DE + trapnr); > diff -r 0c446850d85e -r 722771a2d429 xen/include/asm-x86/hvm/hvm.h > --- a/xen/include/asm-x86/hvm/hvm.h Wed May 11 12:58:04 2011 +0100 > +++ b/xen/include/asm-x86/hvm/hvm.h Thu Jun 09 16:24:09 2011 +0800 > @@ -164,7 +164,8 @@ struct hvm_function_table { > uint64_t (*nhvm_vcpu_guestcr3)(struct vcpu *v); > uint64_t (*nhvm_vcpu_hostcr3)(struct vcpu *v); > uint32_t (*nhvm_vcpu_asid)(struct vcpu *v); > - int (*nhvm_vmcx_guest_intercepts_trap)(struct vcpu *v, unsigned int trapnr); > + int (*nhvm_vmcx_guest_intercepts_trap)(struct vcpu *v, > + unsigned int trapnr, int errcode); > > bool_t (*nhvm_vmcx_hap_enabled)(struct vcpu *v); > > @@ -443,7 +444,8 @@ uint64_t nhvm_vcpu_hostcr3(struct vcpu * > uint32_t nhvm_vcpu_asid(struct vcpu *v); > > /* returns true, when l1 guest intercepts the specified trap */ > -int nhvm_vmcx_guest_intercepts_trap(struct vcpu *v, unsigned int trapnr); > +int nhvm_vmcx_guest_intercepts_trap(struct vcpu *v, > + unsigned int trapnr, int errcode); > > /* returns true when l1 guest wants to use hap to run l2 guest */ > bool_t nhvm_vmcx_hap_enabled(struct vcpu *v); > diff -r 0c446850d85e -r 722771a2d429 xen/include/asm-x86/hvm/svm/nestedsvm.h > --- a/xen/include/asm-x86/hvm/svm/nestedsvm.h Wed May 11 12:58:04 2011 +0100 > +++ b/xen/include/asm-x86/hvm/svm/nestedsvm.h Thu Jun 09 16:24:09 2011 +0800 > @@ -114,7 +114,8 @@ uint64_t nsvm_vcpu_hostcr3(struct vcpu * > uint32_t nsvm_vcpu_asid(struct vcpu *v); > int nsvm_vmcb_guest_intercepts_exitcode(struct vcpu *v, > struct cpu_user_regs *regs, uint64_t exitcode); > -int nsvm_vmcb_guest_intercepts_trap(struct vcpu *v, unsigned int trapnr); > +int nsvm_vmcb_guest_intercepts_trap(struct vcpu *v, unsigned int trapnr, > + int errcode); > bool_t nsvm_vmcb_hap_enabled(struct vcpu *v); > enum hvm_intblk nsvm_intr_blocked(struct vcpu *v); > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >-- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Christoph Egger
2011-Jun-09 10:13 UTC
Re: [Xen-devel] [PATCH 00 of 20] Rebased Nested VMX v2
I Acked patch 1. I am wondering if patch 15 and 17 contain logic that can be shared with svm and moved into common code. Christoph On 06/09/11 10:25, Eddie Dong wrote:> Tim/Keir: > > This patch series enable the nestedvmx support with all fixes to comments. > > patch 1-2 is a pre-cleanup. > patch 3 is for nested vmx data structure patch 4 for nestedhvm ops patch 5, > 7,8,9, 10, 11 is for VMX instruction emulation patch 6 for virtual VMCS data > structure and access APIs. > patch 12 for VMCS switching > Patch 13 for vmreseume/launch emulation > patch 14 for shadow control VMCS fields > patch 15 for n1/n2 guest VMCS switch > patch 16 for interrupt/exceptions > patch 17 for nested vm exit > patch 18 for lazy FPU and patch 19 VMXE bits in CR4 patch 20 for MSR handling > and capability > > > Thanks, Eddie > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >-- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Deegan
2011-Jun-13 08:27 UTC
Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
At 16:25 +0800 on 09 Jun (1307636725), Eddie Dong wrote:> + /* pass through MSRs */ > + case MSR_IA32_VMX_MISC: > + case MSR_IA32_VMX_CR0_FIXED0: > + case MSR_IA32_VMX_CR0_FIXED1: > + case MSR_IA32_VMX_CR4_FIXED0: > + case MSR_IA32_VMX_CR4_FIXED1: > + case MSR_IA32_VMX_VMCS_ENUM: > + gdprintk(XENLOG_WARNING, "VMX MSR %x not fully supported yet.\n", msr);Are you planning to fix this before checking in this series? I''m pretty sure that at least MSR_IA32_VMX_VMCS_ENUM should be trivial, since you define your own VMCS format. Tim.> + break; > + > + default: > + r = 0; > + break; > + } > + > + *msr_content = data; > + return r; > +} > + > +int nvmx_msr_write_intercept(unsigned int msr, u64 msr_content) > +{ > + /* silently ignore for now */ > + return 1; > +} > + > void nvmx_idtv_handling(void) > { > struct vcpu *v = current; > diff -r 3189a3e6f05e -r 480cfcea095b xen/include/asm-x86/hvm/vmx/vvmx.h > --- a/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800 > +++ b/xen/include/asm-x86/hvm/vmx/vvmx.h Thu Jun 09 16:24:09 2011 +0800 > @@ -163,6 +163,10 @@ int nvmx_handle_vmread(struct cpu_user_r > int nvmx_handle_vmwrite(struct cpu_user_regs *regs); > int nvmx_handle_vmresume(struct cpu_user_regs *regs); > int nvmx_handle_vmlaunch(struct cpu_user_regs *regs); > +int nvmx_msr_read_intercept(unsigned int msr, > + u64 *msr_content); > +int nvmx_msr_write_intercept(unsigned int msr, > + u64 msr_content); > > void nvmx_update_exec_control(struct vcpu *v, u32 value); > void nvmx_update_secondary_exec_control(struct vcpu *v, > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel-- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
At 12:13 +0200 on 09 Jun (1307621580), Christoph Egger wrote:> I Acked patch 1.Thanks.> I am wondering if patch 15 and 17 contain > logic that can be shared with svm and moved into common code.Unless you have specific suggestions I''m happy to take tham as they are. Eddie, I''ve queued up 01-19 ready to be committed. Patch 20 still has some MSRs that are passed through directly from the host, which I think needs to be fixed. I''d prefer just a new patch 20 rather than a new drop of the whole series next time, to save me having to re-check 01-19. Cheers, Tim.> On 06/09/11 10:25, Eddie Dong wrote: > >Tim/Keir: > > > >This patch series enable the nestedvmx support with all fixes to comments. > > > >patch 1-2 is a pre-cleanup. > >patch 3 is for nested vmx data structure patch 4 for nestedhvm ops patch 5, > >7,8,9, 10, 11 is for VMX instruction emulation patch 6 for virtual VMCS data > >structure and access APIs. > >patch 12 for VMCS switching > >Patch 13 for vmreseume/launch emulation > >patch 14 for shadow control VMCS fields > >patch 15 for n1/n2 guest VMCS switch > >patch 16 for interrupt/exceptions > >patch 17 for nested vm exit > >patch 18 for lazy FPU and patch 19 VMXE bits in CR4 patch 20 for MSR handling > >and capability > > > > > >Thanks, Eddie > > > > > >_______________________________________________ > >Xen-devel mailing list > >Xen-devel@lists.xensource.com > >http://lists.xensource.com/xen-devel > > > > > -- > ---to satisfy European Law for business letters: > Advanced Micro Devices GmbH > Einsteinring 24, 85689 Dornach b. Muenchen > Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd > Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen > Registergericht Muenchen, HRB Nr. 43632 > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel-- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Dong, Eddie
2011-Jun-14 02:29 UTC
RE: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
> > + case MSR_IA32_VMX_MISC: > > + case MSR_IA32_VMX_CR0_FIXED0: > > + case MSR_IA32_VMX_CR0_FIXED1: > > + case MSR_IA32_VMX_CR4_FIXED0: > > + case MSR_IA32_VMX_CR4_FIXED1: > > + case MSR_IA32_VMX_VMCS_ENUM: > > + gdprintk(XENLOG_WARNING, "VMX MSR %x not fully supported > yet.\n", msr); > > Are you planning to fix this before checking in this series? I''m pretty > sure that at least MSR_IA32_VMX_VMCS_ENUM should be trivial, since you > define your own VMCS format. >Sure, the updated patch is attached. Thx, Eddie _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > Eddie, I''ve queued up 01-19 ready to be committed. Patch 20 still has > some MSRs that are passed through directly from the host, which I think > needs to be fixed. I''d prefer just a new patch 20 rather than a new > drop of the whole series next time, to save me having to re-check > 01-19. >Thanks, Tim. I have reposted patch 20. BTW, here is a bug fix to patch 17. Eddie Filter out the high bit in indexing from port # to iobitmap Signed-off-by: Eddie Dong <eddie.dong@intel.com> diff -r 4e1760dc3134 xen/arch/x86/hvm/vmx/vvmx.c --- a/xen/arch/x86/hvm/vmx/vvmx.c Tue Jun 14 10:33:59 2011 +0800 +++ b/xen/arch/x86/hvm/vmx/vvmx.c Tue Jun 14 10:53:20 2011 +0800 @@ -1531,7 +1531,7 @@ if (debug_nested_event) { { port = __vmread(EXIT_QUALIFICATION) >> 16; bitmap = nvmx->iobitmap[port >> 15]; - if ( bitmap[(port <<1) >> 4] & (1 << (port & 0x7)) ) + if ( bitmap[(port & 0x7fff) >> 4] & (1 << (port & 0x7)) ) nvcpu->nv_vmexit_pending = 1; if ( !nvcpu->nv_vmexit_pending ) gdprintk(XENLOG_WARNING, "L0 PIO %x.\n", port); _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Christoph Egger
2011-Jun-14 07:43 UTC
Re: [Xen-devel] [PATCH 00 of 20] Rebased Nested VMX v2
On 06/13/11 11:24, Tim Deegan wrote:> At 12:13 +0200 on 09 Jun (1307621580), Christoph Egger wrote: >> I Acked patch 1. > > Thanks. > >> I am wondering if patch 15 and 17 contain >> logic that can be shared with svm and moved into common code. > > Unless you have specific suggestions I''m happy to take tham as they > are.I suggest Eddie to send a patch which moves the logic he thinks that can be shared into seperate functions within the vmx tree as first step. I do not mind whether Eddie should do that before or after you commit the patch set. Christoph> Eddie, I''ve queued up 01-19 ready to be committed. Patch 20 still has > some MSRs that are passed through directly from the host, which I think > needs to be fixed. I''d prefer just a new patch 20 rather than a new > drop of the whole series next time, to save me having to re-check > 01-19. > > Cheers, > > Tim. > >> On 06/09/11 10:25, Eddie Dong wrote: >>> Tim/Keir: >>> >>> This patch series enable the nestedvmx support with all fixes to comments. >>> >>> patch 1-2 is a pre-cleanup. >>> patch 3 is for nested vmx data structure patch 4 for nestedhvm ops patch 5, >>> 7,8,9, 10, 11 is for VMX instruction emulation patch 6 for virtual VMCS data >>> structure and access APIs. >>> patch 12 for VMCS switching >>> Patch 13 for vmreseume/launch emulation >>> patch 14 for shadow control VMCS fields >>> patch 15 for n1/n2 guest VMCS switch >>> patch 16 for interrupt/exceptions >>> patch 17 for nested vm exit >>> patch 18 for lazy FPU and patch 19 VMXE bits in CR4 patch 20 for MSR handling >>> and capability >>> >>> >>> Thanks, Eddie-- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
At 11:01 +0800 on 14 Jun (1308049312), Dong, Eddie wrote:> > > > Eddie, I''ve queued up 01-19 ready to be committed. Patch 20 still has > > some MSRs that are passed through directly from the host, which I think > > needs to be fixed. I''d prefer just a new patch 20 rather than a new > > drop of the whole series next time, to save me having to re-check > > 01-19. > > > > Thanks, Tim. I have reposted patch 20. > > BTW, here is a bug fix to patch 17.Thanks, I''ve merged that into the vesion I have queued. Tim. -- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > I suggest Eddie to send a patch which moves the logic he thinks that > can be shared into seperate functions within the vmx tree as first step. > I do not mind whether Eddie should do that before or after you commit > the patch set. >Thanks Chris. I will revisit some time later (and probably w/ you together) once the code itself is upstreamed and stablized in certain level with virtual EPT. Eddie _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Deegan
2011-Jun-15 12:45 UTC
Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
At 10:29 +0800 on 14 Jun (1308047377), Dong, Eddie wrote:> > > + case MSR_IA32_VMX_MISC: > > > + case MSR_IA32_VMX_CR0_FIXED0: > > > + case MSR_IA32_VMX_CR0_FIXED1: > > > + case MSR_IA32_VMX_CR4_FIXED0: > > > + case MSR_IA32_VMX_CR4_FIXED1: > > > + case MSR_IA32_VMX_VMCS_ENUM: > > > + gdprintk(XENLOG_WARNING, "VMX MSR %x not fully supported > > yet.\n", msr); > > > > Are you planning to fix this before checking in this series? I''m pretty > > sure that at least MSR_IA32_VMX_VMCS_ENUM should be trivial, since you > > define your own VMCS format. > > > > Sure, the updated patch is attached.Thanks. I''ve applied the full series. I cleaned up a few things for the 32-bit build as well. Cheers, Tim. -- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeroen Groenewegen van der Weyden
2011-Jun-20 06:31 UTC
Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
Hi, Based on these patch series, I gave it go. I noticed until now that the system becomes in-responsive a few second after activating the second nested guest. steps: 1) dom0 creates domu (pass) 2) domU creates first kvm guest (pass) 3) domU creates second kvm guest (fail) after the third step the domu becomes in-responsive. eg no network / vnc console response. in dom0 is shows domu is stil running. I''m able to provide any input needed, just tell me what you need (and how). mfg, Jeroen My HW setup mobo asus z8nr-d12 proc: 2 times e5645 mem: 96 GB My goal/test in short: HW -> dom0 -> domU -> 4 time kvm guest dom0 opensuse 11.4 x86 xen: unstable cs 23553 domu (HVM) sles11sp1 mem: 8 GB vcpu: 4 domu guests 1) qemu-kvm: propetary OS 2) qemu-kvm: propetary OS 3) qemu-kvm: SLES10SP3 4) qemu-kvm: SLES10SP3 Op 15-6-2011 14:45, Tim Deegan schreef:> At 10:29 +0800 on 14 Jun (1308047377), Dong, Eddie wrote: >>>> + case MSR_IA32_VMX_MISC: >>>> + case MSR_IA32_VMX_CR0_FIXED0: >>>> + case MSR_IA32_VMX_CR0_FIXED1: >>>> + case MSR_IA32_VMX_CR4_FIXED0: >>>> + case MSR_IA32_VMX_CR4_FIXED1: >>>> + case MSR_IA32_VMX_VMCS_ENUM: >>>> + gdprintk(XENLOG_WARNING, "VMX MSR %x not fully supported >>> yet.\n", msr); >>> >>> Are you planning to fix this before checking in this series? I''m pretty >>> sure that at least MSR_IA32_VMX_VMCS_ENUM should be trivial, since you >>> define your own VMCS format. >>> >> Sure, the updated patch is attached. > Thanks. I''ve applied the full series. I cleaned up a few things for > the 32-bit build as well. > > Cheers, > > Tim. >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeroen Groenewegen van der Weyden
2011-Jun-30 14:14 UTC
Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
Hi Tim/Eddi/Christoph, I just gave it a go again with cs23640. But the behaviour is still the same. so L1 becomes inresponsive after starting the second nested quest. I can deliver any trace input you want/need. mfg, Jeroen. Op 20-6-2011 8:31, Jeroen Groenewegen van der Weyden schreef:> Hi, > > Based on these patch series, I gave it go. > I noticed until now that the system becomes in-responsive a few second > after activating the second nested guest. > steps: > 1) dom0 creates domu (pass) > 2) domU creates first kvm guest (pass) > 3) domU creates second kvm guest (fail) > after the third step the domu becomes in-responsive. eg no network / > vnc console response. in dom0 is shows domu is stil running. > > I''m able to provide any input needed, just tell me what you need (and > how). > > mfg, > Jeroen > > My HW setup > mobo asus z8nr-d12 > proc: 2 times e5645 > mem: 96 GB > > My goal/test > in short: HW -> dom0 -> domU -> 4 time kvm guest > > dom0 > opensuse 11.4 x86 > xen: unstable cs 23553 > > domu (HVM) > sles11sp1 > mem: 8 GB > vcpu: 4 > > domu guests > 1) qemu-kvm: propetary OS > 2) qemu-kvm: propetary OS > 3) qemu-kvm: SLES10SP3 > 4) qemu-kvm: SLES10SP3 > > > > Op 15-6-2011 14:45, Tim Deegan schreef: >> At 10:29 +0800 on 14 Jun (1308047377), Dong, Eddie wrote: >>>>> + case MSR_IA32_VMX_MISC: >>>>> + case MSR_IA32_VMX_CR0_FIXED0: >>>>> + case MSR_IA32_VMX_CR0_FIXED1: >>>>> + case MSR_IA32_VMX_CR4_FIXED0: >>>>> + case MSR_IA32_VMX_CR4_FIXED1: >>>>> + case MSR_IA32_VMX_VMCS_ENUM: >>>>> + gdprintk(XENLOG_WARNING, "VMX MSR %x not fully supported >>>> yet.\n", msr); >>>> >>>> Are you planning to fix this before checking in this series? I''m >>>> pretty >>>> sure that at least MSR_IA32_VMX_VMCS_ENUM should be trivial, since you >>>> define your own VMCS format. >>>> >>> Sure, the updated patch is attached. >> Thanks. I''ve applied the full series. I cleaned up a few things for >> the 32-bit build as well. >> >> Cheers, >> >> Tim. >> > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Deegan
2011-Jul-01 09:01 UTC
Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
Eddie? Did you test with KVM guests? Is this expected to work? Tim. At 15:14 +0100 on 30 Jun (1309446872), Jeroen Groenewegen van der Weyden wrote:> Hi Tim/Eddi/Christoph, > > I just gave it a go again with cs23640. But the behaviour is still the > same. so L1 becomes inresponsive after starting the second nested quest. > I can deliver any trace input you want/need. > > mfg, > Jeroen. > > Op 20-6-2011 8:31, Jeroen Groenewegen van der Weyden schreef: > > Hi, > > > > Based on these patch series, I gave it go. > > I noticed until now that the system becomes in-responsive a few second > > after activating the second nested guest. > > steps: > > 1) dom0 creates domu (pass) > > 2) domU creates first kvm guest (pass) > > 3) domU creates second kvm guest (fail) > > after the third step the domu becomes in-responsive. eg no network / > > vnc console response. in dom0 is shows domu is stil running. > > > > I''m able to provide any input needed, just tell me what you need (and > > how). > > > > mfg, > > Jeroen > > > > My HW setup > > mobo asus z8nr-d12 > > proc: 2 times e5645 > > mem: 96 GB > > > > My goal/test > > in short: HW -> dom0 -> domU -> 4 time kvm guest > > > > dom0 > > opensuse 11.4 x86 > > xen: unstable cs 23553 > > > > domu (HVM) > > sles11sp1 > > mem: 8 GB > > vcpu: 4 > > > > domu guests > > 1) qemu-kvm: propetary OS > > 2) qemu-kvm: propetary OS > > 3) qemu-kvm: SLES10SP3 > > 4) qemu-kvm: SLES10SP3 > > > > > > > > Op 15-6-2011 14:45, Tim Deegan schreef: > >> At 10:29 +0800 on 14 Jun (1308047377), Dong, Eddie wrote: > >>>>> + case MSR_IA32_VMX_MISC: > >>>>> + case MSR_IA32_VMX_CR0_FIXED0: > >>>>> + case MSR_IA32_VMX_CR0_FIXED1: > >>>>> + case MSR_IA32_VMX_CR4_FIXED0: > >>>>> + case MSR_IA32_VMX_CR4_FIXED1: > >>>>> + case MSR_IA32_VMX_VMCS_ENUM: > >>>>> + gdprintk(XENLOG_WARNING, "VMX MSR %x not fully supported > >>>> yet.\n", msr); > >>>> > >>>> Are you planning to fix this before checking in this series? I''m > >>>> pretty > >>>> sure that at least MSR_IA32_VMX_VMCS_ENUM should be trivial, since you > >>>> define your own VMCS format. > >>>> > >>> Sure, the updated patch is attached. > >> Thanks. I''ve applied the full series. I cleaned up a few things for > >> the 32-bit build as well. > >> > >> Cheers, > >> > >> Tim. > >> > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > >-- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Christoph Egger
2011-Jul-01 09:54 UTC
Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
KVM on Xen works for me. Also KVM on Xen on Xen. Christoph On 07/01/11 11:01, Tim Deegan wrote:> Eddie? Did you test with KVM guests? Is this expected to work? > > Tim. > > At 15:14 +0100 on 30 Jun (1309446872), Jeroen Groenewegen van der Weyden wrote: >> Hi Tim/Eddi/Christoph, >> >> I just gave it a go again with cs23640. But the behaviour is still the >> same. so L1 becomes inresponsive after starting the second nested quest. >> I can deliver any trace input you want/need. >> >> mfg, >> Jeroen. >> >> Op 20-6-2011 8:31, Jeroen Groenewegen van der Weyden schreef: >>> Hi, >>> >>> Based on these patch series, I gave it go. >>> I noticed until now that the system becomes in-responsive a few second >>> after activating the second nested guest. >>> steps: >>> 1) dom0 creates domu (pass) >>> 2) domU creates first kvm guest (pass) >>> 3) domU creates second kvm guest (fail) >>> after the third step the domu becomes in-responsive. eg no network / >>> vnc console response. in dom0 is shows domu is stil running. >>> >>> I''m able to provide any input needed, just tell me what you need (and >>> how). >>> >>> mfg, >>> Jeroen >>> >>> My HW setup >>> mobo asus z8nr-d12 >>> proc: 2 times e5645 >>> mem: 96 GB >>> >>> My goal/test >>> in short: HW -> dom0 -> domU -> 4 time kvm guest >>> >>> dom0 >>> opensuse 11.4 x86 >>> xen: unstable cs 23553 >>> >>> domu (HVM) >>> sles11sp1 >>> mem: 8 GB >>> vcpu: 4 >>> >>> domu guests >>> 1) qemu-kvm: propetary OS >>> 2) qemu-kvm: propetary OS >>> 3) qemu-kvm: SLES10SP3 >>> 4) qemu-kvm: SLES10SP3 >>> >>> >>> >>> Op 15-6-2011 14:45, Tim Deegan schreef: >>>> At 10:29 +0800 on 14 Jun (1308047377), Dong, Eddie wrote: >>>>>>> + case MSR_IA32_VMX_MISC: >>>>>>> + case MSR_IA32_VMX_CR0_FIXED0: >>>>>>> + case MSR_IA32_VMX_CR0_FIXED1: >>>>>>> + case MSR_IA32_VMX_CR4_FIXED0: >>>>>>> + case MSR_IA32_VMX_CR4_FIXED1: >>>>>>> + case MSR_IA32_VMX_VMCS_ENUM: >>>>>>> + gdprintk(XENLOG_WARNING, "VMX MSR %x not fully supported >>>>>> yet.\n", msr); >>>>>> >>>>>> Are you planning to fix this before checking in this series? I''m >>>>>> pretty >>>>>> sure that at least MSR_IA32_VMX_VMCS_ENUM should be trivial, since you >>>>>> define your own VMCS format. >>>>>> >>>>> Sure, the updated patch is attached. >>>> Thanks. I''ve applied the full series. I cleaned up a few things for >>>> the 32-bit build as well. >>>> >>>> Cheers, >>>> >>>> Tim.-- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85689 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeroen Groenewegen van der Weyden
2011-Jul-01 10:11 UTC
Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
Just a remark to avoid misunderstanding The first nested KVM guest is running ok, for as long as i keep it running When starting a second nested KVM guest (in the same Xen DOMU) that is when the Xen DOMU becomes in-responsive. In DOM0 it it shown that it is still running and consuming time. The complete test is like this dom0 opensuse 11.4 x86 xen: unstable cs 23640 domu1 (HVM) sles11sp1 mem: 8 GB vcpu: 4 domu1 guests 1) qemu-kvm: propetary OS 2) qemu-kvm: propetary OS 3) qemu-kvm: SLES10SP3 4) qemu-kvm: SLES10SP3 mfg, Jeroen Op 1-7-2011 11:54, Christoph Egger schreef:> > KVM on Xen works for me. Also KVM on Xen on Xen. > > Christoph > > > On 07/01/11 11:01, Tim Deegan wrote: >> Eddie? Did you test with KVM guests? Is this expected to work? >> >> Tim. >> >> At 15:14 +0100 on 30 Jun (1309446872), Jeroen Groenewegen van der >> Weyden wrote: >>> Hi Tim/Eddi/Christoph, >>> >>> I just gave it a go again with cs23640. But the behaviour is still the >>> same. so L1 becomes inresponsive after starting the second nested >>> quest. >>> I can deliver any trace input you want/need. >>> >>> mfg, >>> Jeroen. >>> >>> Op 20-6-2011 8:31, Jeroen Groenewegen van der Weyden schreef: >>>> Hi, >>>> >>>> Based on these patch series, I gave it go. >>>> I noticed until now that the system becomes in-responsive a few second >>>> after activating the second nested guest. >>>> steps: >>>> 1) dom0 creates domu (pass) >>>> 2) domU creates first kvm guest (pass) >>>> 3) domU creates second kvm guest (fail) >>>> after the third step the domu becomes in-responsive. eg no network / >>>> vnc console response. in dom0 is shows domu is stil running. >>>> >>>> I''m able to provide any input needed, just tell me what you need (and >>>> how). >>>> >>>> mfg, >>>> Jeroen >>>> >>>> My HW setup >>>> mobo asus z8nr-d12 >>>> proc: 2 times e5645 >>>> mem: 96 GB >>>> >>>> My goal/test >>>> in short: HW -> dom0 -> domU -> 4 time kvm guest >>>> >>>> dom0 >>>> opensuse 11.4 x86 >>>> xen: unstable cs 23553 >>>> >>>> domu (HVM) >>>> sles11sp1 >>>> mem: 8 GB >>>> vcpu: 4 >>>> >>>> domu guests >>>> 1) qemu-kvm: propetary OS >>>> 2) qemu-kvm: propetary OS >>>> 3) qemu-kvm: SLES10SP3 >>>> 4) qemu-kvm: SLES10SP3 >>>> >>>> >>>> >>>> Op 15-6-2011 14:45, Tim Deegan schreef: >>>>> At 10:29 +0800 on 14 Jun (1308047377), Dong, Eddie wrote: >>>>>>>> + case MSR_IA32_VMX_MISC: >>>>>>>> + case MSR_IA32_VMX_CR0_FIXED0: >>>>>>>> + case MSR_IA32_VMX_CR0_FIXED1: >>>>>>>> + case MSR_IA32_VMX_CR4_FIXED0: >>>>>>>> + case MSR_IA32_VMX_CR4_FIXED1: >>>>>>>> + case MSR_IA32_VMX_VMCS_ENUM: >>>>>>>> + gdprintk(XENLOG_WARNING, "VMX MSR %x not fully supported >>>>>>> yet.\n", msr); >>>>>>> >>>>>>> Are you planning to fix this before checking in this series? I''m >>>>>>> pretty >>>>>>> sure that at least MSR_IA32_VMX_VMCS_ENUM should be trivial, >>>>>>> since you >>>>>>> define your own VMCS format. >>>>>>> >>>>>> Sure, the updated patch is attached. >>>>> Thanks. I''ve applied the full series. I cleaned up a few things for >>>>> the 32-bit build as well. >>>>> >>>>> Cheers, >>>>> >>>>> Tim. > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Deegan
2011-Jul-04 08:58 UTC
Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
At 12:11 +0200 on 01 Jul (1309522280), Jeroen Groenewegen van der Weyden wrote:> Just a remark to avoid misunderstanding > > The first nested KVM guest is running ok, for as long as i keep it running > When starting a second nested KVM guest (in the same Xen DOMU) that > is when the Xen DOMU becomes in-responsive. In DOM0 it it shown that > it is still running and consuming time. > > > The complete test is like this > > dom0 > opensuse 11.4 x86 > xen: unstable cs 23640You''re testing on Intel hardware, right? Eddie, any comment? Tim.> domu1 (HVM) > sles11sp1 > mem: 8 GB > vcpu: 4 > > domu1 guests > 1) qemu-kvm: propetary OS > 2) qemu-kvm: propetary OS > 3) qemu-kvm: SLES10SP3 > 4) qemu-kvm: SLES10SP3 > > mfg, > Jeroen > > Op 1-7-2011 11:54, Christoph Egger schreef: > > > >KVM on Xen works for me. Also KVM on Xen on Xen. > > > >Christoph > > > > > >On 07/01/11 11:01, Tim Deegan wrote: > >>Eddie? Did you test with KVM guests? Is this expected to work? > >> > >>Tim. > >> > >>At 15:14 +0100 on 30 Jun (1309446872), Jeroen Groenewegen van > >>der Weyden wrote: > >>>Hi Tim/Eddi/Christoph, > >>> > >>>I just gave it a go again with cs23640. But the behaviour is still the > >>>same. so L1 becomes inresponsive after starting the second > >>>nested quest. > >>>I can deliver any trace input you want/need. > >>> > >>>mfg, > >>>Jeroen. > >>> > >>>Op 20-6-2011 8:31, Jeroen Groenewegen van der Weyden schreef: > >>>>Hi, > >>>> > >>>>Based on these patch series, I gave it go. > >>>>I noticed until now that the system becomes in-responsive a few second > >>>>after activating the second nested guest. > >>>>steps: > >>>>1) dom0 creates domu (pass) > >>>>2) domU creates first kvm guest (pass) > >>>>3) domU creates second kvm guest (fail) > >>>>after the third step the domu becomes in-responsive. eg no network / > >>>>vnc console response. in dom0 is shows domu is stil running. > >>>> > >>>>I''m able to provide any input needed, just tell me what you need (and > >>>>how). > >>>> > >>>>mfg, > >>>>Jeroen > >>>> > >>>>My HW setup > >>>>mobo asus z8nr-d12 > >>>>proc: 2 times e5645 > >>>>mem: 96 GB > >>>> > >>>>My goal/test > >>>>in short: HW -> dom0 -> domU -> 4 time kvm guest > >>>> > >>>>dom0 > >>>>opensuse 11.4 x86 > >>>>xen: unstable cs 23553 > >>>> > >>>>domu (HVM) > >>>>sles11sp1 > >>>>mem: 8 GB > >>>>vcpu: 4 > >>>> > >>>>domu guests > >>>>1) qemu-kvm: propetary OS > >>>>2) qemu-kvm: propetary OS > >>>>3) qemu-kvm: SLES10SP3 > >>>>4) qemu-kvm: SLES10SP3 > >>>> > >>>> > >>>> > >>>>Op 15-6-2011 14:45, Tim Deegan schreef: > >>>>>At 10:29 +0800 on 14 Jun (1308047377), Dong, Eddie wrote: > >>>>>>>>+ case MSR_IA32_VMX_MISC: > >>>>>>>>+ case MSR_IA32_VMX_CR0_FIXED0: > >>>>>>>>+ case MSR_IA32_VMX_CR0_FIXED1: > >>>>>>>>+ case MSR_IA32_VMX_CR4_FIXED0: > >>>>>>>>+ case MSR_IA32_VMX_CR4_FIXED1: > >>>>>>>>+ case MSR_IA32_VMX_VMCS_ENUM: > >>>>>>>>+ gdprintk(XENLOG_WARNING, "VMX MSR %x not fully supported > >>>>>>>yet.\n", msr); > >>>>>>> > >>>>>>>Are you planning to fix this before checking in this series? I''m > >>>>>>>pretty > >>>>>>>sure that at least MSR_IA32_VMX_VMCS_ENUM should be > >>>>>>>trivial, since you > >>>>>>>define your own VMCS format. > >>>>>>> > >>>>>>Sure, the updated patch is attached. > >>>>>Thanks. I''ve applied the full series. I cleaned up a few things for > >>>>>the 32-bit build as well. > >>>>> > >>>>>Cheers, > >>>>> > >>>>>Tim. > > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel-- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeroen Groenewegen van der Weyden
2011-Jul-04 09:58 UTC
Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
You''re testing on Intel hardware, right? - Yes, the proc is a Xeon e5645. Two of them on a asus z8nr-d12 mobo. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeroen Groenewegen van der Weyden
2011-Jul-08 07:12 UTC
Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
Eddie, did I mention I''m eager and capable of testing anything you need. mfg, jeroen Op 4-7-2011 10:58, Tim Deegan schreef:> At 12:11 +0200 on 01 Jul (1309522280), Jeroen Groenewegen van der Weyden wrote: >> Just a remark to avoid misunderstanding >> >> The first nested KVM guest is running ok, for as long as i keep it running >> When starting a second nested KVM guest (in the same Xen DOMU) that >> is when the Xen DOMU becomes in-responsive. In DOM0 it it shown that >> it is still running and consuming time. >> >> >> The complete test is like this >> >> dom0 >> opensuse 11.4 x86 >> xen: unstable cs 23640 > You''re testing on Intel hardware, right? > > Eddie, any comment? > > Tim. > >> domu1 (HVM) >> sles11sp1 >> mem: 8 GB >> vcpu: 4 >> >> domu1 guests >> 1) qemu-kvm: propetary OS >> 2) qemu-kvm: propetary OS >> 3) qemu-kvm: SLES10SP3 >> 4) qemu-kvm: SLES10SP3 >> >> mfg, >> Jeroen >> >> Op 1-7-2011 11:54, Christoph Egger schreef: >>> KVM on Xen works for me. Also KVM on Xen on Xen. >>> >>> Christoph >>> >>> >>> On 07/01/11 11:01, Tim Deegan wrote: >>>> Eddie? Did you test with KVM guests? Is this expected to work? >>>> >>>> Tim. >>>> >>>> At 15:14 +0100 on 30 Jun (1309446872), Jeroen Groenewegen van >>>> der Weyden wrote: >>>>> Hi Tim/Eddi/Christoph, >>>>> >>>>> I just gave it a go again with cs23640. But the behaviour is still the >>>>> same. so L1 becomes inresponsive after starting the second >>>>> nested quest. >>>>> I can deliver any trace input you want/need. >>>>> >>>>> mfg, >>>>> Jeroen. >>>>> >>>>> Op 20-6-2011 8:31, Jeroen Groenewegen van der Weyden schreef: >>>>>> Hi, >>>>>> >>>>>> Based on these patch series, I gave it go. >>>>>> I noticed until now that the system becomes in-responsive a few second >>>>>> after activating the second nested guest. >>>>>> steps: >>>>>> 1) dom0 creates domu (pass) >>>>>> 2) domU creates first kvm guest (pass) >>>>>> 3) domU creates second kvm guest (fail) >>>>>> after the third step the domu becomes in-responsive. eg no network / >>>>>> vnc console response. in dom0 is shows domu is stil running. >>>>>> >>>>>> I''m able to provide any input needed, just tell me what you need (and >>>>>> how). >>>>>> >>>>>> mfg, >>>>>> Jeroen >>>>>> >>>>>> My HW setup >>>>>> mobo asus z8nr-d12 >>>>>> proc: 2 times e5645 >>>>>> mem: 96 GB >>>>>> >>>>>> My goal/test >>>>>> in short: HW -> dom0 -> domU -> 4 time kvm guest >>>>>> >>>>>> dom0 >>>>>> opensuse 11.4 x86 >>>>>> xen: unstable cs 23553 >>>>>> >>>>>> domu (HVM) >>>>>> sles11sp1 >>>>>> mem: 8 GB >>>>>> vcpu: 4 >>>>>> >>>>>> domu guests >>>>>> 1) qemu-kvm: propetary OS >>>>>> 2) qemu-kvm: propetary OS >>>>>> 3) qemu-kvm: SLES10SP3 >>>>>> 4) qemu-kvm: SLES10SP3 >>>>>> >>>>>> >>>>>> >>>>>> Op 15-6-2011 14:45, Tim Deegan schreef: >>>>>>> At 10:29 +0800 on 14 Jun (1308047377), Dong, Eddie wrote: >>>>>>>>>> + case MSR_IA32_VMX_MISC: >>>>>>>>>> + case MSR_IA32_VMX_CR0_FIXED0: >>>>>>>>>> + case MSR_IA32_VMX_CR0_FIXED1: >>>>>>>>>> + case MSR_IA32_VMX_CR4_FIXED0: >>>>>>>>>> + case MSR_IA32_VMX_CR4_FIXED1: >>>>>>>>>> + case MSR_IA32_VMX_VMCS_ENUM: >>>>>>>>>> + gdprintk(XENLOG_WARNING, "VMX MSR %x not fully supported >>>>>>>>> yet.\n", msr); >>>>>>>>> >>>>>>>>> Are you planning to fix this before checking in this series? I''m >>>>>>>>> pretty >>>>>>>>> sure that at least MSR_IA32_VMX_VMCS_ENUM should be >>>>>>>>> trivial, since you >>>>>>>>> define your own VMCS format. >>>>>>>>> >>>>>>>> Sure, the updated patch is attached. >>>>>>> Thanks. I''ve applied the full series. I cleaned up a few things for >>>>>>> the 32-bit build as well. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Tim. >>> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
vickywill
2011-Jul-08 07:42 UTC
[Xen-devel] Re: [PATCH 04 of 20] Add APIs for nestedhvm_ops
We have corresponding discount rate from 10%--30% for the order ,Our Led lights have 3 years quality warranty,All of our LEDs Lighting products have passed the CE and ROHS test,Another 5‰ of your order will be offered for free, if the quantity is over 1000pcs,New LEDs lighting samples will be offered for free ,in the future after being our old customers , if you are favourable policies.please contact us or visit our cheap LEDs lights website -- View this message in context: http://xen.1045712.n5.nabble.com/PATCH-00-of-20-Rebased-Nested-VMX-v2-tp4471985p4563783.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
vickywill
2011-Jul-08 07:43 UTC
[Xen-devel] Re: [PATCH 04 of 20] Add APIs for nestedhvm_ops
http://www.led-gu10.com/ LED GU10 , http://www.led-gu10.com/ gu10 led , http://www.led-gu10.com/ LED bulbs , http://www.led-gu10.com/LED-Spotlight-index.html LED Spotlight , http://www.led-gu10.com/LED-Spotlight-index.html LED Spot light , http://www.led-gu10.com/LED-E27.html LED E27 , http://www.led-gu10.com/LED-MR16.html LED MR16 , http://www.led-gu10.com/LED-AR111.html LED AR111 , -- View this message in context: http://xen.1045712.n5.nabble.com/PATCH-00-of-20-Rebased-Nested-VMX-v2-tp4471985p4563785.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Dong, Eddie
2011-Jul-18 15:41 UTC
RE: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
Jeroen: Sorry for later response. I did a double check locally, I was able to create 2 layer 2 guests. My environment is L1 guest: 64 bits Linux 2.6.25 + KVM-76. One L2 guest is 32 bits Linux, another one is 64 bits guest. For layer 1 guest, I am setting: hap=1 nestedhvm = 1 Thx, Eddie _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeroen Groenewegen van der Weyden
2011-Jul-19 13:59 UTC
Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
Hi eddie, I use the same settings. however my setup becomes in-response after start of the second nested kvm quest. were does that leave us? Should I make some trace and sent it to you. I can give you access to my system as well if you want. just give me your thoughts on how to move forward. mfg, Jeroen. Op 18-7-2011 17:41, Dong, Eddie schreef:> Jeroen: > Sorry for later response. > I did a double check locally, I was able to create 2 layer 2 guests. My environment is L1 guest: 64 bits Linux 2.6.25 + KVM-76. One L2 guest is 32 bits Linux, another one is 64 bits guest. > For layer 1 guest, I am setting: > > hap=1 > nestedhvm = 1 > > Thx, Eddie > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Dong, Eddie
2011-Jul-20 13:44 UTC
RE: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
Hi Jeroen: What L1 guest do u use? Xen or KVM? Thx, Eddie> -----Original Message----- > From: Jeroen Groenewegen van der Weyden [mailto:groen692@grosc.com] > Sent: Tuesday, July 19, 2011 10:00 PM > To: Dong, Eddie > Cc: xen-devel@lists.xensource.com; Tim Deegan; > Christoph.Egger@amd.com > Subject: Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability > exposure > > Hi eddie, I use the same settings. however my setup becomes in-response > after start of the second nested kvm quest. were does that leave us? > Should I make some trace and sent it to you. I can give you access to my > system as well if you want. just give me your thoughts on how to move > forward. > > mfg, > Jeroen. > > Op 18-7-2011 17:41, Dong, Eddie schreef: > > Jeroen: > > Sorry for later response. > > I did a double check locally, I was able to create 2 layer 2 guests. My > environment is L1 guest: 64 bits Linux 2.6.25 + KVM-76. One L2 guest is 32 > bits Linux, another one is 64 bits guest. > > For layer 1 guest, I am setting: > > > > hap=1 > > nestedhvm = 1 > > > > Thx, Eddie > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeroen Groenewegen van der Weyden
2011-Jul-20 14:12 UTC
Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
Eddie, Here my setup, in short: HW -> dom0 opensuse 11.4(xen-cs23728) -> domU (HVM-sles11sp1) KVM -> 4 time kvm guest dom0 opensuse 11.4 x86 kernel 2.6.37.6-0.5-xen xen: unstable cs 23728 - domu (HVM) - sles11sp1 - mem: 8 GB - vcpu: 4 - kvm --domu guests --1) qemu-kvm: propetary OS --2) qemu-kvm: propetary OS --3) qemu-kvm: SLES10SP3 --4) qemu-kvm: SLES10SP3 mfg, Jeroen Op 20-7-2011 15:44, Dong, Eddie schreef:> Hi Jeroen: > What L1 guest do u use? Xen or KVM? > Thx, Eddie > >> -----Original Message----- >> From: Jeroen Groenewegen van der Weyden [mailto:groen692@grosc.com] >> Sent: Tuesday, July 19, 2011 10:00 PM >> To: Dong, Eddie >> Cc: xen-devel@lists.xensource.com; Tim Deegan; >> Christoph.Egger@amd.com >> Subject: Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability >> exposure >> >> Hi eddie, I use the same settings. however my setup becomes in-response >> after start of the second nested kvm quest. were does that leave us? >> Should I make some trace and sent it to you. I can give you access to my >> system as well if you want. just give me your thoughts on how to move >> forward. >> >> mfg, >> Jeroen. >> >> Op 18-7-2011 17:41, Dong, Eddie schreef: >>> Jeroen: >>> Sorry for later response. >>> I did a double check locally, I was able to create 2 layer 2 guests. My >> environment is L1 guest: 64 bits Linux 2.6.25 + KVM-76. One L2 guest is 32 >> bits Linux, another one is 64 bits guest. >>> For layer 1 guest, I am setting: >>> >>> hap=1 >>> nestedhvm = 1 >>> >>> Thx, Eddie >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xensource.com >>> http://lists.xensource.com/xen-devel >>> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Deegan
2011-Jul-25 14:08 UTC
Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
Hi, At 16:12 +0200 on 20 Jul (1311178333), Jeroen Groenewegen van der Weyden wrote:> in short: HW -> dom0 opensuse 11.4(xen-cs23728) -> domU (HVM-sles11sp1) KVM -> 4 time kvm guest > > dom0 > opensuse 11.4 x86 > kernel 2.6.37.6-0.5-xen > xen: unstable cs 23728 > > - domu (HVM) > - sles11sp1 > - mem: 8 GB > - vcpu: 4 > - kvmFWIW, I can reproduce this with a Debian 2.6.32-5-686 n1 guest on current unstable tip. Running two copies of ''kvm'' inside that (i.e. simple n2s without any disks) I see this on the n0 console: (XEN) vvmx.c:1181:d1 vmclear gpa 3661d000 not the same as current vmcs 0000000036459000 (XEN) vvmx.c:1181:d1 vmclear gpa 36459000 not the same as current vmcs 000000003661d000 and the n1 guest locks up using 100% cpu on one of its vcpus. Reducing the n1 guest to only 1 VCPU works around the issue, though I still see one of those complaints about vmclear, so that might be a red herring. Tim. -- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Deegan
2011-Jul-25 16:16 UTC
Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
Hi, At 15:08 +0100 on 25 Jul (1311606523), Tim Deegan wrote:> FWIW, I can reproduce this with a Debian 2.6.32-5-686 n1 guest on > current unstable tip. Running two copies of ''kvm'' inside that > (i.e. simple n2s without any disks) I see this on the n0 console: > > (XEN) vvmx.c:1181:d1 vmclear gpa 3661d000 not the same as current vmcs 0000000036459000 > (XEN) vvmx.c:1181:d1 vmclear gpa 36459000 not the same as current vmcs 000000003661d000 > > and the n1 guest locks up using 100% cpu on one of its vcpus.AFAICS when KVM has two VMs sharing a CPU, it just switches between them with VMPTRLD, rather than VMCLEARing the current one on every context switch. When it migrates one of them away, it VMCLEARs it, even if it''s not the most recently loaded VMCS. Xen''s emulation of VMCLEAR doesn''t clear the ''launched'' bit in this case, though the SDM says it should. The attached patch fixes the hang for me, but has had only very light testing (i.e. I haven''t checked that proper OSes running inside the KVM VMs behave correctly). Eddie, does this look right to you? Jeroen, can you try it and see if it fixes your problems? Cheers, Tim. -- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeroen Groenewegen van der Weyden
2011-Jul-26 07:15 UTC
Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
Hi Tim, I think the behaviour is still the same, 1) cs23726 2) vvmc.c patched with attachment. 3) new compile after a little while the domu becomes ir-responsive. with xm dmesg I see a lot of these: (XEN) vvmx.c:1182:d3 vmclear gpa 1f5a89000 not the same as current vmcs 00000001f448f000 (XEN) vvmx.c:1182:d3 vmclear gpa 1f5a89000 not the same as current vmcs 00000001f448f000 Note: I have to say, patching this on this level is not common practice for me. although I think I did it the right way. please keep in mind I can make mistakes on this level. mfg, Jeroen. Op 25-7-2011 18:16, Tim Deegan schreef:> Hi, > > At 15:08 +0100 on 25 Jul (1311606523), Tim Deegan wrote: >> FWIW, I can reproduce this with a Debian 2.6.32-5-686 n1 guest on >> current unstable tip. Running two copies of ''kvm'' inside that >> (i.e. simple n2s without any disks) I see this on the n0 console: >> >> (XEN) vvmx.c:1181:d1 vmclear gpa 3661d000 not the same as current vmcs 0000000036459000 >> (XEN) vvmx.c:1181:d1 vmclear gpa 36459000 not the same as current vmcs 000000003661d000 >> >> and the n1 guest locks up using 100% cpu on one of its vcpus. > AFAICS when KVM has two VMs sharing a CPU, it just switches between them > with VMPTRLD, rather than VMCLEARing the current one on every context > switch. When it migrates one of them away, it VMCLEARs it, even if it''s > not the most recently loaded VMCS. > > Xen''s emulation of VMCLEAR doesn''t clear the ''launched'' bit in this > case, though the SDM says it should. The attached patch fixes the hang > for me, but has had only very light testing (i.e. I haven''t checked that > proper OSes running inside the KVM VMs behave correctly). > > Eddie, does this look right to you? > > Jeroen, can you try it and see if it fixes your problems? > > Cheers, > > Tim. >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Deegan
2011-Jul-26 10:00 UTC
Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
Hi, At 09:15 +0200 on 26 Jul (1311671730), Jeroen Groenewegen van der Weyden wrote:> I think the behaviour is still the same, > > 1) cs23726 > 2) vvmc.c patched with attachment. > 3) new compile > > after a little while the domu becomes ir-responsive.Dang. :(> with xm dmesg I see a lot of these: > (XEN) vvmx.c:1182:d3 vmclear gpa 1f5a89000 not the same as current > vmcs 00000001f448f000 > (XEN) vvmx.c:1182:d3 vmclear gpa 1f5a89000 not the same as current > vmcs 00000001f448f000Yeah; with the patch applied, those should be harmlesss. If you give your first-level guest only one vcpu, does the problem go away?> Note: I have to say, patching this on this level is not common > practice for me. although I think I did it the right way. please > keep in mind I can make mistakes on this level.If you want to double-check that you''ve done the patch right, edit xen/arch/x86/hvm/vmx/vvmx.c, and at line 1185, just under the line ` /* Even if this VMCS isn''t the current one, we must clear it. */ '' add a line ` printk("boo!\n"); ''. Then when you recompile and test you should see "boo!" printed just after each "vvmx.c:1182:d3" line on the console. Cheers, Tim. -- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Deegan
2011-Jul-26 10:11 UTC
Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
At 11:00 +0100 on 26 Jul (1311678018), Tim Deegan wrote:> If you want to double-check that you''ve done the patch right, > edit xen/arch/x86/hvm/vmx/vvmx.c, and at line 1185, just under the line > ` /* Even if this VMCS isn''t the current one, we must clear it. */ '' > add a line ` printk("boo!\n"); ''. Then when you recompile and test you > should see "boo!" printed just after each "vvmx.c:1182:d3" line on the > console.Oh, and when the domU is hung, can you run the command /usr/lib/xen/bin/xenctx -aCS 1 (replacing ''1'' with the domid of your domU) three or four times and post the output here? On a 64-bit dom0 I think the correct path will be /usr/lib64/xen/bin/xenctx. Cheers, Tim. -- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeroen Groenewegen van der Weyden
2011-Jul-26 10:46 UTC
Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
Here my input mfg, jeroen Op 26-7-2011 12:11, Tim Deegan schreef:> At 11:00 +0100 on 26 Jul (1311678018), Tim Deegan wrote: >> If you want to double-check that you''ve done the patch right, >> edit xen/arch/x86/hvm/vmx/vvmx.c, and at line 1185, just under the line >> ` /* Even if this VMCS isn''t the current one, we must clear it. */ '' >> add a line ` printk("boo!\n"); ''. Then when you recompile and test you >> should see "boo!" printed just after each "vvmx.c:1182:d3" line on the >> console. > Oh, and when the domU is hung, can you run the command > /usr/lib/xen/bin/xenctx -aCS 1 > (replacing ''1'' with the domid of your domU) three or four times > and post the output here? On a 64-bit dom0 I think the correct path > will be /usr/lib64/xen/bin/xenctx. > > Cheers, > > Tim. >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeroen Groenewegen van der Weyden
2011-Jul-26 11:05 UTC
Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
Op 26-7-2011 12:00, Tim Deegan schreef:> If you give your first-level guest only one vcpu, does the problem go > away?I did. I can not tell for sure 100% but it seems different/better. eg from ir-responsive to dead snail performance. after this the DOMU reboot it self but this is/could be a mechanism of the installed application. I''do more investigation to be sure and keep you informed. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Deegan
2011-Jul-26 11:42 UTC
Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
At 12:46 +0200 on 26 Jul (1311684389), Jeroen Groenewegen van der Weyden wrote:> Here my inputThanks. Looks very similar to the bug I thought I fixed with my patch. VCPUs 1 and 3 are always at 0xa01a1c9d: <0f> 01 c2 eb 03 0f 01 c3 which is probably this fragment of code from KVM''s vmx_vcpu_run(): /* Enter guest mode */ "jne .Llaunched \n\t" __ex(ASM_VMX_VMLAUNCH) "\n\t" "jmp .Lkvm_vmx_return \n\t" ".Llaunched: " __ex(ASM_VMX_VMRESUME) "\n\t" ".Lkvm_vmx_return: " So, just like the case I saw, they''re trying to VMLAUNCH a VMCS and failing. That should only fail if the VMCS is already launched. I think the reason they''re _stuck_ is that error paths for VMLAUNCH and VMRESUME emulation are wrong; I can fix them up a little but I suspect that won''t solve the problem; just change it from a hang to some other failure mode. Can you try the attached patch instead of the previous one? Tim. -- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeroen Groenewegen van der Weyden
2011-Jul-26 13:33 UTC
Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
Tim, This improved a lot. the domu does not become in-responsive anymore. However, all four l2 guest are started. but 2 out of 4 are hanging/in-responsive after 30 to 60 seconds. L1 domu (sles11sp1) -> seems to be ok L2-1 propetary OS, seems to be ok L2-2 propetary OS, seems to be ok l2-3 sles10sp3, hanging/in-responsive l2-4 sles10sp3, hanging/in-responsive no degug/error messages in dmesg. mfg, jeroen Op 26-7-2011 13:42, Tim Deegan schreef:> At 12:46 +0200 on 26 Jul (1311684389), Jeroen Groenewegen van der Weyden wrote: >> Here my input > Thanks. Looks very similar to the bug I thought I fixed with my patch. > > VCPUs 1 and 3 are always at 0xa01a1c9d:<0f> 01 c2 eb 03 0f 01 c3 > which is probably this fragment of code from KVM''s vmx_vcpu_run(): > > /* Enter guest mode */ > "jne .Llaunched \n\t" > __ex(ASM_VMX_VMLAUNCH) "\n\t" > "jmp .Lkvm_vmx_return \n\t" > ".Llaunched: " __ex(ASM_VMX_VMRESUME) "\n\t" > ".Lkvm_vmx_return: " > > So, just like the case I saw, they''re trying to VMLAUNCH a VMCS and > failing. That should only fail if the VMCS is already launched. > > I think the reason they''re _stuck_ is that error paths for VMLAUNCH and > VMRESUME emulation are wrong; I can fix them up a little but I suspect > that won''t solve the problem; just change it from a hang to some other > failure mode. > > Can you try the attached patch instead of the previous one? > > Tim. > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Deegan
2011-Jul-26 14:21 UTC
Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
At 15:33 +0200 on 26 Jul (1311694437), Jeroen Groenewegen van der Weyden wrote:> Tim, This improved a lot. the domu does not become in-responsive > anymore. However, all four l2 guest are started. but 2 out of 4 are > hanging/in-responsive after 30 to 60 seconds. > > L1 domu (sles11sp1) > -> seems to be ok > > L2-1 propetary OS, seems to be ok > L2-2 propetary OS, seems to be ok > l2-3 sles10sp3, hanging/in-responsive > l2-4 sles10sp3, hanging/in-responsive > > no degug/error messages in dmesg.Anything in the l1 dmesg? I''m trying to repro with actual linux guests but I''ve found that PXELINUX is hanging for me. :( I''ll have a look at that later if I can. In the meantime I realised I didn''t quite get the logic right in the first patch; there''s one case missing. Can you please try this one? Tim. -- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeroen Groenewegen van der Weyden
2011-Jul-26 15:25 UTC
Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
Tim! everyhting seems to work now. domu is working ok, all 4 nested kvm guests are running. only dmesg seems te complain about something (XEN) vvmx.c:1205:d2 vmclear gpa 1920de000 != 000000018c829000 (XEN) vvmx.c:1205:d2 vmclear gpa 1920de000 != 000000018c829000 (XEN) vvmx.c:1205:d2 vmclear gpa 1920de000 != 00000001f9372000 (XEN) vvmx.c:1205:d2 vmclear gpa 1ec8f7000 != 00000001f9372000 (XEN) vvmx.c:1205:d2 vmclear gpa 1920de000 != 00000001ec8f7000 (XEN) vvmx.c:1205:d2 vmclear gpa 18c829000 != 00000001ec8f7000 (XEN) vvmx.c:1205:d2 vmclear gpa 1920de000 != 00000001ec8f7000 mfg, Jeroen Op 26-7-2011 16:21, Tim Deegan schreef:> At 15:33 +0200 on 26 Jul (1311694437), Jeroen Groenewegen van der Weyden wrote: >> Tim, This improved a lot. the domu does not become in-responsive >> anymore. However, all four l2 guest are started. but 2 out of 4 are >> hanging/in-responsive after 30 to 60 seconds. >> >> L1 domu (sles11sp1) >> -> seems to be ok >> >> L2-1 propetary OS, seems to be ok >> L2-2 propetary OS, seems to be ok >> l2-3 sles10sp3, hanging/in-responsive >> l2-4 sles10sp3, hanging/in-responsive >> >> no degug/error messages in dmesg. > Anything in the l1 dmesg? > > I''m trying to repro with actual linux guests but I''ve found that > PXELINUX is hanging for me. :( I''ll have a look at that later if I can. > > In the meantime I realised I didn''t quite get the logic right in the > first patch; there''s one case missing. Can you please try this one? > > Tim. >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Deegan
2011-Jul-26 15:48 UTC
Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
At 17:25 +0200 on 26 Jul (1311701111), Jeroen Groenewegen van der Weyden wrote:> Tim! everyhting seems to work now. domu is working ok, all 4 nested > kvm guests are running.Excellent. Thank you for the testing. I''ll check those changes in.> only dmesg seems te complain about something > (XEN) vvmx.c:1205:d2 vmclear gpa 1920de000 != 000000018c829000That''s OK; those are benign and I''ll remove them. Cheers, Tim. -- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeroen Groenewegen van der Weyden
2011-Jul-26 16:00 UTC
Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
Tim, just to be complete, I tested them against cs23728. the lastest change set cs23749 fails to boot at my system, it hangs at the hpet. Thank you for cooperation. If you need any further testing done with this nestedhvm just let me know. I can image you want some performance testing and improvments are necessary. mvg, Jeroen Op 26-7-2011 17:48, Tim Deegan schreef:> At 17:25 +0200 on 26 Jul (1311701111), Jeroen Groenewegen van der Weyden wrote: >> Tim! everyhting seems to work now. domu is working ok, all 4 nested >> kvm guests are running. > Excellent. Thank you for the testing. I''ll check those changes in. > >> only dmesg seems te complain about something >> (XEN) vvmx.c:1205:d2 vmclear gpa 1920de000 != 000000018c829000 > That''s OK; those are benign and I''ll remove them. > > Cheers, > > Tim. >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Deegan
2011-Jul-26 16:08 UTC
Re: [Xen-devel] [PATCH 20 of 20] n2 MSR handling and capability exposure
Hi, At 18:00 +0200 on 26 Jul (1311703215), Jeroen Groenewegen van der Weyden wrote:> Thank you for cooperation. If you need any further testing done with > this nestedhvm just let me know. I can image you want some > performance testing and improvments are necessary.Yes, the performance is proabbly pretty poor right now. I believe Eddie has plans for a nested-EPT patch series, which should make a big difference. Tim. -- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel