[ kvm-Bugs-2034672 ] guest: BUG: soft lockup - CPU#0 stuck for 41s!
Bugs item #2034672, was opened at 2008-08-01 08:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2034672group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rafal Wijata (ravpl) Assigned to: Nobody/Anonymous (nobody) Summary: guest: BUG: soft lockup - CPU#0 stuck for 41s! Initial Comment: host: kvm71, 64bit 2.6.25.11-60.fc8, 8Gram, 2*E5420(8cores), 3ware raid10 guest: 64bit 2.6.18-92.1.6.el5, 5Gram, 6cpus, hdd on raw file. I know this bug happens even in non-virtual machines(browsing internet shows that clearly), but inside kvm I'm getting excessive rate of this bug (under load, even few times a hour) An example can be found at end of this message. The record was something over 500 seconds !! Now, I suspect it has something to do with the network or net driver. There's almost always either swapper or network service in the backtrace. But I cannot confirm for surely. BUG: soft lockup - CPU#0 stuck for 41s! [events/0:20] CPU 0: Modules linked in: nfsd exportfs auth_rpcgss ipv6 xfrm_nalgo crypto_api autofs4 nfs lockd fscache nfs_acl sunrpc dm_mirror dm_multipath dm_mod video sbs backlight i2c_ec button battery asus_acpi acpi_memhotplug ac lp floppy loop ide_cd parport_pc i2c_piix4 serio_raw parport cdrom i2c_core e1000 pcspkr ata_piix libata sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd Pid: 20, comm: events/0 Not tainted 2.6.18-92.1.6.el5 #1 RIP: 0010:[80011ec7] [80011ec7] __do_softirq+0x53/0xd6 RSP: 0018:80418f60 EFLAGS: 0206 RAX: 0002 RBX: 803b6f80 RCX: 0380 RDX: 81015f9e7fd8 RSI: 0280 RDI: 81015f9d97a0 RBP: 80418ee0 R08: 0001 R09: 810080bf5000 R10: 0046 R11: 0246 R12: 8005dc8e R13: 0002 R14: 80077090 R15: 80418ee0 FS: () GS:8039f000() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 00300c203080 CR3: 00015df0a000 CR4: 06e0 Call Trace: IRQ [8005e2fc] call_softirq+0x1c/0x28 [8006c6e4] do_softirq+0x2c/0x85 [8005dc8e] apic_timer_interrupt+0x66/0x6c EOI [80064af8] _spin_unlock_irqrestore+0x8/0x9 [880fdc61] :e1000:e1000_update_stats+0x5f6/0x5fd [88101ed5] :e1000:e1000_watchdog_task+0x535/0x65a [8004cea9] run_workqueue+0x94/0xe4 [800497be] worker_thread+0x0/0x122 [800498ae] worker_thread+0xf0/0x122 [8008ad76] default_wake_function+0x0/0xe [8003253d] kthread+0xfe/0x132 [8005dfb1] child_rip+0xa/0x11 [8003243f] kthread+0x0/0x132 [8005dfa7] child_rip+0x0/0x11 BUG: soft lockup - CPU#2 stuck for 17s! [swapper:0] CPU 2: Modules linked in: nfsd exportfs auth_rpcgss ipv6 xfrm_nalgo crypto_api autofs4 nfs lockd fscache nfs_acl sunrpc dm_mirror dm_multipath dm_mod video sbs backlight i2c_ec button battery asus_acpi acpi_memhotplug ac lp floppy loop ide_cd parport_pc i2c_piix4 serio_raw parport cdrom i2c_core e1000 pcspkr ata_piix libata sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd Pid: 0, comm: swapper Not tainted 2.6.18-92.1.6.el5 #1 RIP: 0010:[8006aed7] [8006aed7] default_idle+0x29/0x50 RSP: 0018:810104e63ef0 EFLAGS: 0246 RAX: RBX: 0002 RCX: RDX: RSI: 0001 RDI: 802e6658 RBP: 810104e1d270 R08: 810104e62000 R09: 003e R10: 810104f64038 R11: R12: 0c51b3f5 R13: 3434e623bb62 R14: 81015f9db7e0 R15: 810104e1d080 FS: () GS:810104e1cec0() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 2b3a3b647230 CR3: 00201000 CR4: 06e0 Call Trace: [80048b1d] cpu_idle+0x95/0xb8 [800767da] start_secondary+0x45a/0x469 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2034672group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]: Add a migrate_incoming monitor option
On Thu, Jul 31, 2008 at 12:27:43PM -0500, Anthony Liguori wrote: Chris Lalancette wrote: We've been trying to plumb libvirt to do KVM migration. One of the stumbling blocks we are running into, however, is that libvirt expects to be able to use the Qemu monitor both before and after migration has taken place, on both the source and destination nodes. After migration has taken place is no problem; we return to the main qemu select() loop, and we can run monitor commands. However, before migration, on the destination side, when we start qemu with a command-line like: qemu-kvm -M pc -S blah blah -incoming tcp://0: we can't run any monitor commands since the migration code is synchronously waiting for an incoming tcp connection. To get around this, the following patch adds a new monitor command called migrate_incoming; it takes all of the same parameters as the command-line option, but just starts it later. To make sure it is safe, you actually have to start with -incoming monitor; if you run it without that, it will just spit an error at you. So with this in place, libvirt can do the equivalent of: qemu-kvm -M pc -S blah blah -incoming monitor I think adding a 'nowait' parameter to migration would make more sense than introducing a monitor command. So: qemu-kvm -M pc -S blah blah -incoming tcp://0:,nowait From an implementation perspective, it's just a matter of setting a callback for the accept fd I imagine. An accept trick only handles the TCP case though. I know this was Chris' example that we're currently using, but we intend to switch to passing an open file descriptor instead, and proxying the data via a secure channel instead of the plain tcp, or builtin SSH tunnelling. With an open FD we'll need another way - I guess just registering a event on POLLIN might do the trick. It seems to me that just having an explicit migrate incoming monitor command would be simpler than having to code different triggers to implement 'nowait' for each transport we have. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]: Add a migrate_incoming monitor option
Daniel P. Berrange wrote: An accept trick only handles the TCP case though. I know this was Chris' example that we're currently using, but we intend to switch to passing an open file descriptor instead, and proxying the data via a secure channel instead of the plain tcp, or builtin SSH tunnelling. With an open FD we'll need another way - I guess just registering a event on POLLIN might do the trick. It seems to me that just having an explicit migrate incoming monitor command would be simpler than having to code different triggers to implement 'nowait' for each transport we have. I just finished a patch to do the nowait for tcp as suggested by Anthony, and it was actually far less code then I feared. It just needed a little re-factoring of the migrate_incoming_tcp() function. I'll be posting that in a couple of minutes. Given how this code worked out, doing a nowait for the fd style is really no big deal. Both ways (explicit monitor command and nowait) seem to have their benefits; the monitor command has the benefit of being more flexible, while the nowait has the benefit of being similar to already existing Qemu commands. My preference is for the monitor command since it seems a little more natural for a management tool, but the nowait is clearly an option as well. I'll also post a cleanup patch with Dan's suggestion for the monitor patch, so both implementations will be available. Chris Lalancette -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH]: Implement tcp nowait option for migration
Sometimes you want to be able to start up the receiving side of a live migration
and actually be able to run monitor commands before you do the migration.
Libvirt, in particular, wants to do this for setting up the migration. This
patch implements a nowait option to the receiving side so that you start up
the receiving side similar to:
qemu-kvm -M pc -S blah blah -incoming tcp://0:,nowait
Then you are able to interact with the monitor before the live migration takes
place.
Signed-off-by: Chris Lalancette [EMAIL PROTECTED]
diff --git a/qemu/migration.c b/qemu/migration.c
index a64a287..d16e289 100644
--- a/qemu/migration.c
+++ b/qemu/migration.c
@@ -886,13 +886,10 @@ static int migrate_incoming_fd(int fd)
return ret;
}
-static int migrate_incoming_tcp(const char *host)
+static int migrate_listen_tcp(const char *host, int *outfd)
{
struct sockaddr_in addr;
-socklen_t addrlen = sizeof(addr);
-int fd, sfd;
-ssize_t len;
-uint8_t status = 0;
+int fd = -1;
int reuse = 1;
int rc;
@@ -928,19 +925,43 @@ static int migrate_incoming_tcp(const char *host)
goto error_socket;
}
+*outfd = fd;
+
+return 0;
+
+error_socket:
+close(fd);
+error:
+return rc;
+}
+
+struct migrate_tcp_data {
+int listen_fd;
+int rc;
+};
+
+static void migrate_incoming_tcp(void *opaque)
+{
+struct sockaddr_in addr;
+socklen_t addrlen = sizeof(addr);
+struct migrate_tcp_data *data = (struct migrate_tcp_data *)opaque;
+int sfd;
+ssize_t len;
+uint8_t status = 0;
+
again:
-sfd = accept(fd, (struct sockaddr *)addr, addrlen);
+sfd = accept(data-listen_fd, (struct sockaddr *)addr, addrlen);
if (sfd == -1) {
if (errno == EINTR)
goto again;
perror(accept() failed);
-rc = MIG_STAT_DST_ACCEPT_FAILED;
+data-rc = MIG_STAT_DST_ACCEPT_FAILED;
goto error_socket;
}
-rc = migrate_incoming_fd(sfd);
-if (rc != 0) {
-fprintf(stderr, migrate_incoming_fd failed (rc=%d)\n, rc);
+data-rc = migrate_incoming_fd(sfd);
+if (data-rc != 0) {
+fprintf(stderr, migrate_incoming_fd failed (rc=%d)\n, data-rc);
goto error_accept;
}
@@ -951,13 +972,13 @@ send_ack:
if (len != 1) {
fprintf(stderr, migration: send_ack: write error len=%zu (%s)\n,
len, strerror(errno));
-rc = MIG_STAT_DST_WRITE_FAILED;
+data-rc = MIG_STAT_DST_WRITE_FAILED;
goto error_accept;
}
-rc = wait_for_message(WAIT FOR GO, sfd, wait_for_message_timeout);
-if (rc) {
-rc += 200;
+data-rc = wait_for_message(WAIT FOR GO, sfd, wait_for_message_timeout);
+if (data-rc) {
+data-rc += 200;
goto error_accept;
}
@@ -966,7 +987,7 @@ wait_for_go:
if (len == -1 errno == EAGAIN)
goto wait_for_go;
if (len != 1) {
-rc = MIG_STAT_DST_READ_FAILED;
+data-rc = MIG_STAT_DST_READ_FAILED;
fprintf(stderr, migration: wait_for_go: read error len=%zu (%s)\n,
len, strerror(errno));
}
@@ -974,9 +995,10 @@ wait_for_go:
error_accept:
close(sfd);
error_socket:
-close(fd);
-error:
-return rc;
+qemu_set_fd_handler(data-listen_fd, NULL, NULL, NULL);
+close(data-listen_fd);
+
+qemu_free(data);
}
int migrate_incoming(const char *device)
@@ -996,16 +1018,57 @@ int migrate_incoming(const char *device)
}
} else if (strstart(device, tcp://, ptr)) {
char *host, *end;
+ struct migrate_tcp_data *data;
+ int is_waitconnect = 1;
+
host = strdup(ptr);
+ if (!host)
+ goto fail;
end = strchr(host, '/');
if (end) *end = 0;
- ret = migrate_incoming_tcp(host);
+
+ data = qemu_mallocz(sizeof(struct migrate_tcp_data));
+ if (!data) {
+ qemu_free(host);
+ goto fail;
+ }
+
+ ptr = host;
+ while((ptr = strchr(ptr,','))) {
+ ptr++;
+ if (!strncmp(ptr,nowait,6)) {
+ is_waitconnect = 0;
+ } else {
+ printf(Unknown option: %s\n, ptr);
+ qemu_free(host);
+ goto fail;
+ }
+ }
+
+ ret = migrate_listen_tcp(host, (data-listen_fd));
qemu_free(host);
+ if (ret != 0)
+ goto fail;
+
+ /*
+ * if we made it here, then migrate_incoming_tcp is responsible for
+ * freeing the data structure
+ */
+ if (!is_waitconnect) {
+ socket_set_nonblock(data-listen_fd);
+ qemu_set_fd_handler(data-listen_fd, migrate_incoming_tcp, NULL, data);
+ }
+ else {
+ migrate_incoming_tcp(data);
+ ret = data-rc;
+ }
+
} else {
errno = EINVAL;
ret = MIG_STAT_DST_INVALID_PARAMS;
}
+ fail:
return ret;
}
Re: [PATCH]: Add a migrate_incoming monitor option
Daniel P. Berrange wrote:
@@ -9673,11 +9675,16 @@ int main(int argc, char **argv)
if (incoming) {
int rc;
-rc = migrate_incoming(incoming);
-if (rc != 0) {
-fprintf(stderr, Migration failed rc=%d\n, rc);
-exit(rc);
-}
+if (strncmp(incoming, monitor, 7) == 0) {
+incoming_monitor = 1;
+}
+else {
+rc = migrate_incoming(incoming);
+if (rc != 0) {
+fprintf(stderr, Migration failed rc=%d\n, rc);
+exit(rc);
+}
+}
Rather than putting the strncmp(monitor) into vl.c, I'd just leave
this part as is. Put the logic into the 'migrate_incoming()' method
so that it just sets the 'incoming_monitor' flag and then returns
immediately. That would allwo the 'incoming_Monitor' flag to be declared
static to the migrate.c file, instead of polluting vl.c
Actually, that won't quite work. We still need to share the incoming_monitor
flag between migration.c and monitor.c. However, your suggestion is better in
that this is a migration-specific flag, so I'll move it over like you suggest.
Chris Lalancette
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM compile fails on s390x
On Friday 01 Aug 2008, Christian Borntraeger wrote: Am Freitag, 1. August 2008 schrieb Daniel P. Berrange: What are your intentions for this part longer term. Are you planning to create a QEMU target for s390 so we can use real QEMU binaries instead of emulating a subset of its features. If s390 userspace were QEMU based them you'd be able to use libvirt as a management API in same way as the other architectures. Christian, Daniel, Thanks for the response. I was simply intrigued by the possibility of using KVM to virtualise zLinux and avoid having to use z/VM. Yes, the goal is to move towards qemu. kuli is not intended as a long term solution. Consider it a proof of concept/testing code to show that the kernel part is working. You can also look at our KVM Forum presentation: http://kvm.qumranet.com/kvmwiki/KvmForum2008?action=AttachFiledo=gettarge t=kdf2008_17.pdf The slide Next step contains the merge into common kvm userspace. That would have been my next question: now the kernel modules is build, how do I IPL a guest machine?! I dont think we will see a full s390 backend just to make kvm work. We are considering Anthonys proposal for an kvm backend in qemu instead. I have used Qemu for some years and It has always seemed to me since the inception of KVM that the code bases should be merged to avoid duplication of effort and to make things easier for the users. I will follow up your links, thanks very much for the pointers. Cheers... -Robin -- -- Robin Atwood. Ship me somewheres east of Suez, where the best is like the worst, Where there ain't no Ten Commandments an' a man can raise a thirst from Mandalay by Rudyard Kipling -- -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Weekly KVM Test report, kernel 771310c .. userspace 5c646ce7
Hi All, This is our Weekly KVM Testing Report against lastest kvm.git 771310c770214cd879d30d0825fb5e140cd74866 and kvm-userspace.git 5c646ce7bfb0eb0a108a09f08a3854a27c11cdaf. There is no new issue found this week. Two Old Issues: 1. 32bits Rhel5/FC6 guest may fail to reboot after installation https://sourceforge.net/tracker/?func=detailatid=893831aid=1991647group_id=180599 2. failure to migrate guests with more than 4GB of RAM https://sourceforge.net/tracker/index.php?func=detailaid=1971512group_id=180599atid=893831 Test environment Platform Woodcrest CPU 4 Memory size 8G' Details IA32-pae: 1. boot guest with 256M memory PASS 2. boot guest with 1500M memory PASS 3. boot 4 same guest in parallel PASS 4. boot two windows xp guestPASS 5. boot linux and windows guest in parallel PASS 6. save/restore 32-bit HVM guests PASS 7. save/restore 32-bit HVM guests with 4 vcpus PASS 8. live migration 32-bit HVM guests PASS 9. live migration 32-bit HVM guests with 4 vcpus PASS 10. boot base kernel linux PASS 11. kernel build on SMP linux guestPASS 12. LTP on linux guest PASS 13. boot Windows 2000 without ACPI PASS 14. boot Windows 2000 with ACPI enabled PASS 15. boot Windows 2003 with ACPI enabled PASS 16. boot Windows xp with ACPI enabled PASS 17. boot Windows vista with ACPI enabled PASS 18. boot SMP Windows 2000 with ACPI enabled PASS 19. boot SMP Windows 2003 with ACPI enabled PASS 20. boot SMP Windows xp with ACPI enabled PASS 21. boot SMP Windows 2008 with ACPI enabled PASS IA32e: 1. boot 32-bit guest with 256M memory PASS 2. boot 64-bit guest with 256M memory PASS 3. boot 32-bit guest with 1500M memory PASS 4. boot 64-bit guest with 1500M memory PASS 5. boot 4G pae guest PASS 6. boot 4G 64-bit guest PASS 7. boot four 32-bit guest in parallel PASS 8. boot four 64-bit guest in parallel PASS 9. boot two 32-bit windows xp in parallel PASS 10. boot 32-bit linux and 32 bit windows guest in parallel PASS 11. boot four 32-bit different guest in para PASS 12. save/restore 32-bit linux guests PASS 13. save/restore 64-bit linux guests PASS 14. save/restore 64-bit linux guests with 4 vcpus PASS 15. save/restore 32-bit linux guests with 4 vcpus PASS 16. live migration 64bit linux guests PASS 17. live migration 32bit linux guests PASS 18. live migration 64bit linux guests with 4 vcpus PASS 19. live migration 32bit linux guests with 4 vcpus PASS 20. boot 32-bit x-server PASS 21. kernel build in 32-bit linux guest OS PASS 22. kernel build in 64-bit linux guest OS PASS 23. LTP on 32-bit linux guest OS PASS 24. LTP on 64-bit linux guest OS PASS 25. boot 64-bit guests with ACPI enabled PASS 26. boot 32-bit Windows 2000 without ACPIPASS 27. boot 32-bit Windows xp without ACPIPASS 28. boot 64-bit Windows xp with ACPI enabledPASS 29. boot 64-bit Windows vista with ACPI enabled PASS 30. boot 32-bit SMP Windows 2000 with ACPI enabled PASS 31. boot 32-bit SMP windows 2003 with ACPI enabled PASS 32. boot 32-bit SMP Windows xp with ACPI enabledPASS 33. boot 64-bit SMP Windows vista with ACPI enabled PASS 34. boot 32-bit SMP windows 2008 with ACPI enabled PASS 35. boot 64-bit SMP windows 2003 with ACPI enabled PASS 36. boot 64-bit SMP windows XP with ACPI enabled PASS 37. boot 64-bit SMP windows 2008 with ACPI
How to connect USB enclosue to guest
Hi folks, Ubuntu 8.04 server amd64 - host Ubuntu 6.06 server amd64 - guest KVM 1:62+dfsq UBS enclosure Please advise how to mount the USB enclosure to guest. It can be mounted on host. Pointer would be appreciated. TIA B.R. Stephen L Send instant messages to your online friends http://uk.messenger.yahoo.com -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to connect USB enclosue to guest
On Fri, Aug 1, 2008 at 10:41 AM, Stephen Liu [EMAIL PROTECTED] wrote: Hi folks, Ubuntu 8.04 server amd64 - host Ubuntu 6.06 server amd64 - guest KVM 1:62+dfsq UBS enclosure Please advise how to mount the USB enclosure to guest. It can be mounted on host. Pointer would be appreciated. TIA instead of messing with USB, manage it as any block device. don't mount it on host, and add the /dev/sdX device file as an extra drive on the qemu command line. downside is that you wouldn't be able to (easily) unmount from the guest. -- Javier -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm: bios: Put AP boot up code to 0x1000
Avi Kivity wrote: IIRC the rombios32.c writes to the memory it is in, so it expects RAM, not ROM. kvm doesn't support ROM, so it would work. Qemu doesn't, so it would fail. You can specify either RAM or ROM in Qemu, but you have to edit the C code. If you need RAM in the low 640K, your choices are roughly 0x300..0x340 or in the EBDA. -hpa -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Balloon device in qemu?
On Thu, Jul 31, 2008 at 04:01:54PM +0300, Avi Kivity wrote: Marcelo, the balloon was last seen drifting over your territory. Care to brush it up and send it over? Anthony rewrote the backend, I think this is the latest version: http://www.archivum.info/[EMAIL PROTECTED]/2008-04/msg00080.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 0/2] do not run halted vcpu's
Avi Kivity wrote: Any reason this is not in __vcpu_run()? Our main loop could look like while (no reason to stop) if (runnable) enter guest else block deal with aftermath kvm_emulate_halt would then simply modify the mp state. Like this? - I don't think it is necessary to test for pending signals inside irq safe section, so move that to exit processing. - Same for need_resched(). -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]: pointer to vmcs getting lost
Hi Jesse, On Fri, Aug 01, 2008 at 03:18:52PM -0700, Jesse wrote: Greetings, I noticed a race condition when running two guests simultaneously and debugging both guests (on 64-bit intel cpus). Periodically I would get errors from the vmread, vmwrite, or vmresume instructions. Some research revealed that these errors were being caused by having an invalid vmcs loaded. Further, I found that the vmcs is a per_cpu variable, which I believe means that any reference to it is invalid after a context switch. (Corrections appreciated). This means that the vmcs must be reloaded each time the process is switched to. The preempt notifiers will do that for you. The patch below fixed the problem for me. This patch does three things. 1. Extends the critical section in __vcpu_run to include the handling of vmexits, where many of the vmread/writes occur. 2. Perform a vcpu_load after we enter the critical section, and after we return from kvm_resched. 3. Move the call to kvm_guest_debug_pre into the critical section (because it calls vmread/write). Wouldnt it suffice to move -guest_debug_pre into the non preemptable section? http://article.gmane.org/gmane.comp.emulators.kvm.devel/20244 I haven't tested that patch though. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH] Add HPET emulation to qemu (v2)
Major changes:
- Rebased to register-based operations for ease of save/restore.
- Looked through Xen's hpet implementation and picked up a bunch of
things, though not quite everything yet. Thanks!
- PIT and RTC are entirely disabled in legacy mode, not just their
interrupts.
There is still a bunch to do but I'm re-posting primarily because
of the switch to register-based. I have still only tested with a
linux guest. Windows guest is next on my list... as soon as I return
from my week vacation.
I've been playing with CONFIG_NO_HZ and been surprised by the
results. I was trying to reproduce the wakeup every 10ms that
Samuel Thibault mentioned, thinking the HPET would improve it.
But for an idle guest in both cases (with and without HPET), the
number of wakeups per second was relatively low (28). Ultimately
this depends on exactly what the guest is doing
when idle, so maybe the HPET won't provide any improvement here.
But in any case, I didn't see the 10ms wakeup cycle with CONFIG_NO_HZ.
If anyone can shed any light on this, I could look into it more if need
be.
Signed-off-by: Beth Kon [EMAIL PROTECTED]
***
Makefile.target |2
hw/hpet.c| 441 +++
hw/i8254.c | 11 +
hw/mc146818rtc.c | 30 +++
hw/pc.c |2
5 files changed, 483 insertions(+), 3 deletions(-)
***
diff --git a/Makefile.target b/Makefile.target
index 42162c3..946bdef 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -536,7 +536,7 @@ ifeq ($(TARGET_BASE_ARCH), i386)
OBJS+= ide.o pckbd.o ps2.o vga.o $(SOUND_HW) dma.o
OBJS+= fdc.o mc146818rtc.o serial.o i8259.o i8254.o pcspk.o pc.o
OBJS+= cirrus_vga.o apic.o parallel.o acpi.o piix_pci.o
-OBJS+= usb-uhci.o vmmouse.o vmport.o vmware_vga.o
+OBJS+= usb-uhci.o vmmouse.o vmport.o vmware_vga.o hpet.o
CPPFLAGS += -DHAS_AUDIO -DHAS_AUDIO_CHOICE
endif
ifeq ($(TARGET_BASE_ARCH), ppc)
diff --git a/hw/hpet.c b/hw/hpet.c
new file mode 100644
index 000..adfecf0
--- /dev/null
+++ b/hw/hpet.c
@@ -0,0 +1,441 @@
+/*
+ * High Precisition Event Timer emulation
+ *
+ * Copyright (c) 2007 Alexander Graf
+ * Copyright (c) 2008 IBM Corporation
+ *
+ * Authors: Beth Kon [EMAIL PROTECTED]
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * *
+ *
+ * This driver attempts to emulate an HPET device in software. It is by no
+ * means complete and is prone to break on certain conditions.
+ *
+ */
+#include hw.h
+#include console.h
+#include qemu-timer.h
+
+//#define HPET_DEBUG
+
+#define HPET_BASE 0xfed0
+#define HPET_CLK_PERIOD 1000ULL /* 1000 femtoseconds == 10ns*/
+
+#define FS_PER_NS 100
+#define HPET_NUM_TIMERS 3
+#define HPET_TIMER_TYPE_LEVEL 1
+#define HPET_TIMER_TYPE_EDGE 0
+#define HPET_TIMER_DELIVERY_APIC 0
+#define HPET_TIMER_DELIVERY_FSB 1
+#define HPET_TIMER_CAP_FSB_INT_DEL (1 15)
+#define HPET_TIMER_CAP_PER_INT (1 4)
+
+#define HPET_CFG_ENABLE 0x001
+#define HPET_CFG_LEGACY 0x002
+
+#define HPET_ID 0x000
+#define HPET_PERIOD 0x004
+#define HPET_CFG0x010
+#define HPET_STATUS 0x020
+#define HPET_COUNTER0x0f0
+#define HPET_TN_REGS0x100 ... 0x3ff /*address range of all TN regs*/
+#define HPET_TN_CFG 0x000
+#define HPET_TN_CMP 0x008
+#define HPET_TN_ROUTE 0x010
+
+
+#define HPET_TN_INT_TYPE_LEVEL 0x002
+#define HPET_TN_ENABLE 0x004
+#define HPET_TN_PERIODIC 0x008
+#define HPET_TN_PERIODIC_CAP 0x010
+#define HPET_TN_SIZE_CAP 0x020
+#define HPET_TN_SETVAL 0x040
+#define HPET_TN_32BIT0x100
+#define HPET_TN_INT_ROUTE_MASK 0x3e00
+#define HPET_TN_INT_ROUTE_SHIFT 9
+#define HPET_TN_INT_ROUTE_CAP_SHIFT 32
+#define HPET_TN_CFG_BITS_READONLY_OR_RESERVED 0x80b1U
+
+#define timer_int_route(timer) \
+((timer-config HPET_TN_INT_ROUTE_MASK) HPET_TN_INT_ROUTE_SHIFT)
+
+#define hpet_enabled(s) (s-config HPET_CFG_ENABLE)
+#define timer_is_periodic(t) (t-config HPET_TN_PERIODIC)
+#define timer_enabled(t) (t-config HPET_TN_ENABLE)
+
+struct HPETState;
+typedef struct HPETTimer { /* timers */
+uint8_t tn; /*timer number*/
+QEMUTimer *qemu_timer;
+struct HPETState
Re: [PATCH]: pointer to vmcs getting lost
Thanks for the feedback. Comments inline. Marcelo Tosatti wrote: Hi Jesse, On Fri, Aug 01, 2008 at 03:18:52PM -0700, Jesse wrote: Greetings, I noticed a race condition when running two guests simultaneously and debugging both guests (on 64-bit intel cpus). Periodically I would get errors from the vmread, vmwrite, or vmresume instructions. Some research revealed that these errors were being caused by having an invalid vmcs loaded. Further, I found that the vmcs is a per_cpu variable, which I believe means that any reference to it is invalid after a context switch. (Corrections appreciated). This means that the vmcs must be reloaded each time the process is switched to. The preempt notifiers will do that for you. Right, but they won't call VMPTRLD. For some reason this matters (for intel chips), even if the variable ends up back in the same place, as far as I can tell. The patch below fixed the problem for me. This patch does three things. 1. Extends the critical section in __vcpu_run to include the handling of vmexits, where many of the vmread/writes occur. 2. Perform a vcpu_load after we enter the critical section, and after we return from kvm_resched. 3. Move the call to kvm_guest_debug_pre into the critical section (because it calls vmread/write). Wouldnt it suffice to move -guest_debug_pre into the non preemptable section? http://article.gmane.org/gmane.comp.emulators.kvm.devel/20244 Excellent. I hadn't seen that patch yet. However, many of the vmreads/vmwrites that failed in my testing were in the exit handlers. And a calling VMPTRLD (in vcpu_load) explicitly on entering the critical section secures any other vmcs concurrency problems. I haven't tested that patch though. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to connect USB enclosue to guest
--- Javier Guerra [EMAIL PROTECTED] wrote: On Fri, Aug 1, 2008 at 10:41 AM, Stephen Liu [EMAIL PROTECTED] wrote: Hi folks, Ubuntu 8.04 server amd64 - host Ubuntu 6.06 server amd64 - guest KVM 1:62+dfsq UBS enclosure Please advise how to mount the USB enclosure to guest. It can be mounted on host. Pointer would be appreciated. TIA instead of messing with USB, manage it as any block device. don't mount it on host, and add the /dev/sdX device file as an extra drive on the qemu command line. downside is that you wouldn't be able to (easily) unmount from the guest. Hi Javier, Thanks for your advice. I'm running the USB enclosure (a HD) as portable storage drive to servers. I have to connect it to another server later when in need. I have another thought whether I can create the enclosure as an image on KVM? But even possible I have to recreate a new image next time connecting it to the guest. Any advice? TIA B.R. Stephen Send instant messages to your online friends http://uk.messenger.yahoo.com -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Can several guests run simultaneously on KVM
Hi folks, Can I run serveral guests on KVM at the same time similar to VMware hypervisor? Thanks B.R. Stephen L Send instant messages to your online friends http://uk.messenger.yahoo.com -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can several guests run simultaneously on KVM
Stephen Liu wrote: Hi folks, Can I run serveral guests on KVM at the same time similar to VMware hypervisor? Yes. -- David. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH] Add HPET emulation to qemu (v2)
Major changes:
- Rebased to register-based operations for ease of save/restore.
- Looked through Xen's hpet implementation and picked up a bunch of
things, though not quite everything yet. Thanks!
- PIT and RTC are entirely disabled in legacy mode, not just their
interrupts.
There is still a bunch to do but I'm re-posting primarily because
of the switch to register-based. I have still only tested with a
linux guest. Windows guest is next on my list... as soon as I return
from my week vacation.
I've been playing with CONFIG_NO_HZ and been surprised by the
results. I was trying to reproduce the wakeup every 10ms that
Samuel Thibault mentioned, thinking the HPET would improve it.
But for an idle guest in both cases (with and without HPET), the
number of wakeups per second was relatively low (28). Ultimately
this depends on exactly what the guest is doing
when idle, so maybe the HPET won't provide any improvement here.
But in any case, I didn't see the 10ms wakeup cycle with CONFIG_NO_HZ.
If anyone can shed any light on this, I could look into it more if need
be.
Signed-off-by: Beth Kon [EMAIL PROTECTED]
***
Makefile.target |2
hw/hpet.c| 441 +++
hw/i8254.c | 11 +
hw/mc146818rtc.c | 30 +++
hw/pc.c |2
5 files changed, 483 insertions(+), 3 deletions(-)
***
diff --git a/Makefile.target b/Makefile.target
index 42162c3..946bdef 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -536,7 +536,7 @@ ifeq ($(TARGET_BASE_ARCH), i386)
OBJS+= ide.o pckbd.o ps2.o vga.o $(SOUND_HW) dma.o
OBJS+= fdc.o mc146818rtc.o serial.o i8259.o i8254.o pcspk.o pc.o
OBJS+= cirrus_vga.o apic.o parallel.o acpi.o piix_pci.o
-OBJS+= usb-uhci.o vmmouse.o vmport.o vmware_vga.o
+OBJS+= usb-uhci.o vmmouse.o vmport.o vmware_vga.o hpet.o
CPPFLAGS += -DHAS_AUDIO -DHAS_AUDIO_CHOICE
endif
ifeq ($(TARGET_BASE_ARCH), ppc)
diff --git a/hw/hpet.c b/hw/hpet.c
new file mode 100644
index 000..adfecf0
--- /dev/null
+++ b/hw/hpet.c
@@ -0,0 +1,441 @@
+/*
+ * High Precisition Event Timer emulation
+ *
+ * Copyright (c) 2007 Alexander Graf
+ * Copyright (c) 2008 IBM Corporation
+ *
+ * Authors: Beth Kon [EMAIL PROTECTED]
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * *
+ *
+ * This driver attempts to emulate an HPET device in software. It is by no
+ * means complete and is prone to break on certain conditions.
+ *
+ */
+#include hw.h
+#include console.h
+#include qemu-timer.h
+
+//#define HPET_DEBUG
+
+#define HPET_BASE 0xfed0
+#define HPET_CLK_PERIOD 1000ULL /* 1000 femtoseconds == 10ns*/
+
+#define FS_PER_NS 100
+#define HPET_NUM_TIMERS 3
+#define HPET_TIMER_TYPE_LEVEL 1
+#define HPET_TIMER_TYPE_EDGE 0
+#define HPET_TIMER_DELIVERY_APIC 0
+#define HPET_TIMER_DELIVERY_FSB 1
+#define HPET_TIMER_CAP_FSB_INT_DEL (1 15)
+#define HPET_TIMER_CAP_PER_INT (1 4)
+
+#define HPET_CFG_ENABLE 0x001
+#define HPET_CFG_LEGACY 0x002
+
+#define HPET_ID 0x000
+#define HPET_PERIOD 0x004
+#define HPET_CFG0x010
+#define HPET_STATUS 0x020
+#define HPET_COUNTER0x0f0
+#define HPET_TN_REGS0x100 ... 0x3ff /*address range of all TN regs*/
+#define HPET_TN_CFG 0x000
+#define HPET_TN_CMP 0x008
+#define HPET_TN_ROUTE 0x010
+
+
+#define HPET_TN_INT_TYPE_LEVEL 0x002
+#define HPET_TN_ENABLE 0x004
+#define HPET_TN_PERIODIC 0x008
+#define HPET_TN_PERIODIC_CAP 0x010
+#define HPET_TN_SIZE_CAP 0x020
+#define HPET_TN_SETVAL 0x040
+#define HPET_TN_32BIT0x100
+#define HPET_TN_INT_ROUTE_MASK 0x3e00
+#define HPET_TN_INT_ROUTE_SHIFT 9
+#define HPET_TN_INT_ROUTE_CAP_SHIFT 32
+#define HPET_TN_CFG_BITS_READONLY_OR_RESERVED 0x80b1U
+
+#define timer_int_route(timer) \
+((timer-config HPET_TN_INT_ROUTE_MASK) HPET_TN_INT_ROUTE_SHIFT)
+
+#define hpet_enabled(s) (s-config HPET_CFG_ENABLE)
+#define timer_is_periodic(t) (t-config HPET_TN_PERIODIC)
+#define timer_enabled(t) (t-config HPET_TN_ENABLE)
+
+struct HPETState;
+typedef struct HPETTimer { /* timers */
+uint8_t tn; /*timer number*/
+QEMUTimer *qemu_timer;
+struct HPETState
