Re: [kvm-devel] [PATCH 1/2] KVM: Remove arch specific components from the general code
Gregory Haskins wrote: Signed-off-by: Gregory Haskins [EMAIL PROTECTED] Applied, thanks. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 2/2] KVM: Clean up VMCLEAR/VMPTRLD code on VMX
Gregory Haskins wrote: Signed-off-by: Gregory Haskins [EMAIL PROTECTED] --- Dropped - I don't see a problem with the current code. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 2/2] Dynamically allocate vcpus
Rusty Russell wrote: Dynamically allocate vcpus This patch converts the vcpus array in struct kvm to a pointer array, and changes the vcpu_create and vcpu_setup hooks into one vcpu_create call which does the allocation and initialization of the vcpu (calling back into the kvm_vcpu_init core helper). It is untested on SMP or SVM, and there are more possible cleanups in svm.c and vmx.c, but I was being cautious. Applied; thanks. Both smp and svm work. But watch that whitespace. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] 2.6.23-rc1, KVM-AMD problem
Alistair John Strachan wrote:
Hi,
I'm getting periodic oopses running KVM-33 on 2.6.23-rc1. Here is a digital
photo of the oops. Alarmingly, a lot of the time it triple faults the machine
and I don't get a chance to grab it. This time I was lucky, though.
http://devzero.co.uk/~alistair/kvm-2.6.23-rc1.jpg
Unfortunately, some of the oops text scrolled out of the screen. I will
endeavour to reproduce the bug over serial console, but I can make no
guarantees.
The CPU is an AMD X2 BE-2350, chipset is AMD 690G.
If you are using the modules from 2.6.23-rc1, try upgrading to latest
-git, which contains a patch that might fix this problem. If you are
using the modules from kvm-33, try applying the attached patch.
--
error compiling committee.c: too many arguments to function
commit bfa6c62f98bd0602025d7b48e267d817082f5d07
Author: Aurelien Jarno [EMAIL PROTECTED]
Date: Wed Jul 25 10:19:54 2007 +0200
KVM: disable writeback for 0x0f 0x01 instructions.
0x0f 0x01 instructions (ie lgdt, lidt, smsw, lmsw and invlpg) does
not use writeback. This patch set no_wb=1 when emulating those
instructions.
This fixes a regression booting the FreeBSD kernel on AMD.
Signed-off-by: Aurelien Jarno [EMAIL PROTECTED]
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index 21ce977..cbbb9c5 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -1183,6 +1183,8 @@ pop_instruction:
twobyte_insn:
switch (b) {
case 0x01: /* lgdt, lidt, lmsw */
+ /* Disable writeback. */
+ no_wb = 1;
switch (modrm_reg) {
u16 size;
unsigned long address;
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Improve the method of writing vmcs control
Yang, Sheng wrote: Put cpu feature detecting part in hardware_setup, and stored the vmcs condition in global variable for further check. Applied, thanks. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] qcow2 image growing without reason ?
Ben Budts wrote: Hi, I've been running kvm21 for a long time (just upgraded to kvm-33 with 2.6.22.1) I have a 60GB qcow2 image, I noticed the image was growing without me installing software on the guest os...(WIN XP) When I select all my files and take properties (in win xp that is), it says 3.7GB, as expected... The image is allmost the double though (6.4GB) when i look at the qcow2 image, when taking the properties of the HD in win xp it also indictates 6.4GB. I've been installing some software, after each install I did a restart, bakupped the image etc... Any idea's ? If Windows says the disk size is 6.4GB, then the qcow image certainly can't be smaller. Maybe you have a large paging file, or perhaps you need to run chkdsk. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] 2.6.23-rc1, KVM-AMD problem
On Sunday 29 July 2007 09:16:43 Avi Kivity wrote: Alistair John Strachan wrote: Hi, I'm getting periodic oopses running KVM-33 on 2.6.23-rc1. Here is a digital photo of the oops. Alarmingly, a lot of the time it triple faults the machine and I don't get a chance to grab it. This time I was lucky, though. http://devzero.co.uk/~alistair/kvm-2.6.23-rc1.jpg Unfortunately, some of the oops text scrolled out of the screen. I will endeavour to reproduce the bug over serial console, but I can make no guarantees. The CPU is an AMD X2 BE-2350, chipset is AMD 690G. If you are using the modules from 2.6.23-rc1, try upgrading to latest -git, which contains a patch that might fix this problem. If you are using the modules from kvm-33, try applying the attached patch. Doesn't help, I still get the same crashes. I tried 2.6.22 again and it's rock solid by comparison. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] 2.6.23-rc1, KVM-AMD problem
Alistair John Strachan wrote: On Sunday 29 July 2007 09:16:43 Avi Kivity wrote: Alistair John Strachan wrote: Hi, I'm getting periodic oopses running KVM-33 on 2.6.23-rc1. Here is a digital photo of the oops. Alarmingly, a lot of the time it triple faults the machine and I don't get a chance to grab it. This time I was lucky, though. http://devzero.co.uk/~alistair/kvm-2.6.23-rc1.jpg Unfortunately, some of the oops text scrolled out of the screen. I will endeavour to reproduce the bug over serial console, but I can make no guarantees. The CPU is an AMD X2 BE-2350, chipset is AMD 690G. If you are using the modules from 2.6.23-rc1, try upgrading to latest -git, which contains a patch that might fix this problem. If you are using the modules from kvm-33, try applying the attached patch. Doesn't help, I still get the same crashes. I tried 2.6.22 again and it's rock solid by comparison. Do you mean, kvm-33 on top of 2.6.22, or the kvm modules from 2.6.22? Please describe your configuration *exactly*. And what do you mean, rock solid by comparison? Either it's rock solid or it isn't. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] qcow2 image growing without reason ?
On 7/26/07, Ben Budts [EMAIL PROTECTED] wrote: When I select all my files and take properties (in win xp that is), it says 3.7GB, as expected... The image is allmost the double though (6.4GB) when i look at the qcow2 image, when taking the properties of the HD in win xp it also indictates 6.4GB. Hum, then the used disk space is 6.4GB. Selecting all files may skip hidden/system/whatever files according to explorer settings. Luca - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] 2.6.23-rc1, KVM-AMD problem
Alistair John Strachan wrote: On Sunday 29 July 2007 12:34:28 you wrote: [snip] Doesn't help, I still get the same crashes. I tried 2.6.22 again and it's rock solid by comparison. Do you mean, kvm-33 on top of 2.6.22, or the kvm modules from 2.6.22? Please describe your configuration *exactly*. I'm using the kvm-33 *userspace* package (based on Debian's kvm-28 packaging) and 2.6.23-rc1's KVM modules. I patched 2.6.23-rc1 with the patch you provided in your last email. So I'm not using -git HEAD. Maybe there's been additional necessary fixes to -git requiring me to update to HEAD? That wasn't clear from your last email. No, that patch is the only potential fix post -rc1. There are a few other fixes there, but they are intended to avoid guest crashes, not host crashes. What guest are you running? Maybe I can reproduce it here. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] 2.6.23-rc1, KVM-AMD problem
On Sunday 29 July 2007 12:34:28 you wrote: [snip] Doesn't help, I still get the same crashes. I tried 2.6.22 again and it's rock solid by comparison. Do you mean, kvm-33 on top of 2.6.22, or the kvm modules from 2.6.22? Please describe your configuration *exactly*. I'm using the kvm-33 *userspace* package (based on Debian's kvm-28 packaging) and 2.6.23-rc1's KVM modules. I patched 2.6.23-rc1 with the patch you provided in your last email. So I'm not using -git HEAD. Maybe there's been additional necessary fixes to -git requiring me to update to HEAD? That wasn't clear from your last email. And what do you mean, rock solid by comparison? Either it's rock solid or it isn't. It's rock solid. It does not crash. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] 2.6.23-rc1, KVM-AMD problem
On Sunday 29 July 2007 14:47:57 you wrote: Alistair John Strachan wrote: On Sunday 29 July 2007 12:34:28 you wrote: [snip] Doesn't help, I still get the same crashes. I tried 2.6.22 again and it's rock solid by comparison. Do you mean, kvm-33 on top of 2.6.22, or the kvm modules from 2.6.22? Please describe your configuration *exactly*. I'm using the kvm-33 *userspace* package (based on Debian's kvm-28 packaging) and 2.6.23-rc1's KVM modules. I patched 2.6.23-rc1 with the patch you provided in your last email. So I'm not using -git HEAD. Maybe there's been additional necessary fixes to -git requiring me to update to HEAD? That wasn't clear from your last email. No, that patch is the only potential fix post -rc1. There are a few other fixes there, but they are intended to avoid guest crashes, not host crashes. What guest are you running? Maybe I can reproduce it here. Right now, Windows XP. I'm pretty sure Linux (well, Debian Etch) works fine. I could only get Windows to install with -no-acpi, but I run it with the following (if this is at all useful): kvm -no-acpi -m 256 -hda $IMAGE -net nic -net tap,script=/etc/kvm/kvm-ifup Basically, the installer seems to work fine, but Windows seemed to have problems after installing post-SP2 updates. Maybe that's why not everybody is seeing it yet. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] Add cpu consistence check in vmx.
All the physical CPUs on the board should support the same VMX feature
set.
The hardware_enable() do the per-cpu check now.
In case of vmx/svm enabling failure, transfer a variable in
hardware_enable()
for error report.
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
---
drivers/kvm/kvm_main.c |9 +++--
drivers/kvm/svm.c |3 +-
drivers/kvm/vmx.c | 84
+---
3 files changed, 59 insertions(+), 37 deletions(-)
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index bc11c2d..10443ea 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -2974,14 +2974,14 @@ static void decache_vcpus_on_cpu(int cpu)
spin_unlock(kvm_lock);
}
-static void hardware_enable(void *junk)
+static void hardware_enable(void *rtn)
{
int cpu = raw_smp_processor_id();
if (cpu_isset(cpu, cpus_hardware_enabled))
return;
cpu_set(cpu, cpus_hardware_enabled);
- kvm_arch_ops-hardware_enable(NULL);
+ kvm_arch_ops-hardware_enable(rtn);
}
static void hardware_disable(void *junk)
@@ -3173,7 +3173,10 @@ int kvm_init_arch(struct kvm_arch_ops *ops,
struct module *module)
if (r 0)
goto out;
- on_each_cpu(hardware_enable, NULL, 0, 1);
+ on_each_cpu(hardware_enable, r, 0, 1);
+ if (r 0)
+ goto out;
+
r = register_cpu_notifier(kvm_cpu_notifier);
if (r)
goto out_free_1;
diff --git a/drivers/kvm/svm.c b/drivers/kvm/svm.c
index 850a1b1..1e76417 100644
--- a/drivers/kvm/svm.c
+++ b/drivers/kvm/svm.c
@@ -285,7 +285,7 @@ static void svm_hardware_disable(void *garbage)
}
}
-static void svm_hardware_enable(void *garbage)
+static void svm_hardware_enable(void *rtn)
{
struct svm_cpu_data *svm_data;
@@ -298,6 +298,7 @@ static void svm_hardware_enable(void *garbage)
struct desc_struct *gdt;
int me = raw_smp_processor_id();
+ *(int*)rtn = 0;
if (!has_svm()) {
printk(KERN_ERR svm_cpu_init: err EOPNOTSUPP on %d\n,
me);
return;
diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
index e5721a5..8032c7e 100644
--- a/drivers/kvm/vmx.c
+++ b/drivers/kvm/vmx.c
@@ -756,31 +756,6 @@ static __init int vmx_disabled_by_bios(void)
/* locked but not enabled */
}
-static void hardware_enable(void *garbage)
-{
- int cpu = raw_smp_processor_id();
- u64 phys_addr = __pa(per_cpu(vmxarea, cpu));
- u64 old;
-
- rdmsrl(MSR_IA32_FEATURE_CONTROL, old);
- if ((old (MSR_IA32_FEATURE_CONTROL_LOCKED |
- MSR_IA32_FEATURE_CONTROL_VMXON_ENABLED))
- != (MSR_IA32_FEATURE_CONTROL_LOCKED |
- MSR_IA32_FEATURE_CONTROL_VMXON_ENABLED))
- /* enable and lock */
- wrmsrl(MSR_IA32_FEATURE_CONTROL, old |
- MSR_IA32_FEATURE_CONTROL_LOCKED |
- MSR_IA32_FEATURE_CONTROL_VMXON_ENABLED);
- write_cr4(read_cr4() | X86_CR4_VMXE); /* FIXME: not cpu hotplug
safe */
- asm volatile (ASM_VMX_VMXON_RAX : : a(phys_addr),
m(phys_addr)
- : memory, cc);
-}
-
-static void hardware_disable(void *garbage)
-{
- asm volatile (ASM_VMX_VMXOFF : : : cc);
-}
-
static __init int adjust_vmx_controls(u32 ctl_min, u32 ctl_opt,
u32 msr, u32* result)
{
@@ -856,18 +831,61 @@ static __init int setup_vmcs_config(void)
if (((vmx_msr_high 18) 15) != 6)
return -1;
- vmcs_config.size = vmx_msr_high 0x1fff;
- vmcs_config.order = get_order(vmcs_config.size);
- vmcs_config.revision_id = vmx_msr_low;
-
- vmcs_config.pin_based_exec_ctrl = _pin_based_exec_control;
- vmcs_config.cpu_based_exec_ctrl = _cpu_based_exec_control;
- vmcs_config.vmexit_ctrl = _vmexit_control;
- vmcs_config.vmentry_ctrl= _vmentry_control;
+ if (vmcs_config.size == 0) {
+ /* called in hardware_setup(), initialization */
+ vmcs_config.size = vmx_msr_high 0x1fff;
+ vmcs_config.order = get_order(vmcs_config.size);
+ vmcs_config.revision_id = vmx_msr_low;
+
+ vmcs_config.pin_based_exec_ctrl =
_pin_based_exec_control;
+ vmcs_config.cpu_based_exec_ctrl =
_cpu_based_exec_control;
+ vmcs_config.vmexit_ctrl = _vmexit_control;
+ vmcs_config.vmentry_ctrl= _vmentry_control;
+ } else if ((vmcs_config.size != (vmx_msr_high 0x1fff))
+ || (vmcs_config.revision_id != vmx_msr_low)
+ || (vmcs_config.pin_based_exec_ctrl !=
_pin_based_exec_control)
+ || (vmcs_config.cpu_based_exec_ctrl !=
_cpu_based_exec_control)
+ || (vmcs_config.vmexit_ctrl != _vmexit_control)
+ || (vmcs_config.vmentry_ctrl != _vmentry_control)) {
+ /* called in
[kvm-devel] Storing command line options in qcow2 images
Hi Avi, hi all, I've started some (very minor) groundwork for this task. My idea was to add an extra annotation field in qcow2 snapshots. In this way, a snapshot can hold abitrary information; for example, command line arguments. Before going any further, I wanted to validate the general idea with the list. I am planning on using a snapshot with a distinct name to store command line options. This approach seems simple yet it is powerful enough for what we need to do. There's a slight overhead as now all qcow2 snapshots have to store a extra (probably) empty pointer. An alternative approach would be to somehow indicate that some snapshots are descriptive snapshots and others are useful snapshots; however, I felt that this would be more complicated. I have a working patch to qemu-img that allows storing arbitrary annotations into qcow2 images. I developed it as a testing utility. Right now annotations are implemented as another string alongside the snapshot's 'name' and 'id'. I thought about storing annotations as key/value pairs but again, it seemed overkill. From here, the plan would be to add a command to qemu-img that allows embedding of command line options into qcow2 images. These options would be stored in a snapshot with a special name, and qemu would check for the presence of this snapshot in order to read command line options from the qcow2 image. Ideas? Suggestions? I can send the patches for the functionality that's implemented right now. Cheers, Jorge - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
