Re: [Qemu-devel] Memory sync algorithm during migration
On 22 nov. 2011, at 14:04, Oliver Hookins wrote: On Tue, Nov 22, 2011 at 10:31:58AM +0100, ext Juan Quintela wrote: Oliver Hookins oliver.hook...@nokia.com wrote: On Tue, Nov 15, 2011 at 11:47:58AM +0100, ext Juan Quintela wrote: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp wrote: Adding qemu-devel ML to CC. Your question should have been sent to qemu-devel ML because the logic is implemented in QEMU, not KVM. (2011/11/11 1:35), Oliver Hookins wrote: Hi, I am performing some benchmarks on KVM migration on two different types of VM. One has 4GB RAM and the other 32GB. More or less idle, the 4GB VM takes about 20 seconds to migrate on our hardware while the 32GB VM takes about a minute. With a reasonable amount of memory activity going on (in the hundreds of MB per second) the 32GB VM takes 3.5 minutes to migrate, but the 4GB VM never completes. Intuitively this tells me there is some watermarking of dirty pages going on that is not particularly efficient when the dirty pages ratio is high compared to total memory, but I may be completely incorrect. You can change the ratio IIRC. Hopefully, someone who knows well about QEMU will tell you better ways. Takuya Could anybody fill me in on what might be going on here? We're using libvirt 0.8.2 and kvm-83-224.el5.centos.1 This is pretty old qemu/kvm code base. In principle, it makes no sense that with 32GB RAM migration finishes, and with 4GB RAM it is unable (intuitively it should be, if ever, the other way around). Do you have an easy test that makes the problem easily reproducible? Have you tried ustream qemu.git? (some improvements on that department). I've just tried the qemu-kvm 0.14.1 tag which seems to be the latest that builds on my platform. For some strange reason migrations always seem to fail in one direction with Unknown savevm section or instance 'hpet' 0 messages. What is your platform? This seems like you are running with hpet in one side, but without it in the other. What command line are you using? Yes, my mistake. We were also testing later kernels and my test machines managed to get out of sync. One had support for hpet clocksource but the other one didn't. This seems to point to different migration protocols on either end but they are both running the same version of qemu-kvm I built. Does this ring any bells for anyone? Command line mismatch. But, what is your platform? CentOS5.6. Now running the VMs through qemu-kvm 0.14.1, unloaded migrations take about half the time but with memory I/O load now both VMs never complete the migration. In practical terms I'm writing about 50MB/s into memory and we have a 10Gbps network (and I've seen real speeds up to 8-9Gbps on the wire) so there should be enough capacity to sync up the dirty pages. So now the 32GB and 4GB VMs have matching behaviour (which makes more sense) but I'm not any closer to figuring out what is going on. Did you modify the max downtime? The default is 30 ms. At 8 Gbps, this only allows to send 30 MB of data on the wire. -- Pierre Riteau -- PhD student, Myriads team, IRISA, Rennes, France http://perso.univ-rennes1.fr/pierre.riteau/ -- 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: [Qemu-devel] Memory sync algorithm during migration
On 22 nov. 2011, at 14:04, Oliver Hookins wrote: On Tue, Nov 22, 2011 at 10:31:58AM +0100, ext Juan Quintela wrote: Oliver Hookins oliver.hook...@nokia.com wrote: On Tue, Nov 15, 2011 at 11:47:58AM +0100, ext Juan Quintela wrote: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp wrote: Adding qemu-devel ML to CC. Your question should have been sent to qemu-devel ML because the logic is implemented in QEMU, not KVM. (2011/11/11 1:35), Oliver Hookins wrote: Hi, I am performing some benchmarks on KVM migration on two different types of VM. One has 4GB RAM and the other 32GB. More or less idle, the 4GB VM takes about 20 seconds to migrate on our hardware while the 32GB VM takes about a minute. With a reasonable amount of memory activity going on (in the hundreds of MB per second) the 32GB VM takes 3.5 minutes to migrate, but the 4GB VM never completes. Intuitively this tells me there is some watermarking of dirty pages going on that is not particularly efficient when the dirty pages ratio is high compared to total memory, but I may be completely incorrect. You can change the ratio IIRC. Hopefully, someone who knows well about QEMU will tell you better ways. Takuya Could anybody fill me in on what might be going on here? We're using libvirt 0.8.2 and kvm-83-224.el5.centos.1 This is pretty old qemu/kvm code base. In principle, it makes no sense that with 32GB RAM migration finishes, and with 4GB RAM it is unable (intuitively it should be, if ever, the other way around). Do you have an easy test that makes the problem easily reproducible? Have you tried ustream qemu.git? (some improvements on that department). I've just tried the qemu-kvm 0.14.1 tag which seems to be the latest that builds on my platform. For some strange reason migrations always seem to fail in one direction with Unknown savevm section or instance 'hpet' 0 messages. What is your platform? This seems like you are running with hpet in one side, but without it in the other. What command line are you using? Yes, my mistake. We were also testing later kernels and my test machines managed to get out of sync. One had support for hpet clocksource but the other one didn't. This seems to point to different migration protocols on either end but they are both running the same version of qemu-kvm I built. Does this ring any bells for anyone? Command line mismatch. But, what is your platform? CentOS5.6. Now running the VMs through qemu-kvm 0.14.1, unloaded migrations take about half the time but with memory I/O load now both VMs never complete the migration. In practical terms I'm writing about 50MB/s into memory and we have a 10Gbps network (and I've seen real speeds up to 8-9Gbps on the wire) so there should be enough capacity to sync up the dirty pages. So now the 32GB and 4GB VMs have matching behaviour (which makes more sense) but I'm not any closer to figuring out what is going on. You say you write 50 MB/s in memory, but this does not provide enough information to analyze the problem. How distributed in memory are these writes? If your writes are not restricted to a small memory region, they could dirty many pages. In this case, live migration would have to transfer much more than 50 MB/s of pages to the destination. -- Pierre Riteau -- PhD student, Myriads team, IRISA, Rennes, France http://perso.univ-rennes1.fr/pierre.riteau/ -- 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/8] use eventfd for iothread
When this was merged in qemu-kvm/master (commit
6249f61a891b6b003531ca4e459c3a553faa82bc) it removed Avi's compile fix when
!CONFIG_EVENTFD (db311e8619d310bd7729637b702581d3d8565049).
So current master fails to build:
CCosdep.o
cc1: warnings being treated as errors
osdep.c: In function 'qemu_eventfd':
osdep.c:296: error: unused variable 'ret'
make: *** [osdep.o] Error 1
On 22 févr. 2010, at 22:26, Marcelo Tosatti wrote:
From: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com
---
osdep.c | 32
qemu-common.h |1 +
vl.c |9 +
3 files changed, 38 insertions(+), 4 deletions(-)
diff --git a/osdep.c b/osdep.c
index 9059f01..9e4b17b 100644
--- a/osdep.c
+++ b/osdep.c
@@ -37,6 +37,10 @@
#include sys/statvfs.h
#endif
+#ifdef CONFIG_EVENTFD
+#include sys/eventfd.h
+#endif
+
#ifdef _WIN32
#include windows.h
#elif defined(CONFIG_BSD)
@@ -281,6 +285,34 @@ ssize_t qemu_write_full(int fd, const void *buf, size_t
count)
#ifndef _WIN32
/*
+ * Creates an eventfd that looks like a pipe and has EFD_CLOEXEC set.
+ */
+int qemu_eventfd(int fds[2])
+{
+int ret;
+
+#ifdef CONFIG_EVENTFD
+ret = eventfd(0, 0);
+if (ret = 0) {
+fds[0] = ret;
+qemu_set_cloexec(ret);
+if ((fds[1] = dup(ret)) == -1) {
+close(ret);
+return -1;
+}
+qemu_set_cloexec(fds[1]);
+return 0;
+}
+
+if (errno != ENOSYS) {
+return -1;
+}
+#endif
+
+return qemu_pipe(fds);
+}
+
+/*
* Creates a pipe with FD_CLOEXEC set on both file descriptors
*/
int qemu_pipe(int pipefd[2])
diff --git a/qemu-common.h b/qemu-common.h
index b09f717..c941006 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -170,6 +170,7 @@ ssize_t qemu_write_full(int fd, const void *buf, size_t
count)
void qemu_set_cloexec(int fd);
#ifndef _WIN32
+int qemu_eventfd(int pipefd[2]);
int qemu_pipe(int pipefd[2]);
#endif
diff --git a/vl.c b/vl.c
index 98918ac..1957018 100644
--- a/vl.c
+++ b/vl.c
@@ -3211,14 +3211,15 @@ static int io_thread_fd = -1;
static void qemu_event_increment(void)
{
-static const char byte = 0;
+/* Write 8 bytes to be compatible with eventfd. */
+static uint64_t val = 1;
ssize_t ret;
if (io_thread_fd == -1)
return;
do {
-ret = write(io_thread_fd, byte, sizeof(byte));
+ret = write(io_thread_fd, val, sizeof(val));
} while (ret 0 errno == EINTR);
/* EAGAIN is fine, a read must be pending. */
@@ -3235,7 +3236,7 @@ static void qemu_event_read(void *opaque)
ssize_t len;
char buffer[512];
-/* Drain the notify pipe */
+/* Drain the notify pipe. For eventfd, only 8 bytes will be read. */
do {
len = read(fd, buffer, sizeof(buffer));
} while ((len == -1 errno == EINTR) || len == sizeof(buffer));
@@ -3246,7 +3247,7 @@ static int qemu_event_init(void)
int err;
int fds[2];
-err = qemu_pipe(fds);
+err = qemu_eventfd(fds);
if (err == -1)
return -errno;
--
1.6.6
--
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
--
Pierre Riteau -- PhD student, Myriads team, IRISA, Rennes, France
http://perso.univ-rennes1.fr/pierre.riteau/
--
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: Seabios incompatible with Linux 2.6.26 host?
On 8 févr. 2010, at 13:21, Avi Kivity wrote: On 02/08/2010 01:13 PM, Jan Kiszka wrote: I confirm that this exception does not happen with kvm-kmod-2.6.33-rc6. However, after I run and stop a guest VM just executing the bios sequence (no disk/CD image attached), I get this kind of errors on the host when untar a small archive (less than 1MB, about 300 files): Feb 8 12:00:32 paraquad-7 kernel: [ 200.073865] Bad page state in process 'gzip' Feb 8 12:00:32 paraquad-7 kernel: [ 200.073867] page:e200040c4638 flags:0x021c mapping: mapcount:0 count:0 Feb 8 12:00:32 paraquad-7 kernel: [ 200.102991] Trying to fix it up, but a reboot is needed Feb 8 12:00:32 paraquad-7 kernel: [ 200.102992] Backtrace: Feb 8 12:00:32 paraquad-7 kernel: [ 200.129821] Pid: 3559, comm: gzip Tainted: P 2.6.26-2-amd64 #1 Feb 8 12:00:32 paraquad-7 kernel: [ 200.143267] Feb 8 12:00:32 paraquad-7 kernel: [ 200.143268] Call Trace: Feb 8 12:00:32 paraquad-7 kernel: [ 200.156024] [8022f0d2] hrtick_set+0x88/0xf7 Feb 8 12:00:32 paraquad-7 kernel: [ 200.167250] [8027504d] bad_page+0x6b/0x95 Feb 8 12:00:32 paraquad-7 kernel: [ 200.179879] [80276482] get_page_from_freelist+0x3e1/0x606 Feb 8 12:00:32 paraquad-7 kernel: [ 200.195345] [80276929] __alloc_pages_internal+0xd6/0x3bf Feb 8 12:00:32 paraquad-7 kernel: [ 200.210580] [80281707] handle_mm_fault+0x244/0x867 Feb 8 12:00:32 paraquad-7 kernel: [ 200.223694] [8027313a] filemap_fault+0x1c2/0x33c Feb 8 12:00:32 paraquad-7 kernel: [ 200.237948] [80221fbc] do_page_fault+0x5d8/0x9c8 Feb 8 12:00:32 paraquad-7 kernel: [ 200.251793] [8042a599] error_exit+0x0/0x60 Feb 8 12:00:32 paraquad-7 kernel: [ 200.265754] [80270df1] file_read_actor+0x52/0x125 Feb 8 12:00:32 paraquad-7 kernel: [ 200.278595] [802764fb] get_page_from_freelist+0x45a/0x606 Feb 8 12:00:32 paraquad-7 kernel: [ 200.294022] [80272c03] generic_file_aio_read+0x29e/0x4ae Feb 8 12:00:32 paraquad-7 kernel: [ 200.309319] [8029ae47] do_sync_read+0xc9/0x10c Feb 8 12:00:32 paraquad-7 kernel: [ 200.322816] [80246221] autoremove_wake_function+0x0/0x2e Feb 8 12:00:32 paraquad-7 kernel: [ 200.338051] [80221fbc] do_page_fault+0x5d8/0x9c8 Feb 8 12:00:32 paraquad-7 kernel: [ 200.351919] [8029b638] vfs_read+0xaa/0x152 Feb 8 12:00:32 paraquad-7 kernel: [ 200.366108] [8029ba19] sys_read+0x45/0x6e Feb 8 12:00:32 paraquad-7 kernel: [ 200.378750] [8020beca] system_call_after_swapgs+0x8a/0x8f Haven't seen this before. Can you reproduce it with a) kvm-kmod-2.6.32.7? Same problem with this version loaded in the 2.6.26 kernel. b) a host kernel= 2.6.27? Good guess - perhaps we are busted without mmu notifiers. For b), please ensure CONFIG_MMU_NOTIFIER is enabled in the host kernel configuration. Very good guess indeed! 2.6.27 with KVM enabled (so CONFIG_MMU_NOTIFIER=y) and kvm-kmod-2.6.33-rc6 works OK. 2.6.27 with KVM disabled (so CONFIG_MMU_NOTIFIER is also disabled) and kvm-kmod-2.6.33-rc6 shows the Bad page state errors. -- Pierre Riteau -- PhD student, Myriads team, IRISA, Rennes, France http://perso.univ-rennes1.fr/pierre.riteau/ -- 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: Seabios incompatible with Linux 2.6.26 host?
On 5 févr. 2010, at 16:07, Jan Kiszka wrote: Pierre Riteau wrote: On 5 févr. 2010, at 15:46, Jan Kiszka wrote: Pierre Riteau wrote: On 4 févr. 2010, at 15:34, Pierre Riteau wrote: Hello, I'm having trouble running the latest qemu-kvm code on Debian Lenny (Linux 2.6.26). qemu-kvm dies with an error like this one: exception 13 (0) rax 0010 rbx 8c00 rcx 6ebe rdx 000c8c00 rsi e201 rdi 000c rsp 6eb4 rbp e201 r8 r9 r10 r11 r12 r13 r14 r15 rip 000fdeb0 rflags 00033002 cs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ds (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) es (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ss (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) fs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) gs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) tr (feffd000/2088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt (/ p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) gdt f7a20/37 idt f8aa0/0 cr0 10 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 I think I traced back the issue to the switch from Bochs BIOS to Seabios. By forcing the usage of Bochs BIOS 5f08bb45861f54be478b25075b90d2406a0f8bb3 works, while it dies without the -bios override. Unfortunately, newer versions don't seem to work with Bochs BIOS. Upgrading the host kernel to 2.6.32 (Debian Squeeze) solves the issue. No problem on Fedora 12 as well. Am I the only one to see this issue? The oldest kernels I've running here are 2.6.27. They all run kvm-kmod, and they are all happy (mostly). Are you using the KVM support 2.6.26 provided or are you on some recent kvm-kmod? The latter is highly recommended for tons of reasons. Jan I use the KVM modules provided by the distribution. Then it makes some sense to try with kvm-kmod first. I do not know what KVM patches debian people back-ported to their kernel, maybe you run into long-fixed bugs. I confirm that this exception does not happen with kvm-kmod-2.6.33-rc6. However, after I run and stop a guest VM just executing the bios sequence (no disk/CD image attached), I get this kind of errors on the host when untar a small archive (less than 1MB, about 300 files): Feb 8 12:00:32 paraquad-7 kernel: [ 200.073865] Bad page state in process 'gzip' Feb 8 12:00:32 paraquad-7 kernel: [ 200.073867] page:e200040c4638 flags:0x021c mapping: mapcount:0 count:0 Feb 8 12:00:32 paraquad-7 kernel: [ 200.102991] Trying to fix it up, but a reboot is needed Feb 8 12:00:32 paraquad-7 kernel: [ 200.102992] Backtrace: Feb 8 12:00:32 paraquad-7 kernel: [ 200.129821] Pid: 3559, comm: gzip Tainted: P 2.6.26-2-amd64 #1 Feb 8 12:00:32 paraquad-7 kernel: [ 200.143267] Feb 8 12:00:32 paraquad-7 kernel: [ 200.143268] Call Trace: Feb 8 12:00:32 paraquad-7 kernel: [ 200.156024] [8022f0d2] hrtick_set+0x88/0xf7 Feb 8 12:00:32 paraquad-7 kernel: [ 200.167250] [8027504d] bad_page+0x6b/0x95 Feb 8 12:00:32 paraquad-7 kernel: [ 200.179879] [80276482] get_page_from_freelist+0x3e1/0x606 Feb 8 12:00:32 paraquad-7 kernel: [ 200.195345] [80276929] __alloc_pages_internal+0xd6/0x3bf Feb 8 12:00:32 paraquad-7 kernel: [ 200.210580] [80281707] handle_mm_fault+0x244/0x867 Feb 8 12:00:32 paraquad-7 kernel: [ 200.223694] [8027313a] filemap_fault+0x1c2/0x33c Feb 8 12:00:32 paraquad-7 kernel: [ 200.237948] [80221fbc] do_page_fault+0x5d8/0x9c8 Feb 8 12:00:32 paraquad-7 kernel: [ 200.251793] [8042a599] error_exit+0x0/0x60 Feb 8 12:00:32 paraquad-7 kernel: [ 200.265754] [80270df1] file_read_actor+0x52/0x125 Feb 8 12:00:32 paraquad-7 kernel: [ 200.278595] [802764fb] get_page_from_freelist+0x45a/0x606 Feb 8 12:00:32 paraquad-7 kernel: [ 200.294022] [80272c03] generic_file_aio_read+0x29e/0x4ae Feb 8 12:00:32 paraquad-7 kernel: [ 200.309319] [8029ae47] do_sync_read+0xc9/0x10c Feb 8 12:00:32 paraquad-7 kernel: [ 200.322816] [80246221] autoremove_wake_function+0x0/0x2e Feb 8 12:00:32 paraquad-7 kernel: [ 200.338051] [80221fbc] do_page_fault+0x5d8/0x9c8 Feb 8 12:00:32 paraquad-7 kernel: [ 200.351919] [8029b638] vfs_read+0xaa/0x152 Feb 8 12:00:32 paraquad-7 kernel: [ 200.366108] [8029ba19] sys_read+0x45/0x6e Feb 8 12:00:32 paraquad-7 kernel: [ 200.378750] [8020beca] system_call_after_swapgs+0x8a/0x8f -- Pierre Riteau
Re: Seabios incompatible with Linux 2.6.26 host?
On 4 févr. 2010, at 15:34, Pierre Riteau wrote: Hello, I'm having trouble running the latest qemu-kvm code on Debian Lenny (Linux 2.6.26). qemu-kvm dies with an error like this one: exception 13 (0) rax 0010 rbx 8c00 rcx 6ebe rdx 000c8c00 rsi e201 rdi 000c rsp 6eb4 rbp e201 r8 r9 r10 r11 r12 r13 r14 r15 rip 000fdeb0 rflags 00033002 cs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ds (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) es (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ss (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) fs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) gs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) tr (feffd000/2088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt (/ p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) gdt f7a20/37 idt f8aa0/0 cr0 10 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 I think I traced back the issue to the switch from Bochs BIOS to Seabios. By forcing the usage of Bochs BIOS 5f08bb45861f54be478b25075b90d2406a0f8bb3 works, while it dies without the -bios override. Unfortunately, newer versions don't seem to work with Bochs BIOS. Upgrading the host kernel to 2.6.32 (Debian Squeeze) solves the issue. No problem on Fedora 12 as well. Am I the only one to see this issue? -- Pierre Riteau -- PhD student, Myriads team, IRISA, Rennes, France http://perso.univ-rennes1.fr/pierre.riteau/ -- 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: Seabios incompatible with Linux 2.6.26 host?
On 5 févr. 2010, at 15:46, Jan Kiszka wrote: Pierre Riteau wrote: On 4 févr. 2010, at 15:34, Pierre Riteau wrote: Hello, I'm having trouble running the latest qemu-kvm code on Debian Lenny (Linux 2.6.26). qemu-kvm dies with an error like this one: exception 13 (0) rax 0010 rbx 8c00 rcx 6ebe rdx 000c8c00 rsi e201 rdi 000c rsp 6eb4 rbp e201 r8 r9 r10 r11 r12 r13 r14 r15 rip 000fdeb0 rflags 00033002 cs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ds (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) es (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ss (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) fs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) gs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) tr (feffd000/2088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt (/ p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) gdt f7a20/37 idt f8aa0/0 cr0 10 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 I think I traced back the issue to the switch from Bochs BIOS to Seabios. By forcing the usage of Bochs BIOS 5f08bb45861f54be478b25075b90d2406a0f8bb3 works, while it dies without the -bios override. Unfortunately, newer versions don't seem to work with Bochs BIOS. Upgrading the host kernel to 2.6.32 (Debian Squeeze) solves the issue. No problem on Fedora 12 as well. Am I the only one to see this issue? The oldest kernels I've running here are 2.6.27. They all run kvm-kmod, and they are all happy (mostly). Are you using the KVM support 2.6.26 provided or are you on some recent kvm-kmod? The latter is highly recommended for tons of reasons. Jan I use the KVM modules provided by the distribution. -- Pierre Riteau -- PhD student, Myriads team, IRISA, Rennes, France http://perso.univ-rennes1.fr/pierre.riteau/ -- 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
Seabios incompatible with Linux 2.6.26 host?
Hello, I'm having trouble running the latest qemu-kvm code on Debian Lenny (Linux 2.6.26). qemu-kvm dies with an error like this one: exception 13 (0) rax 0010 rbx 8c00 rcx 6ebe rdx 000c8c00 rsi e201 rdi 000c rsp 6eb4 rbp e201 r8 r9 r10 r11 r12 r13 r14 r15 rip 000fdeb0 rflags 00033002 cs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ds (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) es (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ss (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) fs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) gs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) tr (feffd000/2088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt (/ p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) gdt f7a20/37 idt f8aa0/0 cr0 10 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 I think I traced back the issue to the switch from Bochs BIOS to Seabios. By forcing the usage of Bochs BIOS 5f08bb45861f54be478b25075b90d2406a0f8bb3 works, while it dies without the -bios override. Unfortunately, newer versions don't seem to work with Bochs BIOS. Upgrading the host kernel to 2.6.32 (Debian Squeeze) solves the issue. No problem on Fedora 12 as well. -- Pierre Riteau -- PhD student, Myriads team, IRISA, Rennes, France http://perso.univ-rennes1.fr/pierre.riteau/ -- 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] configure: Correct KVM options in help output
On 10 janv. 2010, at 15:02, Avi Kivity wrote: On 12/01/2009 03:53 PM, Pierre Riteau wrote: Signed-off-by: Pierre Riteaupierre.rit...@irisa.fr --- configure |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/configure b/configure index 376c458..85f7b5e 100755 --- a/configure +++ b/configure @@ -723,10 +723,10 @@ echo --disable-bluez disable bluez stack connectivity echo --enable-bluez enable bluez stack connectivity echo --disable-kvmdisable KVM acceleration support echo --enable-kvm enable KVM acceleration support -echo --disable-cap-kvm-pitdisable KVM pit support -echo --enable-cap-kvm-pit enable KVM pit support -echo --disable-cap-device-assignmentdisable KVM device assignment support -echo --enable-cap-device-assignment enable KVM device assignment support +echo --disable-kvm-cap-pitdisable KVM pit support +echo --enable-kvm-cap-pit enable KVM pit support +echo --disable-kvm-cap-device-assignmentdisable KVM device assignment support +echo --enable-kvm-cap-device-assignment enable KVM device assignment support echo --disable-nptl disable usermode NPTL support echo --enable-nptlenable usermode NPTL support echo --enable-system enable all system emulation targets Not sure the new names are any better than the old ones. I'm not sure I understand... I fixed the names in the help output to make them consistent with the options actually recognized by configure. If you don't like the names you are free to change them: just make sure that both the code and the help text are modified. -- Pierre Riteau -- http://perso.univ-rennes1.fr/pierre.riteau/ -- 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] configure: Correct KVM options in help output
Signed-off-by: Pierre Riteau pierre.rit...@irisa.fr --- configure |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/configure b/configure index 81c44e8..4254485 100755 --- a/configure +++ b/configure @@ -756,10 +756,10 @@ echo --disable-bluez disable bluez stack connectivity echo --enable-bluez enable bluez stack connectivity echo --disable-kvmdisable KVM acceleration support echo --enable-kvm enable KVM acceleration support -echo --disable-cap-kvm-pitdisable KVM pit support -echo --enable-cap-kvm-pit enable KVM pit support -echo --disable-cap-device-assignmentdisable KVM device assignment support -echo --enable-cap-device-assignment enable KVM device assignment support +echo --disable-kvm-cap-pitdisable KVM pit support +echo --enable-kvm-cap-pit enable KVM pit support +echo --disable-kvm-cap-device-assignmentdisable KVM device assignment support +echo --enable-kvm-cap-device-assignment enable KVM device assignment support echo --disable-nptl disable usermode NPTL support echo --enable-nptlenable usermode NPTL support echo --enable-system enable all system emulation targets -- 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: [PATCH] configure: Correct KVM options in help output
On 1 déc. 2009, at 14:53, Pierre Riteau wrote: Signed-off-by: Pierre Riteau pierre.rit...@irisa.fr --- configure |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/configure b/configure index 376c458..85f7b5e 100755 --- a/configure +++ b/configure @@ -723,10 +723,10 @@ echo --disable-bluez disable bluez stack connectivity echo --enable-bluez enable bluez stack connectivity echo --disable-kvmdisable KVM acceleration support echo --enable-kvm enable KVM acceleration support -echo --disable-cap-kvm-pitdisable KVM pit support -echo --enable-cap-kvm-pit enable KVM pit support -echo --disable-cap-device-assignmentdisable KVM device assignment support -echo --enable-cap-device-assignment enable KVM device assignment support +echo --disable-kvm-cap-pitdisable KVM pit support +echo --enable-kvm-cap-pit enable KVM pit support +echo --disable-kvm-cap-device-assignmentdisable KVM device assignment support +echo --enable-kvm-cap-device-assignment enable KVM device assignment support echo --disable-nptl disable usermode NPTL support echo --enable-nptlenable usermode NPTL support echo --enable-system enable all system emulation targets -- 1.6.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 I think this patch is still valid... -- Pierre Riteau -- http://perso.univ-rennes1.fr/pierre.riteau/ -- 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: libvirk KVM save (migrate) terribly slow
On 10 déc. 2009, at 12:44, Daniel P. Berrange wrote: On Thu, Dec 10, 2009 at 08:05:12AM +0100, Nikola Ciprich wrote: Hi, I noticed that using libvirt to save running domain is terribly slow, I mean it can take even 10 minutes to save VM with 2GB RAM, although the host is almost idle (8CPU, 16GB RAM). If I understand correctly, libvirt first pauses the vm and then migrates it to file (optionally through gzip). Restoring it back to running state is almost instant. I guess this is not what should be expected, is there something particular I should check? This matches behaviour that I see when saving VMs. QEMU takes a really very long time to save itself using migrate exec:. It is not CPU limited even in gzip mode - there is near zero CPU usage while this is going on. QEMU just seems to be very slow at sending the data. I've not had time to investigate whether this is a flaw in QEMU's exec: migration handling, or whether it is being hurt by too small pipe buffers, or something else entirely. I must say I'm not entirely convinced that it is a good idea for QEMU to be mixing use of FILE * / popen, with non-blocking I/O, but that could be a red-herring. Daniel I've reported this issue back when the regression was introduced in qemu. Anthony had the same idea (not mixing popen with non-blocking I/O), but no solution was found at the time. I haven't tried recently (I'm using TCP migration only) but the problem must still be here. The thread on qemu-devel: http://lists.gnu.org/archive/html/qemu-devel/2009-08/msg01557.html http://lists.gnu.org/archive/html/qemu-devel/2009-09/msg00020.html -- Pierre Riteau -- http://perso.univ-rennes1.fr/pierre.riteau/ -- 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] configure: Correct KVM options in help output
Signed-off-by: Pierre Riteau pierre.rit...@irisa.fr --- configure |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/configure b/configure index 376c458..85f7b5e 100755 --- a/configure +++ b/configure @@ -723,10 +723,10 @@ echo --disable-bluez disable bluez stack connectivity echo --enable-bluez enable bluez stack connectivity echo --disable-kvmdisable KVM acceleration support echo --enable-kvm enable KVM acceleration support -echo --disable-cap-kvm-pitdisable KVM pit support -echo --enable-cap-kvm-pit enable KVM pit support -echo --disable-cap-device-assignmentdisable KVM device assignment support -echo --enable-cap-device-assignment enable KVM device assignment support +echo --disable-kvm-cap-pitdisable KVM pit support +echo --enable-kvm-cap-pit enable KVM pit support +echo --disable-kvm-cap-device-assignmentdisable KVM device assignment support +echo --enable-kvm-cap-device-assignment enable KVM device assignment support echo --disable-nptl disable usermode NPTL support echo --enable-nptlenable usermode NPTL support echo --enable-system enable all system emulation targets -- 1.6.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
[PATCH] monitor: Fix build on 32-bit
Error was: monitor.c: In function 'print_cpu_iter': monitor.c:450: error: format '%ld' expects type 'long int', but argument 3 has type 'int64_t' Signed-off-by: Pierre Riteau pierre.rit...@irisa.fr --- monitor.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/monitor.c b/monitor.c index b4c4878..cf633a4 100644 --- a/monitor.c +++ b/monitor.c @@ -447,7 +447,7 @@ static void print_cpu_iter(QObject *obj, void *opaque) if (strcmp(qdict_get_str(cpu, halted), yes) == 0) monitor_printf(mon, (halted)); -monitor_printf(mon, thread_id=%ld, qdict_get_int(cpu, thread_id)); +monitor_printf(mon, thread_id=% PRId64, qdict_get_int(cpu, thread_id)); monitor_printf(mon, \n); } -- 1.6.3.3 -- 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
