Re: nested KVM on AMD (proxmox in proxmox)
On 27.11.2009, at 17:30, Adrian Terranova wrote: On Fri, Nov 27, 2009 at 11:13 AM, Alexander Graf ag...@suse.de wrote: On 27.11.2009, at 17:01, Adrian Terranova wrote: On Thu, Nov 26, 2009 at 12:55 PM, Alexander Graf ag...@suse.de wrote: On 26.11.2009, at 17:06, Adrian Terranova wrote: Hello, Looking for a pointer to a working setup of kvm nesting kvm with svm extensions working thruout. I'm working with proxmox - and trying to get a proxmox in a proxmox working. KVM is called as follows from the proxmox host. 31515 ?Sl27:15 /usr/bin/kvm -monitor unix:/var/run/qemu-server/109.mon,server,nowait -vnc unix:/var/run/qemu-server/109.vnc,password -pidfile /var/run/qemu-server/109.pid -daemonize -usbdevice tablet -name proxmoxkvmtest -smp sockets=1,cores=1 -vga cirrus -tdf -k en-us -drive file=/mnt/pve/nfsimages/images/109/vm-109-disk-1.raw,if=ide,index=0,boot=on -drive file=/var/lib/vz/template/iso/proxmox-ve_1.4-4390.iso,if=ide,index=2,media=cdrom -m 512 -net tap,vlan=0,ifname=vmtab109i0,script=/var/lib/qemu-server/bridge-vlan -net nic,vlan=0,model=e1000,macaddr=A2:40:B2:EF:69:B8 -id 109 -cpuunits 1000 -enable-nesting The key thing (it appears - is the enable nesting) - the other piece that it looks like it needs is a kernel argument to properly enable the kvm extensions cause there is no /dev/kvm but there is an error in dmesg from the dmesg output / boot console of the virtualized kvm instance of the following [snip from dmesg of first boot] ... tun: (C) 1999-2004 Max Krasnyansky m...@qualcomm.com general protection fault: [1] PREEMPT SMP CPU: 0 Modules linked in: kvm_amd kvm vzethdev vznetdev simfs vzrst vzcpt tun vzdquota vzmon vzdev xt_tcpudp xt_length ipt_ttl xt_tcpmss xt_TCPMSS iptable_mangle iptab le_filter xt_multiport xt_limit ipt_tos ipt_REJECT ip_tables x_tables ipv6 ib_is er rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi scsi_tran sport_iscsi bridge virtio_balloon parport_pc parport floppy psmouse pcspkr serio _raw e1000 joydev evdev thermal button processor sg scsi_wait_scan virtio_blk dm _mod usbhid hid usb_storage libusual sd_mod sr_mod ide_disk ide_generic ide_cd c drom ide_core ata_piix pata_acpi ata_generic libata scsi_mod uhci_hcd usbcore i2 c_piix4 i2c_core virtio_pci virtio_ring virtio isofs msdos fat Pid: 2914, comm: modprobe Not tainted 2.6.24-8-pve #1 ovz005 RIP: 0010:[884532b0] [884532b0] :kvm_amd:svm_hardware_enabl e+0x80/0xe0 RSP: 0018:81001dcb5de8 EFLAGS: 00010006 RAX: 1d01 RBX: 0010 RCX: c080 RDX: RSI: 88458b26 RDI: RBP: 81001d49b240 R08: 0001 R09: R10: R11: 88453230 R12: 88420050 R13: 8845c100 R14: 8845c100 R15: c21f8618 FS: 7fe49ff576e0() GS:80628000() knlGS: CS: 0010 DS: ES: CR0: 8005003b ... More can be found here if you feel really interested http://www.proxmox.com/forum/showthread.php?t=2675 trying to figure out what I missed. You need to modprobe kvm-amd with the nested=1 parameter on the host. Alex Did that - and get ht following in the guest [snip] more dmesg output ... kvm: Nested Virtualization enabled general protection fault: [1] PREEMPT SMP You should get Nested Virtualization enabled on the host and the GPF inside the guest. The fact that you get the GPF tells me that kvm blocked the hardware_enable which is setting a bit in EFER. That's exactly what the enable_nested=1 parameter is supposed to allow. I don't really know Proxmox or what version of KVM they use. Could you please try something reasonably recent? Alex Alex, It works - I was being stupid and setting it in the guest -not the host - this is what I get now (it just works) Yep, the guest doesn't need any modifications for this to work. So in fact you can even run Xen HVM inside KVM. Hyper-V still breaks, but in theory getting that working is the goal :-). Btw - I'd recommend using nested SVM only with nested paging capable machines. Doing shadow paging on the host and the guest is unbearably slow. 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 1/2] Adds a test to verify resources inside a VM
On Sun, Nov 29, 2009 at 12:50 PM, Yolkfull Chow yz...@redhat.com wrote:
On Wed, Nov 25, 2009 at 11:35:02AM +0530, sudhir kumar wrote:
This patch adds a test for verifying whether the number of cpus and amount
of memory as seen inside a guest is same as allocated to it on the qemu
command line.
Hello Sudhir,
Please see embedded comments as below:
Signed-off-by: Sudhir Kumar sku...@linux.vnet.ibm.com
Index: kvm/tests/verify_resources.py
===
--- /dev/null
+++ kvm/tests/verify_resources.py
@@ -0,0 +1,74 @@
+import logging, time
+from autotest_lib.client.common_lib import error
+import kvm_subprocess, kvm_test_utils, kvm_utils
+
+
+Test to verify if the guest has the equal amount of resources
+as allocated through the qemu command line
+
+...@copyright: 2009 IBM Corporation
+...@author: Sudhir Kumar sku...@linux.vnet.ibm.com
+
+
+
+def run_verify_resources(test, params, env):
+
+ KVM test for verifying VM resources(#vcpu, memory):
+ 1) Get resources from the VM parameters
+ 2) Log into the guest
+ 3) Get actual resources, compare and report the pass/failure
+
+ �...@param test: kvm test object
+ �...@param params: Dictionary with the test parameters
+ �...@param env: Dictionary with test environment.
+
+ vm = kvm_test_utils.get_living_vm(env, params.get(main_vm))
+
+ # Get info about vcpu and memory from dictionary
+ exp_vcpus = int(params.get(smp))
+ exp_mem_mb = long(params.get(mem))
+ real_vcpus = 0
+ real_mem_kb = 0
+ real_mem_mb = 0
+ # Some memory is used by bios and all, so lower the expected
value say by 5%
+ exp_mem_mb = long(exp_mem_mb * 0.95)
+ logging.info(The guest should have vcpus: %s % exp_vcpus)
+ logging.info(The guest should have min mem: %s MB % exp_mem_mb)
+
+ session = kvm_test_utils.wait_for_login(vm)
+
+ # Get info about vcpu and memory from within guest
+ if params.get(guest_os_type) == Linux:
+ output = session.get_command_output(cat /proc/cpuinfo|grep
processor)
We'd better here not hard code the command that getting CPU count. As KVM
supports not
only Linux Windows, but also others say Unix/BSD.
A recommended method could be define it in config file for different
platforms:
I agree. The only concern that made me doing it inside test is the
increasing size and complexity of the config file. I am fine with
passing the command from the config file but still the code paths have
to be different for each type of OS ie windows linux etc.
- @Linux:
verify_resources:
count_cpu_cmd = grep processor /proc/cpuinfo
- @Windows:
verify_resources:
count_cpu_cmd = systeminfo (here I would not suggest we use
'systeminfo'
for catching M$ guest's memory size)
+ for line in output.split('\n'):
+ if 'processor' in line:
+ real_vcpus = real_vcpus + 1
+
+ output = session.get_command_output(cat /proc/meminfo)
For catching memory size of Linux guests, I prefer command 'dmidecode' which
can
catch memory size exactly in MB.
I think we can use both here. To my knowledge dmidecode will test the
BIOS code of kvm and hence we can include both the methods?
+ for line in output.split('\n'):
+ if 'MemTotal' in line:
+ real_mem_kb = long(line.split()[1])
+ real_mem_mb = real_mem_kb / 1024
+
+ elif params.get(guest_os_type) == Windows:
+ # Windows takes long time to display output for systeminfo
+ output = session.get_command_output(systeminfo, timeout =
150, internal_timeout = 50)
+ for line in output.split('\n'):
+ if 'Processor' in line:
+ real_vcpus = int(line.split()[1])
+
+ for line in output.split('\n'):
+ if 'Total Physical Memory' in line:
+ real_mem_mb = long(.join(%s % k for k in
line.split()[3].split(',')))
So many slice and split operations can easy results in problems.
To catch memory of Windows guests, I recommend we use 'wmic memphysical' which
can dump memory size in KB exactly.
Is the command available for all windows OSes? If yes we can
definitely use the command.
Meanwhile, we also need to verify guest's NICs' count and their(its) model,
hard disk(s)'s count model etc. Therefore I think we need a case to verify
them together.
Yeah, I just gave a first try for such a test. We need to test all the
emulated hardware.
I had wrote such test couples of days before. I also ran it several times.
Please comment on it when I post it here later. Thanks,
Sure. Please post them. I am happy to see them getting merged.
Thanks a lot for your comments!!
Sudhir
+
+ else:
+ raise error.TestFail(Till date this test is supported only
for Linux and Windows)
+
+ logging.info(The guest has cpus: %s % real_vcpus)
+
Re: [PATCH 1/2] Adds a test to verify resources inside a VM
On 11/29/2009 9:20 AM, Yolkfull Chow wrote:
On Wed, Nov 25, 2009 at 11:35:02AM +0530, sudhir kumar wrote:
This patch adds a test for verifying whether the number of cpus and amount
of memory as seen inside a guest is same as allocated to it on the qemu
command line.
Hello Sudhir,
Please see embedded comments as below:
Signed-off-by: Sudhir Kumarsku...@linux.vnet.ibm.com
Index: kvm/tests/verify_resources.py
===
--- /dev/null
+++ kvm/tests/verify_resources.py
@@ -0,0 +1,74 @@
+import logging, time
+from autotest_lib.client.common_lib import error
+import kvm_subprocess, kvm_test_utils, kvm_utils
+
+
+Test to verify if the guest has the equal amount of resources
+as allocated through the qemu command line
+
+...@copyright: 2009 IBM Corporation
+...@author: Sudhir Kumarsku...@linux.vnet.ibm.com
+
+
+
+def run_verify_resources(test, params, env):
+
+KVM test for verifying VM resources(#vcpu, memory):
+1) Get resources from the VM parameters
+2) Log into the guest
+3) Get actual resources, compare and report the pass/failure
+
+@param test: kvm test object
+@param params: Dictionary with the test parameters
+@param env: Dictionary with test environment.
+
+vm = kvm_test_utils.get_living_vm(env, params.get(main_vm))
+
+# Get info about vcpu and memory from dictionary
+exp_vcpus = int(params.get(smp))
+exp_mem_mb = long(params.get(mem))
+real_vcpus = 0
+real_mem_kb = 0
+real_mem_mb = 0
+# Some memory is used by bios and all, so lower the expected
value say by 5%
+exp_mem_mb = long(exp_mem_mb * 0.95)
+logging.info(The guest should have vcpus: %s % exp_vcpus)
+logging.info(The guest should have min mem: %s MB % exp_mem_mb)
+
+session = kvm_test_utils.wait_for_login(vm)
+
+# Get info about vcpu and memory from within guest
+if params.get(guest_os_type) == Linux:
+output = session.get_command_output(cat /proc/cpuinfo|grep processor)
We'd better here not hard code the command that getting CPU count. As KVM
supports not
only Linux Windows, but also others say Unix/BSD.
A recommended method could be define it in config file for different platforms:
- @Linux:
verify_resources:
count_cpu_cmd = grep processor /proc/cpuinfo
- @Windows:
verify_resources:
count_cpu_cmd = systeminfo (here I would not suggest we use
'systeminfo'
for catching M$ guest's memory size)
+for line in output.split('\n'):
+if 'processor' in line:
+real_vcpus = real_vcpus + 1
If you want just to count the number of processors, count using:
/bin/grep -c processor /proc/cpuinfo
However, I feel there's more data we could get from the output - such as
the topology (sockets/cores/threads) and cpuid level and flags which we
should look at .
+
+output = session.get_command_output(cat /proc/meminfo)
/bin/grep MemTotal /proc/meminfo
Y.
For catching memory size of Linux guests, I prefer command 'dmidecode' which can
catch memory size exactly in MB.
+for line in output.split('\n'):
+if 'MemTotal' in line:
+real_mem_kb = long(line.split()[1])
+real_mem_mb = real_mem_kb / 1024
+
+elif params.get(guest_os_type) == Windows:
+# Windows takes long time to display output for systeminfo
+output = session.get_command_output(systeminfo, timeout =
150, internal_timeout = 50)
+for line in output.split('\n'):
+if 'Processor' in line:
+real_vcpus = int(line.split()[1])
+
+for line in output.split('\n'):
+if 'Total Physical Memory' in line:
+ real_mem_mb = long(.join(%s % k for k in
line.split()[3].split(',')))
So many slice and split operations can easy results in problems.
To catch memory of Windows guests, I recommend we use 'wmic memphysical' which
can dump memory size in KB exactly.
Meanwhile, we also need to verify guest's NICs' count and their(its) model,
hard disk(s)'s count model etc. Therefore I think we need a case to verify
them together.
I had wrote such test couples of days before. I also ran it several times.
Please comment on it when I post it here later. Thanks,
+
+else:
+raise error.TestFail(Till date this test is supported only
for Linux and Windows)
+
+logging.info(The guest has cpus: %s % real_vcpus)
+logging.info(The guest has mem: %s MB % real_mem_mb)
+if exp_vcpus != real_vcpus or real_mem_mb exp_mem_mb:
+raise error.TestFail(Actual resources(cpu ='%s' memory ='%s' MB)
+ differ from Allocated resources(cpu = '%s' memory ='%s' MB
+ % (real_vcpus, real_mem_mb, exp_vcpus, exp_mem_mb))
+
+session.close()
Sending the patch as an attachment too. Please review and provide your comments.
--
Sudhir
Re: [PATCH 1/2] Adds a test to verify resources inside a VM
On Sun, Nov 29, 2009 at 02:22:40PM +0530, sudhir kumar wrote:
On Sun, Nov 29, 2009 at 12:50 PM, Yolkfull Chow yz...@redhat.com wrote:
On Wed, Nov 25, 2009 at 11:35:02AM +0530, sudhir kumar wrote:
This patch adds a test for verifying whether the number of cpus and amount
of memory as seen inside a guest is same as allocated to it on the qemu
command line.
Hello Sudhir,
Please see embedded comments as below:
Signed-off-by: Sudhir Kumar sku...@linux.vnet.ibm.com
Index: kvm/tests/verify_resources.py
===
--- /dev/null
+++ kvm/tests/verify_resources.py
@@ -0,0 +1,74 @@
+import logging, time
+from autotest_lib.client.common_lib import error
+import kvm_subprocess, kvm_test_utils, kvm_utils
+
+
+Test to verify if the guest has the equal amount of resources
+as allocated through the qemu command line
+
+...@copyright: 2009 IBM Corporation
+...@author: Sudhir Kumar sku...@linux.vnet.ibm.com
+
+
+
+def run_verify_resources(test, params, env):
+
+ KVM test for verifying VM resources(#vcpu, memory):
+ 1) Get resources from the VM parameters
+ 2) Log into the guest
+ 3) Get actual resources, compare and report the pass/failure
+
+ �...@param test: kvm test object
+ �...@param params: Dictionary with the test parameters
+ �...@param env: Dictionary with test environment.
+
+ vm = kvm_test_utils.get_living_vm(env, params.get(main_vm))
+
+ # Get info about vcpu and memory from dictionary
+ exp_vcpus = int(params.get(smp))
+ exp_mem_mb = long(params.get(mem))
+ real_vcpus = 0
+ real_mem_kb = 0
+ real_mem_mb = 0
+ # Some memory is used by bios and all, so lower the expected
value say by 5%
+ exp_mem_mb = long(exp_mem_mb * 0.95)
+ logging.info(The guest should have vcpus: %s % exp_vcpus)
+ logging.info(The guest should have min mem: %s MB % exp_mem_mb)
+
+ session = kvm_test_utils.wait_for_login(vm)
+
+ # Get info about vcpu and memory from within guest
+ if params.get(guest_os_type) == Linux:
+ output = session.get_command_output(cat /proc/cpuinfo|grep
processor)
We'd better here not hard code the command that getting CPU count. As KVM
supports not
only Linux Windows, but also others say Unix/BSD.
A recommended method could be define it in config file for different
platforms:
I agree. The only concern that made me doing it inside test is the
increasing size and complexity of the config file. I am fine with
passing the command from the config file but still the code paths have
to be different for each type of OS ie windows linux etc.
- @Linux:
verify_resources:
count_cpu_cmd = grep processor /proc/cpuinfo
- @Windows:
verify_resources:
count_cpu_cmd = systeminfo (here I would not suggest we use
'systeminfo'
for catching M$ guest's memory size)
+ for line in output.split('\n'):
+ if 'processor' in line:
+ real_vcpus = real_vcpus + 1
+
+ output = session.get_command_output(cat /proc/meminfo)
For catching memory size of Linux guests, I prefer command 'dmidecode'
which can
catch memory size exactly in MB.
I think we can use both here. To my knowledge dmidecode will test the
BIOS code of kvm and hence we can include both the methods?
+ for line in output.split('\n'):
+ if 'MemTotal' in line:
+ real_mem_kb = long(line.split()[1])
+ real_mem_mb = real_mem_kb / 1024
+
+ elif params.get(guest_os_type) == Windows:
+ # Windows takes long time to display output for systeminfo
+ output = session.get_command_output(systeminfo, timeout =
150, internal_timeout = 50)
+ for line in output.split('\n'):
+ if 'Processor' in line:
+ real_vcpus = int(line.split()[1])
+
+ for line in output.split('\n'):
+ if 'Total Physical Memory' in line:
+ real_mem_mb = long(.join(%s % k for k in
line.split()[3].split(',')))
So many slice and split operations can easy results in problems.
To catch memory of Windows guests, I recommend we use 'wmic memphysical'
which
can dump memory size in KB exactly.
Is the command available for all windows OSes? If yes we can
definitely use the command.
Yes it's available for all Windows OSes although with some limitations that it
can
only be executed within TELNET session or Windows command prompt. But it's
fixed now.:)
Cheers,
Meanwhile, we also need to verify guest's NICs' count and their(its) model,
hard disk(s)'s count model etc. Therefore I think we need a case to verify
them together.
Yeah, I just gave a first try for such a test. We need to test all the
emulated hardware.
I had wrote such test couples of days
Re: 2.6.31.5 x86-64 KVM: 'emulation failed (pagetable) rip 7fb49335da7b 66 0f 7f 07'
On 11/27/2009 11:56 PM, Nix wrote: So I installed my first KVM guest image (a prerelease of Ubuntu 9.10 that I had lying around) this morning (through virt-manager, as it happens). Everything worked fine, the install was searingly fast compared to the UML virtual machines I'm used to. I got back to it this evening, restarted the VM, and found that it had suddenly slowed right down again, with one CPU being saturated with work even when nothing was happening. Looking at the syslog shows (what would be but for ratelimit) incredible numbers of these messages being logged: Nov 27 21:44:00 spindle info: [444857.792205] device vnet0 entered promiscuous mode Nov 27 21:44:00 spindle info: [444857.794347] linux-net: port 2(vnet0) entering learning state Nov 27 21:44:03 spindle warning: [444860.856640] __ratelimit: 928705 callbacks suppressed Nov 27 21:44:03 spindle err: [444860.856729] emulation failed (pagetable) rip 7f3845f36a7b 66 0f 7f 07 66 0f 7f 07 movdqa %xmm0,(%rdi) which we don't emulate. Can you, using the qemu monitor, see where the guest is trying to write? (qemu) info registers (qemu) x/30i $eip - 20 -- error compiling committee.c: too many arguments to function -- 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: 2.6.31.5 x86-64 KVM: 'emulation failed (pagetable) rip 7fb49335da7b 66 0f 7f 07'
On 29 Nov 2009, Avi Kivity uttered the following: 66 0f 7f 07 movdqa %xmm0,(%rdi) which we don't emulate. x86-64 glibc 2.10 memset(), perhaps? On SSE-capable platforms that does a whole bunch of L(SSE0QB): movdqa %xmm0,-0xb0(%rdi) L(SSE0QA): movdqa %xmm0,-0xa0(%rdi) L(SSE0Q9): movdqa %xmm0,-0x90(%rdi) L(SSE0Q8): movdqa %xmm0,-0x80(%rdi) L(SSE0Q7): movdqa %xmm0,-0x70(%rdi) L(SSE0Q6): movdqa %xmm0,-0x60(%rdi) L(SSE0Q5): movdqa %xmm0,-0x50(%rdi) L(SSE0Q4): movdqa %xmm0,-0x40(%rdi) L(SSE0Q3): movdqa %xmm0,-0x30(%rdi) L(SSE0Q2): movdqa %xmm0,-0x20(%rdi) L(SSE0Q1): movdqa %xmm0,-0x10(%rdi) L(SSE0Q0): retq (multiple blocks of this, catering for alignment, I guess) and x86-64 is always SSE-capable. Can you, using the qemu monitor, see where the guest is trying to write? (qemu) info registers (qemu) x/30i $eip - 20 looks like a leaveq, consistently (big flow-of-control change): want a dump of some higher stack frames? (qemu) info registers RAX= RBX=81813a28 RCX= RDX= RSI=0001 RDI=818f4fa8 RBP=81769eb8 RSP=81769eb8 R8 = R9 =81925418 R10=000e R11=000e R12=6db6db6db6db6db7 R13=818f2000 R14=81769fa8 R15=0008c000 RIP=810316f6 RFL=0246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=1 ES =0018 00c09300 DPL=0 DS [-WA] CS =0010 00a09b00 DPL=0 CS64 [-RA] SS =0018 00c09300 DPL=0 DS [-WA] DS =0018 00c09300 DPL=0 DS [-WA] FS = GS = 8800019c5000 LDT= TR =0040 8800019d8140 2087 8b00 DPL=0 TSS64-busy GDT= 8800019c9000 007f IDT= 818f2000 0fff CR0=8005003b CR2=00f57000 CR3=3dc13000 CR4=06b0 DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 FCW=037f FSW= [ST=0] FTW=00 MXCSR= FPR0=0025 FPR1=001b FPR2=12a05f24a800 FPR3=0002540be495 FPR4= FPR5= FPR6= FPR7= XMM00=ff00ff00 XMM01= XMM02= XMM03=00ff XMM04=406e XMM05=3fd8234618ab9d47 XMM06=3fd8234618ab9d47 XMM07=3fec5c5c5c5c5c5c XMM08=4032 XMM09=404e XMM10=405e XMM11= XMM12= XMM13= XMM14= XMM15= (qemu) x/30i $eip - 20 0x810316e2: mov%esp,%ebp 0x810316e4: sti 0x810316e5: leaveq 0x810316e6: retq 0x810316e7: nopw 0x0(%rax,%rax,1) 0x810316f0: push %rbp 0x810316f1: mov%rsp,%rbp 0x810316f4: sti 0x810316f5: hlt 0x810316f6: leaveq 0x810316f7: retq 0x810316f8: nopl 0x0(%rax,%rax,1) 0x81031700: push %rbp 0x81031701: mov%rsp,%rbp 0x81031704: hlt 0x81031705: leaveq 0x81031706: retq 0x81031707: nopw 0x0(%rax,%rax,1) 0x81031710: push %rbp 0x81031711: mov%rsp,%rbp 0x81031714: clts 0x81031716: leaveq 0x81031717: retq 0x81031718: nopl 0x0(%rax,%rax,1) 0x81031720: push %rbp 0x81031721: mov%rsp,%rbp 0x81031724: mov%cr0,%rax 0x81031727: leaveq 0x81031728: retq 0x81031729: nopl 0x0(%rax) -- 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: 2.6.31.5 x86-64 KVM: 'emulation failed (pagetable) rip 7fb49335da7b 66 0f 7f 07'
On 11/29/2009 03:48 PM, Nix wrote: On 29 Nov 2009, Avi Kivity uttered the following: 66 0f 7f 07 movdqa %xmm0,(%rdi) which we don't emulate. x86-64 glibc 2.10 memset(), perhaps? On SSE-capable platforms that does a whole bunch of L(SSE0QB): movdqa %xmm0,-0xb0(%rdi) L(SSE0QA): movdqa %xmm0,-0xa0(%rdi) L(SSE0Q9): movdqa %xmm0,-0x90(%rdi) L(SSE0Q8): movdqa %xmm0,-0x80(%rdi) L(SSE0Q7): movdqa %xmm0,-0x70(%rdi) L(SSE0Q6): movdqa %xmm0,-0x60(%rdi) L(SSE0Q5): movdqa %xmm0,-0x50(%rdi) L(SSE0Q4): movdqa %xmm0,-0x40(%rdi) L(SSE0Q3): movdqa %xmm0,-0x30(%rdi) L(SSE0Q2): movdqa %xmm0,-0x20(%rdi) L(SSE0Q1): movdqa %xmm0,-0x10(%rdi) L(SSE0Q0): retq (multiple blocks of this, catering for alignment, I guess) and x86-64 is always SSE-capable. Most likely, either this or something similar is called on a userspace device driver. Can you check if this is triggered by starting X? If so, we'll have to emulate this instruction, which will be a bitch. -- error compiling committee.c: too many arguments to function -- 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 tip:x86/entry] core: fix user return notifier on fork()
fork() clones all thread_info flags, including TIF_USER_RETURN_NOTIFY; if the
new task is first scheduled on a cpu which doesn't have user return notifiers
set, this causes user return notifiers to trigger without any way of clearing
itself.
This is easy to trigger with a forky workload on the host in parallel with
kvm, resulting in a cpu in an endless loop on the verge of returning to
userspace.
Fix by dropping the TIF_USER_RETURN_NOTIFY immediately after fork.
Signed-off-by: Avi Kivity a...@redhat.com
---
include/linux/user-return-notifier.h |7 +++
kernel/fork.c|2 ++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/include/linux/user-return-notifier.h
b/include/linux/user-return-notifier.h
index b6ac056..9c4a445 100644
--- a/include/linux/user-return-notifier.h
+++ b/include/linux/user-return-notifier.h
@@ -26,6 +26,11 @@ static inline void propagate_user_return_notify(struct
task_struct *prev,
void fire_user_return_notifiers(void);
+static inline void clear_user_return_notifier(struct task_struct *p)
+{
+ clear_tsk_thread_flag(p, TIF_USER_RETURN_NOTIFY);
+}
+
#else
struct user_return_notifier {};
@@ -37,6 +42,8 @@ static inline void propagate_user_return_notify(struct
task_struct *prev,
static inline void fire_user_return_notifiers(void) {}
+static inline void clear_user_return_notifier(struct task_struct *p) {}
+
#endif
#endif
diff --git a/kernel/fork.c b/kernel/fork.c
index 166b8c4..7d4a348 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -64,6 +64,7 @@
#include linux/magic.h
#include linux/perf_event.h
#include linux/posix-timers.h
+#include linux/user-return-notifier.h
#include asm/pgtable.h
#include asm/pgalloc.h
@@ -249,6 +250,7 @@ static struct task_struct *dup_task_struct(struct
task_struct *orig)
goto out;
setup_thread_stack(tsk, orig);
+ clear_user_return_notifier(tsk);
stackend = end_of_stack(tsk);
*stackend = STACK_END_MAGIC;/* for overflow detection */
--
1.6.5.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
Re: kernel bug in kvm_intel
On 11/26/2009 03:35 AM, Andrew Theurer wrote: I just tried testing tip of kvm.git, but unfortunately I think I might be hitting a different problem, where processes run 100% in kernel mode. In my case, cpus 9 and 13 were stuck, running qemu processes. A stack backtrace for both cpus are below. FWIW, kernel.org 2.6.32-rc7 does not have this problem, or the original problem. I just posted a patch fixing this, titled [PATCH tip:x86/entry] core: fix user return notifier on fork(). -- error compiling committee.c: too many arguments to function -- 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] virtio: set pci bus master enable bit
As all virtio devices perform DMA, we must enable bus mastering for them to be spec compliant. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- drivers/virtio/virtio_pci.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c index 28d9cf7..717bae1 100644 --- a/drivers/virtio/virtio_pci.c +++ b/drivers/virtio/virtio_pci.c @@ -648,6 +648,7 @@ static int __devinit virtio_pci_probe(struct pci_dev *pci_dev, goto out_req_regions; pci_set_drvdata(pci_dev, vp_dev); + pci_set_master(pci_dev); /* we use the subsystem vendor/device id as the virtio vendor/device * id. this allows us to use the same PCI vendor/device id for all -- 1.6.5.2.143.g8cc62 -- 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: [Autotest] [KVM-AUTOTEST] KSM-overcommit test v.2 (python version)
On 11/26/2009 12:11 PM, Lukáš Doktor wrote:
Hello Dor,
Thank you for your review. I have few questions about your comments:
--- snip ---
+ stat += Guests memsh = {
+ for vm in lvms:
+ if vm.is_dead():
+ logging.info(Trying to get informations of death VM: %s
+ % vm.name)
+ continue
You can fail the entire test. Afterwards it will be hard to find the
issue.
Well if it's what the community wants, we can change it. We just didn't
want to lose information about the rest of the systems. Perhaps we can
set some DIE flag and after collecting all statistics raise an Error.
I don't think we need to continue testing if some thing as basic as VM
died upon us.
--- snip ---
+ def get_true_pid(vm):
+ pid = vm.process.get_pid()
+ for i in range(1,10):
+ pid = pid + 1
What are you trying to do here? It's seems like a nasty hack that might
fail on load.
qemu has -pifile option. It works fine.
Yes and I'm really sorry for this ugly hack. The qemu command has
changed since the first patch was made. Nowadays the vm.pid returns
PID of the command itself, not the actual qemu process.
We need to have the PID of the actual qemu process, which is executed by
the command with PID vm.pid. That's why first I try finding the qemu
process as the following vm.pid PID. I haven't found another solution
yet (in case we don't want to change the qemu command back in the
framework).
We have tested this solution under heavy process load and either first
or second part always finds the right value.
--- snip ---
+ if (params['ksm_test_size'] == paralel) :
+ vmsc = 1
+ overcommit = 1
+ mem = host_mem
+ # 32bit system adjustment
+ if not params['image_name'].endswith(64):
+ logging.debug(Probably i386 guest architecture, \
+ max allocator mem = 2G)
Better not to relay on the guest name. You can test percentage of the
guest mem.
What do you mean by percentage of the guest mem? This adjustment is
made because the maximum memory for 1 process in 32 bit OS is 2GB.
Testing of the 'image_name' showed to be most reliable method we found.
It's not that important but it should be a convention of kvm autotest.
If that's acceptable, fine, otherwise, each VM will define it in the
config file
--- snip ---
+ # Guest can have more than 2G but kvm mem + 1MB (allocator itself)
+ # can't
+ if (host_mem 2048):
+ mem = 2047
+
+
+ if os.popen(uname -i).readline().startswith(i386):
+ logging.debug(Host is i386 architecture, max guest mem is 2G)
There are bigger 32 bit guests.
How do you mean this note? We are testing whether the host machine is 32
bit. If so, the maximum process allocation is 2GB (similar case to 32
bit guest) but this time the whole qemu process (2GB qemu machine + 64
MB qemu overhead) can't exceeded 2GB.
Still the maximum memory used in test is the same (as we increase the VM
count - host_mem = quest_mem * vm_count; quest_mem is decreased,
vm_count is increased)
i386 guests with PAE mode (additional 4 bits) can have up to 16G ram on
theory.
--- snip ---
+
+ # Copy the allocator.c into guests
.py
yes indeed.
--- snip ---
+ # Let kksmd works (until shared mem rich expected value)
+ shm = 0
+ i = 0
+ cmd = cat/proc/%d/statm % get_true_pid(vm)
+ while shm ksm_size:
+ if i 64:
+ logging.info(get_stat(lvms))
+ raise error.TestError(SHM didn't merged the memory until \
+ the DL on guest: %s% (vm.name))
+ logging.debug(Sleep(%d) % (ksm_size / 200 * perf_ratio))
+ time.sleep(ksm_size / 200 * perf_ratio)
+ try:
+ shm = int(os.popen(cmd).readline().split()[2])
+ shm = shm * 4 / 1024
+ i = i + 1
Either you have nice statistic calculation function or not.
I vote for the first case.
Yes, we are using the statistics function for the output. But in this
case we just need to know the shm value, not to log anything.
If this is a big problem even for others, we can split the statistics
function into 2:
int = _get_stat(vm) - returns shm value
string = get_stat(vm) - Uses _get_stats and creates a nice log output
--- snip ---
+ Check if memory in max loading guest is allright
+ logging.info(Starting phase 3b)
+
+ Kill rest of machine
We should have a function for it for all kvm autotest
you think lsessions[i].close() instead of (status,data) =
lsessions[i].get_command_status_output(exit;,20)?
Yes, it would be better.
+ for i in range(last_vm+1, vmsc):
+ (status,data) = lsessions[i].get_command_status_output(exit;,20)
+ if i == (vmsc-1):
+ logging.info(get_stat([lvms[i]]))
+ lvms[i].destroy(gracefully = False)
--- snip ---
+ def phase_paralel():
+ Paralel page spliting
+ logging.info(Phase 1: Paralel page spliting)
+ # We have to wait until allocator is finished (it waits 5 seconds to
+ # clean the socket
+
The whole function is very similar to phase_separate_first_guest please
refactor them.
Yes, those functions are a bit similar. On the other hand there are
Amount of virtual disks with KVM
Hi all! I'm trying to make a migration of a Xen PV virtual machine to KVM. For this I'm starting a VM with SystemRescueCD [1] of the following way: # /usr/local/kvm/bin/qemu-system-x86_64 -hda /dev/vm/hermes-disk -boot d \ -cdrom /space/isos/systemrescuecd-x86-1.3.2.iso -m 512 -daemonize -vnc \ :2 -k es -localtime -hdb hermes-raiz.raw -hdc hermes-var.raw -net \ nic,vlan=0,macaddr=00:16:3e:00:00:34 -net tap Where hermes-disk is the disk that will use the VM in the destination host, and hermes-raiz.raw and hermes-var.raw are the raw partitions that was using the Xen PV virtual machine in source host. My idea is to create the partitions in hermes-disk, to mount the raw partitions and to do cp -a to the partitions created in hermes-disk, but after boot only hermes-disk and hermes-raiz.raw are exported (like sda and sdb). Which can be the problem? Using VIRTIO for the raw partitions I didn't have this problem. Something similar happened to me with a ISO of Debian netinstall. It doesn't boot passing three disks with -hdX. But making the installation with netinstall and two disks and after it have finished and have booted and added a third disk, the system boots without problems. Will it be by the same cause? Thanks in advance for your reply. Regards, Daniel [1] http://www.sysresccd.org/Main_Page -- Fingerprint: BFB3 08D6 B4D1 31B2 72B9 29CE 6696 BF1B 14E6 1D37 Powered by Debian GNU/Linux Squeeze - Linux user #188.598 signature.asc Description: Digital signature
usb_add crashes stable kvm-0.11.0
On 29 Nov 2009, Avi Kivity stated: Most likely, either this or something similar is called on a userspace device driver. Can you check if this is triggered by starting X? Damn thing hasn't recurred yet. I'll keep trying. (Obviously I'm not properly replicating my original failure case.) One qemu-kvm-specific bug, definitely non-kernel-related, is this crash, frequently encountered when hotadding more than one USB device (to an XP guest, as it happens, but that doesn't look relevant here): #1 usb_host_device_open (devname=0x126ee25 13fe:3100) at usb-linux.c:1000 #2 0x0040adf2 in usb_device_add (devname=0x126ee20 host:13fe:3100, is_hotplug=1) at /usr/src/qemu/x86_64-spindle/vl.c:2562 #3 0x004142b3 in monitor_handle_command (mon=value optimized out, cmdline=value optimized out) at /usr/src/qemu/x86_64-spindle/monitor.c:2870 #4 0x00414429 in monitor_command_cb (mon=0xc51390, cmdline=0x5 Address 0x5 out of bounds, opaque=0x7fffbaa7) at /usr/src/qemu/x86_64-spindle/monitor.c:3160 #5 0x00488b97 in readline_handle_byte (rs=0xc517f0, ch=value optimized out) at readline.c:369 #6 0x0041449b in monitor_read (opaque=0x72636e456d756d69, buf=0x7fffc3a0 \r\303\377\377\377\177, size=1) at /usr/src/qemu/x86_64-spindle/monitor.c:3146 #7 0x004af2a4 in mux_chr_read (opaque=0xc51170, buf=0x7fffc3a0 \r\303\377\377\377\177, size=value optimized out) at qemu-char.c:425 #8 0x004af723 in tcp_chr_read (opaque=value optimized out) at qemu-char.c:2006 #9 0x0040a159 in main_loop_wait (timeout=value optimized out) at /usr/src/qemu/x86_64-spindle/vl.c:4188 #10 0x00421e6a in kvm_main_loop () at /usr/src/qemu/x86_64-spindle/qemu-kvm.c:2079 #11 0x0040e7f5 in main_loop (argc=value optimized out, argv=value optimized out, envp=value optimized out) at /usr/src/qemu/x86_64-spindle/vl.c:4393 #12 main (argc=value optimized out, argv=value optimized out, envp=value optimized out) at /usr/src/qemu/x86_64-spindle/vl.c:6263 Something skewy with the monitor I suspect. -- 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: 2.6.31.5 x86-64 KVM: 'emulation failed (pagetable) rip 7fb49335da7b 66 0f 7f 07'
On 29 Nov 2009, Avi Kivity stated: Most likely, either this or something similar is called on a userspace device driver. Can you check if this is triggered by starting X? *sigh* I just wasted twenty minutes trying to find some way, *any* way to not start X under Ubuntu Karmic, so as to test this. None is evident. I can't even figure out what and where in upstart's horrific dependency tangle is starting X in the first place: deleting suspicious-looking things from rc*.d has no effect at all. I can't even tell if rc*.d is still used, nor if the concept of runlevel is even meaningful any longer. There are lots of things googleable that claim to say how to do this, but all relate to the non-dependency-based inittab-emulating method used in previous Ubuntu versions. Anyone know? -- 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] KVM test: Add a subtest params_verify
This patch will test following parameters of a VM:
1) count of CPU, hard disks and NICs
2) memory size
3) model of hard disks and NICs
4) NICs' mac address
5) UUID and serial number (if defined the command in config file)
Signed-off-by: Yolkfull Chow yz...@redhat.com
---
client/bin/harness_standalone.py|2 +-
client/tests/kvm/kvm_tests.cfg.sample | 11 +++
client/tests/kvm/kvm_vm.py | 39 +++
client/tests/kvm/tests/params_verify.py | 110 +++
4 files changed, 161 insertions(+), 1 deletions(-)
create mode 100644 client/tests/kvm/tests/params_verify.py
diff --git a/client/bin/harness_standalone.py b/client/bin/harness_standalone.py
index 4ec7cd2..c70c09b 100644
--- a/client/bin/harness_standalone.py
+++ b/client/bin/harness_standalone.py
@@ -36,7 +36,7 @@ class harness_standalone(harness.harness):
if os.path.exists('/etc/event.d'):
# NB: assuming current runlevel is default
initdefault = utils.system_output('/sbin/runlevel').split()[1]
-else if os.path.exists('/etc/inittab'):
+elif os.path.exists('/etc/inittab'):
initdefault = utils.system_output('grep :initdefault:
/etc/inittab')
initdefault = initdefault.split(':')[1]
else:
diff --git a/client/tests/kvm/kvm_tests.cfg.sample
b/client/tests/kvm/kvm_tests.cfg.sample
index feffb8d..94763c5 100644
--- a/client/tests/kvm/kvm_tests.cfg.sample
+++ b/client/tests/kvm/kvm_tests.cfg.sample
@@ -243,6 +243,10 @@ variants:
kill_vm = yes
kill_vm_gracefully = no
+- params_verify:
+type = params_verify
+catch_uuid_cmd = dmidecode | awk -F: '/UUID/ {print $2}'
+
# NICs
variants:
@@ -269,6 +273,8 @@ variants:
shell_port = 22
file_transfer_client = scp
file_transfer_port = 22
+mem_chk_cmd = dmidecode -t 17 | awk -F: '/Size/ {print $2}'
+cpu_chk_cmd = grep -c processor /proc/cpuinfo
variants:
- Fedora:
@@ -542,6 +548,9 @@ variants:
# This ISO will be used for all tests except install:
cdrom = windows/winutils.iso
+cpu_chk_cmd = echo %NUMBER_OF_PROCESSORS%
+mem_chk_cmd = wmic memphysical
+
migrate:
migration_test_command = ver vol
migration_bg_command = start ping -t localhost
@@ -583,6 +592,8 @@ variants:
reference_cmd = wmic diskdrive list brief
find_pci_cmd = wmic diskdrive list brief
pci_test_cmd = echo select disk 1 dt echo online dt
echo detail disk dt echo exit dt diskpart /s dt
+params_verify:
+catch_uuid_cmd =
variants:
- Win2000:
diff --git a/client/tests/kvm/kvm_vm.py b/client/tests/kvm/kvm_vm.py
index 100b567..cc314d4 100755
--- a/client/tests/kvm/kvm_vm.py
+++ b/client/tests/kvm/kvm_vm.py
@@ -821,3 +821,42 @@ class VM:
return self.uuid
else:
return self.params.get(uuid, None)
+
+
+def get_cpu_count(self):
+
+Get the cpu count of the VM.
+
+try:
+session = self.remote_login()
+if session:
+cmd = self.params.get(cpu_chk_cmd)
+s, count = session.get_command_status_output(cmd)
+if s == 0:
+return int(count)
+return None
+finally:
+session.close()
+
+
+def get_memory_size(self):
+
+Get memory size of the VM.
+
+try:
+session = self.remote_login()
+if session:
+cmd = self.params.get(mem_chk_cmd)
+s, mem_str = session.get_command_status_output(cmd)
+if s != 0:
+return None
+mem = re.findall(([0-9][0-9][0-9]+), mem_str)
+mem_size = 0
+for m in mem:
+mem_size += int(m)
+if not MB in mem_str:
+mem_size /= 1024
+return int(mem_size)
+return None
+finally:
+session.close()
diff --git a/client/tests/kvm/tests/params_verify.py
b/client/tests/kvm/tests/params_verify.py
new file mode 100644
index 000..a30a91d
--- /dev/null
+++ b/client/tests/kvm/tests/params_verify.py
@@ -0,0 +1,110 @@
+import re, string, logging
+from autotest_lib.client.common_lib import error
+import kvm_test_utils, kvm_utils
+
+def run_params_verify(test, params, env):
+
+Verify all parameters in KVM command line:
+1) Log into the guest
+2) Verify whether cpu counts ,memory size, nics' model,
+ count and drives' format count, drive_serial, UUID
+3) Verify all nic cards' macaddr
+
+@param test: kvm test object
+@param params: Dictionary with the test parameters
+@param env: Dictionary with test environment.
+
+vm = kvm_test_utils.get_living_vm(env,
