Re: [kvm-devel] Real Mode Improvement on Intel Hosts - GSoC Project
On Thu, 24 Apr 2008 11:05:39 -0500
Anthony Liguori [EMAIL PROTECTED] wrote:
The first stage is to detect vmentry failures and run x86_emulate() for
a single instruction. If you look at the mailing list, you'll see
patches from myself and Guillaume. This should be enough to allow most
Ubuntu installer CDs to work under KVM.
Howdy,
Here is the last patch I have. It can detects a vmentry failure and it
emulates one instruction. I added the emulation of several instructions
like ljmp, mov Sreg, reg, mov reg, Sreg... The problem I'm
working on is that once I entered in emulation of real mode I do not
manage to recover a VMX friendly state (in my case cs.rpl ==
ss.rpl). So I emulate more and more instructions.
I added a trace to see instructions that are emulated (emulation of
0xa8 is in progress so it currently fails):
[60108.040894] emulation at (46e53) rip 6e13: ea 18 6e 18
[60108.072108] emulation at (46e58) rip 6e18: 66 b8 20 00
[60108.103997] emulation at (46e5c) rip 6e1c: 8e d8 8c d0
[60108.148114] emulation at (46e5e) rip 6e1e: 8c d0 81 e4
[60108.180117] emulation at (46e60) rip 6e20: 81 e4 ff ff
[60108.212008] emulation at (46e66) rip 6e26: c1 e0 04 01
[60108.244926] emulation at (46e69) rip 6e29: 01 c4 66 b8
[60108.272948] emulation at (46e6b) rip 6e2b: 66 b8 08 00
[60108.304953] emulation at (46e6f) rip 6e2f: 8e d0 8e c0
[60108.348973] emulation at (46e71) rip 6e31: 8e c0 8e e0
[60108.396965] emulation at (46e73) rip 6e33: 8e e0 8e e8
[60108.445002] emulation at (46e75) rip 6e35: 8e e8 58 66
[60108.489021] emulation at (46e77) rip 6e37: 58 66 9d 66
[60108.521028] emulation at (46e78) rip 6e38: 66 9d 66 c3
[60108.552979] emulation at (46e7a) rip 6e3a: 66 c3 66 9c
[60108.581048] emulation at (40e2a) rip dea: be 29 0a 00
[60108.613033] emulation at (40e2f) rip def: e8 41 12 00
[60108.644970] emulation at (42075) rip 2035: c6 05 84 07
[60108.673038] emulation at (4207c) rip 203c: e8 18 01 00
[60108.705039] emulation at (42199) rip 2159: 31 c0 80 3d
[60108.736998] emulation at (4219b) rip 215b: 80 3d 86 07
[60108.765041] emulation at (421a2) rip 2162: 74 01 26 ac
[60108.797044] emulation at (421a5) rip 2165: ac c3 80 3d
[60108.829033] emulation at (421a6) rip 2166: c3 80 3d 86
[60108.857068] emulation at (42081) rip 2041: 09 c0 0f 84
[60108.889053] emulation at (42083) rip 2043: 0f 84 0f 01
[60108.921054] emulation at (42198) rip 2158: c3 31 c0 80
[60108.949076] emulation at (40e34) rip df4: 26 66 ff 35
[60108.981077] emulation at (40e3c) rip dfc: 66 8f 05 d0
[60109.013011] emulation at (40e43) rip e03: a1 b4 00 00
[60109.041079] emulation at (40e48) rip e08: 26 8a 40 03
[60109.073039] emulation at (40e4c) rip e0c: a8 01 74 4c
[60109.101078] emulation failed (vmentry failure) rip e0c a8 01 74 4c
So as we can see the first emulated instruction is the ljump and after
we emulate gfxboot loader instruction. I suspect a problem with an
update of SS segment or something like that in instructions that I
emulate.
I paste the patch. Don't worry about the last modification of the two
header files it's not related to real mode emulation.
Regards,
Guillaume
---
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 8e5d664..2c4c14d 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1183,7 +1183,9 @@ static void enter_pmode(struct kvm_vcpu *vcpu)
fix_pmode_dataseg(VCPU_SREG_GS, vcpu-arch.rmode.gs);
fix_pmode_dataseg(VCPU_SREG_FS, vcpu-arch.rmode.fs);
+#if 0
vmcs_write16(GUEST_SS_SELECTOR, 0);
+#endif
vmcs_write32(GUEST_SS_AR_BYTES, 0x93);
vmcs_write16(GUEST_CS_SELECTOR,
@@ -2323,6 +2325,53 @@ static int handle_task_switch(struct kvm_vcpu *vcpu,
struct kvm_run *kvm_run)
return kvm_task_switch(vcpu, tss_selector, reason);
}
+static int handle_vmentry_failure(struct kvm_vcpu *vcpu,
+ struct kvm_run *kvm_run, u32 failure_reason)
+{
+ u16 ss, cs;
+ u8 opcodes[4];
+ unsigned long rip = vcpu-arch.rip;
+ unsigned long rip_linear;
+
+ ss = vmcs_read16(GUEST_SS_SELECTOR);
+ cs = vmcs_read16(GUEST_CS_SELECTOR);
+
+ if ((ss 0x03) != (cs 0x03)) {
+ int err;
+
+#if 0
+ printk(KERN_INFO vmentry failure because ss.cpl != cs.cpl\n);
+#endif
+ rip_linear = rip + vmx_get_segment_base(vcpu, VCPU_SREG_CS);
+ emulator_read_std(rip_linear, (void *)opcodes, 4, vcpu);
+ printk(KERN_INFO emulation at (%lx) rip %lx: %02x %02x %02x
%02x\n,
+ rip_linear,
+ rip, opcodes[0], opcodes[1], opcodes[2],
opcodes[3]);
+ err = emulate_instruction(vcpu, kvm_run, 0, 0, 0);
+ switch (err) {
+ case EMULATE_DONE:
+#if 0
+ printk(KERN_INFO successfully emulated instruction\n);
+#endif
+ return 1;
+ case EMULATE_DO_MMIO:
+ printk(KERN_INFO
Re: [kvm-devel] Real Mode Improvement on Intel Hosts - GSoC Project
Guillaume Thouvenin wrote: On Thu, 24 Apr 2008 11:05:39 -0500 Anthony Liguori [EMAIL PROTECTED] wrote: The first stage is to detect vmentry failures and run x86_emulate() for a single instruction. If you look at the mailing list, you'll see patches from myself and Guillaume. This should be enough to allow most Ubuntu installer CDs to work under KVM. Howdy, Here is the last patch I have. It can detects a vmentry failure and it emulates one instruction. I added the emulation of several instructions like ljmp, mov Sreg, reg, mov reg, Sreg... The problem I'm working on is that once I entered in emulation of real mode I do not manage to recover a VMX friendly state (in my case cs.rpl == ss.rpl). So I emulate more and more instructions. I added a trace to see instructions that are emulated (emulation of 0xa8 is in progress so it currently fails): [60108.040894] emulation at (46e53) rip 6e13: ea 18 6e 18 Here cs.rpl == cpl == 0 [60108.072108] emulation at (46e58) rip 6e18: 66 b8 20 00 [60108.103997] emulation at (46e5c) rip 6e1c: 8e d8 8c d0 [60108.148114] emulation at (46e5e) rip 6e1e: 8c d0 81 e4 [60108.180117] emulation at (46e60) rip 6e20: 81 e4 ff ff [60108.212008] emulation at (46e66) rip 6e26: c1 e0 04 01 [60108.244926] emulation at (46e69) rip 6e29: 01 c4 66 b8 [60108.272948] emulation at (46e6b) rip 6e2b: 66 b8 08 00 mov $8, %eax [60108.304953] emulation at (46e6f) rip 6e2f: 8e d0 8e c0 mov %eax, %ss Here, ss.rpl == 0 -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Real Mode Improvement on Intel Hosts - GSoC Project
On Fri, 25 Apr 2008 09:51:04 +0300 Avi Kivity [EMAIL PROTECTED] wrote: [60108.040894] emulation at (46e53) rip 6e13: ea 18 6e 18 Here cs.rpl == cpl == 0 [60108.072108] emulation at (46e58) rip 6e18: 66 b8 20 00 [60108.103997] emulation at (46e5c) rip 6e1c: 8e d8 8c d0 [60108.148114] emulation at (46e5e) rip 6e1e: 8c d0 81 e4 [60108.180117] emulation at (46e60) rip 6e20: 81 e4 ff ff [60108.212008] emulation at (46e66) rip 6e26: c1 e0 04 01 [60108.244926] emulation at (46e69) rip 6e29: 01 c4 66 b8 [60108.272948] emulation at (46e6b) rip 6e2b: 66 b8 08 00 mov $8, %eax [60108.304953] emulation at (46e6f) rip 6e2f: 8e d0 8e c0 mov %eax, %ss Here, ss.rpl == 0 Yes, thus ss.rpl should be equal to cs.rpl (both equal to 0) and we should be in VMX friendly state. Mmmh, that means I made a mistake in the implementation of 0xb8 or 0x8e instruction. I'm investigating, thanks for your help. Best regards, Guillaume - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]: Fix MSR_K7_EVNTSEL{0,3} for SVM
Chris Lalancette wrote: Avi Kivity wrote: Now it uses %rsi instead of %esi, and any junk in the upper bits will cause the ja to be taken. We need to get a reduced testcase to the gcc folks, this is a serious bug. Any changes in the code to work around this would be fragile. Avi, I've now filed a bug in the upstream gcc database: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36040 And I came up with a reduced test case, available here: http://people.redhat.com/clalance/rsi-test-case.tar.bz2 If I compile the code in the above and look at the disassembly, it shows the problem; however, I can't reproduce the bug by actually running the code. I suspect the %rsi register is always 0 when we start in this userland code, so I never run into the bogus ja, but I just thought I'd mention it. Hmm, looking back at the dump: 1811: 8d 86 00 00 ff 3f lea0x3fff(%rsi),%eax 1817: 83 f8 03cmp$0x3,%eax 181a: 0f 87 e2 01 00 00 ja 1a02 svm_set_msr+0x27f So while gcc is using %rsi, it loads the result back into %eax, which has the effect of dropping back into 32-bits. So looks like gcc was right here. Sorry for spreading confusion and apologies to gcc. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 0/8] EPT support for KVM v4
Hi, Avi Here is the latest EPT patchset. Change from v3: 1. Build the identity mapping pagetable from kernel rather than userspace. The address was changed to 0xfffbc000ul 2. Fix the S/R and LM problem. 3. EPT enabled on 32pae host now. The 2m page should also works, though test blocked by current hugetlb bug. -- Thanks Yang, Sheng - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 1/8] KVM: VMX: EPT Feature Detection
From cd0cf53ce955328f949893316b4717f051085f5a Mon Sep 17 00:00:00 2001
From: Sheng Yang [EMAIL PROTECTED]
Date: Fri, 25 Apr 2008 10:13:16 +0800
Subject: [PATCH 1/8] KVM: VMX: EPT Feature Detection
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
---
arch/x86/kvm/vmx.c | 63 +++
arch/x86/kvm/vmx.h | 25
2 files changed, 83 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 8e5d664..d93250d 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -42,6 +42,9 @@ module_param(enable_vpid, bool, 0);
static int flexpriority_enabled = 1;
module_param(flexpriority_enabled, bool, 0);
+static int enable_ept;
+module_param(enable_ept, bool, 0);
+
struct vmcs {
u32 revision_id;
u32 abort;
@@ -107,6 +110,11 @@ static struct vmcs_config {
u32 vmentry_ctrl;
} vmcs_config;
+struct vmx_capability {
+ u32 ept;
+ u32 vpid;
+} vmx_capability;
+
#define VMX_SEGMENT_FIELD(seg) \
[VCPU_SREG_##seg] = { \
.selector = GUEST_##seg##_SELECTOR, \
@@ -214,6 +222,32 @@ static inline bool
cpu_has_vmx_virtualize_apic_accesses(void)
SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES);
}
+static inline int cpu_has_vmx_invept_individual_addr(void)
+{
+ return (!!(vmx_capability.ept VMX_EPT_EXTENT_INDIVIDUAL_BIT));
+}
+
+static inline int cpu_has_vmx_invept_context(void)
+{
+ return (!!(vmx_capability.ept VMX_EPT_EXTENT_CONTEXT_BIT));
+}
+
+static inline int cpu_has_vmx_invept_global(void)
+{
+ return (!!(vmx_capability.ept VMX_EPT_EXTENT_GLOBAL_BIT));
+}
+
+static inline int cpu_has_vmx_ept(void)
+{
+ return (vmcs_config.cpu_based_2nd_exec_ctrl
+ SECONDARY_EXEC_ENABLE_EPT);
+}
+
+static inline int vm_need_ept(void)
+{
+ return (cpu_has_vmx_ept() enable_ept);
+}
+
static inline int vm_need_virtualize_apic_accesses(struct kvm *kvm)
{
return ((cpu_has_vmx_virtualize_apic_accesses())
@@ -985,7 +1019,7 @@ static __init int adjust_vmx_controls(u32 ctl_min, u32
ctl_opt,
static __init int setup_vmcs_config(struct vmcs_config *vmcs_conf)
{
u32 vmx_msr_low, vmx_msr_high;
- u32 min, opt;
+ u32 min, opt, min2, opt2;
u32 _pin_based_exec_control = 0;
u32 _cpu_based_exec_control = 0;
u32 _cpu_based_2nd_exec_control = 0;
@@ -1003,6 +1037,8 @@ static __init int setup_vmcs_config(struct vmcs_config
*vmcs_conf)
CPU_BASED_CR8_LOAD_EXITING |
CPU_BASED_CR8_STORE_EXITING |
#endif
+ CPU_BASED_CR3_LOAD_EXITING |
+ CPU_BASED_CR3_STORE_EXITING |
CPU_BASED_USE_IO_BITMAPS |
CPU_BASED_MOV_DR_EXITING |
CPU_BASED_USE_TSC_OFFSETING;
@@ -1018,11 +1054,13 @@ static __init int setup_vmcs_config(struct vmcs_config
*vmcs_conf)
~CPU_BASED_CR8_STORE_EXITING;
#endif
if (_cpu_based_exec_control CPU_BASED_ACTIVATE_SECONDARY_CONTROLS) {
- min = 0;
- opt = SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES |
+ min2 = 0;
+ opt2 = SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES |
SECONDARY_EXEC_WBINVD_EXITING |
- SECONDARY_EXEC_ENABLE_VPID;
- if (adjust_vmx_controls(min, opt, MSR_IA32_VMX_PROCBASED_CTLS2,
+ SECONDARY_EXEC_ENABLE_VPID |
+ SECONDARY_EXEC_ENABLE_EPT;
+ if (adjust_vmx_controls(min2, opt2,
+ MSR_IA32_VMX_PROCBASED_CTLS2,
_cpu_based_2nd_exec_control) 0)
return -EIO;
}
@@ -1031,6 +1069,16 @@ static __init int setup_vmcs_config(struct vmcs_config
*vmcs_conf)
SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES))
_cpu_based_exec_control = ~CPU_BASED_TPR_SHADOW;
#endif
+ if (_cpu_based_2nd_exec_control SECONDARY_EXEC_ENABLE_EPT) {
+ /* CR3 accesses don't need to cause VM Exits when EPT enabled */
+ min = ~(CPU_BASED_CR3_LOAD_EXITING |
+CPU_BASED_CR3_STORE_EXITING);
+ if (adjust_vmx_controls(min, opt, MSR_IA32_VMX_PROCBASED_CTLS,
+ _cpu_based_exec_control) 0)
+ return -EIO;
+ rdmsr(MSR_IA32_VMX_EPT_VPID_CAP,
+ vmx_capability.ept, vmx_capability.vpid);
+ }
min = 0;
#ifdef CONFIG_X86_64
@@ -1638,6 +1686,9 @@ static int vmx_vcpu_setup(struct vcpu_vmx *vmx)
CPU_BASED_CR8_LOAD_EXITING;
#endif
}
+ if (!vm_need_ept())
+ exec_control |= CPU_BASED_CR3_STORE_EXITING |
+ CPU_BASED_CR3_LOAD_EXITING;
[kvm-devel] [PATCH 2/8] KVM: MMU: Move some defination
From 75e9d921390a29ecf9c85dd1370103c921beacd7 Mon Sep 17 00:00:00 2001
From: Sheng Yang [EMAIL PROTECTED]
Date: Fri, 25 Apr 2008 10:17:08 +0800
Subject: [PATCH 2/8] KVM: MMU: Move some defination
Move some defination to mmu.h in order to building common table entries.
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
---
arch/x86/kvm/mmu.c | 34 --
arch/x86/kvm/mmu.h | 33 +
2 files changed, 33 insertions(+), 34 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 2ad6f54..bcfaf7e 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -79,36 +79,6 @@ static int dbg = 1;
}
#endif
-#define PT64_PT_BITS 9
-#define PT64_ENT_PER_PAGE (1 PT64_PT_BITS)
-#define PT32_PT_BITS 10
-#define PT32_ENT_PER_PAGE (1 PT32_PT_BITS)
-
-#define PT_WRITABLE_SHIFT 1
-
-#define PT_PRESENT_MASK (1ULL 0)
-#define PT_WRITABLE_MASK (1ULL PT_WRITABLE_SHIFT)
-#define PT_USER_MASK (1ULL 2)
-#define PT_PWT_MASK (1ULL 3)
-#define PT_PCD_MASK (1ULL 4)
-#define PT_ACCESSED_MASK (1ULL 5)
-#define PT_DIRTY_MASK (1ULL 6)
-#define PT_PAGE_SIZE_MASK (1ULL 7)
-#define PT_PAT_MASK (1ULL 7)
-#define PT_GLOBAL_MASK (1ULL 8)
-#define PT64_NX_SHIFT 63
-#define PT64_NX_MASK (1ULL PT64_NX_SHIFT)
-
-#define PT_PAT_SHIFT 7
-#define PT_DIR_PAT_SHIFT 12
-#define PT_DIR_PAT_MASK (1ULL PT_DIR_PAT_SHIFT)
-
-#define PT32_DIR_PSE36_SIZE 4
-#define PT32_DIR_PSE36_SHIFT 13
-#define PT32_DIR_PSE36_MASK \
- (((1ULL PT32_DIR_PSE36_SIZE) - 1) PT32_DIR_PSE36_SHIFT)
-
-
#define PT_FIRST_AVAIL_BITS_SHIFT 9
#define PT64_SECOND_AVAIL_BITS_SHIFT 52
@@ -154,10 +124,6 @@ static int dbg = 1;
#define PFERR_USER_MASK (1U 2)
#define PFERR_FETCH_MASK (1U 4)
-#define PT64_ROOT_LEVEL 4
-#define PT32_ROOT_LEVEL 2
-#define PT32E_ROOT_LEVEL 3
-
#define PT_DIRECTORY_LEVEL 2
#define PT_PAGE_TABLE_LEVEL 1
diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h
index e64e9f5..a4fcb78 100644
--- a/arch/x86/kvm/mmu.h
+++ b/arch/x86/kvm/mmu.h
@@ -9,6 +9,39 @@
#define TDP_ROOT_LEVEL PT32E_ROOT_LEVEL
#endif
+#define PT64_PT_BITS 9
+#define PT64_ENT_PER_PAGE (1 PT64_PT_BITS)
+#define PT32_PT_BITS 10
+#define PT32_ENT_PER_PAGE (1 PT32_PT_BITS)
+
+#define PT_WRITABLE_SHIFT 1
+
+#define PT_PRESENT_MASK (1ULL 0)
+#define PT_WRITABLE_MASK (1ULL PT_WRITABLE_SHIFT)
+#define PT_USER_MASK (1ULL 2)
+#define PT_PWT_MASK (1ULL 3)
+#define PT_PCD_MASK (1ULL 4)
+#define PT_ACCESSED_MASK (1ULL 5)
+#define PT_DIRTY_MASK (1ULL 6)
+#define PT_PAGE_SIZE_MASK (1ULL 7)
+#define PT_PAT_MASK (1ULL 7)
+#define PT_GLOBAL_MASK (1ULL 8)
+#define PT64_NX_SHIFT 63
+#define PT64_NX_MASK (1ULL PT64_NX_SHIFT)
+
+#define PT_PAT_SHIFT 7
+#define PT_DIR_PAT_SHIFT 12
+#define PT_DIR_PAT_MASK (1ULL PT_DIR_PAT_SHIFT)
+
+#define PT32_DIR_PSE36_SIZE 4
+#define PT32_DIR_PSE36_SHIFT 13
+#define PT32_DIR_PSE36_MASK \
+ (((1ULL PT32_DIR_PSE36_SIZE) - 1) PT32_DIR_PSE36_SHIFT)
+
+#define PT64_ROOT_LEVEL 4
+#define PT32_ROOT_LEVEL 2
+#define PT32E_ROOT_LEVEL 3
+
static inline void kvm_mmu_free_some_pages(struct kvm_vcpu *vcpu)
{
if (unlikely(vcpu-kvm-arch.n_free_mmu_pages KVM_MIN_FREE_MMU_PAGES))
--
1.5.4.5
From 75e9d921390a29ecf9c85dd1370103c921beacd7 Mon Sep 17 00:00:00 2001
From: Sheng Yang [EMAIL PROTECTED]
Date: Fri, 25 Apr 2008 10:17:08 +0800
Subject: [PATCH 2/8] KVM: MMU: Move some defination
Move some defination to mmu.h in order to building common table entries.
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
---
arch/x86/kvm/mmu.c | 34 --
arch/x86/kvm/mmu.h | 33 +
2 files changed, 33 insertions(+), 34 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 2ad6f54..bcfaf7e 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -79,36 +79,6 @@ static int dbg = 1;
}
#endif
-#define PT64_PT_BITS 9
-#define PT64_ENT_PER_PAGE (1 PT64_PT_BITS)
-#define PT32_PT_BITS 10
-#define PT32_ENT_PER_PAGE (1 PT32_PT_BITS)
-
-#define PT_WRITABLE_SHIFT 1
-
-#define PT_PRESENT_MASK (1ULL 0)
-#define PT_WRITABLE_MASK (1ULL PT_WRITABLE_SHIFT)
-#define PT_USER_MASK (1ULL 2)
-#define PT_PWT_MASK (1ULL 3)
-#define PT_PCD_MASK (1ULL 4)
-#define PT_ACCESSED_MASK (1ULL 5)
-#define PT_DIRTY_MASK (1ULL 6)
-#define PT_PAGE_SIZE_MASK (1ULL 7)
-#define PT_PAT_MASK (1ULL 7)
-#define PT_GLOBAL_MASK (1ULL 8)
-#define PT64_NX_SHIFT 63
-#define PT64_NX_MASK (1ULL PT64_NX_SHIFT)
-
-#define PT_PAT_SHIFT 7
-#define PT_DIR_PAT_SHIFT 12
-#define PT_DIR_PAT_MASK (1ULL PT_DIR_PAT_SHIFT)
-
-#define PT32_DIR_PSE36_SIZE 4
-#define PT32_DIR_PSE36_SHIFT 13
-#define PT32_DIR_PSE36_MASK \
- (((1ULL PT32_DIR_PSE36_SIZE) - 1) PT32_DIR_PSE36_SHIFT)
-
-
#define PT_FIRST_AVAIL_BITS_SHIFT 9
#define PT64_SECOND_AVAIL_BITS_SHIFT 52
@@ -154,10 +124,6 @@ static int dbg = 1;
#define PFERR_USER_MASK (1U 2)
#define PFERR_FETCH_MASK (1U 4)
-#define PT64_ROOT_LEVEL 4
-#define PT32_ROOT_LEVEL 2
-#define
[kvm-devel] [PATCH 3/8] KVM: Add kvm_x86_ops get_tdp_level()
From 143c1240c5e5391f4e108aedfeb4491e6347d04e Mon Sep 17 00:00:00 2001
From: Sheng Yang [EMAIL PROTECTED]
Date: Fri, 25 Apr 2008 10:20:22 +0800
Subject: [PATCH 3/8] KVM: Add kvm_x86_ops get_tdp_level()
The function get_tdp_level() provided the number of tdp level for EPT and
NPT rather than the NPT specific macro.
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
---
arch/x86/kvm/mmu.h |6 --
arch/x86/kvm/svm.c | 10 ++
arch/x86/kvm/vmx.c |6 ++
arch/x86/kvm/vmx.h |1 +
include/asm-x86/kvm_host.h |2 +-
5 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h
index a4fcb78..1730757 100644
--- a/arch/x86/kvm/mmu.h
+++ b/arch/x86/kvm/mmu.h
@@ -3,12 +3,6 @@
#include linux/kvm_host.h
-#ifdef CONFIG_X86_64
-#define TDP_ROOT_LEVEL PT64_ROOT_LEVEL
-#else
-#define TDP_ROOT_LEVEL PT32E_ROOT_LEVEL
-#endif
-
#define PT64_PT_BITS 9
#define PT64_ENT_PER_PAGE (1 PT64_PT_BITS)
#define PT32_PT_BITS 10
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 89e0be2..ab22615 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1863,6 +1863,15 @@ static bool svm_cpu_has_accelerated_tpr(void)
return false;
}
+static int get_npt_level(void)
+{
+#ifdef CONFIG_X86_64
+ return PT64_ROOT_LEVEL;
+#else
+ return PT32E_ROOT_LEVEL;
+#endif
+}
+
static struct kvm_x86_ops svm_x86_ops = {
.cpu_has_kvm_support = has_svm,
.disabled_by_bios = is_disabled,
@@ -1920,6 +1929,7 @@ static struct kvm_x86_ops svm_x86_ops = {
.inject_pending_vectors = do_interrupt_requests,
.set_tss_addr = svm_set_tss_addr,
+ .get_tdp_level = get_npt_level,
};
static int __init svm_init(void)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index d93250d..98e4f2b 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2788,6 +2788,11 @@ static void __init vmx_check_processor_compat(void
*rtn)
}
}
+static int get_ept_level(void)
+{
+ return VMX_EPT_DEFAULT_GAW + 1;
+}
+
static struct kvm_x86_ops vmx_x86_ops = {
.cpu_has_kvm_support = cpu_has_kvm_support,
.disabled_by_bios = vmx_disabled_by_bios,
@@ -2844,6 +2849,7 @@ static struct kvm_x86_ops vmx_x86_ops = {
.inject_pending_vectors = do_interrupt_requests,
.set_tss_addr = vmx_set_tss_addr,
+ .get_tdp_level = get_ept_level,
};
static int __init vmx_init(void)
diff --git a/arch/x86/kvm/vmx.h b/arch/x86/kvm/vmx.h
index 5f7fdc9..093b085 100644
--- a/arch/x86/kvm/vmx.h
+++ b/arch/x86/kvm/vmx.h
@@ -351,5 +351,6 @@ enum vmcs_field {
#define VMX_EPT_EXTENT_INDIVIDUAL_BIT (1ull 24)
#define VMX_EPT_EXTENT_CONTEXT_BIT (1ull 25)
#define VMX_EPT_EXTENT_GLOBAL_BIT (1ull 26)
+#define VMX_EPT_DEFAULT_GAW3
#endif
diff --git a/include/asm-x86/kvm_host.h b/include/asm-x86/kvm_host.h
index 9d963cd..65b27c9 100644
--- a/include/asm-x86/kvm_host.h
+++ b/include/asm-x86/kvm_host.h
@@ -422,8 +422,8 @@ struct kvm_x86_ops {
struct kvm_run *run);
int (*set_tss_addr)(struct kvm *kvm, unsigned int addr);
+ int (*get_tdp_level)(void);
};
-
extern struct kvm_x86_ops *kvm_x86_ops;
int kvm_mmu_module_init(void);
--
1.5.4.5
From 143c1240c5e5391f4e108aedfeb4491e6347d04e Mon Sep 17 00:00:00 2001
From: Sheng Yang [EMAIL PROTECTED]
Date: Fri, 25 Apr 2008 10:20:22 +0800
Subject: [PATCH 3/8] KVM: Add kvm_x86_ops get_tdp_level()
The function get_tdp_level() provided the number of tdp level for EPT and
NPT rather than the NPT specific macro.
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
---
arch/x86/kvm/mmu.h |6 --
arch/x86/kvm/svm.c | 10 ++
arch/x86/kvm/vmx.c |6 ++
arch/x86/kvm/vmx.h |1 +
include/asm-x86/kvm_host.h |2 +-
5 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h
index a4fcb78..1730757 100644
--- a/arch/x86/kvm/mmu.h
+++ b/arch/x86/kvm/mmu.h
@@ -3,12 +3,6 @@
#include linux/kvm_host.h
-#ifdef CONFIG_X86_64
-#define TDP_ROOT_LEVEL PT64_ROOT_LEVEL
-#else
-#define TDP_ROOT_LEVEL PT32E_ROOT_LEVEL
-#endif
-
#define PT64_PT_BITS 9
#define PT64_ENT_PER_PAGE (1 PT64_PT_BITS)
#define PT32_PT_BITS 10
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 89e0be2..ab22615 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1863,6 +1863,15 @@ static bool svm_cpu_has_accelerated_tpr(void)
return false;
}
+static int get_npt_level(void)
+{
+#ifdef CONFIG_X86_64
+ return PT64_ROOT_LEVEL;
+#else
+ return PT32E_ROOT_LEVEL;
+#endif
+}
+
static struct kvm_x86_ops svm_x86_ops = {
.cpu_has_kvm_support = has_svm,
.disabled_by_bios = is_disabled,
@@ -1920,6 +1929,7 @@ static struct kvm_x86_ops svm_x86_ops = {
.inject_pending_vectors = do_interrupt_requests,
.set_tss_addr = svm_set_tss_addr,
+ .get_tdp_level = get_npt_level,
};
[kvm-devel] [PATCH 4/8] KVM: MMU: Add EPT support
From 239f38236196c2321989c64d7c61ff28490b3f00 Mon Sep 17 00:00:00 2001
From: Sheng Yang [EMAIL PROTECTED]
Date: Fri, 25 Apr 2008 21:13:50 +0800
Subject: [PATCH 4/8] KVM: MMU: Add EPT support
Enable kvm_set_spte() to generate EPT entries.
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
---
arch/x86/kvm/mmu.c | 47 ---
arch/x86/kvm/x86.c |3 ++
include/asm-x86/kvm_host.h |3 ++
3 files changed, 41 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index bcfaf7e..c28a36b 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -152,6 +152,12 @@ static struct kmem_cache *mmu_page_header_cache;
static u64 __read_mostly shadow_trap_nonpresent_pte;
static u64 __read_mostly shadow_notrap_nonpresent_pte;
+static u64 __read_mostly shadow_base_present_pte;
+static u64 __read_mostly shadow_nx_mask;
+static u64 __read_mostly shadow_x_mask;/* mutual exclusive with
nx_mask */
+static u64 __read_mostly shadow_user_mask;
+static u64 __read_mostly shadow_accessed_mask;
+static u64 __read_mostly shadow_dirty_mask;
void kvm_mmu_set_nonpresent_ptes(u64 trap_pte, u64 notrap_pte)
{
@@ -160,6 +166,23 @@ void kvm_mmu_set_nonpresent_ptes(u64 trap_pte, u64
notrap_pte)
}
EXPORT_SYMBOL_GPL(kvm_mmu_set_nonpresent_ptes);
+void kvm_mmu_set_base_ptes(u64 base_pte)
+{
+ shadow_base_present_pte = base_pte;
+}
+EXPORT_SYMBOL_GPL(kvm_mmu_set_base_ptes);
+
+void kvm_mmu_set_mask_ptes(u64 user_mask, u64 accessed_mask,
+ u64 dirty_mask, u64 nx_mask, u64 x_mask)
+{
+ shadow_user_mask = user_mask;
+ shadow_accessed_mask = accessed_mask;
+ shadow_dirty_mask = dirty_mask;
+ shadow_nx_mask = nx_mask;
+ shadow_x_mask = x_mask;
+}
+EXPORT_SYMBOL_GPL(kvm_mmu_set_mask_ptes);
+
static int is_write_protection(struct kvm_vcpu *vcpu)
{
return vcpu-arch.cr0 X86_CR0_WP;
@@ -198,7 +221,7 @@ static int is_writeble_pte(unsigned long pte)
static int is_dirty_pte(unsigned long pte)
{
- return pte PT_DIRTY_MASK;
+ return pte shadow_dirty_mask;
}
static int is_rmap_pte(u64 pte)
@@ -513,7 +536,7 @@ static void rmap_remove(struct kvm *kvm, u64 *spte)
return;
sp = page_header(__pa(spte));
pfn = spte_to_pfn(*spte);
- if (*spte PT_ACCESSED_MASK)
+ if (*spte shadow_accessed_mask)
kvm_set_pfn_accessed(pfn);
if (is_writeble_pte(*spte))
kvm_release_pfn_dirty(pfn);
@@ -1039,17 +1062,17 @@ static void mmu_set_spte(struct kvm_vcpu *vcpu, u64
*shadow_pte,
* whether the guest actually used the pte (in order to detect
* demand paging).
*/
- spte = PT_PRESENT_MASK | PT_DIRTY_MASK;
+ spte = shadow_base_present_pte | shadow_dirty_mask;
if (!speculative)
pte_access |= PT_ACCESSED_MASK;
if (!dirty)
pte_access = ~ACC_WRITE_MASK;
- if (!(pte_access ACC_EXEC_MASK))
- spte |= PT64_NX_MASK;
-
- spte |= PT_PRESENT_MASK;
+ if (pte_access ACC_EXEC_MASK)
+ spte |= shadow_x_mask;
+ else
+ spte |= shadow_nx_mask;
if (pte_access ACC_USER_MASK)
- spte |= PT_USER_MASK;
+ spte |= shadow_user_mask;
if (largepage)
spte |= PT_PAGE_SIZE_MASK;
@@ -1155,7 +1178,7 @@ static int __direct_map(struct kvm_vcpu *vcpu, gpa_t v,
int write,
}
table[index] = __pa(new_table-spt) | PT_PRESENT_MASK
- | PT_WRITABLE_MASK | PT_USER_MASK;
+ | PT_WRITABLE_MASK | shadow_user_mask;
}
table_addr = table[index] PT64_BASE_ADDR_MASK;
}
@@ -1343,7 +1366,7 @@ static int tdp_page_fault(struct kvm_vcpu *vcpu, gva_t
gpa,
spin_lock(vcpu-kvm-mmu_lock);
kvm_mmu_free_some_pages(vcpu);
r = __direct_map(vcpu, gpa, error_code PFERR_WRITE_MASK,
-largepage, gfn, pfn, TDP_ROOT_LEVEL);
+largepage, gfn, pfn, kvm_x86_ops-get_tdp_level());
spin_unlock(vcpu-kvm-mmu_lock);
return r;
@@ -1450,7 +1473,7 @@ static int init_kvm_tdp_mmu(struct kvm_vcpu *vcpu)
context-page_fault = tdp_page_fault;
context-free = nonpaging_free;
context-prefetch_page = nonpaging_prefetch_page;
- context-shadow_root_level = TDP_ROOT_LEVEL;
+ context-shadow_root_level = kvm_x86_ops-get_tdp_level();
context-root_hpa = INVALID_PAGE;
if (!is_paging(vcpu)) {
@@ -1599,7 +1622,7 @@ static bool last_updated_pte_accessed(struct kvm_vcpu
*vcpu)
{
u64 *spte = vcpu-arch.last_pte_updated;
- return !!(spte (*spte PT_ACCESSED_MASK));
+ return !!(spte (*spte shadow_accessed_mask));
}
static void mmu_guess_page_from_pte_write(struct kvm_vcpu *vcpu, gpa_t gpa,
diff --git
[kvm-devel] [PATCH 5/8] KVM: MMU: Remove #ifdef CONFIG_X86_64 to support 4 level EPT
From 169c62e33ea1dbadc8d2fbc3d4880e63caa4d6ab Mon Sep 17 00:00:00 2001
From: Sheng Yang [EMAIL PROTECTED]
Date: Fri, 25 Apr 2008 21:44:42 +0800
Subject: [PATCH 5/8] KVM: MMU: Remove #ifdef CONFIG_X86_64 to support 4 level
EPT
Currently EPT level is 4 for both PAE and 32e. The patch remove the #ifdef
for alloc root_hpa and free root_hpa to support EPT.
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
---
arch/x86/kvm/mmu.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index c28a36b..3dbedf1 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1233,7 +1233,6 @@ static void mmu_free_roots(struct kvm_vcpu *vcpu)
if (!VALID_PAGE(vcpu-arch.mmu.root_hpa))
return;
spin_lock(vcpu-kvm-mmu_lock);
-#ifdef CONFIG_X86_64
if (vcpu-arch.mmu.shadow_root_level == PT64_ROOT_LEVEL) {
hpa_t root = vcpu-arch.mmu.root_hpa;
@@ -1245,7 +1244,6 @@ static void mmu_free_roots(struct kvm_vcpu *vcpu)
spin_unlock(vcpu-kvm-mmu_lock);
return;
}
-#endif
for (i = 0; i 4; ++i) {
hpa_t root = vcpu-arch.mmu.pae_root[i];
@@ -1271,7 +1269,6 @@ static void mmu_alloc_roots(struct kvm_vcpu *vcpu)
root_gfn = vcpu-arch.cr3 PAGE_SHIFT;
-#ifdef CONFIG_X86_64
if (vcpu-arch.mmu.shadow_root_level == PT64_ROOT_LEVEL) {
hpa_t root = vcpu-arch.mmu.root_hpa;
@@ -1286,7 +1283,6 @@ static void mmu_alloc_roots(struct kvm_vcpu *vcpu)
vcpu-arch.mmu.root_hpa = root;
return;
}
-#endif
metaphysical = !is_paging(vcpu);
if (tdp_enabled)
metaphysical = 1;
--
1.5.4.5
From 169c62e33ea1dbadc8d2fbc3d4880e63caa4d6ab Mon Sep 17 00:00:00 2001
From: Sheng Yang [EMAIL PROTECTED]
Date: Fri, 25 Apr 2008 21:44:42 +0800
Subject: [PATCH 5/8] KVM: MMU: Remove #ifdef CONFIG_X86_64 to support 4 level EPT
Currently EPT level is 4 for both PAE and 32e. The patch remove the #ifdef
for alloc root_hpa and free root_hpa to support EPT.
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
---
arch/x86/kvm/mmu.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index c28a36b..3dbedf1 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1233,7 +1233,6 @@ static void mmu_free_roots(struct kvm_vcpu *vcpu)
if (!VALID_PAGE(vcpu-arch.mmu.root_hpa))
return;
spin_lock(vcpu-kvm-mmu_lock);
-#ifdef CONFIG_X86_64
if (vcpu-arch.mmu.shadow_root_level == PT64_ROOT_LEVEL) {
hpa_t root = vcpu-arch.mmu.root_hpa;
@@ -1245,7 +1244,6 @@ static void mmu_free_roots(struct kvm_vcpu *vcpu)
spin_unlock(vcpu-kvm-mmu_lock);
return;
}
-#endif
for (i = 0; i 4; ++i) {
hpa_t root = vcpu-arch.mmu.pae_root[i];
@@ -1271,7 +1269,6 @@ static void mmu_alloc_roots(struct kvm_vcpu *vcpu)
root_gfn = vcpu-arch.cr3 PAGE_SHIFT;
-#ifdef CONFIG_X86_64
if (vcpu-arch.mmu.shadow_root_level == PT64_ROOT_LEVEL) {
hpa_t root = vcpu-arch.mmu.root_hpa;
@@ -1286,7 +1283,6 @@ static void mmu_alloc_roots(struct kvm_vcpu *vcpu)
vcpu-arch.mmu.root_hpa = root;
return;
}
-#endif
metaphysical = !is_paging(vcpu);
if (tdp_enabled)
metaphysical = 1;
--
1.5.4.5
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 6/8] KVM: Export necessary function for EPT
From 6edba459ef83a1f2c64c3b782ce67a14e74f9330 Mon Sep 17 00:00:00 2001 From: Sheng Yang [EMAIL PROTECTED] Date: Fri, 25 Apr 2008 21:44:50 +0800 Subject: [PATCH 6/8] KVM: Export necessary function for EPT Signed-off-by: Sheng Yang [EMAIL PROTECTED] --- virt/kvm/kvm_main.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 5e7802e..1d7991a 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -522,6 +522,7 @@ unsigned long gfn_to_hva(struct kvm *kvm, gfn_t gfn) return bad_hva(); return (slot-userspace_addr + (gfn - slot-base_gfn) * PAGE_SIZE); } +EXPORT_SYMBOL_GPL(gfn_to_hva); /* * Requires current-mm-mmap_sem to be held -- 1.5.4.5 From 6edba459ef83a1f2c64c3b782ce67a14e74f9330 Mon Sep 17 00:00:00 2001 From: Sheng Yang [EMAIL PROTECTED] Date: Fri, 25 Apr 2008 21:44:50 +0800 Subject: [PATCH 6/8] KVM: Export necessary function for EPT Signed-off-by: Sheng Yang [EMAIL PROTECTED] --- virt/kvm/kvm_main.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 5e7802e..1d7991a 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -522,6 +522,7 @@ unsigned long gfn_to_hva(struct kvm *kvm, gfn_t gfn) return bad_hva(); return (slot-userspace_addr + (gfn - slot-base_gfn) * PAGE_SIZE); } +EXPORT_SYMBOL_GPL(gfn_to_hva); /* * Requires current-mm-mmap_sem to be held -- 1.5.4.5 - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 7/8] KVM: VMX: Perpare a identity page table for EPT in real mode
From 30448ffed0d5dad04d0538a53661764128cf05f5 Mon Sep 17 00:00:00 2001
From: Sheng Yang [EMAIL PROTECTED]
Date: Fri, 25 Apr 2008 21:44:52 +0800
Subject: [PATCH 7/8] KVM: VMX: Perpare a identity page table for EPT in real
mode
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
---
arch/x86/kvm/vmx.c | 79
++--
arch/x86/kvm/vmx.h |3 ++
include/asm-x86/kvm_host.h |3 ++
3 files changed, 82 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 98e4f2b..de5f615 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -87,7 +87,7 @@ static inline struct vcpu_vmx *to_vmx(struct kvm_vcpu *vcpu)
return container_of(vcpu, struct vcpu_vmx, vcpu);
}
-static int init_rmode_tss(struct kvm *kvm);
+static int init_rmode(struct kvm *kvm);
static DEFINE_PER_CPU(struct vmcs *, vmxarea);
static DEFINE_PER_CPU(struct vmcs *, current_vmcs);
@@ -1304,7 +1304,7 @@ static void enter_rmode(struct kvm_vcpu *vcpu)
fix_rmode_seg(VCPU_SREG_FS, vcpu-arch.rmode.fs);
kvm_mmu_reset_context(vcpu);
- init_rmode_tss(vcpu-kvm);
+ init_rmode(vcpu-kvm);
}
#ifdef CONFIG_X86_64
@@ -1578,6 +1578,41 @@ out:
return ret;
}
+static int init_rmode_identity_map(struct kvm *kvm)
+{
+ int i, r, ret;
+ pfn_t identity_map_pfn;
+ u32 tmp;
+
+ if (!vm_need_ept())
+ return 1;
+ if (unlikely(!kvm-arch.ept_identity_pagetable)) {
+ printk(KERN_ERR EPT: identity-mapping pagetable
+ haven't been allocated!\n);
+ return 0;
+ }
+ if (likely(kvm-arch.ept_identity_pagetable_done))
+ return 1;
+ ret = 0;
+ identity_map_pfn = VMX_EPT_IDENTITY_PAGETABLE_ADDR PAGE_SHIFT;
+ r = kvm_clear_guest_page(kvm, identity_map_pfn, 0, PAGE_SIZE);
+ if (r 0)
+ goto out;
+ /* Set up identity-mapping pagetable for EPT in real mode */
+ for (i = 0; i PT32_ENT_PER_PAGE; i++) {
+ tmp = (i 22) + (_PAGE_PRESENT | _PAGE_RW | _PAGE_USER |
+ _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_PSE);
+ r = kvm_write_guest_page(kvm, identity_map_pfn,
+ tmp, i * sizeof(tmp), sizeof(tmp));
+ if (r 0)
+ goto out;
+ }
+ kvm-arch.ept_identity_pagetable_done = true;
+ ret = 1;
+out:
+ return ret;
+}
+
static void seg_setup(int seg)
{
struct kvm_vmx_segment_field *sf = kvm_vmx_segment_fields[seg];
@@ -1612,6 +1647,31 @@ out:
return r;
}
+static int alloc_identity_pagetable(struct kvm *kvm)
+{
+ struct kvm_userspace_memory_region kvm_userspace_mem;
+ int r = 0;
+
+ down_write(kvm-slots_lock);
+ if (kvm-arch.ept_identity_pagetable)
+ goto out;
+ kvm_userspace_mem.slot = IDENTITY_PAGETABLE_PRIVATE_MEMSLOT;
+ kvm_userspace_mem.flags = 0;
+ kvm_userspace_mem.guest_phys_addr = VMX_EPT_IDENTITY_PAGETABLE_ADDR;
+ kvm_userspace_mem.memory_size = PAGE_SIZE;
+ r = __kvm_set_memory_region(kvm, kvm_userspace_mem, 0);
+ if (r)
+ goto out;
+
+ down_read(current-mm-mmap_sem);
+ kvm-arch.ept_identity_pagetable = gfn_to_page(kvm,
+ VMX_EPT_IDENTITY_PAGETABLE_ADDR PAGE_SHIFT);
+ up_read(current-mm-mmap_sem);
+out:
+ up_write(kvm-slots_lock);
+ return r;
+}
+
static void allocate_vpid(struct vcpu_vmx *vmx)
{
int vpid;
@@ -1775,6 +1835,15 @@ static int vmx_vcpu_setup(struct vcpu_vmx *vmx)
return 0;
}
+static int init_rmode(struct kvm *kvm)
+{
+ if (!init_rmode_tss(kvm))
+ return 0;
+ if (!init_rmode_identity_map(kvm))
+ return 0;
+ return 1;
+}
+
static int vmx_vcpu_reset(struct kvm_vcpu *vcpu)
{
struct vcpu_vmx *vmx = to_vmx(vcpu);
@@ -1782,7 +1851,7 @@ static int vmx_vcpu_reset(struct kvm_vcpu *vcpu)
int ret;
down_read(vcpu-kvm-slots_lock);
- if (!init_rmode_tss(vmx-vcpu.kvm)) {
+ if (!init_rmode(vmx-vcpu.kvm)) {
ret = -ENOMEM;
goto out;
}
@@ -2759,6 +2828,10 @@ static struct kvm_vcpu *vmx_create_vcpu(struct kvm
*kvm, unsigned int id)
if (alloc_apic_access_page(kvm) != 0)
goto free_vmcs;
+ if (vm_need_ept())
+ if (alloc_identity_pagetable(kvm) != 0)
+ goto free_vmcs;
+
return vmx-vcpu;
free_vmcs:
diff --git a/arch/x86/kvm/vmx.h b/arch/x86/kvm/vmx.h
index 093b085..f97eccc 100644
--- a/arch/x86/kvm/vmx.h
+++ b/arch/x86/kvm/vmx.h
@@ -340,6 +340,7 @@ enum vmcs_field {
#define MSR_IA32_FEATURE_CONTROL_VMXON_ENABLED 0x4
#define APIC_ACCESS_PAGE_PRIVATE_MEMSLOT 9
+#define IDENTITY_PAGETABLE_PRIVATE_MEMSLOT 10
#define VMX_NR_VPIDS (1 16)
#define
[kvm-devel] [PATCH 8/8] KVM: VMX: Enable EPT feature for KVM
From 592b7855a88266fa19505f0d51fe12ec0eadfa62 Mon Sep 17 00:00:00 2001
From: Sheng Yang [EMAIL PROTECTED]
Date: Fri, 25 Apr 2008 22:14:06 +0800
Subject: [PATCH 8/8] KVM: VMX: Enable EPT feature for KVM
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
---
arch/x86/kvm/mmu.c | 11 ++-
arch/x86/kvm/vmx.c | 227
++--
arch/x86/kvm/vmx.h |9 ++
include/asm-x86/kvm_host.h |1 +
4 files changed, 238 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 3dbedf1..7a8640a 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1177,8 +1177,15 @@ static int __direct_map(struct kvm_vcpu *vcpu, gpa_t v,
int write,
return -ENOMEM;
}
- table[index] = __pa(new_table-spt) | PT_PRESENT_MASK
- | PT_WRITABLE_MASK | shadow_user_mask;
+ if (shadow_user_mask)
+ table[index] = __pa(new_table-spt)
+ | PT_PRESENT_MASK | PT_WRITABLE_MASK
+ | shadow_user_mask;
+ else
+ table[index] = __pa(new_table-spt)
+ | PT_PRESENT_MASK | PT_WRITABLE_MASK
+ | shadow_x_mask;
+ table[index] = __pa(new_table-spt) | 0x7;
}
table_addr = table[index] PT64_BASE_ADDR_MASK;
}
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index de5f615..8870c6f 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -42,7 +42,7 @@ module_param(enable_vpid, bool, 0);
static int flexpriority_enabled = 1;
module_param(flexpriority_enabled, bool, 0);
-static int enable_ept;
+static int enable_ept = 1;
module_param(enable_ept, bool, 0);
struct vmcs {
@@ -284,6 +284,18 @@ static inline void __invvpid(int ext, u16 vpid, gva_t
gva)
: : a(operand), c(ext) : cc, memory);
}
+static inline void __invept(int ext, u64 eptp, gpa_t gpa)
+{
+ struct {
+ u64 eptp, gpa;
+ } operand = {eptp, gpa};
+
+ asm volatile (ASM_VMX_INVEPT
+ /* CF==1 or ZF==1 -- rc = -1 */
+ ; ja 1f ; ud2 ; 1:\n
+ : : a (operand), c (ext) : cc, memory);
+}
+
static struct kvm_msr_entry *find_msr_entry(struct vcpu_vmx *vmx, u32 msr)
{
int i;
@@ -335,6 +347,33 @@ static inline void vpid_sync_vcpu_all(struct vcpu_vmx
*vmx)
__invvpid(VMX_VPID_EXTENT_SINGLE_CONTEXT, vmx-vpid, 0);
}
+static inline void ept_sync_global(void)
+{
+ if (cpu_has_vmx_invept_global())
+ __invept(VMX_EPT_EXTENT_GLOBAL, 0, 0);
+}
+
+static inline void ept_sync_context(u64 eptp)
+{
+ if (vm_need_ept()) {
+ if (cpu_has_vmx_invept_context())
+ __invept(VMX_EPT_EXTENT_CONTEXT, eptp, 0);
+ else
+ ept_sync_global();
+ }
+}
+
+static inline void ept_sync_individual_addr(u64 eptp, gpa_t gpa)
+{
+ if (vm_need_ept()) {
+ if (cpu_has_vmx_invept_individual_addr())
+ __invept(VMX_EPT_EXTENT_INDIVIDUAL_ADDR,
+ eptp, gpa);
+ else
+ ept_sync_context(eptp);
+ }
+}
+
static unsigned long vmcs_readl(unsigned long field)
{
unsigned long value;
@@ -422,6 +461,8 @@ static void update_exception_bitmap(struct kvm_vcpu *vcpu)
eb |= 1u 1;
if (vcpu-arch.rmode.active)
eb = ~0;
+ if (vm_need_ept())
+ eb = ~(1u PF_VECTOR); /* bypass_guest_pf = 0 */
vmcs_write32(EXCEPTION_BITMAP, eb);
}
@@ -1352,8 +1393,64 @@ static void vmx_decache_cr4_guest_bits(struct kvm_vcpu
*vcpu)
vcpu-arch.cr4 |= vmcs_readl(GUEST_CR4) ~KVM_GUEST_CR4_MASK;
}
+static void ept_load_pdptrs(struct kvm_vcpu *vcpu)
+{
+ if (is_paging(vcpu) is_pae(vcpu) !is_long_mode(vcpu)) {
+ if (!load_pdptrs(vcpu, vcpu-arch.cr3)) {
+ printk(KERN_ERR EPT: Fail to load pdptrs!\n);
+ return;
+ }
+ vmcs_write64(GUEST_PDPTR0, vcpu-arch.pdptrs[0]);
+ vmcs_write64(GUEST_PDPTR1, vcpu-arch.pdptrs[1]);
+ vmcs_write64(GUEST_PDPTR2, vcpu-arch.pdptrs[2]);
+ vmcs_write64(GUEST_PDPTR3, vcpu-arch.pdptrs[3]);
+ }
+}
+
+static void vmx_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4);
+
+static void ept_update_paging_mode_cr0(unsigned long *hw_cr0,
+ unsigned long cr0,
+ struct kvm_vcpu *vcpu)
+{
+ if (!(cr0 X86_CR0_PG)) {
+ /* From paging/starting to nonpaging */
+
Re: [kvm-devel] [kvm-ppc-devel] Moving kvm lists to kernel.org?
Avi == Avi Kivity [EMAIL PROTECTED] writes: Avi kvm-devel doesn't do manual moderation. If vger has the Avi infrastructure, I don't see why you can't continue doing this on Avi kvm-ppc-devel. Please don't do this for the kvm-ia64 list either. Avi btw, we can probably shorten the names to kvm@ and kvm-$arch@ Avi while we're at it. Either way works IMHO. Cheers, Jes - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] KVM-66 stop working with lilo boot loader
Hello everybody I have problem to boot guests with lilo installed, after I upgrade to KVM-66 (from 65). Boot sequence always stop with LIL output. With kvm-65 everythink works great. I have also windows XP guest, which boot without problem. With -no-kvm, all my guests with lilo start correctly. Processor: AMD Opteron 2210 KVM: kvm-64 Host: gentoo-sources-2.6.25-r1 Arch: x86_64 Guests: gentoo, 2.6.25, x86_64 dmesg: Apr 21 09:53:37 kvm BUG: unable to handle kernel NULL pointer dereference at Apr 21 09:53:37 kvm IP: [88029c85] :kvm:x86_emulate_insn+0x3a47/0x468f Apr 21 09:53:37 kvm PGD 11e989067 PUD 11ec0a067 PMD 0 Apr 21 09:53:37 kvm Oops: 0002 [2] SMP Apr 21 09:53:37 kvm CPU 2 Apr 21 09:53:37 kvm Modules linked in: w83627hf hwmon_vid xt_tcpudp xt_state iptable_mangle iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack iptable_filter ip_tables x_tables tun kvm_amd kvm shpchp pci_hotplug k8temp i2c_nforce2 i2c_core Apr 21 09:53:37 kvm Pid: 7130, comm: kvm Tainted: G D 2.6.25-gentoo-r1 #1 Apr 21 09:53:37 kvm RIP: 0010:[88029c85] [88029c85] :kvm:x86_emulate_insn+0x3a47/0x468f Apr 21 09:53:37 kvm RSP: 0018:81011e3e5738 EFLAGS: 00010246 Apr 21 09:53:37 kvm RAX: 0010 RBX: RCX: 81011e3e7378 Apr 21 09:53:37 kvm RDX: RSI: RDI: 81011e3e6000 Apr 21 09:53:37 kvm RBP: 81011e3e7378 R08: R09: Apr 21 09:53:37 kvm R10: 88041988 R11: 81011e3e7378 R12: 81011e3e7330 Apr 21 09:53:37 kvm R13: R14: 88033a20 R15: 0ce3 Apr 21 09:53:37 kvm FS: 41e68950(0063) GS:81011ff1b000() knlGS: Apr 21 09:53:37 kvm CS: 0010 DS: ES: CR0: 8005003b Apr 21 09:53:37 kvm CR2: CR3: 00011e1af000 CR4: 06e0 Apr 21 09:53:37 kvm DR0: 805b34f8 DR1: DR2: Apr 21 09:53:37 kvm DR3: DR6: 0ff1 DR7: 0701 Apr 21 09:53:37 kvm Process kvm (pid: 7130, threadinfo 81011e3e4000, task 81011e56) Apr 21 09:53:37 kvm Stack: 8021a311 000f fff7 8021a49b Apr 21 09:53:37 kvm 81011ed41d00 c20001926000 Apr 21 09:53:37 kvm 8021a311 802347a0 81011ed41d00 880419e0 Apr 21 09:53:37 kvm Call Trace: Apr 21 09:53:37 kvm [8021a311] ? do_flush_tlb_all+0x0/0x2f Apr 21 09:53:37 kvm [8021a49b] ? smp_call_function_mask+0x47/0x55 Apr 21 09:53:37 kvm [8021a311] ? do_flush_tlb_all+0x0/0x2f Apr 21 09:53:37 kvm [802347a0] ? on_each_cpu+0x19/0x25 Apr 21 09:53:37 kvm [880419e0] Apr 21 09:53:37 kvm [88020501] ? :kvm:kvm_get_cs_db_l_bits+0x9/0x2f Apr 21 09:53:37 kvm [8801f101] ? :kvm:emulate_instruction+0x1ef/0x3a5 Apr 21 09:53:37 kvm [8801f101] ? :kvm:emulate_instruction+0x1ef/0x3a5 Apr 21 09:53:37 kvm [88041fbc] Apr 21 09:53:37 kvm [88020148] ? :kvm:kvm_arch_vcpu_ioctl_run+0x44a/0x5b8 Apr 21 09:53:37 kvm [8801bf23] ? :kvm:kvm_resched+0x1b4/0x9b7 Apr 21 09:53:37 kvm [8802ad63] ? :kvm:kvm_pic_set_irq+0x21/0x6b Apr 21 09:53:37 kvm [8801e81b] ? :kvm:kvm_arch_vm_ioctl+0x38e/0x5e6 Apr 21 09:53:37 kvm [8026217b] ? zone_statistics+0x41/0x94 Apr 21 09:53:37 kvm [8025bc16] ? get_page_from_freelist+0x457/0x5af Apr 21 09:53:37 kvm [8025bdc0] ? __alloc_pages+0x52/0x2ee Apr 21 09:53:37 kvm [80225e50] ? source_load+0x25/0x41 Apr 21 09:53:37 kvm [802286f1] ? find_busiest_group+0x268/0x742 Apr 21 09:53:37 kvm [80225552] ? hrtick_set+0x99/0x107 Apr 21 09:53:37 kvm [805b3aae] ? thread_return+0x64/0xa5 Apr 21 09:53:37 kvm [80249099] ? get_futex_key+0x76/0x14d Apr 21 09:53:37 kvm [80249816] ? unqueue_me+0x6b/0x73 Apr 21 09:53:37 kvm [80249bc1] ? futex_wait+0x290/0x327 Apr 21 09:53:37 kvm [80227c36] ? try_to_wake_up+0xfa/0x10c Apr 21 09:53:37 kvm [80229752] ? __wake_up_common+0x49/0x74 Apr 21 09:53:37 kvm [80268c29] ? find_extend_vma+0x16/0x61 Apr 21 09:53:37 kvm [80249099] ? get_futex_key+0x76/0x14d Apr 21 09:53:37 kvm [803c1439] ? __up_read+0x10/0x8a Apr 21 09:53:37 kvm [8024955e] ? futex_wake+0xfa/0x10c Apr 21 09:53:37 kvm [80242e5a] ? ktime_get_ts+0x56/0x5d Apr 21 09:53:37 kvm [8801c3cb] ? :kvm:kvm_resched+0x65c/0x9b7 Apr 21 09:53:37 kvm [80225552] ? hrtick_set+0x99/0x107 Apr 21 09:53:37 kvm [8028a311] ? vfs_ioctl+0x29/0x6f Apr 21 09:53:37 kvm [8028a5a4] ? do_vfs_ioctl+0x24d/0x25c Apr 21 09:53:37 kvm [8028a5ef] ? sys_ioctl+0x3c/0x61 Apr 21 09:53:37 kvm [8020b09b] ? system_call_after_swapgs+0x7b/0x80 Apr 21 09:53:37 kvm Apr 21 09:53:37 kvm Apr 21 09:53:37 kvm Code: 02 74 20 77 06 ff c8 74 0e eb 78 83 f8 04 74 20
[kvm-devel] You will be surprised at how easy it is
Why go for surgery when you can take and see the effects of these nutritional supplements in 6 months? http://www.esmoses.com/ - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]: Fix MSR_K7_EVNTSEL{0,3} for SVM
Avi Kivity wrote: Hmm, looking back at the dump: 1811:8d 86 00 00 ff 3f lea0x3fff(%rsi),%eax 1817:83 f8 03cmp$0x3,%eax 181a:0f 87 e2 01 00 00 ja 1a02 svm_set_msr+0x27f So while gcc is using %rsi, it loads the result back into %eax, which has the effect of dropping back into 32-bits. So looks like gcc was right here. Sorry for spreading confusion and apologies to gcc. OK. Well, then I can't explain why we are unconditionally calling kvm_set_msr_common(), regardless of whether data == 0 or not. Avi, you said it works for you; what version of gcc are you using, and can you send me your objdump -Sr? I'd like to compare the assembly output with what 4.3.0 is spitting out. Chris Lalancette - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] [PATCH 2 of 3] Add PowerPC KVM guest wait handling support
On Friday 25 April 2008 00:56:03 Jerone Young wrote:
This patch handles a guest that is in a wait state. This ensures that the
guest is not allways eating up 100% cpu when it is idle.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -265,6 +265,11 @@ int kvmppc_emulate_instruction(struct kv
case 146: /* mtmsr */
rs = get_rs(inst);
kvmppc_set_msr(vcpu, vcpu-arch.gpr[rs]);
+
+ /* handle guest vcpu that is in wait state */
+ if (vcpu-arch.msr MSR_WE) {
+ kvm_vcpu_block(vcpu);
+ }
break;
case 163: /* wrteei */
So if I apply this patch and not #3, the guest will put itself to sleep and
never wake up? You need to combine patches 2 and 3.
Also, for completeness, you should add the same test to the rfi emulation,
which could (theoretically) also set MSR[WE].
--
Hollis Blanchard
IBM Linux Technology Center
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] [PATCH 3 of 3] Add premption handlers properly wake sleeping guest
On Friday 25 April 2008 00:56:04 Jerone Young wrote:
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -212,6 +212,9 @@ static void kvmppc_decrementer_func(unsi
{
struct kvm_vcpu *vcpu = (struct kvm_vcpu *)data;
+ if (waitqueue_active(vcpu-wq))
+ wake_up_interruptible(vcpu-wq);
+
kvmppc_queue_exception(vcpu, BOOKE_INTERRUPT_DECREMENTER);
}
Hooray!
int kvm_vcpu_ioctl_interrupt(struct kvm_vcpu *vcpu, struct kvm_interrupt
*irq)
{
+ vcpu_load(vcpu);
kvmppc_queue_exception(vcpu, BOOKE_INTERRUPT_EXTERNAL);
+ vcpu_put(vcpu);
+
return 0;
}
load/put here is definitely unnecessary.
That makes me question how necessary it is in other parts of this patch too. I
think the (hardware) TLB is the only state we really need to worry about,
because there is no other state that our guest can load into the hardware
that is not handled by a regular context switch.
If that's true, we should only need vcpu_load/put() on paths where we muck
with the TLB behind the host's back, and that is only in the run path.
--
Hollis Blanchard
IBM Linux Technology Center
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] [PATCH 0 of 3] Fix guest eating 100% cpu when guest is idle on PowerPC
On Friday 25 April 2008 00:56:01 Jerone Young wrote: This set of patches fixes 100% CPU usage when a guest is idle on PowerPC. This time it uses common kvm functions to sleep the guest. Looking much better now, with just a few minor issues to correct. With these patches applied, about how much CPU *does* an idling guest consume? By the way, you don't explicitly *unset* MSR[WE]. I think this works implicitly because of the way we deliver interrupts; could you add a comment explaining that? -- Hollis Blanchard IBM Linux Technology Center - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] [PATCH 0 of 3] Fix guest eating 100% cpu when guest is idle on PowerPC
On Fri, 2008-04-25 at 09:00 -0500, Hollis Blanchard wrote: On Friday 25 April 2008 00:56:01 Jerone Young wrote: This set of patches fixes 100% CPU usage when a guest is idle on PowerPC. This time it uses common kvm functions to sleep the guest. Looking much better now, with just a few minor issues to correct. With these patches applied, about how much CPU *does* an idling guest consume? With the current patch *as is* idle guest are eating about 16% CPU. Better then 100%, but more then the other patch. I'll see if by removing the vcpu_loads vcpu_puts if that goes down. By the way, you don't explicitly *unset* MSR[WE]. I think this works implicitly because of the way we deliver interrupts; could you add a comment explaining that? Yes it is unset implicity. I can add a comment on this. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1 of 9] Lock the entire mm to prevent any mmu related operation to happen
I somehow lost missed this email in my inbox, found it now because it
was strangely still unread... Sorry for the late reply!
On Tue, Apr 22, 2008 at 03:06:24PM +1000, Rusty Russell wrote:
On Wednesday 09 April 2008 01:44:04 Andrea Arcangeli wrote:
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1050,6 +1050,15 @@
unsigned long addr, unsigned long len,
unsigned long flags, struct page **pages);
+struct mm_lock_data {
+ spinlock_t **i_mmap_locks;
+ spinlock_t **anon_vma_locks;
+ unsigned long nr_i_mmap_locks;
+ unsigned long nr_anon_vma_locks;
+};
+extern struct mm_lock_data *mm_lock(struct mm_struct * mm);
+extern void mm_unlock(struct mm_struct *mm, struct mm_lock_data *data);
As far as I can tell you don't actually need to expose this struct at all?
Yes, it should be possible to only expose 'struct mm_lock_data;'.
+ data-i_mmap_locks = vmalloc(nr_i_mmap_locks *
+sizeof(spinlock_t));
This is why non-typesafe allocators suck. You want 'sizeof(spinlock_t *)'
here.
+ data-anon_vma_locks = vmalloc(nr_anon_vma_locks *
+ sizeof(spinlock_t));
and here.
Great catch! (it was temporarily wasting some ram which isn't nice at all)
+ err = -EINTR;
+ i_mmap_lock_last = NULL;
+ nr_i_mmap_locks = 0;
+ for (;;) {
+ spinlock_t *i_mmap_lock = (spinlock_t *) -1UL;
+ for (vma = mm-mmap; vma; vma = vma-vm_next) {
...
+ data-i_mmap_locks[nr_i_mmap_locks++] = i_mmap_lock;
+ }
+ data-nr_i_mmap_locks = nr_i_mmap_locks;
How about you track your running counter in data-nr_i_mmap_locks, leave
nr_i_mmap_locks alone, and BUG_ON(data-nr_i_mmap_locks != nr_i_mmap_locks)?
Even nicer would be to wrap this in a get_sorted_mmap_locks() function.
I'll try to clean this up further and I'll make a further update for review.
Unfortunately, I just don't think we can fail locking like this. In your
next
patch unregistering a notifier can fail because of it: that not usable.
Fortunately I figured out we don't really need mm_lock in unregister
because it's ok to unregister in the middle of the range_begin/end
critical section (that's definitely not ok for register that's why
register needs mm_lock). And it's perfectly ok to fail in register().
Also it wasn't ok to unpin the module count in -release as -release
needs to 'ret' to get back to the mmu notifier code. And without any
unregister at all, the module can't be unloaded at all which
is quite unacceptable...
The logic is to prevent mmu_notifier_register to race with
mmu_notifier_release because it takes the mm_users pin (implicit or
explicit, and then mmput just after mmu_notifier_register
returns). Then _register serializes against all the mmu notifier
methods (except -release) with srcu (-release can't run thanks to
the mm_users pin). The mmu_notifier_mm-lock then serializes the
modification on the list (register vs unregister) and it ensures one
and only one between _unregister and _releases calls -release before
_unregister returns. All other methods runs freely with srcu. Having
the guarante that -release is called just before all pages are freed
or inside _unregister, allows the module to zap and freeze its
secondary mmu inside -release with the race condition of exit()
against mmu_notifier_unregister internally by the mmu notifier code
and without dependency on exit_files/exit_mm ordering depending if the
fd of the driver is open the filetables or in the vma only. The
mmu_notifier_mm can be reset to 0 only after the last mmdrop.
About the mm_count refcounting for _release and _unregiste: no mmu
notifier and not even mmu_notifier_unregister and _release can cope
with mmu_notfier_mm list and srcu structures going away out of
order. exit_mmap is safe as it holds an mm_count implicitly because
mmdrop is run after exit_mmap returns. mmu_notifier_unregister is safe
too as _register takes the mm_count pin. We can't prevent
mmu_notifer_mm to go away with mm_users as that will screwup the vma
filedescriptor closure that only happens inside exit_mmap (mm_users
pinned prevents exit_mmap to run, and it can only be taken temporarily
until _register returns).
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1 of 9] Lock the entire mm to prevent any mmu related operation to happen
On Fri, Apr 25, 2008 at 06:56:39PM +0200, Andrea Arcangeli wrote: + data-i_mmap_locks = vmalloc(nr_i_mmap_locks * + sizeof(spinlock_t)); This is why non-typesafe allocators suck. You want 'sizeof(spinlock_t *)' here. + data-anon_vma_locks = vmalloc(nr_anon_vma_locks * +sizeof(spinlock_t)); and here. Great catch! (it was temporarily wasting some ram which isn't nice at all) As I went into the editor I just found the above already fixed in #v14-pre3. And I can't move the structure into the file anymore without kmallocing it. Exposing that structure avoids the ERR_PTR/PTR_ERR on the retvals and one kmalloc so I think it makes the code simpler in the end to keep it as it is now. I'd rather avoid further changes to the 1/N patch, as long as they don't make any difference at runtime and as long as they involve more than cut-and-pasting a structure from .h to .c file. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] performance with guests running 2.4 kernels (specifically RHEL3)
David S. Ahern wrote:
Avi Kivity wrote:
David S. Ahern wrote:
I added the traces and captured data over another apparent lockup of
the guest.
This seems to be representative of the sequence (pid/vcpu removed).
(+4776) VMEXIT [ exitcode = 0x, rip = 0x
c016127c ]
(+ 0) PAGE_FAULT [ errorcode = 0x0003, virt = 0x
c0009db4 ]
(+3632) VMENTRY
(+4552) VMEXIT [ exitcode = 0x, rip = 0x
c016104a ]
(+ 0) PAGE_FAULT [ errorcode = 0x000b, virt = 0x
fffb61c8 ]
(+ 54928) VMENTRY
Can you oprofile the host to see where the 54K cycles are spent?
Most of the cycles (~80% of that 54k+) are spent in paging64_prefetch_page():
for (i = 0; i PT64_ENT_PER_PAGE; ++i) {
gpa_t pte_gpa = gfn_to_gpa(sp-gfn);
pte_gpa += (i+offset) * sizeof(pt_element_t);
r = kvm_read_guest_atomic(vcpu-kvm, pte_gpa, pt,
sizeof(pt_element_t));
if (r || is_present_pte(pt))
sp-spt[i] = shadow_trap_nonpresent_pte;
else
sp-spt[i] = shadow_notrap_nonpresent_pte;
}
This loop is run 512 times and takes a total of ~45k cycles, or ~88 cycles per
loop.
This function gets run 20,000/sec during some of the kscand loops.
david
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]: Fix MSR_K7_EVNTSEL{0,3} for SVM
Avi Kivity wrote:
Hmm, looking back at the dump:
1811:8d 86 00 00 ff 3f lea0x3fff(%rsi),%eax
1817:83 f8 03cmp$0x3,%eax
181a:0f 87 e2 01 00 00 ja 1a02 svm_set_msr+0x27f
So while gcc is using %rsi, it loads the result back into %eax, which
has the effect of dropping back into 32-bits. So looks like gcc was
right here. Sorry for spreading confusion and apologies to gcc.
Avi,
Arg. I was completely, utterly wrong about the problem here (although
there is definitely still a problem). I'm sorry for making a confusing mess out
of this. Here is what is actually happening:
During startup, the RHEL-4 x86_64 kernel (2.6.9-67.EL, if you care) setups up
the NMI watchdog. It does the following:
for(i = 0; i 4; ++i) {
/* Simulator may not support it */
if (checking_wrmsrl(MSR_K7_EVNTSEL0+i, 0UL))
return;
wrmsrl(MSR_K7_PERFCTR0+i, 0UL);
}
checking_wrmsrl() just does a test write to the msr; because of the code that
is currently in there, this succeeds. However, when it tries to do the
MSR_K7_PERFCTR0 wrmsr, *that* is where it fails, since we don't currently handle
that MSR, and KVM injects a GPF into the guest (which kills it). My previous
patch just happened to fix this because it was making checking_wrmsrl() fail on
the EVNTSEL0, so we just returned out of this loop rather than trying to write
to the PERFCTR0.
Unfortunately, we can't just fake emulate MSR_K7_PERFCTR[0-3] like we are
doing for MSR_K7_EVNTSEL[0-3]; if they are there, linux expects to be able to
put values into them. I think the correct solution here is to emulate
MSR_K7_PERFCTR[0-3] and MSR_K7_EVNTSEL[0-3] for real. I'm working on a patch to
do this now.
Chris Lalancette
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 0 of 2] [v2] Fix guest eating 100% cpu when guest is idle on PowerPC
* This update consolidates patches, adds more explicit comments, and add wait check when rfi instruction is emulated. This set of patches fixes 100% CPU usage when a guest is idle on PowerPC. Idle CPU usage is now at ~15-16% CPU time. An improvment. Signed-off-by: Jeorne Young [EMAIL PROTECTED] 4 files changed, 91 insertions(+), 4 deletions(-) arch/powerpc/kvm/emulate.c | 14 +++ arch/powerpc/kvm/powerpc.c | 12 -- arch/powerpc/platforms/44x/Makefile |2 - arch/powerpc/platforms/44x/idle.c | 67 +++ - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1 of 9] Lock the entire mm to prevent any mmu related operation to happen
On Fri, Apr 25, 2008 at 06:56:40PM +0200, Andrea Arcangeli wrote: Fortunately I figured out we don't really need mm_lock in unregister because it's ok to unregister in the middle of the range_begin/end critical section (that's definitely not ok for register that's why register needs mm_lock). And it's perfectly ok to fail in register(). I think you still need mm_lock (unless I miss something). What happens when one callout is scanning mmu_notifier_invalidate_range_start() and you unlink. That list next pointer with LIST_POISON1 which is a really bad address for the processor to track. Maybe I misunderstood your description. Thanks, Robin - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 2 of 2] Add PowerPC KVM guest wait handling support
2 files changed, 23 insertions(+), 3 deletions(-)
arch/powerpc/kvm/emulate.c | 14 ++
arch/powerpc/kvm/powerpc.c | 12 +---
This patch handles a guest that is in a wait state wake up guest that end up
being recheduled and go to sleep. This ensures that the guest is not allways
eating up 100% cpu when it is idle.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -235,6 +235,13 @@ int kvmppc_emulate_instruction(struct kv
case 50:/* rfi */
kvmppc_emul_rfi(vcpu);
advance = 0;
+
+ /* Handle guest vcpu that is in wait state.
+* This will implicitly wake up when it is ready.
+*/
+ if (vcpu-arch.msr MSR_WE) {
+ kvm_vcpu_block(vcpu);
+ }
break;
default:
@@ -265,6 +272,13 @@ int kvmppc_emulate_instruction(struct kv
case 146: /* mtmsr */
rs = get_rs(inst);
kvmppc_set_msr(vcpu, vcpu-arch.gpr[rs]);
+
+ /* Handle guest vcpu that is in wait state
+* This will implicitly wake up when it is ready.
+*/
+ if (vcpu-arch.msr MSR_WE) {
+ kvm_vcpu_block(vcpu);
+ }
break;
case 163: /* wrteei */
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -36,13 +36,12 @@ gfn_t unalias_gfn(struct kvm *kvm, gfn_t
int kvm_cpu_has_interrupt(struct kvm_vcpu *v)
{
- /* XXX implement me */
- return 0;
+ return !!(v-arch.pending_exceptions);
}
int kvm_arch_vcpu_runnable(struct kvm_vcpu *v)
{
- return 1;
+ return !(v-arch.msr MSR_WE);
}
@@ -213,6 +212,9 @@ static void kvmppc_decrementer_func(unsi
{
struct kvm_vcpu *vcpu = (struct kvm_vcpu *)data;
+ if (waitqueue_active(vcpu-wq))
+ wake_up_interruptible(vcpu-wq);
+
kvmppc_queue_exception(vcpu, BOOKE_INTERRUPT_DECREMENTER);
}
@@ -339,6 +341,8 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_v
int r;
sigset_t sigsaved;
+ vcpu_load(vcpu);
+
if (vcpu-sigset_active)
sigprocmask(SIG_SETMASK, vcpu-sigset, sigsaved);
@@ -362,6 +366,8 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_v
if (vcpu-sigset_active)
sigprocmask(SIG_SETMASK, sigsaved, NULL);
+
+ vcpu_put(vcpu);
return r;
}
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 1 of 2] Add idle wait support for 44x platforms
2 files changed, 68 insertions(+), 1 deletion(-)
arch/powerpc/platforms/44x/Makefile |2 -
arch/powerpc/platforms/44x/idle.c | 67 +++
This patch has been accepted upstream and will be in 2.6.26. So it will
eventually need to be removed when we move to 2.6.26rc.
This patch adds the ability for the CPU to go into wait state while in cpu_idle
loop. This helps virtulization solutions know when the guest Linux kernel is in
an idle state. There are two ways to do it.
Command line options:
idle=spin -- CPU will spin
By default will go into wait mode.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff --git a/arch/powerpc/platforms/44x/Makefile
b/arch/powerpc/platforms/44x/Makefile
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -1,4 +1,4 @@ obj-$(CONFIG_44x) := misc_44x.o
-obj-$(CONFIG_44x) := misc_44x.o
+obj-$(CONFIG_44x) := misc_44x.o idle.o
obj-$(CONFIG_EBONY)+= ebony.o
obj-$(CONFIG_TAISHAN) += taishan.o
obj-$(CONFIG_BAMBOO) += bamboo.o
diff --git a/arch/powerpc/platforms/44x/idle.c
b/arch/powerpc/platforms/44x/idle.c
new file mode 100644
--- /dev/null
+++ b/arch/powerpc/platforms/44x/idle.c
@@ -0,0 +1,67 @@
+/*
+ * Copyright 2008 IBM Corp.
+ *
+ * Based on arch/powerpc/platforms/pasemi/idle.c:
+ * Copyright (C) 2006-2007 PA Semi, Inc
+ *
+ * Added by: Jerone Young [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that 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 linux/of.h
+#include linux/kernel.h
+#include asm/machdep.h
+
+static int mode_spin;
+
+static void ppc44x_idle(void)
+{
+ unsigned long msr_save;
+
+ msr_save = mfmsr();
+ /* set wait state MSR */
+ mtmsr(msr_save|MSR_WE|MSR_EE|MSR_CE|MSR_DE);
+ isync();
+ /* return to initial state */
+ mtmsr(msr_save);
+ isync();
+}
+
+int __init ppc44x_idle_init(void)
+{
+ if (!mode_spin) {
+ /* If we are not setting spin mode
+ then we set to wait mode */
+ ppc_md.power_save = ppc44x_idle;
+ }
+
+ return 0;
+}
+
+arch_initcall(ppc44x_idle_init);
+
+static int __init idle_param(char *p)
+{
+
+ if (!strcmp(spin, p)) {
+ mode_spin = 1;
+ ppc_md.power_save = NULL;
+ }
+
+ return 0;
+}
+
+early_param(idle, idle_param);
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] QEMU/KVM [RFC]: add support for 128 PCI slots
On Fri, Apr 25, 2008 at 11:38:21AM +0200, Alexander Graf wrote: On Apr 25, 2008, at 3:01 AM, Marcelo Tosatti wrote: Add three PCI bridges to support 128 slots. Vendor and device_id have been stolen from my test box. I/O port addresses behind each bridge are statically allocated starting from 0x2000 with 0x1000 length. Once the bridge runs out of I/O space the guest (Linux at least) happily allocates outside of the region. That needs verification. I/O memory addresses are divided between 0xf000 - APIC base. The PCI irq mapping function is also changed, there was the assumption that devices behind the bridge use the IRQ allocated to the bridge device itself, which is weird. Apparently this is how the SPARC ABP PCI host works (only user of the bridge code at the moment). Is there any reason we're not using the _PIC function and give the OS a clue on which APIC pin the device is? Right now everything boils down to LNKA - LNKD which it does not have to. It might even be a good idea to connect each PCI device to a specific APIC pin, so we don't need to share too much, which might become a problem with a lot of PCI devices. As far as I know there is no limitation on how many pins an APIC may have. I was not aware of the _PIC function. Will take a look at it. The number of IRQ's certainly needs to increase. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] QEMU/KVM [RFC]: add support for 128 PCI slots
On Apr 25, 2008, at 10:39 PM, Marcelo Tosatti wrote: On Fri, Apr 25, 2008 at 11:38:21AM +0200, Alexander Graf wrote: On Apr 25, 2008, at 3:01 AM, Marcelo Tosatti wrote: Add three PCI bridges to support 128 slots. Vendor and device_id have been stolen from my test box. I/O port addresses behind each bridge are statically allocated starting from 0x2000 with 0x1000 length. Once the bridge runs out of I/O space the guest (Linux at least) happily allocates outside of the region. That needs verification. I/O memory addresses are divided between 0xf000 - APIC base. The PCI irq mapping function is also changed, there was the assumption that devices behind the bridge use the IRQ allocated to the bridge device itself, which is weird. Apparently this is how the SPARC ABP PCI host works (only user of the bridge code at the moment). Is there any reason we're not using the _PIC function and give the OS a clue on which APIC pin the device is? Right now everything boils down to LNKA - LNKD which it does not have to. It might even be a good idea to connect each PCI device to a specific APIC pin, so we don't need to share too much, which might become a problem with a lot of PCI devices. As far as I know there is no limitation on how many pins an APIC may have. I was not aware of the _PIC function. Will take a look at it. The number of IRQ's certainly needs to increase. The Operating System can call _PIC to set IRQ routing on PIC mode (0) or APIC mode (1). Most DSDTs check for this and enable routing via native pins instead of going through the LNKx pseudo-devices. Unfortunately qemu was built around an ISA PC, so nearly everything is based on the assumption that we have two i8259 which can only handle 16 interrupts. This assumption even shows in parts where you wouldn't expect it (like piix_pci.c:228). At least I didn't ;-). I started messing with this today, to get interrupts working properly in Darwin. So maybe we can join efforts here to get the IRQ routing work as it should. In a perfect world (at least in mine) every PCI device would have a separate interrupt lane which is handled by an IRQ 16. It might be worth considering MSI emulation for this too. Alex - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Automatically hibernate XP guest on suspend?
David Abrahams wrote: If I suspend my host while running a Windows XP guest, the whole machine crashes, so I was hoping to automate hibernation of the guest OS and integrate that into my host's suspend process. Does anyone know how to do that? Hi Dave, What host OS are you running? Cam - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] kvm-devel
实用 操作 即时 制造型企业车间管理能力提升训练高级研修班 主办单位：众人行管理咨询 时 间：2OO8 年04月19- 20 日 地 点：深圳人才酒店 时 间：2OO8 年04月26- 27 日 地 点：上海兆安酒店 联系人:凌小姐 电 话:0755-26075365 传真:0755-61351396 费用:2200元/人（包括资料费、午餐及上下午茶点等） 为什么要培训？ 产品品种越来越多，产品生命周期越来越短的市场环境下，生产部生产压力 越来越大：客户要求交货期更短，更准时，且价格更低，品质更好。制造业的竞 争归根结底是生产效率、成本控制与管理能力的竞争。卓越、有效的生产管理能 力. 车间是制造型企业的中心，车间和制造部门管理的好坏，直接影响着产品“质量 、成本、交货期”各项指标的完成，伴随着微利时代的到来和组织结构趋向扁平 化的今天，车间管理在企业中将扮演愈加重要的角色!车间主管既要带领团队完成 各项工作任务，又要有效地管理生产现场的进度、质量、成本和人员。如何进行 车间管理和生产过程控制，如何协同其他部门共同处理现场的各种问题。这已成 为中国企业车间管理人员必须掌握和重视的职业化技能。是一种从技术到管理实 现一体化、系统化的飞跃。 要成为优秀的企业，企业领导必须重视车间管理人员这群不可或缺的人力资源！ 而车间管理人员常常面临： l、工作做了不少，每天也忙忙碌碌，管理好象还是理不出头绪，如何有效的推进 车间管理工作？ 2、主管要改善，老板要降本，生产现场如何有效发现问题，持续改进？ 3、品种多，计划变化频繁，生产任务忽高忽低，如何提高生产车间柔型，有效的 保证生产进度？ 4、生产过程不稳定，机器故障和产品质量问题常常发生，如何有效的控制提高质 量和提高设备利用率? 5、现场很多事情需要依靠下属和同级部门共同努力，可是经常是出了问题后，人 人相互推脱，事情一误再误，如何有效的与他人沟通和协调，如何激发下属的主 动性和责任心？内容系统完整、注重实际运用、两天的精心研修，与您共享车间 管理的奥秘！ 培训收益： l、明确现场干部的角色定位，掌握车间日常事务管理及人员管理的精髓 2、掌握简单的质量工具改进生产品质的方法 3、学习有效掌握生产进度，控制制造成本的方法 4、学会发现和挖掘问题，掌握用简单工具解决各种车间复杂问题 5、培养设备保养意识，学会运用TPM的方法提高生产力 培训特色： l、可操作性：聚焦于现场的实际操作训练与实践能力提升 2、系统提高：锁定车间管理人员能力点，通过训练，改变管理行为，提升管理技 能 3、寓教于练：知名企业实际案例分析，您的困惑大家解答，您所参加的不是一堂 枯燥的“填鸭”课程 课程内容： 一、找准车间管理人员职责定位 l、车间管理人员的职责与角色认知 2、如何建立好的管理的基础 3、如何成为好的车间现场管理人员 4、车间管理工作的重心与要点 二、如何有效的推进车间管理工作 l、车间整体工作的推进体系 2、车间管理项目的指标化 3、如何将目标与指标展开为具体的实施方案 4、如何有效的分解车间管理目标 5、如何通过报告与例会进行管理追踪 三、如何有效的挖掘车间问题 l、工厂常见问题 2、如何从4M查核各个环节的问题 3、如何寻找“三呆”，消除“三呆” 4、如何建立适宜的标准，作为暴露问题的指针 四、如何运用5S和目视管理 l、为什么5S是工厂管理合理化的根本 2、5S的核心与实质 3、精益目视管理 4、TAKT信息板、发布信息板 5、5S信息板,KANBAN卡片 6、创建和应用不同类型的视觉控制工具 7、5S的效用 8、案例研讨 五、车间计划管理和异常控制 l、生产作业计划的追踪实施 2、如何控制最佳的生产节拍，保持有效产出 3、如何减少运输时间，缩短交期 4、如何提高生产管理系统的柔性 5、运用U型生产线布置方式提高生产线的柔性 6、如何降低换线时间适应生产线的转换 7、如何利用多能工随时调整生产安排 8、如何化解瓶颈环节的制约 9、瓶颈管理概念 lO、如何解决瓶颈 ll、生产负荷平衡 l2、瓶颈管理案例 l3、如何通过快速换型技术实现多品种生产转换 l4、快速换型的概念和方案 l5、换型物料车与换型工具车的使用 l6、换型的过程分析 l7、快速换型案例 l8、针对小批量生产的作业调度与监控 l9、生产调度与即时统计反馈 2O、针对多品种小批量的作业计划方法 六、现场质量改进 l、如何识别质量问题 2、如何运用品管圈活动改进质量管理 3、推移管理与预防性问题发现 4、质量问题的对应流程与要点 5、质量改善活动的四阶段十步骤 七、现场成本控制 企业生存的根本 l、盈亏平衡点学习老板的经营观 2、现场成本管理的主要指标 3、降低制造成本的主要途径 4、减少现场浪费的活动方法 5、放大镜从宏观到微观的CD工具 6、标准成本与标准工时的测定 7、标准成本/标准工时的差异分析 八、现场设备管理TPM l、设备管理的八大支柱 2、数字化的综合效率管理 3、设备的六大损失 4、改善慢性损失，向零故障挑战 5、设备初期清扫与困难源对策 6、自主保养的七步骤 九、车间人员管理 l、新型的上下级关系 2、自我培养与培养下属的意识 3、如何有效的指导与辅导下属 4、如何塑造持续学习与改善的现场氛围 5、如何有效的向上级沟通与汇报 6、同级部门之间沟通与反馈的技巧 7、人际技巧与关系处理 8、激励下属的技巧与方法 十、综合案例分析 讲师介绍： 陶树令 先生:台湾范本、台湾品质学会理事/资深讲师，专注于生产管理、现 场管理课程近十八年、丰田式管理研究小组(TPS)研究员,TQM小组研究员，G/P小 组研究员、台湾工业总会讲师、ATT台湾区协力厂商OTD研习会全程讲师、中原大 学工业工程研究所及鸿海（富士康）6Sigma管理备案资深顾问师、台湾公共工程 委员会品质学会备案合格讲师、台湾品质学会品管工程师(CQE),可靠度工程师 (CRE)专业训练及鉴定合格。主持“福特、克莱斯勒、通用等三大汽车公司及货车 制造业的QS9000及QSA台湾首版教材编译”、品管圈(QCC)导入及日本住友集团 QCStory发表会编译、亚洲生产力中心,香港全面品质管理(TQM)研讨会台湾地区代 表。 - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Automatically hibernate XP guest on suspend?
Cam Macdonell wrote: David Abrahams wrote: If I suspend my host while running a Windows XP guest, the whole machine crashes, so I was hoping to automate hibernation of the guest OS and integrate that into my host's suspend process. Does anyone know how to do that? Hi Dave, What host OS are you running? Ubuntu 8.04 Hardy Heron -- Dave Abrahams Boost Consulting http://boost-consulting.com - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] libkvm: initialize no_pit_creation
Valgrind caught this: ==11754== Conditional jump or move depends on uninitialised value(s) ==11754==at 0x50C9BC: kvm_create_pit (libkvm-x86.c:153) ==11754==by 0x50CA7F: kvm_arch_create (libkvm-x86.c:178) ==11754==by 0x50AB31: kvm_create (libkvm.c:383) ==11754==by 0x4EE691: kvm_qemu_create_context (qemu-kvm.c:616) ==11754==by 0x412031: main (vl.c:9653) Signed-off-by: Marcelo Tosatti [EMAIL PROTECTED] diff --git a/libkvm/libkvm.c b/libkvm/libkvm.c index 329f29f..adf09a5 100644 --- a/libkvm/libkvm.c +++ b/libkvm/libkvm.c @@ -249,6 +249,7 @@ kvm_context_t kvm_init(struct kvm_callbacks *callbacks, kvm-opaque = opaque; kvm-dirty_pages_log_all = 0; kvm-no_irqchip_creation = 0; + kvm-no_pit_creation = 0; return kvm; out_close: - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 1 of 9] Lock the entire mm to prevent any mmu related operation to happen
On Fri, Apr 25, 2008 at 02:25:32PM -0500, Robin Holt wrote: I think you still need mm_lock (unless I miss something). What happens when one callout is scanning mmu_notifier_invalidate_range_start() and you unlink. That list next pointer with LIST_POISON1 which is a really bad address for the processor to track. Ok, _release list_del_init qcan't race with that because it happens in exit_mmap when no other mmu notifier can trigger anymore. _unregister can run concurrently but it does list_del_rcu, that only overwrites the pprev pointer with LIST_POISON2. The mmu_notifier_invalidate_range_start won't crash on LIST_POISON1 thanks to srcu. Actually I did more changes than necessary, for example I noticed the mmu_notifier_register can return a list_add_head instead of list_add_head_rcu. _register can't race against _release thanks to the mm_users temporary or implicit pin. _register can't race against _unregister thanks to the mmu_notifier_mm-lock. And register can't race against all other mmu notifiers thanks to the mm_lock. At this time I've no other pending patches on top of v14-pre3 other than the below micro-optimizing cleanup. It'd be great to have confirmation that v14-pre3 passes GRU/XPMEM regressions tests as well as my KVM testing already passed successfully on it. I'll forward v14-pre3 mmu-notifier-core plus the below to Andrew tomorrow, I'm trying to be optimistic here! ;) diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c --- a/mm/mmu_notifier.c +++ b/mm/mmu_notifier.c @@ -187,7 +187,7 @@ int mmu_notifier_register(struct mmu_not * current-mm or explicitly with get_task_mm() or similar). */ spin_lock(mm-mmu_notifier_mm-lock); - hlist_add_head_rcu(mn-hlist, mm-mmu_notifier_mm-list); + hlist_add_head(mn-hlist, mm-mmu_notifier_mm-list); spin_unlock(mm-mmu_notifier_mm-lock); out_unlock: mm_unlock(mm, data); - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] Fix QEMU vcpu thread race with apic_reset
There is a race between when the vcpu thread issues a create ioctl and when
apic_reset() gets called resulting in getting a badfd error.
main threadvcpu thread
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index 78127de..3513e8c 100644
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -31,7 +31,9 @@ extern int smp_cpus;
static int qemu_kvm_reset_requested;
pthread_mutex_t qemu_mutex = PTHREAD_MUTEX_INITIALIZER;
+pthread_mutex_t vcpu_mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t qemu_aio_cond = PTHREAD_COND_INITIALIZER;
+pthread_cond_t qemu_vcpuup_cond = PTHREAD_COND_INITIALIZER;
__thread struct vcpu_info *vcpu;
struct qemu_kvm_signal_table {
@@ -369,6 +371,11 @@ static void *ap_main_loop(void *_env)
sigfillset(signals);
sigprocmask(SIG_BLOCK, signals, NULL);
kvm_create_vcpu(kvm_context, env-cpu_index);
+/* block until cond_wait occurs */
+pthread_mutex_lock(vcpu_mutex);
+/* now we can signal */
+pthread_cond_signal(qemu_vcpuup_cond);
+pthread_mutex_unlock(vcpu_mutex);
kvm_qemu_init_env(env);
kvm_main_loop_cpu(env);
return NULL;
@@ -388,9 +395,10 @@ static void kvm_add_signal(struct qemu_kvm_signal_table
*sigtab, int signum)
void kvm_init_new_ap(int cpu, CPUState *env)
{
+pthread_mutex_lock(vcpu_mutex);
pthread_create(vcpu_info[cpu].thread, NULL, ap_main_loop, env);
-/* FIXME: wait for thread to spin up */
-usleep(200);
+pthread_cond_wait(qemu_vcpuup_cond, vcpu_mutex);
+pthread_mutex_unlock(vcpu_mutex);
}
static void qemu_kvm_init_signal_tables(void)
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Fix QEMU vcpu thread race with apic_reset
* Ryan Harper [EMAIL PROTECTED] [2008-04-26 00:27]: There is a race between when the vcpu thread issues a create ioctl and when apic_reset() gets called resulting in getting a badfd error. main threadvcpu thread guilt refresh clipped my text short. main threadvcpu thread ------ qemu/hw/pc.c:pc_new_cpu() cpu_init() cpu_x86_init() kvm_init_new_ap() ap_main_loop() *blocks* usleep() apic_init() kvm_set_lapic() kvm_ioctl with unitilized context badfd To fix this, ensure we create the vcpu in the vcpu thread before returning from kvm_init_new_ap. Synchronize on a new mutux, vcpu_mutex, and wait for the vcpuup condition before signaling to ensure the main thread is waiting before we send the signal. With this patch, I can launch 64 kvm guests, 1 second apart and not see any Bad File descriptor errors. Signed-off-by: Ryan Harper [EMAIL PROTECTED] -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 [EMAIL PROTECTED] - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
