Lock warning traceback
Hi! I've been getting some locking-related warning when I fire up a KVM machine. This has been popping up since a 2.6.30 kernel: [snip] [119206.978058] BUG: MAX_LOCK_DEPTH too low! [119206.978062] turning off the locking correctness validator. [119206.978067] Pid: 9510, comm: kvm Not tainted 2.6.31 #44 [119206.978071] Call Trace: [119206.978080] [] __lock_acquire+0x94c/0x974 [119206.978086] [] lock_acquire+0xcc/0xe9 [119206.978092] [] ? mm_take_all_locks+0xd9/0x110 [119206.978099] [] ? mutex_lock_nested+0x23b/0x24a [119206.978104] [] ? mm_take_all_locks+0x3a/0x110 [119206.978109] [] _spin_lock_nest_lock+0x2c/0x3b [119206.978114] [] ? mm_take_all_locks+0xd9/0x110 [119206.978119] [] mm_take_all_locks+0xd9/0x110 [119206.978125] [] do_mmu_notifier_register +0xa8/0x16a [119206.978130] [] mmu_notifier_register+0xe/0x10 [119206.978136] [] kvm_dev_ioctl+0x136/0x2ed [119206.978142] [] vfs_ioctl+0x1d/0x82 [119206.978147] [] do_vfs_ioctl+0x45b/0x4a1 [119206.978153] [] ? __up_read+0x9a/0xa2 [119206.978158] [] ? up_read+0x26/0x2a [119206.978163] [] sys_ioctl+0x42/0x65 [119206.978169] [] system_call_fastpath+0x16/0x1b [119216.471426] kvm: emulating exchange as write [/snip] Although, this does not seem to be critical as my guest op-system seems to be working fine... Päikest, Priit :) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Modifying RAM during runtime on guest
Daniel Bareiro wrote: > Hi Brian. > > On Tuesday, 08 September 2009 16:18:09 -0500, > Brian Jackson wrote: > > > > I'm trying to modify the amount of RAM that has some of guests. Host > > > has 2.6.30 kernel with KVM-88. > > > > > > In one of guest I didn't have problems when decreasing the amount of > > > memory from 3584 MIB to 1024 MiB. This guest has 2.6.26-2-686 stock > > > kernel. Also I was trying to decrease the amount RAM of another guest > > > from 3584 MiB to 2048 MiB, but it didn't work. This other guest has > > > 2.6.24-etchnhalf.1-686-bigmem stock kernel. Does Ballooning in guest > > > require 2.6.25 or superior? > > > I don't know, if that kernel has a virtio-balloon driver, I'd think that > > was all you need to balloon memory. > > Then can be that it is related to kernel that is using the guest: > > # uname -a > Linux aprender01 2.6.24-etchnhalf.1-686-bigmem #1 SMP Mon Jul 27 03:56:49 UTC > 2009 i686 GNU/Linux > > # cat config-2.6.24-etchnhalf.1-686-bigmem | grep -i virtio > # > > > > Thinking that it could be an impediment related to the kernel version > > > of guest, I tried to increase the memory of another one guest with > > > 2.6.26-2-686 from 512 MIB to 1024 MIB, but this didn't work either. > > > You can only grow memory up to the amount you specified on the command > > line if you've already ballooned down. > > Good. Thanks for clarifying to me this detail. > > > So if you specify "-m 1024M" on the command line, then shrink it to 512, > > you could then balloon it back up to a max of 1024. > > According to the tests that I was doing in guest with kernel with support > for virtio, shrinking works, but when trying to return to the amount of > initial memory, seems that it fails and I lose connectivity by serial > console and ssh. > > In the guest: > > # uname -a > Linux central 2.6.26-2-amd64 #1 SMP Sun Jul 26 20:35:48 UTC 2009 x86_64 > GNU/Linux > > # cat config-2.6.26-2-amd64 | grep -i virtio > CONFIG_NET_9P_VIRTIO=m > CONFIG_VIRTIO_BLK=m > CONFIG_VIRTIO_NET=m > CONFIG_HW_RANDOM_VIRTIO=m > CONFIG_VIRTIO=m > CONFIG_VIRTIO_RING=m > CONFIG_VIRTIO_PCI=m > CONFIG_VIRTIO_BALLOON=m > > In the host: > > # telnet localhost 4045 > Trying 127.0.0.1... > Connected to localhost. > Escape character is '^]'. > QEMU 0.10.50 monitor - type 'help' for more information > (qemu) > (qemu) info balloon > balloon: actual=512 > (qemu) balloon 256 > (qemu) info balloon > balloon: actual=256 > (qemu) > (qemu) balloon 512 > (qemu) info balloon > balloon: actual=36 > > At this moment I'm unable to connect by serial console to the guest and the > ssh sessions are freeze nevertheless kvm process of the guest is running. > Using a VNC client I see several messages of this type in the guest: > > Out of memory: kill process () score xx or a child > Killed process () > > Finally: > > Kernel panic - not syncing - Out of memory and no killable processes... > > > > Thanks for your reply. Hi Daniel, I noticed no-one answered this, and I just ran into the same thing myself. As Avi pointed out earlier, it is a guest bug, and upgrading the guest to 2.6.27 should fix it: http://www.mail-archive.com/kvm@vger.kernel.org/msg10849.html -jim -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2: kvm 3/4] Fix printk name error in svm.c
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/svm.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 9a4daca..d1036ce 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -330,13 +330,14 @@ static int svm_hardware_enable(void *garbage)
return -EBUSY;
if (!has_svm()) {
- printk(KERN_ERR "svm_cpu_init: err EOPNOTSUPP on %d\n", me);
+ printk(KERN_ERR "svm_hardware_enable: err EOPNOTSUPP on %d\n",
+ me);
return -EINVAL;
}
svm_data = per_cpu(svm_data, me);
if (!svm_data) {
- printk(KERN_ERR "svm_cpu_init: svm_data is NULL on %d\n",
+ printk(KERN_ERR "svm_hardware_enable: svm_data is NULL on %d\n",
me);
return -EINVAL;
}
--
1.6.4.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2: kvm 4/4] Fix hotplug of CPUs for KVM.
Both VMX and SVM require per-cpu memory allocation, which is done at module
init time, for only online cpus.
Backend was not allocating enough structure for all possible CPUs, so
new CPUs coming online could not be hardware enabled.
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/svm.c |4 ++--
arch/x86/kvm/vmx.c |6 --
virt/kvm/kvm_main.c |3 ---
3 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index d1036ce..02a4269 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -482,7 +482,7 @@ static __init int svm_hardware_setup(void)
kvm_enable_efer_bits(EFER_SVME);
}
- for_each_online_cpu(cpu) {
+ for_each_possible_cpu(cpu) {
r = svm_cpu_init(cpu);
if (r)
goto err;
@@ -516,7 +516,7 @@ static __exit void svm_hardware_unsetup(void)
{
int cpu;
- for_each_online_cpu(cpu)
+ for_each_possible_cpu(cpu)
svm_cpu_uninit(cpu);
__free_pages(pfn_to_page(iopm_base >> PAGE_SHIFT), IOPM_ALLOC_ORDER);
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 3fe0d42..e86f1a6 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1350,15 +1350,17 @@ static void free_kvm_area(void)
{
int cpu;
- for_each_online_cpu(cpu)
+ for_each_possible_cpu(cpu) {
free_vmcs(per_cpu(vmxarea, cpu));
+ per_cpu(vmxarea, cpu) = NULL;
+ }
}
static __init int alloc_kvm_area(void)
{
int cpu;
- for_each_online_cpu(cpu) {
+ for_each_possible_cpu(cpu) {
struct vmcs *vmcs;
vmcs = alloc_vmcs_cpu(cpu);
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index e27b7a9..2cd8bc2 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1716,9 +1716,6 @@ static int kvm_cpu_hotplug(struct notifier_block
*notifier, unsigned long val,
{
int cpu = (long)v;
- if (!kvm_usage_count)
- return NOTIFY_OK;
-
val &= ~CPU_TASKS_FROZEN;
switch (val) {
case CPU_DYING:
--
1.6.4.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2: kvm 2/4] Kill the confusing tsc_ref_khz and ref_freq variables.
They are globals, not clearly protected by any ordering or locking, and
vulnerable to various startup races.
Instead, for variable TSC machines, register the cpufreq notifier and get
the TSC frequency directly from the cpufreq machinery. Not only is it
always right, it is also perfectly accurate, as no error prone measurement
is required.
On such machines, when a new CPU online is brought online, it isn't clear what
frequency it will start with, and it may not correspond to the reference, thus
in hardware_enable we clear the cpu_tsc_khz variable to zero and make sure
it is set before running on a VCPU.
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/x86.c | 30 --
1 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 15d2ace..9cbd53a 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1326,6 +1326,8 @@ out:
void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
{
kvm_x86_ops->vcpu_load(vcpu, cpu);
+ if (unlikely(per_cpu(cpu_tsc_khz, cpu) == 0))
+ per_cpu(cpu_tsc_khz, cpu) = cpufreq_quick_get(cpu);
kvm_request_guest_time_update(vcpu);
}
@@ -3061,9 +3063,6 @@ static void bounce_off(void *info)
/* nothing */
}
-static unsigned int ref_freq;
-static unsigned long tsc_khz_ref;
-
static int kvmclock_cpufreq_notifier(struct notifier_block *nb, unsigned long
val,
void *data)
{
@@ -3072,14 +3071,11 @@ static int kvmclock_cpufreq_notifier(struct
notifier_block *nb, unsigned long va
struct kvm_vcpu *vcpu;
int i, send_ipi = 0;
- if (!ref_freq)
- ref_freq = freq->old;
-
if (val == CPUFREQ_PRECHANGE && freq->old > freq->new)
return 0;
if (val == CPUFREQ_POSTCHANGE && freq->old < freq->new)
return 0;
- per_cpu(cpu_tsc_khz, freq->cpu) = cpufreq_scale(tsc_khz_ref, ref_freq,
freq->new);
+ per_cpu(cpu_tsc_khz, freq->cpu) = freq->new;
spin_lock(&kvm_lock);
list_for_each_entry(kvm, &vm_list, vm_list) {
@@ -3120,12 +3116,18 @@ static void kvm_timer_init(void)
{
int cpu;
- for_each_possible_cpu(cpu)
- per_cpu(cpu_tsc_khz, cpu) = tsc_khz;
if (!boot_cpu_has(X86_FEATURE_CONSTANT_TSC)) {
- tsc_khz_ref = tsc_khz;
cpufreq_register_notifier(&kvmclock_cpufreq_notifier_block,
CPUFREQ_TRANSITION_NOTIFIER);
+ for_each_online_cpu(cpu)
+ per_cpu(cpu_tsc_khz, cpu) = cpufreq_get(cpu);
+ } else {
+ for_each_possible_cpu(cpu)
+ per_cpu(cpu_tsc_khz, cpu) = tsc_khz;
+ }
+ for_each_possible_cpu(cpu) {
+ printk(KERN_DEBUG "kvm: cpu %d = %ld khz\n",
+ cpu, per_cpu(cpu_tsc_khz, cpu));
}
}
@@ -4698,6 +4700,14 @@ int kvm_arch_vcpu_reset(struct kvm_vcpu *vcpu)
int kvm_arch_hardware_enable(void *garbage)
{
+ /*
+* Since this may be called from a hotplug notifcation,
+* we can't get the CPU frequency directly.
+*/
+ if (!boot_cpu_has(X86_FEATURE_CONSTANT_TSC)) {
+ int cpu = raw_smp_processor_id();
+ per_cpu(cpu_tsc_khz, cpu) = 0;
+ }
return kvm_x86_ops->hardware_enable(garbage);
}
--
1.6.4.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2: kvm 1/4] Code motion. Separate timer intialization into an indepedent function.
Signed-off-by: Zachary Amsden
---
arch/x86/kvm/x86.c | 23 +++
1 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index fedac9d..15d2ace 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3116,9 +3116,22 @@ static struct notifier_block
kvmclock_cpufreq_notifier_block = {
.notifier_call = kvmclock_cpufreq_notifier
};
+static void kvm_timer_init(void)
+{
+ int cpu;
+
+ for_each_possible_cpu(cpu)
+ per_cpu(cpu_tsc_khz, cpu) = tsc_khz;
+ if (!boot_cpu_has(X86_FEATURE_CONSTANT_TSC)) {
+ tsc_khz_ref = tsc_khz;
+ cpufreq_register_notifier(&kvmclock_cpufreq_notifier_block,
+ CPUFREQ_TRANSITION_NOTIFIER);
+ }
+}
+
int kvm_arch_init(void *opaque)
{
- int r, cpu;
+ int r;
struct kvm_x86_ops *ops = (struct kvm_x86_ops *)opaque;
if (kvm_x86_ops) {
@@ -3150,13 +3163,7 @@ int kvm_arch_init(void *opaque)
kvm_mmu_set_mask_ptes(PT_USER_MASK, PT_ACCESSED_MASK,
PT_DIRTY_MASK, PT64_NX_MASK, 0);
- for_each_possible_cpu(cpu)
- per_cpu(cpu_tsc_khz, cpu) = tsc_khz;
- if (!boot_cpu_has(X86_FEATURE_CONSTANT_TSC)) {
- tsc_khz_ref = tsc_khz;
- cpufreq_register_notifier(&kvmclock_cpufreq_notifier_block,
- CPUFREQ_TRANSITION_NOTIFIER);
- }
+ kvm_timer_init();
return 0;
--
1.6.4.4
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hotplug / TSC cleanup and fixing
Greatly simplified version of the patches; allocate and dealloc all required structs at module load and unload time. Clarification: per_cpu(var, cpu) does indeed work for not-present CPUs; the allocations for module specific per-cpu variables are done at module load and unload time, while the per_cpu chunks are setup for all possible CPUs at boot time. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Biweekly KVM Test report, kernel 94252... qemu 5cc3c...
Hi All, This Weekly KVM Testing Report against lastest kvm.git 94252a58662dc4ca6191eac479efb40e0716865c and qemu-kvm.git 5cc3cfb6c2254483ae324da407a13307fe7355f3. Qemu-kvm tree build issue is fixed by qemu commit 781774b38c90797add71d029b7fbee43200c66d4. There is no other new bug found in this two weeks. There are 7 old bugs open in bug tracking. Seven Old Issues: 1. Guest hang with exhausted IRQ sources error if 8 VFs assigned https://sourceforge.net/tracker/?func=detail&aid=2847560&group_id=180599&atid=893831 2. Hot-added device is not visible in guest after migration https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2832416&group_id=180599 3. ltp diotest running time is 2.54 times than before https://sourceforge.net/tracker/?func=detail&aid=2723366&group_id=180599&atid=893831 4. 32bits Rhel5/FC6 guest may fail to reboot after installation https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1991647&group_id=180599 5. OpenSuse10.2 can not be installed http://sourceforge.net/tracker/index.php?func=detail&aid=2088475&group_id=180599&atid=893831 6. Fail to Save Restore Guest https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2175042&group_id=180599 7. perfctr wrmsr warning when booting 64bit RHEl5.3 https://sourceforge.net/tracker/?func=detail&aid=2721640&group_id=180599&atid=893831 Test environment Platform A Stoakley/Clovertown CPU 4 Memory size 8G' Report Summary on IA32-pae Summary Test Report of Last Session = Total PassFailNoResult Crash = control_panel 8 6 2 00 gtest 16 16 0 00 = control_panel 8 6 2 00 :KVM_256M_guest_PAE_gPAE 1 1 0 00 :KVM_linux_win_PAE_gPAE1 1 0 00 :KVM_two_winxp_PAE_gPAE1 1 0 00 :KVM_four_sguest_PAE_gPA 1 1 0 00 :KVM_1500M_guest_PAE_gPA 1 1 0 00 :KVM_LM_Continuity_PAE_g 1 1 0 00 :KVM_LM_SMP_PAE_gPAE 1 0 1 00 :KVM_SR_Continuity_PAE_g 1 0 1 00 gtest 16 16 0 00 :ltp_nightly_PAE_gPAE 1 1 0 00 :boot_up_acpi_PAE_gPAE 1 1 0 00 :boot_up_acpi_xp_PAE_gPA 1 1 0 00 :boot_up_vista_PAE_gPAE1 1 0 00 :reboot_xp_PAE_gPAE1 1 0 00 :boot_base_kernel_PAE_gP 1 1 0 00 :boot_up_acpi_win2k3_PAE 1 1 0 00 :boot_smp_acpi_win2k3_PA 1 1 0 00 :boot_smp_acpi_win2k_PAE 1 1 0 00 :boot_up_win2008_PAE_gPA 1 1 0 00 :boot_up_acpi_win2k_PAE_ 1 1 0 00 :boot_smp_acpi_xp_PAE_gP 1 1 0 00 :boot_up_noacpi_win2k_PA 1 1 0 00 :boot_smp_vista_PAE_gPAE 1 1 0 00 :boot_smp_win2008_PAE_gP 1 1 0 00 :kb_nightly_PAE_gPAE 1 1 0 00 = Total 24 22 2 00 Report Summary on IA32e Summary Test Report of Last Session = Total PassFailNoResult Crash = control_panel 17 14 3 00 gtest 23 23 0 00 = control_panel 17 14 3 00 :KVM_4G_guest_64_g32e 1 1 0 00 :KVM_four_sguest_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_g32e1 1 0 00 :KVM_linux_win_64_gPAE 1 1 0 00 :KVM_LM_SMP_64_gPAE1 1 0 00 :KVM_SR_Continuity_64_gP 1 0 1 00 :KVM_four_sguest_64_g32e 1 1 0 00 :KVM_four_dguest_64_gPAE 1 1 0 00 :KVM_SR_SMP_64_gPAE1 0 1 00 :KVM_LM_Continuity_64_g3 1
Re: [PATCH] Use Little Endian for Dirty Bitmap
On 29.09.2009, at 02:08, Hollis Blanchard wrote: On Mon, 2009-07-27 at 12:38 +0200, Alexander Graf wrote: We currently use host endian long types to store information in the dirty bitmap. This works reasonably well on Little Endian targets, because the u32 after the first contains the next 32 bits. On Big Endian this breaks completely though, forcing us to be inventive here. So Ben suggested to always use Little Endian, which looks reasonable. We only have dirty bitmap implemented in Little Endian targets so far and since PowerPC would be the first Big Endian platform, we can just as well switch to Little Endian always with little effort without breaking existing targets. Signed-off-by: Alexander Graf --- virt/kvm/kvm_main.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 17d8688..3482ad1 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -48,6 +48,7 @@ #include #include #include +#include #ifdef KVM_COALESCED_MMIO_PAGE_OFFSET #include "coalesced_mmio.h" @@ -1656,8 +1657,8 @@ void mark_page_dirty(struct kvm *kvm, gfn_t gfn) unsigned long rel_gfn = gfn - memslot->base_gfn; /* avoid RMW */ - if (!test_bit(rel_gfn, memslot->dirty_bitmap)) - set_bit(rel_gfn, memslot->dirty_bitmap); + if (!generic_test_le_bit(rel_gfn, memslot->dirty_bitmap)) + generic___set_le_bit(rel_gfn, memslot->dirty_bitmap); } } I don't think I've ever exercised the dirty bitmap code, and I don't really have an opinion. Avi? No big endian kvm target currently implements dirty bitmaps. In fact, IIRC only x86 does atm. So by pinning it to LE now, we save ourselves from much trouble for any later user. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Use Little Endian for Dirty Bitmap
On Mon, 2009-07-27 at 12:38 +0200, Alexander Graf wrote: > We currently use host endian long types to store information > in the dirty bitmap. > > This works reasonably well on Little Endian targets, because the > u32 after the first contains the next 32 bits. On Big Endian this > breaks completely though, forcing us to be inventive here. > > So Ben suggested to always use Little Endian, which looks reasonable. > > We only have dirty bitmap implemented in Little Endian targets so far > and since PowerPC would be the first Big Endian platform, we can just > as well switch to Little Endian always with little effort without > breaking existing targets. > > Signed-off-by: Alexander Graf > --- > virt/kvm/kvm_main.c |5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > index 17d8688..3482ad1 100644 > --- a/virt/kvm/kvm_main.c > +++ b/virt/kvm/kvm_main.c > @@ -48,6 +48,7 @@ > #include > #include > #include > +#include > > #ifdef KVM_COALESCED_MMIO_PAGE_OFFSET > #include "coalesced_mmio.h" > @@ -1656,8 +1657,8 @@ void mark_page_dirty(struct kvm *kvm, gfn_t gfn) > unsigned long rel_gfn = gfn - memslot->base_gfn; > > /* avoid RMW */ > - if (!test_bit(rel_gfn, memslot->dirty_bitmap)) > - set_bit(rel_gfn, memslot->dirty_bitmap); > + if (!generic_test_le_bit(rel_gfn, memslot->dirty_bitmap)) > + generic___set_le_bit(rel_gfn, memslot->dirty_bitmap); > } > } I don't think I've ever exercised the dirty bitmap code, and I don't really have an opinion. Avi? -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9] x86: Pick up local arch trace headers
On Sun, Sep 27, 2009 at 10:38:41AM +0200, Avi Kivity wrote: > On 09/25/2009 07:18 PM, Jan Kiszka wrote: >> This unbreaks 2.6.31 builds but also ensures that we always use the most >> recent ones. >> >> Signed-off-by: Jan Kiszka >> --- >> >> include/arch/x86/kvm |1 + >> 1 files changed, 1 insertions(+), 0 deletions(-) >> create mode 12 include/arch/x86/kvm >> >> diff --git a/include/arch/x86/kvm b/include/arch/x86/kvm >> new file mode 12 >> index 000..c635817 >> --- /dev/null >> +++ b/include/arch/x86/kvm >> @@ -0,0 +1 @@ >> +../../../x86 >> \ No newline at end of file >> >> > > Shouldn't it be asm-x86? No, trace.h is in x86/ -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] kvm-kmod: Various fixes
On Fri, Sep 25, 2009 at 06:18:01PM +0200, Jan Kiszka wrote: > As requested, here is my current kvm-kmod queue. Most fixes target > latest 2.6.31 so aren't that urgent yet, but some also affect older > kernels in specific configurations. > > Find the patches also at git://git.kiszka.org/kvm-kmod.git queue > > Jan Kiszka (9): > x86: Pick up local arch trace headers > Revert "kvm-kmod: Fix including of arch/*/kvm/trace.h" > kvm_vma_kernel_pagesize support > Update souce link > Update .gitignore > x86: Remove zombie kvm_trace from build > Fix fragile kernelsourcedir construction > Fix arch include for KVM trace headers > Switch to bz2 tarball releases Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: R/W HG memory mappings with kvm?
Hello,
>> Sorry about that. The issue is the BUG in gfn_to_pgn where the pfn is
>> not calculated correctly after looking up the vma.
>> I still don't see how to get the physical address from the vma, since
>> vm_pgoff is zero, and the vm_ops are not filled. The vma does not seem
>> to store the physical base address.
> So it seems the only place the pfns are stored are in the ptes themselves. Is
> there an API to recover the ptes from a virtual address? We could use that
> instead.
I'm also trying to share H/G memory with another solution -
by overwriting shadow page table.
It seems that gfn_to_pfn is the key function which associate
guest memoy with host memory. So I changed gfn_to_pfn
as follows:
pfn_t gfn_to_pfn(struct kvm *kvm, gfn_t gfn)
{
...
} else
if ( shared_gfn && shared_gfn == gfn ){
return shared_pfn; // return pfn which is wanted to share
}else {
pfn = page_to_pfn(page[0]);
}
}
...
}
Here, shared_gfn is registered by walking soft mmu with gva.
And shared_pfn is the page frame number which is hostside.
By rewriting adobe, kvm is foxed and make up new shadow
page table with new mapping after zap all pages.
But I failed to share the memory. Do I have any misunderstanding?
Regards,
Tsuyoshi Ozawa
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 0/2] test: parallel vmexit
Run the vmexit tests in parallel on each present cpu. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 1/2] test: add wait parameter to on_cpu
To determine whether to wait for IPI to finish on remote cpu.
Signed-off-by: Marcelo Tosatti
Index: qemu-kvm/kvm/user/test/lib/x86/smp.c
===
--- qemu-kvm.orig/kvm/user/test/lib/x86/smp.c
+++ qemu-kvm/kvm/user/test/lib/x86/smp.c
@@ -82,7 +82,7 @@ static void setup_smp_id(void *data)
asm ("mov %0, %%gs:0" : : "r"(apic_id()) : "memory");
}
-void on_cpu(int cpu, void (*function)(void *data), void *data)
+void on_cpu(int cpu, void (*function)(void *data), void *data, int wait)
{
spin_lock(&ipi_lock);
if (cpu == smp_id())
@@ -93,9 +93,11 @@ void on_cpu(int cpu, void (*function)(vo
apic_icr_write(APIC_INT_ASSERT | APIC_DEST_PHYSICAL | APIC_DM_FIXED
| IPI_VECTOR,
cpu);
- while (!ipi_done)
- ;
- ipi_done = 0;
+ if (wait) {
+ while (!ipi_done)
+ ;
+ ipi_done = 0;
+ }
}
spin_unlock(&ipi_lock);
}
@@ -109,6 +111,6 @@ void smp_init(void)
setup_smp_id(0);
for (i = 1; i < cpu_count(); ++i)
-on_cpu(i, setup_smp_id, 0);
+on_cpu(i, setup_smp_id, 0, 1);
}
Index: qemu-kvm/kvm/user/test/lib/x86/smp.h
===
--- qemu-kvm.orig/kvm/user/test/lib/x86/smp.h
+++ qemu-kvm/kvm/user/test/lib/x86/smp.h
@@ -9,7 +9,7 @@ void smp_init(void);
int cpu_count(void);
int smp_id(void);
-void on_cpu(int cpu, void (*function)(void *data), void *data);
+void on_cpu(int cpu, void (*function)(void *data), void *data, int wait);
void spin_lock(struct spinlock *lock);
void spin_unlock(struct spinlock *lock);
Index: qemu-kvm/kvm/user/test/x86/smptest.c
===
--- qemu-kvm.orig/kvm/user/test/x86/smptest.c
+++ qemu-kvm/kvm/user/test/x86/smptest.c
@@ -20,6 +20,6 @@ int main()
ncpus = cpu_count();
printf("found %d cpus\n", ncpus);
for (i = 0; i < ncpus; ++i)
- on_cpu(i, ipi_test, (void *)(long)i);
+ on_cpu(i, ipi_test, (void *)(long)i, 1);
return 0;
}
Index: qemu-kvm/kvm/user/test/x86/vmexit.c
===
--- qemu-kvm.orig/kvm/user/test/x86/vmexit.c
+++ qemu-kvm/kvm/user/test/x86/vmexit.c
@@ -63,14 +63,14 @@ static void nop(void *junk)
static void ipi(void)
{
- on_cpu(1, nop, 0);
+ on_cpu(1, nop, 0, 1);
}
static void ipi_halt(void)
{
unsigned long long t;
- on_cpu(1, nop, 0);
+ on_cpu(1, nop, 0, 1);
t = rdtsc() + 2000;
while (rdtsc() < t)
;
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2/2] test: vmexit: run parallel tests on each cpu
So one can measure SMP overhead.
Signed-off-by: Marcelo Tosatti
Index: qemu-kvm-test/kvm/user/test/x86/vmexit.c
===
--- qemu-kvm-test.orig/kvm/user/test/x86/vmexit.c
+++ qemu-kvm-test/kvm/user/test/x86/vmexit.c
@@ -85,6 +85,9 @@ static struct test {
{ vmcall, "vmcall", },
{ mov_from_cr8, "mov_from_cr8" },
{ mov_to_cr8, "mov_to_cr8" },
+};
+
+static struct test smp_tests[] = {
{ ipi, "ipi", is_smp },
{ ipi_halt, "ipi+halt", is_smp },
};
@@ -113,14 +116,25 @@ static void do_test(struct test *test)
#define ARRAY_SIZE(_x) (sizeof(_x) / sizeof((_x)[0]))
-int main(void)
+static void do_tests(void *junk)
{
int i;
- smp_init();
-
for (i = 0; i < ARRAY_SIZE(tests); ++i)
do_test(&tests[i]);
+}
+
+int main(void)
+{
+ int i, n;
+
+ smp_init();
+
+ for (n = cpu_count(); n > 0; n--)
+ on_cpu(n-1, do_tests, 0, 0);
+
+ for (i = 0; i < ARRAY_SIZE(smp_tests); ++i)
+ do_test(&smp_tests[i]);
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: fix LAPIC timer period overflow
On Fri, Sep 25, 2009 at 11:09:37AM +0200, Aurelien Jarno wrote:
> Don't overflow when computing the 64-bit period from 32-bit registers.
>
> Fixes sourceforge bug #2826486.
>
> Signed-off-by: Aurelien Jarno
> ---
> arch/x86/kvm/lapic.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 9c8f901..3ca7767 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -658,7 +658,7 @@ static void start_apic_timer(struct kvm_lapic *apic)
> {
> ktime_t now = apic->lapic_timer.timer.base->get_time();
>
> - apic->lapic_timer.period = apic_get_reg(apic, APIC_TMICT) *
> + apic->lapic_timer.period = (u64)apic_get_reg(apic, APIC_TMICT) *
> APIC_BUS_CYCLE_NS * apic->divide_count;
> atomic_set(&apic->lapic_timer.pending, 0);
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm: allocate correct size for dirty bitmap
On Wed, Sep 23, 2009 at 04:13:18PM -0600, Bruce Rogers wrote:
> The dirty bitmap copied out to userspace is stored in a long array, and gets
> copied out to userspace accordingly. This patch accounts for that correctly.
> Currently I'm seeing kvm crashing due to writing beyond the end of the
> alloc'd dirty bitmap memory, because the buffer has the wrong size.
>
> Signed-off-by: Bruce Rogers
> ---
> qemu-kvm.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/qemu-kvm.c b/qemu-kvm.c
> index 6511cb6..ee5db76 100644
> --- a/qemu-kvm.c
> +++ b/qemu-kvm.c
> @@ -702,7 +702,7 @@ int kvm_get_dirty_pages_range(kvm_context_t kvm, unsigned
> long phys_addr,
> for (i = 0; i < KVM_MAX_NUM_MEM_REGIONS; ++i) {
> if ((slots[i].len && (uint64_t) slots[i].phys_addr >= phys_addr)
> && ((uint64_t) slots[i].phys_addr + slots[i].len <= end_addr)) {
> -buf = qemu_malloc((slots[i].len / 4096 + 7) / 8 + 2);
> +buf = qemu_malloc(BITMAP_SIZE(slots[i].len));
> r = kvm_get_map(kvm, KVM_GET_DIRTY_LOG, i, buf);
> if (r) {
> qemu_free(buf);
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] kvm ksm support v3
On Wed, Sep 23, 2009 at 09:47:15PM +0300, Izik Eidus wrote: > Change from v2 : remove unused if. > > Thanks. > > Izik Eidus (3): > kvm: dont hold pagecount reference for mapped sptes pages > add SPTE_HOST_WRITEABLE flag to the shadow ptes > add support for change_pte mmu notifiers > > arch/x86/include/asm/kvm_host.h |1 + > arch/x86/kvm/mmu.c | 84 ++ > arch/x86/kvm/paging_tmpl.h | 18 +++- > virt/kvm/kvm_main.c | 14 ++ > 4 files changed, 96 insertions(+), 21 deletions(-) Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2868883 ] netkvm.sys stops sending/receiving on Windows Server 2003 VM
Bugs item #2868883, was opened at 2009-09-28 15:27 Message generated for change (Comment added) made by mdw21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2868883&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Weaver (mdw21) Assigned to: Nobody/Anonymous (nobody) Summary: netkvm.sys stops sending/receiving on Windows Server 2003 VM Initial Comment: This usually happens within an hour or two of starting the interface. It can be cured temporarily by disabling/enabling the adapter within Windows. I've run the Windows interface with log level set to 2 -- when traffic stops it still logs outgoing traffic as normal but ParaNdis_ProcessRxPath stops being logged. I suspect this is to do with the traffic content or timing as I cannot reproduce this with iperf, but only with external traffic to a website hosted on the machine. What further steps can I take to debug this issue? Host details: 2 x dual core xeons: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Xeon(R) CPU E5410 @ 2.33GHz stepping: 6 cpu MHz : 2327.685 cache size : 6144 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 lahf_lm tpr_shadow vnmi flexpriority bogomips: 4655.37 clflush size: 64 cache_alignment : 64 address sizes : 38 bits physical, 48 bits virtual power management: kernel is 2.6.31 from kernel.org, userspace is debian lenny, all 64-bit qemu is qemu-kvm-0.10.6 Guest details: Windows Server 2003 32-bit qemu is started as: qemu-system-x86_64 \ -boot c \ -drive file="/data/vms/stooge/boot.raw",if=virtio,boot=on,cache=off \ -m 3072 \ -smp 1 \ -vnc 10.80.80.89:2 \ -k en-gb \ -net nic,model=virtio,macaddr=DE:AD:BE:EF:11:29 \ -net tap,ifname=tap0 \ -localtime \ -usb -usbdevice tablet \ -mem-path /hugepages & -- >Comment By: Mark Weaver (mdw21) Date: 2009-09-28 15:43 Message: should have said that this was tested both with the binary driver from: https://sourceforge.net/projects/kvm/files/kvm-guest-drivers-windows/2/kvm-guest-drivers-windows-2.zip/download and also a self-compiled driver from the kvm git tree -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2868883&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2868883 ] netkvm.sys stops sending/receiving on Windows Server 2003 VM
Bugs item #2868883, was opened at 2009-09-28 15:27 Message generated for change (Tracker Item Submitted) made by mdw21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2868883&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Weaver (mdw21) Assigned to: Nobody/Anonymous (nobody) Summary: netkvm.sys stops sending/receiving on Windows Server 2003 VM Initial Comment: This usually happens within an hour or two of starting the interface. It can be cured temporarily by disabling/enabling the adapter within Windows. I've run the Windows interface with log level set to 2 -- when traffic stops it still logs outgoing traffic as normal but ParaNdis_ProcessRxPath stops being logged. I suspect this is to do with the traffic content or timing as I cannot reproduce this with iperf, but only with external traffic to a website hosted on the machine. What further steps can I take to debug this issue? Host details: 2 x dual core xeons: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Xeon(R) CPU E5410 @ 2.33GHz stepping: 6 cpu MHz : 2327.685 cache size : 6144 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 lahf_lm tpr_shadow vnmi flexpriority bogomips: 4655.37 clflush size: 64 cache_alignment : 64 address sizes : 38 bits physical, 48 bits virtual power management: kernel is 2.6.31 from kernel.org, userspace is debian lenny, all 64-bit qemu is qemu-kvm-0.10.6 Guest details: Windows Server 2003 32-bit qemu is started as: qemu-system-x86_64 \ -boot c \ -drive file="/data/vms/stooge/boot.raw",if=virtio,boot=on,cache=off \ -m 3072 \ -smp 1 \ -vnc 10.80.80.89:2 \ -k en-gb \ -net nic,model=virtio,macaddr=DE:AD:BE:EF:11:29 \ -net tap,ifname=tap0 \ -localtime \ -usb -usbdevice tablet \ -mem-path /hugepages & -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2868883&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: KVM-88 broke VirtIO Hard Disks
VirtIO is still broken in qemu-kvm-0-11.0. Reverting the patch solves the problem. Should I report that bug somewhere else? - Dietmar > -Original Message- > From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On > Behalf Of Alexey Eromenko > Sent: Donnerstag, 23. Juli 2009 16:24 > To: kvm > Subject: Re: KVM-88 broke VirtIO Hard Disks > > > - "Marcelo Tosatti" wrote: > > > On Thu, Jul 23, 2009 at 07:37:37AM -0400, Alexey Eromenko wrote: > > > > > > Hi All ! > > > > > > In addition to Floppy controllers KVM-88 also break VirtIO hard > > disks. (Windows 2003 Drivers refuse to work now) > > > > > > Linux (RHEL 5.3/x64) still boots off VirtIO Hard Disk. > > > > > > It turned out to be a Qemu merge into KVM userspace: > > > kvm-87-119-ga8b7f95 (commit > > a8b7f959d1fd97c4ccaf08ce750020ecd08b4c88) > > > > > > Can you look into it? > > > > Not sure if you familiar with this, but anyway: > > > > $ git diff-tree -p bf011293f | patch -R -p1 > > > > Yes, Thanks, This is it ! This is the problem.
Re: [PATCH] [RESEND] KVM:VMX: Add support for Pause-Loop Exiting
Avi Kivity wrote:
+#define KVM_VMX_DEFAULT_PLE_GAP41
+#define KVM_VMX_DEFAULT_PLE_WINDOW 4096
+static int __read_mostly ple_gap = KVM_VMX_DEFAULT_PLE_GAP;
+module_param(ple_gap, int, S_IRUGO);
+
+static int __read_mostly ple_window = KVM_VMX_DEFAULT_PLE_WINDOW;
+module_param(ple_window, int, S_IRUGO);
Shouldn't be __read_mostly since they're read very rarely (__read_mostly
should be for variables that are very often read, and rarely written).
In general, they are read only except that experienced user may try
different parameter for perf tuning.
I'm not even sure they should be parameters.
For different spinlock in different OS, and for different workloads, we
need different parameter for tuning. It's similar as the enable_ept.
/*
+ * Indicate a busy-waiting vcpu in spinlock. We do not enable the PAUSE
+ * exiting, so only get here on cpu with PAUSE-Loop-Exiting.
+ */
+static int handle_pause(struct kvm_vcpu *vcpu,
+ struct kvm_run *kvm_run)
+{
+ ktime_t expires;
+ skip_emulated_instruction(vcpu);
+
+ /* Sleep for 1 msec, and hope lock-holder got scheduled */
+ expires = ktime_add_ns(ktime_get(), 100UL);
I think this should be much lower, 50-100us. Maybe this should be a
parameter. With 1ms we losing significant cpu time if the congestion
clears.
I have made it a parameter with default value of 100 us.
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule_hrtimeout(&expires, HRTIMER_MODE_ABS);
+
Please add a tracepoint for this (since it can cause significant change
in behaviour),
Isn't trace_kvm_exit(exit_reason, ...) enough? We can tell the PLE
vmexit from other vmexits.
and move the logic to kvm_main.c. It will be reused by
the AMD implementation, possibly my software spinlock detector,
paravirtualized spinlocks, and hopefully other architectures.
Done.
+ return 1;
+}
+
+/*
kvm_ple_hrtimer_v2.patch
Description: Binary data
compiling kvm-kmod with 2.6.24 fails
Hi all, the kvm-XX packages always included the kernel module, but this is not the case for stable qemu-kvm-0.11.0? So I am trying to compile the latest kernel module for our 2.6.24 kernel. # git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git # cd kvm-kmod # git submodule update --init This downloads a whole kernel tree - is there a way to avoid that? #./configure --kerneldir=/path/to/our/kernel/dir # make sync no problems so far, but 'make' does not work. Any idea whats wrong? # make make -C /home/dietmar/svn-devel/pve-kernel-2.6.24/linux-2.6.24-openvz M=`pwd` \ LINUXINCLUDE="-I`pwd`/include -Iinclude \ -Iarch/x86/include -I`pwd`/include-compat \ -include include/linux/autoconf.h \ -include `pwd`/x86/external-module-compat.h " \ "$@" make[1]: Entering directory `/home/dietmar/svn-devel/pve-kernel-2.6.24/linux-2.6.24-openvz' LD /home/dietmar/svn-devel/pve-kernel-2.6.24/kvm-kmod/x86/built-in.o CC [M] /home/dietmar/svn-devel/pve-kernel-2.6.24/kvm-kmod/x86/svm.o In file included from /home/dietmar/svn-devel/pve-kernel-2.6.24/kvm-kmod/x86/external-module-compat.h:16, from :0: /home/dietmar/svn-devel/pve-kernel-2.6.24/kvm-kmod/x86/../external-module-compat-comm.h: In function \ufffd\ufffd\ufffdkvm_vma_kernel_pagesize\ufffd\ufffd\ufffd: /home/dietmar/svn-devel/pve-kernel-2.6.24/kvm-kmod/x86/../external-module-compat-comm.h:968: error: implicit declaration of function \ufffd\ufffd\ufffdhstate_vma\ufffd\ufffd\ufffd /home/dietmar/svn-devel/pve-kernel-2.6.24/kvm-kmod/x86/../external-module-compat-comm.h:968: warning: assignment makes pointer from integer without a cast /home/dietmar/svn-devel/pve-kernel-2.6.24/kvm-kmod/x86/../external-module-compat-comm.h:970: error: dereferencing pointer to incomplete type make[3]: *** [/home/dietmar/svn-devel/pve-kernel-2.6.24/kvm-kmod/x86/svm.o] Error 1 make[2]: *** [/home/dietmar/svn-devel/pve-kernel-2.6.24/kvm-kmod/x86] Error 2 make[1]: *** [_module_/home/dietmar/svn-devel/pve-kernel-2.6.24/kvm-kmod] Error 2 make[1]: Leaving directory `/home/dietmar/svn-devel/pve-kernel-2.6.24/linux-2.6.24-openvz' make: *** [all] Error 2 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fix a bug in function create in kvm_vm
Signed-off-by: Yolkfull Chow
---
client/tests/kvm/kvm_vm.py |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/client/tests/kvm/kvm_vm.py b/client/tests/kvm/kvm_vm.py
index 55220f9..8ae 100755
--- a/client/tests/kvm/kvm_vm.py
+++ b/client/tests/kvm/kvm_vm.py
@@ -406,7 +406,7 @@ class VM:
self.process.get_output()))
return False
-logging.debug("VM appears to be alive with PID %d",
+logging.debug("VM appears to be alive with PID %d" %
self.process.get_pid())
return True
--
1.6.2.5
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
