[kvm-devel] crash booting Windows with current -git
I'm getting the following crash with current -git userspace. I'm running a stock 2.6.22-14-generic ubuntu kernels with modules from the kvm-userspace tree. I believe my BIOS images are also from current -git. The crash occurs about 10 or 15 seconds after the GUI comes up. Booting with -no-kvm is OK. [EMAIL PROTECTED]:~/projects/qemu$ ~/src/kvm-userspace/qemu/x86_64-softmmu/qemu-system-x86_64 -hda ~/projects/qemu/windows-xp-base-runme.img qemu: unsupported keyboard cmd=0xa1 qemu: unsupported keyboard cmd=0xba unhandled vm exit: 0x9 vcpu_id 0 rax fc65b948 rbx 806ed0e0 rcx rdx rsi 811f84d8 rdi 806ed0b8 rsp 15fffc5f rbp fc65b96c r8 r9 r10 r11 r12 r13 r14 r15 rip fc5f157e rflags 00010206 cs 0008 (/ p 1 dpl 0 db 1 s 1 type b l 0 g 1 avl 0) ds 0023 (/ p 1 dpl 3 db 1 s 1 type 3 l 0 g 1 avl 0) es 0023 (/ p 1 dpl 3 db 1 s 1 type 3 l 0 g 1 avl 0) ss 0010 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) fs 0030 (ffdff000/1fff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) gs (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) tr 0028 (80042000/20ab p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gdt 8003f000/3ff idt 8003f400/7ff cr0 8001003b cr2 806ed0b4 cr3 3b8f000 cr4 6d8 cr8 0 efer 0 Aborted (core dumped) -- Dave - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm causing memory corruption? ~2.6.25-rc6
On Thu, 2008-03-27 at 11:36 +0200, Avi Kivity wrote: I dug out my i386 install and tried it. Doesn't reproduce for me on either kvm.git or -rc7. Do you have a working setup that we can bisect? I don't really have a working revision to bisect against. I'm not sure that it ever worked. It's also on my actual laptop, so it's a bit of a pain to get any other work done while I'm bisecting. :) I'll move the Windows image over to another machine today and see if I can reproduce elsewhere. I'll also check some older versions of KVM to see if any of those work. If I do that, should I keep the kvm userspace, modules and BIOSes all synchronized from each version that I test? -- Dave - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm causing memory corruption? ~2.6.25-rc6
On Thu, 2008-03-27 at 17:53 +0200, Avi Kivity wrote: Dave Hansen wrote: On Thu, 2008-03-27 at 11:36 +0200, Avi Kivity wrote: I dug out my i386 install and tried it. Doesn't reproduce for me on either kvm.git or -rc7. Do you have a working setup that we can bisect? I don't really have a working revision to bisect against. I'm not sure that it ever worked. I'm fairly sure Windows works on kvm... Oh, I didn't mean to imply that Windows doesn't work, just that the particular perverted way in which I'm poking it may have never worked. :) How did you generate the image? The original install was done in a kqemu-accelerated host. It's also on my actual laptop, so it's a bit of a pain to get any other work done while I'm bisecting. :) I'll move the Windows image over to another machine today and see if I can reproduce elsewhere. I'll also check some older versions of KVM to see if any of those work. If I do that, should I keep the kvm userspace, modules and BIOSes all synchronized from each version that I test? You can keep the userspace (qemu + bios) fixed and change the kernel, or vice versa. -- Dave - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm causing memory corruption? ~2.6.25-rc6
On Thu, 2008-03-27 at 16:59 +0200, Avi Kivity wrote: Dave Hansen wrote: On Thu, 2008-03-27 at 12:10 +0200, Avi Kivity wrote: btw, is this with = 4GB RAM on the host? Well, are you asking whether I have PAE on or not? :) No, I'm asking whether there is a possibility of address truncation :) PAE by itself doesn't affect kvm much, as it always runs the guest in pae mode. Can you try running with mem=2000M or something? Oh, sure. I'll give that a shot. -- Dave - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm causing memory corruption? ~2.6.25-rc6
On Wed, 2008-03-26 at 18:58 +0200, Avi Kivity wrote: Dave Hansen wrote: On Wed, 2008-03-26 at 11:50 +0200, Avi Kivity wrote: Dave Hansen wrote: I was getting some kvm userspace crashes trying to run a Windows guest. So, I decided to try a recent kernel (2.6.25-rc6-00333-ga4083c9) with the kvm kernel code that shipped with that kernel. This is fixed in 2.6.25-rc7. I just updated to -rc7 and re-tested. Same symptoms: Bad. Which kvm userspace are you running? ~/src/kvm-userspace$ git describe kvm-63-118-g52be1a1 -- Dave - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm causing memory corruption? ~2.6.25-rc6
On Wed, 2008-03-26 at 11:50 +0200, Avi Kivity wrote: Dave Hansen wrote: I was getting some kvm userspace crashes trying to run a Windows guest. So, I decided to try a recent kernel (2.6.25-rc6-00333-ga4083c9) with the kvm kernel code that shipped with that kernel. This is fixed in 2.6.25-rc7. I just updated to -rc7 and re-tested. Same symptoms: [ 751.033545] BUG: unable to handle kernel paging request at 0096b848 [ 751.040082] IP: [c01a0636] d_instantiate+0x26/0x50 [ 751.048065] Oops: 0002 [#1] SMP [ 751.052057] Modules linked in: kvm_intel kvm nls_iso8859_1 vfat fat rfcomm l2cap tun ppdev acpi_cpufreq cpufreq_ondemand cpe [ 751.052057] [ 751.052057] Pid: 8743, comm: evolution Not tainted (2.6.25-rc7 #146) [ 751.052057] EIP: 0060:[c01a0636] EFLAGS: 00210286 CPU: 0 [ 751.052057] EIP is at d_instantiate+0x26/0x50 [ 751.052057] EAX: 0096b844 EBX: e65d7d48 ECX: EDX: e65d7d60 [ 751.052057] ESI: e67a7d00 EDI: e67a7cc0 EBP: e802ce48 ESP: e802ce3c [ 751.052057] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 751.052057] Process evolution (pid: 8743, ti=e802c000 task=f3c8ce00 task.ti=e802c000) [ 751.052057] Stack: e65d7d48 f4c191f8 e802ce60 c01e2fa4 e67a7cc0 f4c191f8 e65d7d48 [ 751.052057]e660c280 e802ce80 c01e30c3 8180 e67a7cc0 c03b4a00 e660c280 [ 751.052057]8180 e802cea0 c0197964 e802cf24 c03b4a00 e67a7cc0 e660c280 e802cf24 [ 751.052057] Call Trace: [ 751.052057] [c01e2fa4] ? ext3_add_nondir+0x34/0x60 [ 751.052057] [c01e30c3] ? ext3_create+0xf3/0x100 [ 751.052057] [c0197964] ? vfs_create+0x74/0x100 [ 751.052057] [c0197c8f] ? open_namei_create+0x4f/0xa0 [ 751.052057] [c01981f3] ? open_namei+0x513/0x560 [ 751.052057] [c018db2c] ? do_filp_open+0x2c/0x60 [ 751.052057] [c018dd29] ? get_unused_fd_flags+0x39/0xd0 [ 751.052057] [c018dec4] ? do_sys_open+0x54/0xe0 [ 751.052057] [c018df6c] ? sys_open+0x1c/0x20 [ 751.052057] [c0104e2c] ? sysenter_past_esp+0x6d/0xa5 [ 751.052057] [c039] ? quirk_vt8235_acpi+0x90/0xa0 [ 751.052057] === [ 751.052057] Code: 27 00 00 00 00 55 89 e5 57 89 c7 56 8d 70 40 53 89 d3 39 70 40 75 37 b8 40 15 4e c0 e8 14 d1 1f 00 85 db [ 751.052057] EIP: [c01a0636] d_instantiate+0x26/0x50 SS:ESP 0068:e802ce3c [ 751.052103] ---[ end trace 514c1de750400319 ]--- -- Dave - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] kvm causing memory corruption? ~2.6.25-rc6
I was getting some kvm userspace crashes trying to run a Windows guest.
So, I decided to try a recent kernel (2.6.25-rc6-00333-ga4083c9) with
the kvm kernel code that shipped with that kernel.
I've had some lockups doing similar things over the last month or two,
but figured it was something really stupid I was doing, and never really
connected the dots. Now, I've hooked up a serial console and reproduced
it with a fresh boot and not much else going on at all on the machine.
Machine is a Thinkpad T61. .config is here:
http://sr71.net/~dave/linux/config-2.6.25-rc6-00333-ga4083c9
To trigger it, I first run kvm and see an error (-no-kvm works fine,
btw):
$ ~/src/kvm-userspace/qemu/x86_64-softmmu/qemu-system-x86_64 -hda
~/projects/qemu/windows-xp-base-runme.img
kvm_run: Cannot allocate memory
kvm_run returned -12
Then, run it again. I usually get an oops. But, the weird part is that
the oops isn't *in* kvm. It's in some other part of the kernel and in
some *OTHER* process. One in bash is below. That's what leads me to
believe it is memory corruption. The machine also becomes increasingly
unstable after the original oops so there's definitely collateral
damage.
$ addr2line -e vmlinux c01795e4
/home/dave/kernels/linux-2.6.git/mm/filemap.c:1327
int filemap_fault(struct vm_area_struct *vma, struct vm_fault
*vmf)
{
int error;
struct file *file = vma-vm_file;
struct address_space *mapping = file-f_mapping;
struct file_ra_state *ra = file-f_ra;
HERE---struct inode *inode = mapping-host;
Which is a line of code that literally hasn't touched since the
beginning of time (in git terms :). Full oops is below:
[ 435.057922] BUG: unable to handle kernel NULL pointer dereference at 0048
[ 435.067275] IP: [c01795e4] filemap_fault+0x34/0x310
[ 435.072815] *pdpt = 2a4a7001 *pde =
[ 435.081272] Oops: [#2] SMP
[ 435.084812] Modules linked in: nls_iso8859_1 vfat fat rfcomm l2cap tun ppdev
acpi_cpufreq cpufreq_ondemand cpufreq_conservative cpufreq_stats freq_table
cpufreq_userspace cpufreq_powersave sbs container sbshc af_packet sbp2 lp loop
usb_storage arc4 ecb crypto_blkcipher pcmcia usbhid libusual hid snd_hda_intel
snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi_event
snd_seq snd_timer snd_seq_device joydev iwl4965 snd serio_raw mac80211
yenta_socket parport_pc sdhci uhci_hcd ehci_hcd ricoh_mmc ohci1394
rsrc_nonstatic soundcore cfg80211 parport psmouse mmc_core ieee1394 pcmcia_core
usbcore snd_page_alloc e1000 button thinkpad_acpi nvram evdev thermal processor
fan fuse
[ 435.084812]
[ 435.084812] Pid: 7691, comm: bash Tainted: G D
(2.6.25-rc6-00333-ga4083c9 #144)
[ 435.084812] EIP: 0060:[c01795e4] EFLAGS: 00010286 CPU: 0
[ 435.084812] EIP is at filemap_fault+0x34/0x310
[ 435.084812] EAX: ef83bf48 EBX: 0012 ECX: EDX: ef83c7e8
[ 435.084812] ESI: c04cc248 EDI: EBP: ef96ee40 ESP: ef96ee00
[ 435.084812] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 435.084812] Process bash (pid: 7691, ti=ef96e000 task=ef8a2e00
task.ti=ef96e000)
[ 435.084812] Stack: ef96ee2c c0130cbc ef96ee28 c01870bb ef96ee28
[ 435.084812]ef83bf48 ef83c7e8 ef83bf00 ef96ee9c ea49f7e8 0012
c04cc248
[ 435.084812]ef96eeb8 c018ab57 8001 0001 0001
eacb6314
[ 435.084812] Call Trace:
[ 435.084812] [c0130cbc] ? kmap_atomic_prot+0x12c/0x150
[ 435.084812] [c01870bb] ? vm_normal_page+0x2b/0xa0
[ 435.084812] [c018ab57] ? __do_fault+0x67/0x4e0
[ 435.084812] [c01a8a70] ? pipe_read+0x1f0/0x290
[ 435.084812] [c018b03d] ? do_linear_fault+0x6d/0x80
[ 435.084812] [c018b570] ? handle_mm_fault+0x1c0/0x4d0
[ 435.084812] [c014d58e] ? do_sigaction+0x16e/0x190
[ 435.084812] [c03b3419] ? do_page_fault+0x169/0x4d0
[ 435.084812] [c01a38b9] ? fput+0x19/0x20
[ 435.084812] [c03b32b0] ? do_page_fault+0x0/0x4d0
[ 435.084812] [c03b187a] ? error_code+0x72/0x78
[ 435.084812] [c03b] ? wait_for_completion_killable+0x10/0x30
[ 435.084812] ===
[ 435.084812] Code: 89 45 f0 89 55 ec 8b 40 4c 89 45 e8 8b 50 7c 83 c0 48 89
45 e0 89 55 e4 8b 0a c7 45 d8 00 00 00 00 c7 45 d4 00 00 00 00 89 4d dc 8b 49
48 89 f6 8d bc 27 00 00 00 00 89 c8 8b 7d dc 8b 5f 40 8b
[ 435.084812] EIP: [c01795e4] filemap_fault+0x34/0x310 SS:ESP 0068:ef96ee00
[ 435.084870] ---[ end trace addcd60623916614 ]---
~/src/kvm-userspace$ git describe
kvm-63-118-g52be1a1
/proc/cpuinfo:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz
stepping: 10
cpu MHz : 800.000
cache size : 4096 KB
physical id : 0
siblings: 2
core id : 0
cpu cores : 2
fdiv_bug: no
hlt_bug : no
Re: [kvm-devel] [RFC/PATCH 01/15] preparation: provide hook to enable pgstes in user pagetable
On Thu, 2008-03-20 at 21:35 +0100, Carsten Otte wrote: Dave Hansen wrote: Well, and more fundamentally: do we really want dup_mm() able to be called from other code? Maybe we need a bit more detailed justification why fork() itself isn't good enough. It looks to me like they basically need an arch-specific argument to fork, telling the new process's page tables to take the fancy new bit. I'm really curious how this new stuff is going to get used. Are you basically replacing fork() when creating kvm guests? No. The trick is, that we do need bigger page tables when running guests: our page tables are usually 2k, but when running a guest they're 4k to track both guest and host dirtyreference information. This looks like this: *--* *2k PTE's * *--* *2k PGSTE * *--* We don't want to waste precious memory for all page tables. We'd like to have one kernel image that runs regular server workload _and_ guests. That makes a lot of sense. Is that layout (the shadow and regular stacked together) specified in hardware somehow, or was it just chosen? What you've done with dup_mm() is probably the brute-force way that I would have done it had I just been trying to make a proof of concept or something. I'm worried that there are a bunch of corner cases that haven't been considered. What if someone else is poking around with ptrace or something similar and they bump the mm_users: + if (tsk-mm-context.pgstes) + return 0; + if (!tsk-mm || atomic_read(tsk-mm-mm_users) 1 || + tsk-mm != tsk-active_mm || tsk-mm-ioctx_list) + return -EINVAL; HERE + tsk-mm-context.pgstes = 1;/* dirty little tricks .. */ + mm = dup_mm(tsk); It'll race, possibly fault in some other pages, and those faults will be lost during the dup_mm(). I think you need to be able to lock out all of the users of access_process_vm() before you go and do this. You also need to make sure that anyone who has looked at task-mm doesn't go and get a reference to it and get confused later when it isn't the task-mm any more. Therefore, we need to reallocate the page table after fork() once we know that task is going to be a hypervisor. That's what this code does: reallocate a bigger page table to accomondate the extra information. The task needs to be single-threaded when calling for extended page tables. Btw: at fork() time, we cannot tell whether or not the user's going to be a hypervisor. Therefore we cannot do this in fork. Can you convert the page tables at a later time without doing a wholesale replacement of the mm? It should be a bit easier to keep people off the pagetables than keep their grubby mitts off the mm itself. -- Dave - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC/PATCH 01/15] preparation: provide hook to enable pgstes in user pagetable
On Thu, 2008-03-20 at 10:28 -0700, Jeremy Fitzhardinge wrote: Carsten Otte wrote: +struct mm_struct *dup_mm(struct task_struct *tsk); No prototypes in .c files. Put this in an appropriate header. Well, and more fundamentally: do we really want dup_mm() able to be called from other code? Maybe we need a bit more detailed justification why fork() itself isn't good enough. It looks to me like they basically need an arch-specific argument to fork, telling the new process's page tables to take the fancy new bit. I'm really curious how this new stuff is going to get used. Are you basically replacing fork() when creating kvm guests? -- Dave - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Slow usernet from last qemu merge (~kvm-61)
I use '-net user' because it is simple for me to set up, and it has always worked flawlessly. On a recent update, though, I realized that I couldn't use vi inside my guest because it had gotten too slow. It feels to me like lots of network latency, but is isn't _actual_ network latency. I can scp a very small file to a kvm-60 guest in ~3 seconds. The same file takes 15 seconds on kvm-61 with the exact same host kernel/modules, guest kernel and guest disk. I'm running the bios from the current git tree. I git bisected this behavior down to the qemu merge at: e6fd8f045bf87e8518985d1f5a0102e5f5640d5a. I also moved over to the qemu branch at just before the merge and built that version of qemu by itself. The scp time on that non-kvm-accelerated version is about 4 seconds; barely slower than the fast kvm, and way *FASTER* than current versions of kvm. I'm quite sure that this qemu was not accelerated because the boot was very, very slow. I've tried ne2k, 8139 and e1000. Changing between them didn't seem to affect the problem. Any ideas how to track this down further? -- Dave - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] make KVM selectable again
Current git for me (b1d0e4f535e10775cffde922208b49629169aeaa) doesn't let me build KVM. In fact, I don't seem to have *ANY* kvm-related symbols in my .config at all. I've verified that arch/x86/kvm/Kconfig was getting run by putting some comments in it. It seems to me like just putting: config HAVE_KVM bool isn't letting anything come into my .config at all. I'm not sure why we do that, and then have: select HAVE_KVM in arch/x86/Kconfig. This patch just defines HAVE_KVM in the x86 Kconfig and is done with it. Seems to work for me. Was there some reason that it was done this way? Was it ever tested? -- Dave Signed-off-by: Dave Hansen [EMAIL PROTECTED] diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 65a70b7..cbbf35d 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -115,7 +115,8 @@ config ARCH_HAS_CPU_RELAX config HAVE_SETUP_PER_CPU_AREA def_bool X86_64 -select HAVE_KVM +config HAVE_KVM + def_bool y config ARCH_HIBERNATION_POSSIBLE def_bool y diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig index 41962e7..f2177ec 100644 --- a/arch/x86/kvm/Kconfig +++ b/arch/x86/kvm/Kconfig @@ -1,8 +1,6 @@ # # KVM configuration # -config HAVE_KVM - bool menuconfig VIRTUALIZATION bool Virtualization - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Slow Kernel Boot
On Tue, 2008-01-08 at 12:12 +0530, Amit Shah wrote:
BIOS-provided physical RAM map:
BIOS-e820: - 0009fc00 (usable)
BIOS-e820: 0009fc00 - 000a (reserved)
BIOS-e820: 000e8000 - 0010 (reserved)
BIOS-e820: 0010 - fffbd000 (usable)
BIOS-e820: fffbd000 - (reserved)
Note that this is with '-m 1G'!! It looks to me like one of those
And there lies the problem. qemu doesn't understand suffixes like 'G'.
If you
pass -m 1024, you'll boot just fine.
This is really annoying of qemu (it should either accept that input
properly
or bail out); a patch is welcome!
OK. Here's a function stolen blatantly from the kernel. Seems to work
OK for me for:
-m 1234
-m 1234M
-m 1G
-m 99G
diff -ru orig/qemu-0.9.1/vl.c qemu-0.9.1/vl.c
--- orig/qemu-0.9.1/vl.c2008-01-06 11:38:42.0 -0800
+++ qemu-0.9.1/vl.c 2008-01-08 11:23:29.0 -0800
@@ -8052,6 +8052,47 @@
}
#endif
+/**
+ * memparse - parse a string with mem suffixes into a number of bytes
+ * @ptr: Where parse begins
+ *
+ * Parses a string into a number. The number stored at @ptr is
+ * potentially suffixed with %M (for megabytes, or 1048576 bytes)
+ * or %G (for gigabytes, or 1073741824). If the number is
+ * suffixed with M or G, then the return value is the number
+ * multiplied by one megabyte or one gigabyte, respectively. No
+ * suffix implies megabytes.
+ */
+
+unsigned long long memparse (const char *ptr)
+{
+ char *endptr;
+ unsigned long ret = strtoull(ptr, endptr, 0);
+
+ switch (*endptr) {
+ case 'G':
+ case 'g':
+ ret = 10;
+ case 'M':
+ case 'm':
+ ret = 20;
+ break;
+ default:
+ /* for backward compatibility; qemu has
+* traditionally taken this in plain MB */
+ ret = 20;
+ break;
+ }
+ if (ret = 0)
+ help(1);
+ if (ret PHYS_RAM_MAX_SIZE) {
+ fprintf(stderr, qemu: at most %d MB RAM can be simulated\n,
+ PHYS_RAM_MAX_SIZE / (1024 * 1024));
+ exit(1);
+ }
+ return ret;
+}
+
#define MAX_NET_CLIENTS 32
int main(int argc, char **argv)
@@ -8402,14 +8443,7 @@
help(0);
break;
case QEMU_OPTION_m:
-ram_size = atoi(optarg) * 1024 * 1024;
-if (ram_size = 0)
-help(1);
-if (ram_size PHYS_RAM_MAX_SIZE) {
-fprintf(stderr, qemu: at most %d MB RAM can be
simulated\n,
-PHYS_RAM_MAX_SIZE / (1024 * 1024));
-exit(1);
-}
+ram_size = memparse(optarg);
break;
case QEMU_OPTION_d:
{
@@ -8664,6 +8698,7 @@
}
}
}
+fprintf(stderr, qemu: using %d MB RAM\n, ram_size20);
#ifndef _WIN32
if (daemonize !nographic vnc_display == NULL) {
-- Dave
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Slow Kernel Boot
With kvm-44, I thought my kernel was freezing during boot if I gave it 1G of RAM. But, it boots fine with 512M. So, I instrumented the kernel, and found out that it is just taking a long time to memset a 58MB area of memory for mem_map[]. It appears to be taking a mmio_exit for every access of every byte of memory. The end result is a ~100kbps memset() speed. Yes, 100 kilobytes/sec. I just tried kvm from git, and the kernel doesn't even get that far. I see this in debugfs insn_emulation:1393985 even before I get a single kernel message. And it keeps going up, fast. I can get the kernel to boot just fine if I give it less than 896MB of RAM. kvm-44 boots long enough for me to see a really funky e820 table: BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e8000 - 0010 (reserved) BIOS-e820: 0010 - fffbd000 (usable) BIOS-e820: fffbd000 - (reserved) Note that this is with '-m 1G'!! It looks to me like one of those sections is basically from 0x10 up to ~4G and *usable*. That doesn't look right. Eventually, the kvm-git one just pukes: exception 13 (33) rax 0002 rbx 2000 rcx rdx rsi 002a1358 rdi 00099100 rsp 673a rbp 673a r8 r9 r10 r11 r12 r13 r14 r15 rip fb24 rflags 00033086 cs 9020 (00090200/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ds 9000 (0009/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) es 9000 (0009/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ss 9000 (0009/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) fs 9000 (0009/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) gs 9000 (0009/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) tr (fffbd000/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 8f5c/27 idt 0/3ff cr0 6010 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 -- f0 01 f0 03 0e 00 00 00 70 01 70 03 0f 00 00 00 e8 01 e0 03 0c 00 00 00 68 01 60 03 0b 00 Aborted Any idea how to debug this? -- Dave - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Slow Kernel Boot
On Tue, 2008-01-08 at 00:16 +0200, Izik Eidus wrote: Dave Hansen wrote: With kvm-44, I thought my kernel was freezing during boot if I gave it 1G of RAM. But, it boots fine with 512M. So, I instrumented the kernel, and found out that it is just taking a long time to memset a 58MB area of memory for mem_map[]. It appears to be taking a mmio_exit for every access of every byte of memory. The end result is a ~100kbps memset() speed. Yes, 100 kilobytes/sec. I just tried kvm from git, and the kernel doesn't even get that far. I see this in debugfs insn_emulation:1393985 even before I get a single kernel message. And it keeps going up, fast. I can get the kernel to boot just fine if I give it less than 896MB of RAM. kvm-44 boots long enough for me to see a really funky e820 table: BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e8000 - 0010 (reserved) BIOS-e820: 0010 - fffbd000 (usable) BIOS-e820: fffbd000 - (reserved) Note that this is with '-m 1G'!! It looks to me like one of those sections is basically from 0x10 up to ~4G and *usable*. That doesn't look right. yea it really dont look right, it look like it for some reason map the whole memory up untill the bios to the kernel as memory it even map it on the pci hole so... hrmmm, very weird, what is your host info (32/64 amd/intel kernel...)? 64-bit intel host, kernel 2.6.24-rc5 Running kvm's current git userspace with modules from the same version. and what is the guest info (kernel 32/64...) ? 32-bit 2.6.23-rc6-mm1 and what happen if you run it with -no-kvm ? Both current -git and kvm-44 seem to lock up at early kernel boot before even early printk is available. But, GRUB comes up in both cases. -no-kvm doesn't seem to change things at all. -- Dave - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Slow Kernel Boot
On Tue, 2008-01-08 at 00:46 +0200, Izik Eidus wrote: Dave Hansen wrote: On Tue, 2008-01-08 at 00:16 +0200, Izik Eidus wrote: Dave Hansen wrote: With kvm-44, I thought my kernel was freezing during boot if I gave it 1G of RAM. But, it boots fine with 512M. So, I instrumented the kernel, and found out that it is just taking a long time to memset a 58MB area of memory for mem_map[]. It appears to be taking a mmio_exit for every access of every byte of memory. The end result is a ~100kbps memset() speed. Yes, 100 kilobytes/sec. I just tried kvm from git, and the kernel doesn't even get that far. I see this in debugfs insn_emulation:1393985 even before I get a single kernel message. And it keeps going up, fast. I can get the kernel to boot just fine if I give it less than 896MB of RAM. kvm-44 boots long enough for me to see a really funky e820 table: BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e8000 - 0010 (reserved) BIOS-e820: 0010 - fffbd000 (usable) BIOS-e820: fffbd000 - (reserved) Note that this is with '-m 1G'!! It looks to me like one of those sections is basically from 0x10 up to ~4G and *usable*. That doesn't look right. yea it really dont look right, it look like it for some reason map the whole memory up untill the bios to the kernel as memory it even map it on the pci hole so... hrmmm, very weird, what is your host info (32/64 amd/intel kernel...)? 64-bit intel host, kernel 2.6.24-rc5 Running kvm's current git userspace with modules from the same version. and what is the guest info (kernel 32/64...) ? 32-bit 2.6.23-rc6-mm1 and what happen if you run it with -no-kvm ? Both current -git and kvm-44 seem to lock up at early kernel boot before even early printk is available. But, GRUB comes up in both cases. -no-kvm doesn't seem to change things at all. -- Dave when you see the grub how much memory is it saying you have? GNU GRUB version 0.97 (639K lower / 4193279K upper memory) how can i get the image that you are using? The disk images? I made them myself and I've been using them for quite a while. Probably a year or more. (i dont know if it will be too much to ask, but if you run it with pure qemu (from qemu.org) is it working?) Ahhh. I'm using the ubuntu one, and it does the same thing. I guess that means I found a qemu bug. for some reason the e820 return a really false values for your guest... i would have suggest to check if you have the latest kvm bios(not in your physical computer bios) but it cannot be the problem as that you dont run it with more than 3.something giga... Yeah, I just updated the BIOSes. They're right out of KVM's git repo. -- Dave - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] 2.6.23 git current compile error on UP
drivers/kvm/kvm_main.c: In function `kvm_flush_remote_tlbs': drivers/kvm/kvm_main.c:220: error: implicit declaration of function `smp_call_function_mask' make[2]: *** [drivers/kvm/kvm_main.o] Error 1 make[1]: *** [drivers/kvm] Error 2 http://sr71.net/~dave/linux/config-kvm-up Looks like that function calls smp_call_function_mask() which is never defined for UP. Nobody else uses it that way, so I'm not sure what the right fix is. I'm not even sure kvm_flush_remote_tlbs() is safe with its raw_smp_processor_id() use. Is there a reason it can't get preempted? -- Dave - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm-27 vs 28 I/O speed
On Sat, 2007-07-14 at 09:27 +0300, Avi Kivity wrote: Dave, can you compare the output of hdparm -v /dev/hda? Maybe more clues there. slow: qemu:~# hdparm -v /dev/hda /dev/hda: multcount= 16 (on) IO_support = 0 (default 16-bit) unmaskirq= 0 (off) using_dma= 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead= 256 (on) geometry = 10402/255/63, sectors = 10485760, start = 0 fast: qemu:~# hdparm -v /dev/hda /dev/hda: multcount= 16 (on) IO_support = 0 (default 16-bit) unmaskirq= 0 (off) using_dma= 0 (off) keepsettings = 0 (off) readonly = 0 (off) readahead= 256 (on) geometry = 10402/255/63, sectors = 10485760, start = 0 -- Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm-27 vs 28 I/O speed
On Sun, 2007-07-15 at 21:27 +0200, Luca wrote: On 7/13/07, Dave Hansen [EMAIL PROTECTED] wrote: diff -ru kvm-fast-dmesg.txt kvm-slow-dmesg.txt Linux version 2.6.22 ([EMAIL PROTECTED]) (gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)) #13 Wed Jul 11 15:27:01 PDT 2007 Is this a vanilla 2.6.22? 32 bit? Yep, vanilla. @@ -107,20 +90,21 @@ PIIX3: IDE controller at PCI slot :00:01.1 PIIX3: chipset revision 0 PIIX3: not 100% native mode: will probe irqs later -PIIX3: neither IDE port enabled (BIOS) +ide0: BM-DMA at 0x1400-0x1407, BIOS settings: hda:pio, hdb:pio +ide1: BM-DMA at 0x1408-0x140f, BIOS settings: hdc:pio, hdd:pio Hum, FC6 PIIX driver always comes up with the same mode, regardless of what I'm doing to the controller... -- Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm-27 vs 28 I/O speed
On Sun, 2007-07-15 at 23:22 +0200, Luca wrote: Can you re-test KVM 27 with it's BIOS (i.e. use something like -L ~/src/kvm-27/qemu/pc-bios)? Doing that does appear to make it behave like kvm-28. DMA enabled, and slow I/O: qemu:~# hdparm -v /dev/hda /dev/hda: multcount= 16 (on) IO_support = 0 (default 16-bit) unmaskirq= 0 (off) using_dma= 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead= 256 (on) geometry = 10402/255/63, sectors = 10485760, start = 0 -- Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm-27 vs 28 I/O speed
On Fri, 2007-07-13 at 17:39 +0200, Luca wrote: Dave, can you confirm that backing out my patch fixes your speed issue? Sure, I'll check current git with and without your patch. I've reproduced that _applying_ it to kvm-27 creates the slowdown, but I'll double-check that backing it out restores things. -- Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm-27 vs 28 I/O speed
On Thu, 2007-07-12 at 08:37 +0300, Avi Kivity wrote: Can you confirm it by backing out that one patch? Do you know the git commit id by chance? -- Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm-27 vs 28 I/O speed
On Tue, 2007-07-10 at 08:44 +0300, Avi Kivity wrote: What does 'top' on the host show in both cases? On the fast one (kvm-27) I just see the dd as a flash in top. It doesn't stay for long. The VM isn't very responsive during the dd. On the slow (kvm-28) one, I see the dd in top creeping along, using ~2% of the CPU. The guest is responsive during this time There was a change in kvm userspace that affected IDE. Can you try kvm-27 userspace with a kvm-28 kernel module? That's actually what I've been doing the whole time. Sorry, my initial problem description must not have been very clear. I've been using the kvm-28 modules the entire time, and only varying the userspace. The IDE changes do look suspect. -- Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm-27 vs 28 I/O speed
On Sun, 2007-07-08 at 11:14 +0300, Avi Kivity wrote: Dave Hansen wrote: I've noticed that some of my tests run *MUCH* slower in kvm-28 than in 27. I'm sure that wall time is pretty wonky in the guests, but it is much slower in real-world time as well. Here's a little test to create a 32MB zeroed file with dd. Here it is from kvm-27 (this took ~5.5 seconds on my wristwatch): 33554432 bytes transferred in 0.052050 seconds (644657845 bytes/sec) 33554432 bytes transferred in 0.062933 seconds (533176451 bytes/sec) Here's the same thing from kvm-28 (~80 seconds on my wristwatch): 33554432 bytes transferred in 38.607065 seconds (869127 bytes/sec) 33554432 bytes transferred in 22.274318 seconds (1506418 bytes/sec) Same host kernel, same kvm kernel modules (from kvm-28) same guest kernel, same command-line options, same disk image. Any ideas what is going on? Is this repeatable? I don't see anything in kvm-27..kvm-28 that warrants such a regression. Right now, it's completely repeatable Things to check: - effect of pinning the vm onto one cpu (with 'taskset') Tried this. No effect that I can see at all. - does any counter in kvm_stat behave differently Nothing really stands out. The most strange thing to me is that the counters are very stationary on the slow one. It doesn't look like it is spinning on something, just that it is idle. Its counters during the dd look very much like the guest does when it is idle: the slow one: [EMAIL PROTECTED]:~$ KVM=28 HDA=qemu.raw ./run-qemu -snapshot idle: efer_reload156984 800 exits 395676 800 halt_exits 7165 100 invlpg 0 0 io_exits 123487 700 irq_exits1406 0 irq_window817 0 light_exits238692 0 mmio_exits 24716 0 pf_fixed 130354 0 pf_guest57309 0 request_irq 0 0 signal_exit 781 0 tlb_flush2267 0 dd'ing (mosly idle?): efer_reload197669 856 exits 455341 856 halt_exits 11568 100 invlpg 0 0 io_exits 159006 740 irq_exits2125 14 irq_window975 2 light_exits257672 0 mmio_exits 24716 0 pf_fixed 146646 0 pf_guest59596 0 request_irq 0 0 signal_exit 1383 14 tlb_flush2455 0 burst during dd: efer_reload205387 854 exits 4651662953 halt_exits 12471 98 invlpg 0 0 io_exits 165605 733 irq_exits2341 30 irq_window985 2 light_exits2597792099 mmio_exits 24716 0 pf_fixed 1487312082 pf_guest59596 0 request_irq 0 0 33554432 bytes transferred in 20.837575 seconds (1610285 bytes/sec) the fast one: $ KVM=27 HDA=qemu.raw ./run-qemu -snapshot idle: efer_reload164333 800 exits 416798 800 halt_exits 4570 100 invlpg 0 0 io_exits 132855 700 irq_exits 838 0 irq_window 2037 0 light_exits252465 0 mmio_exits 24716 0 pf_fixed 130325 0 pf_guest57275 0 request_irq 0 0 signal_exit 127 0 tlb_flush1864 0 during dd: efer_reload243917 29963 exits 523608 34205 halt_exits 6766 0 invlpg 0 0 io_exits 207716 28730 irq_exits1079 52 irq_window 45251232 light_exits2796954235 mmio_exits 24716 0 pf_fixed 1486564177 pf_guest59560 0 request_irq 0 0 signal_exit 154 7 tlb_flush2043 8 33554432 bytes transferred in 0.100797 seconds (332891147 bytes/sec) If you are using qcow, maybe the effect is due to the first test hitting a hole and the second being forced to read from disk. I recommend doing performance tests from a real partition or volume. I switched over to a raw image, and used -snapshot. I don't have the disk space to give them their own partitions right now. -- Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] kvm-27 host oopses
I had a host running kvm-27 oops on me last week. The system had been
up for about 2 weeks, and had probably run and stopped at least a couple
hundred kvm guests. I don't think it is very reproducible, but here it
is anyway. The host is running 2.6.20.4.
Here's the actual BUG_ON() that was hit:
static void *mmu_memory_cache_alloc(struct kvm_mmu_memory_cache *mc,
size_t size)
{
void *p;
BUG_ON(!mc-nobjs);
p = mc-objects[--mc-nobjs];
memset(p, 0, size);
return p;
}
There were several oopses in there, but I think probably on the first
one is of any real interest.
Jun 29 06:40:45 elm3b173 kernel: [982460.818197] [ cut here
]
Jun 29 06:40:45 elm3b173 kernel: [982460.827716] kernel BUG at
/home/dave/kvm-27/kernel/mmu.c:276!
Jun 29 06:40:45 elm3b173 kernel: [982460.841230] invalid opcode: [1] SMP
Jun 29 06:40:45 elm3b173 kernel: [982460.849587] CPU 0
Jun 29 06:40:45 elm3b173 kernel: [982460.853928] Modules linked in: kvm_intel
kvm aic94xx
Jun 29 06:40:45 elm3b173 kernel: [982460.864257] Pid: 11430, comm:
qemu-system-x86 Not tainted 2.6.20.4 #6
Jun 29 06:40:45 elm3b173 kernel: [982460.877419] RIP:
0010:[_end+124740199/2127394328] [_end+124740199/2127394328]
:kvm:mmu_memory_cache_alloc+0xf/0x40
Jun 29 06:40:45 elm3b173 kernel: [982460.896268] RSP: 0018:810129485548
EFLAGS: 00010246
Jun 29 06:40:45 elm3b173 kernel: [982460.907199] RAX: RBX:
8101d49cf820 RCX: 0002
Jun 29 06:40:45 elm3b173 kernel: [982460.921831] RDX: RSI:
0050 RDI: 8101f9ad24e8
Jun 29 06:40:45 elm3b173 kernel: [982460.936469] RBP: 810129485558 R08:
R09:
Jun 29 06:40:45 elm3b173 kernel: [982460.951101] R10: 8100504f4000 R11:
1000 R12: 8101f9ad2128
Jun 29 06:40:45 elm3b173 kernel: [982460.965739] R13: R14:
8101f9ad1990 R15: 8101f9ad2128
Jun 29 06:40:45 elm3b173 kernel: [982460.980375] FS: 2ba55b51fa00()
GS:807d4000() knlGS:
Jun 29 06:40:45 elm3b173 kernel: [982460.996918] CS: 0010 DS: 002b ES: 002b
CR0: 80050033
Jun 29 06:40:45 elm3b173 kernel: [982461.008690] CR2: b7f3e884 CR3:
0001d37b CR4: 26e0
Jun 29 06:40:45 elm3b173 kernel: [982461.023339] Process qemu-system-x86 (pid:
11430, threadinfo 810129484000, task 8102172900c0)
Jun 29 06:40:45 elm3b173 kernel: [982461.041972] Stack: 810088fd31e0
8101d49cf820 810129485588 8801f1d8
Jun 29 06:40:45 elm3b173 kernel: [982461.058500] 81019896fefc
8101d49cf820 0322 270d
Jun 29 06:40:45 elm3b173 kernel: [982461.073776] 8101294855c8
8801f5ea 8101f9ad2128
Jun 29 06:40:45 elm3b173 kernel: [982461.088592] Call Trace:
Jun 29 06:40:45 elm3b173 kernel: [982461.094248] [_end+124741616/2127394328]
:kvm:kvm_mmu_alloc_page+0x38/0x110
Jun 29 06:40:45 elm3b173 kernel: [982461.107243] [_end+124742658/2127394328]
:kvm:kvm_mmu_get_page+0xda/0x150
Jun 29 06:40:45 elm3b173 kernel: [982461.119888] [_end+124744897/2127394328]
:kvm:mmu_alloc_roots+0xf9/0x190
Jun 29 06:40:45 elm3b173 kernel: [982461.132360] [_end+124745400/2127394328]
:kvm:paging_new_cr3+0x30/0x60
Jun 29 06:40:45 elm3b173 kernel: [982461.144467] [_end+124724233/2127394328]
:kvm:set_cr3+0xb1/0xd0
Jun 29 06:40:45 elm3b173 kernel: [982461.155369] [_end+124818018/2127394328]
:kvm_intel:handle_cr+0xba/0x1d0
Jun 29 06:40:45 elm3b173 kernel: [982461.167839] [_end+124819078/2127394328]
:kvm_intel:kvm_handle_exit+0x7e/0xb0
Jun 29 06:40:45 elm3b173 kernel: [982461.181163] [_end+124819740/2127394328]
:kvm_intel:vmx_vcpu_run+0x224/0x2d0
Jun 29 06:40:45 elm3b173 kernel: [982461.194314] [_end+124732211/2127394328]
:kvm:kvm_vcpu_ioctl_run+0xfb/0x140
Jun 29 06:40:45 elm3b173 kernel: [982461.207305] [_end+124736555/2127394328]
:kvm:kvm_vcpu_ioctl+0x113/0x420
Jun 29 06:40:45 elm3b173 kernel: [982461.219779] [__alloc_pages+100/768]
__alloc_pages+0x64/0x300
Jun 29 06:40:45 elm3b173 kernel: [982461.231031] [find_busiest_group+673/1856]
find_busiest_group+0x2a1/0x740
Jun 29 06:40:45 elm3b173 kernel: [982461.243319]
[find_next_zero_string+39/128] find_next_zero_string+0x27/0x80
Jun 29 06:40:45 elm3b173 kernel: [982461.255772] [iommu_range_alloc+40/208]
iommu_range_alloc+0x28/0xd0
Jun 29 06:40:45 elm3b173 kernel: [982461.267531] [iommu_alloc+134/208]
iommu_alloc+0x86/0xd0
Jun 29 06:40:45 elm3b173 kernel: [982461.278256] [calgary_map_single+75/128]
calgary_map_single+0x4b/0x80
Jun 29 06:40:45 elm3b173 kernel: [982461.290199]
[tg3_start_xmit_dma_bug+1215/1344] tg3_start_xmit_dma_bug+0x4bf/0x540
Jun 29 06:40:45 elm3b173 kernel: [982461.303175] [dev_hard_start_xmit+131/256]
dev_hard_start_xmit+0x83/0x100
Jun 29 06:40:45 elm3b173 kernel: [982461.315457] [__qdisc_run+83/480]
__qdisc_run+0x53/0x1e0
Jun 29
Re: [kvm-devel] kvm-27 host oopses
On Mon, 2007-07-02 at 20:58 +0200, Luca wrote: MMU working memory was exhausted during a guest context switch. It has been fixed by: KVM: Lazy guest cr3 switching 4b82b37a35a085a07d9ed84efee06c69655fd3d1 which is included in KVM-28. OK, I'll give kvm-28 a shot. Thanks for the help! -- Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
