[kvm-devel] Problems with vmwarevga and graphical syslinux menus
The changes so that the vmwarevga code respects the E820 region runs afoul of the fact that the VBE bios used has a hard-coded base address for vesa modes. Thus when syslinux uses VBE to do its graphical bits, the lfb address doesn't match what the bios thinks it is :-/ Test case is any Fedora boot.iso or live CD from the past year or so. Jeremy - 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] KVM-58 -- existing VM just hangs with black screen
On Wed, 2008-01-02 at 19:13 +0200, Avi Kivity wrote: > Can you try the option '-no-kvm' both with kvm-57 and kvm-58? -no-kvm works. I can hit this just booting a live CD both on a 32bit and a 64bit host. It looks like compatibility with old kernels is broken (the kvm package only contains the userspace bits, the kernel bits come from the kernel which is currently 2.6.24-rc6). Building an updated kernel module makes things start to work on my laptop Jeremy - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. 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] How to handle kvm-abi-10 case for other archs.
On Sat, 2007-12-01 at 12:10 +0200, Avi Kivity wrote: > Zhang, Xiantao wrote: > > I think new archs for kvm doesn't need to care about kvm-abi > > case in their code, since current abi is bigger than 10. But in current > > libkvm.c, we can see that many abi-specific code in it. How to handle it > > ? Can we use __x86__ macro to make it sightless for other archs or > > other good methods ? > > > > #ifdef is okay for this. Actually we can probably remove abi 10 support > since the F7 kernel now supports the modern ABI (I don't think anybody > else uses abi 10, which is pre 2.6.22 when we announced ABI compatibility. > > Jeremy, is removing abi 10 support fine with you? I note that both the > kernel supports the new ABI and F7 userspace doesn't require it, so > we're fine on both counts. Yeah, that sounds like it should be fine. The updates have been out for quite a while at this point Jeremy - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Add support for a basic boot menu to the bios
On Sun, 2007-09-16 at 22:00 +0200, Avi Kivity wrote:
> > The attached patch adds support for a relatively basic boot device
> > selection menu to the bochs bios code.
[snip]
> This is nice! Two comments:
>
> - it would be nice for qemu to provide the bios an indication if the
> '-boot' parameter was specified to qemu. if so, the bios should skip
> the menu on first bootup, reducing the boot delay. On subsequent boots
> the menu should be offered. This is primarily useful in managed
> environments.
While this could be nice, at the same time, -boot is going to be getting
passed for a long time, even when it's no longer needed, just due to
people not updating their tools. So I almost think it's better to take
the 3 second hit since it's going to be there every other time. We
could tweak it to be a little bit less, but 3 seems in line with what
other BIOSes seem to do.
> - coding this stuff in rombios32.c instead of rombios.c (with its
> strange idea of C) is *much* preferable for maintainability. As far as
> i can tell, there is no reason not to do so, especially for code which
> is not called from the 16-bit OS.
The code is called from the 16-bit OS, though. It needs to be done
after rom scanning has been done so that we can show network or not as
appropriate. And unless I'm missing something, calling into rombios32.c
outside of rombios32_init() is going to add just as much
hard-to-maintain code.
Updated patch against kvm git attached that actually works with kvm.
Also ends up being a little bit simpler because we're doing less mucking
around with the timer.
Signed-off-by: Jeremy Katz <[EMAIL PROTECTED]>
Jeremy
diff --git a/bios/BIOS-bochs-latest b/bios/BIOS-bochs-latest
index c10ae62..e13af69 100644
Binary files a/bios/BIOS-bochs-latest and b/bios/BIOS-bochs-latest differ
diff --git a/bios/BIOS-bochs-legacy b/bios/BIOS-bochs-legacy
index 131e62b..5c03460 100644
Binary files a/bios/BIOS-bochs-legacy and b/bios/BIOS-bochs-legacy differ
diff --git a/bios/rombios.c b/bios/rombios.c
index ac918ad..4ebdb71 100644
--- a/bios/rombios.c
+++ b/bios/rombios.c
@@ -1950,6 +1950,228 @@ print_cdromboot_failure( code )
return;
}
+#define WAIT_HZ 18
+/**
+ * Check for keystroke.
+ * @returnsTrue if keystroke available, False if not.
+ */
+Bit8u check_for_keystroke()
+{
+ASM_START
+mov ax, #0x100
+int #0x16
+jz no_key
+mov al, #1
+jmp done
+no_key:
+xor al, al
+done:
+ASM_END
+}
+
+/**
+ * Get keystroke.
+ * @returnsBIOS scan code.
+ */
+Bit8u get_keystroke()
+{
+ASM_START
+mov ax, #0x0
+int #0x16
+xchg ah, al
+ASM_END
+}
+
+/**
+ * Waits (sleeps) for the given number of ticks.
+ * Checks for keystroke.
+ *
+ * @returns BIOS scan code if available, 0 if not.
+ * @param ticks Number of ticks to sleep.
+ * @param stop_on_key Whether to stop immediately upon keypress.
+ */
+Bit8u wait(ticks, stop_on_key)
+ Bit16u ticks;
+ Bit8u stop_on_key;
+{
+long ticks_to_wait, delta;
+Bit32u prev_ticks, t;
+Bit8u scan_code = 0;
+
+/*
+ * The 0:046c wraps around at 'midnight' according to a 18.2Hz clock.
+ * We also have to be careful about interrupt storms.
+ */
+ticks_to_wait = ticks;
+prev_ticks = read_dword(0x0, 0x46c);
+do
+{
+t = read_dword(0x0, 0x46c);
+if (t > prev_ticks)
+{
+delta = t - prev_ticks; /* The temp var is required or bcc screws up. */
+ticks_to_wait -= delta;
+}
+else if (t < prev_ticks)
+ticks_to_wait -= t; /* wrapped */
+prev_ticks = t;
+
+if (check_for_keystroke())
+{
+scan_code = get_keystroke();
+bios_printf(BIOS_PRINTF_DEBUG, "Key pressed: %x\n", scan_code);
+if (stop_on_key)
+return scan_code;
+}
+} while (ticks_to_wait > 0);
+return scan_code;
+}
+
+static void clearscreen() {
+/* Hide cursor, clear screen and move cursor to starting position */
+ASM_START
+push bx
+push cx
+push dx
+
+mov ax, #0x100
+mov cx, #0x1000
+int #0x10
+
+mov ax, #0x700
+mov bh, #7
+xor cx, cx
+mov dx, #0x184f
+int #0x10
+
+mov ax, #0x200
+xor bx, bx
+xor dx, dx
+int #0x10
+
+pop dx
+pop cx
+pop bx
+ASM_END
+}
+
+int bootmenu(selected)
+ int selected;
+{
+Bit8u scode;
+int max;
+
+/* get the number of boot devices */
+max = read_word(IPL_SEG, IPL_COUNT_OFFSET);
+
+for(;;) {
+clearscreen();
+bios_printf(BIOS_PRINTF_SCREEN | BIOS_PRINTF_INFO, "\n\n\n\n\n\n\n");
+bios_printf(BIOS_PRINTF_SCREEN | BIOS_PRINTF_INFO, " Select boot device\n\n");
+bios_printf(BIOS_PRINTF_SCREEN
Re: [kvm-devel] [PATCH] Add support for a basic boot menu to the bios
On Wed, 2007-09-12 at 15:19 -0500, Anthony Liguori wrote: > Very cool! Long-term itch of mine scratched :-) > My mailer doesn't want to quote your patch, but I noticed the following: > > > + > > +/* set the default based on the keypress or menu */ [snip] > But the CMOS memory isn't persisted in QEMU. Another nice patch > (although certainly not required IMHO for this to go in), would be to > make nvram optionally persistent for QEMU so these settings would > persist across boots. Yeah, the lack of persistence is sort of a "feature" in this case. If you use the similar menus on most real hardware, they don't persist (you have to go into the bios setup screens to make it persist). That said, if things were to persist, then we'd probably want to change the patch to set something else which was looked at prior to the CMOS Jeremy - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. 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] Add support for a basic boot menu to the bios
I sent this to the bochs list earlier today, but given that kvm is
already carrying patches for the BIOS, it may be worthwhile/interesting
to add this also as it can make the user experience substantially nicer.
-- Begin forwarded message --
The attached patch adds support for a relatively basic boot device
selection menu to the bochs bios code.
Instead of immediately booting from the boot device set in the cmos, we
wait for 3 seconds for the user to press F10; if they press it, then we
show a basic boot menu that they can select what device to boot from.
Otherwise, we continue on with what was setup before running the virtual
machine. The advantage is that users can change their boot device just
on rebooting a virtual machine rather than having to stop and then
restart it.
This includes the wait routines added by VirtualBox
(http://www.virtualbox.org) in their modifications to the rombios as
they made things a bit easier.
Jeremy
Index: rombios.c
===
RCS file: /cvsroot/bochs/bochs/bios/rombios.c,v
retrieving revision 1.182
diff -u -u -r1.182 rombios.c
--- rombios.c 1 Aug 2007 17:09:51 - 1.182
+++ rombios.c 11 Sep 2007 15:10:53 -
@@ -1950,6 +1950,289 @@
return;
}
+#define WAIT_HZ 64
+/**
+ * Check for keystroke.
+ * @returnsTrue if keystroke available, False if not.
+ */
+Bit8u check_for_keystroke()
+{
+ASM_START
+mov ax, #0x100
+int #0x16
+jz no_key
+mov al, #1
+jmp done
+no_key:
+xor al, al
+done:
+ASM_END
+}
+
+/**
+ * Get keystroke.
+ * @returnsBIOS scan code.
+ */
+Bit8u get_keystroke()
+{
+ASM_START
+mov ax, #0x0
+int #0x16
+xchg ah, al
+ASM_END
+}
+
+/**
+ * Waits (sleeps) for the given number of ticks.
+ * Checks for keystroke.
+ *
+ * @returns BIOS scan code if available, 0 if not.
+ * @param ticks Number of ticks to sleep.
+ * @param stop_on_key Whether to stop immediately upon keypress.
+ */
+Bit8u wait(ticks, stop_on_key)
+ Bit16u ticks;
+ Bit8u stop_on_key;
+{
+long ticks_to_wait, delta;
+Bit32u prev_ticks, t;
+Bit8u scan_code = 0;
+
+/*
+ * The 0:046c wraps around at 'midnight' according to a 18.2Hz clock.
+ * We also have to be careful about interrupt storms.
+ */
+ASM_START
+pushf
+sti
+ASM_END
+ticks_to_wait = ticks;
+prev_ticks = read_dword(0x0, 0x46c);
+do
+{
+ASM_START
+hlt
+ASM_END
+t = read_dword(0x0, 0x46c);
+if (t > prev_ticks)
+{
+delta = t - prev_ticks; /* The temp var is required or bcc screws up. */
+ticks_to_wait -= delta;
+}
+else if (t < prev_ticks)
+ticks_to_wait -= t; /* wrapped */
+prev_ticks = t;
+
+if (check_for_keystroke())
+{
+scan_code = get_keystroke();
+bios_printf(BIOS_PRINTF_DEBUG, "Key pressed: %x\n", scan_code);
+if (stop_on_key)
+return scan_code;
+}
+} while (ticks_to_wait > 0);
+ASM_START
+popf
+ASM_END
+return scan_code;
+}
+
+void wait_init()
+{
+/* The default is 18.2 ticks per second (~55ms tick interval).
+ Set the timer to 16ms ticks (64K / (Hz / (PIT_HZ / 64K)) = count).
+ 0x1 / (1000 / (1193182 / 0x1)) = 1193 (0x04a9)
+ 0x1 / ( 128 / (1193182 / 0x1)) = 9321 (0x2469)
+ 0x1 / ( 64 / (1193182 / 0x1)) = 18643 (0x48d3) */
+ASM_START
+mov al, #0x34 ; timer0: binary count, 16bit count, mode 2
+out 0x43, al
+mov al, #0xd3 ; Low byte - 64Hz
+out 0x40, al
+mov al, #0x48 ; High byte - 64Hz
+out 0x40, al
+ASM_END
+}
+
+void wait_uninit()
+{
+ASM_START
+pushf
+cli
+
+/* Restore the timer to the default 18.2Hz. */
+mov al, #0x34 ; timer0: binary count, 16bit count, mode 2
+out 0x43, al
+xor ax, ax; maximum count of H = 18.2Hz
+out 0x40, al
+out 0x40, al
+
+/*
+ * Reinitialize the tick and rollover counts since we've
+ * screwed them up by running the timer at WAIT_HZ for a while.
+ */
+pushad
+push ds
+mov ds, ax ; already 0
+call timer_tick_post
+pop ds
+popad
+
+popf
+ASM_END
+}
+
+static void clearscreen() {
+/* Hide cursor, clear screen and move cursor to starting position */
+ASM_START
+push bx
+push cx
+push dx
+
+mov ax, #0x100
+mov cx, #0x1000
+int #0x10
+
+mov ax, #0x700
+mov bh, #7
+xor cx, cx
+mov dx, #0x184f
+int #0x10
+
+mov ax, #0x200
+xor bx, bx
+xor dx, dx
+int #0x10
+
+pop dx
+pop cx
+pop bx
+ASM_END
+}
+
+int bootmenu(selected)
+ int selected;
+{
+Bit8u scode;
+int max;
+
+/* get the number of boot devices */
+max = read_word(IPL_SEG, IPL_COUNT_OFFSET);
+
+for(;;) {
+clearscreen();
+printf("\n\n\n\n\n\n
[kvm-devel] [PATCH] Add support for passing extra LDFLAGS to qemu's configure
There are cases[1] where you want to be able to pass more ldflags to
qemu's configure. This lets you set LDFLAGS to accomplish that
Signed-off-by: Jeremy Katz <[EMAIL PROTECTED]>
Jeremy
[1] Such as with the new build-id support in binutils so that you can
pass --build-id to the linker while still building with the old compiler
as needed for qemu
diff -up kvm-35/configure.ldflags kvm-35/configure
--- kvm-35/configure.ldflags 2007-08-20 17:40:39.0 -0400
+++ kvm-35/configure 2007-08-20 17:40:50.0 -0400
@@ -83,7 +83,7 @@ target_cpu() {
(cd user; ./configure --prefix="$prefix" --kerneldir="$libkvm_kerneldir")
(cd qemu; ./configure --target-list=$(target_cpu)-softmmu --cc="$qemu_cc" \
--disable-kqemu --extra-cflags="-I $PWD/../user" \
---extra-ldflags="-L $PWD/../user" \
+--extra-ldflags="-L $PWD/../user $LDFLAGS" \
--enable-kvm --kernel-path="$libkvm_kerneldir" \
--enable-alsa \
${disable_gcc_check:+"--disable-gcc-check"} \
-
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] Suspending with kvm and kvm_loaded
On Tue, 2007-06-19 at 11:05 +0300, Avi Kivity wrote: > Richard Hughes wrote: > > On Sun, 2007-06-17 at 11:10 +0300, Avi Kivity wrote: > >> I posted a patchset which does just that, when the F kernel > >> integrates > >> it (through inclusion of 2.6.23 or by patching the current kernel), > >> Fedora will be able to suspend/resume just fine. > >> > > I've tried the current kvm kernel git tree and that failed to suspend > > with a running VM. Is there a different branch I should try? > > I've rebased the 'hotplug' branch. Please try it out. I actually extracted the patch set yesterday for the Fedora kernel and it's in today's rawhide kernel. Should be a good way to get some extra testing on it. In my quick trial run yesterday, it worked quite nicely! Jeremy - 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] Suspending with kvm and kvm_loaded
On Fri, 2007-06-15 at 13:56 +0100, Richard Hughes wrote: > I'm getting lots of bug reports about installing kvm and then suspend > breaking. Some background: when the fedora package kvm is installed, > then the kvm and kvm_xxx modules get auto loaded at boot. To get the > machine to suspend again, the modules have to be rmmod'd on suspend and > then modprobe'd on resume. > > We can automate the rmmodding and modprobeing adding a simple script in > pm-utils (/etc/pm/sleep.d/) on package install, but to avoid just > bodging the issue I wanted to ask you guys first. Also could go into the kvm package instead. Probably shouldn't be done generally in pm-utils (the mantra of fix the real problem, don't add more bodges around it ;-) > * Is it safe to rmmod kvm and kvm_x before suspend? Relatively. Although I vaguely remember having it cause an interesting problem once or twice, but not reproducibly enough to actually figure out what was going on. > * Is there any work on adding suspend and resume hooks into the kvm > driver to support suspend? The bigger thing is there's a need to add some hooks so that kvm can do things at the right point in the suspend sequence. Avi has patches, but they missed the .22 merge window. I need to sit down (maybe today) and refresh the Fedora kvm patch; I was thinking of pushing those changes in at the same time so that this can go away. And if that pans out for a little bit in rawhide, it could easily go out as an F7 update. Jeremy - 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] [RFT] kvm host suspend/resume
Avi Kivity wrote:
Jeremy Katz wrote:
On Wed, 2007-01-31 at 12:32 +0200, Avi Kivity wrote:
Jeremy Katz wrote:
Avi Kivity wrote:
I've committed kvm support for host suspend-to-disk (and hopefully
resume too). This means you can suspend your machine with running
vms, and resume it later will all vms returning to the saved
state. This should please laptop owners.
So testing with trunk (r4365) + 2.6.20-rc5-ish, I'm able to suspend
and resume with the modules loaded. Starting a guest after resume
gets the following oops in the host; guest is in the grub menu at
that point.
2.6.20-rc6 can't suspend my test machine (regardless of kvm), so this
possible fix is completely untested.
Failure looks basically the same. Will try to do some more
investigation later today.
Looks like ->hardware_enable() was not called for some reason.
Sprinkling printks in the cpu hotplug and resume callbacks will help.
Multiple things failing here together.
1) With the versioning of Fedora kernels, things were falling back to
the compat version of smp_call_function_single which then doesn't seem
to work properly (->hardware_disable() and ->hardware_enable() never get
called AFAICT)
2) Switching to use the real smp_call_function_single, I get an oops on
suspend since we're trying to run code on the dead cpu. Attached patch
makes it so that we do ->hardware_enable() and ->hardware_disable() when
the cpu is in a functioning state. With it, I can suspend/resume
successfully with no guests running. With a guest running, it's a bit
of a toss-up. But one step at a time :)
Signed-off-by: Jeremy Katz <[EMAIL PROTECTED]>
Jeremy
Index: kvm_main.c
===
--- kvm_main.c (revision 4369)
+++ kvm_main.c (working copy)
@@ -2107,13 +2107,15 @@
int cpu = (long)v;
switch (val) {
- case CPU_DEAD:
+ case CPU_DOWN_PREPARE:
case CPU_UP_CANCELED:
+ printk(KERN_INFO, "kvm: disabling virtualization on CPU%d\n", cpu);
decache_vcpus_on_cpu(cpu);
smp_call_function_single(cpu, kvm_arch_ops->hardware_disable,
NULL, 0, 1);
break;
- case CPU_UP_PREPARE:
+ case CPU_ONLINE:
+ printk(KERN_INFO, "kvm: enabling virtualization on CPU%d\n", cpu);
smp_call_function_single(cpu, kvm_arch_ops->hardware_enable,
NULL, 0, 1);
break;
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFT] kvm host suspend/resume
On Wed, 2007-01-31 at 12:32 +0200, Avi Kivity wrote: > Jeremy Katz wrote: > > Avi Kivity wrote: > >> I've committed kvm support for host suspend-to-disk (and hopefully > >> resume too). This means you can suspend your machine with running > >> vms, and resume it later will all vms returning to the saved state. > >> This should please laptop owners. > > > > So testing with trunk (r4365) + 2.6.20-rc5-ish, I'm able to suspend > > and resume with the modules loaded. Starting a guest after resume > > gets the following oops in the host; guest is in the grub menu at that > > point. > > > > 2.6.20-rc6 can't suspend my test machine (regardless of kvm), so this > possible fix is completely untested. Failure looks basically the same. Will try to do some more investigation later today. kvm: msrs: 1 invalid opcode: [#1] SMP last sysfs file: /devices/pci:00/:00:1c.0/:02:00.0/cmd Modules linked in: snd_hda_intel snd_hda_codec button kvm_intel kvm tun i915 drm ipt_MASQUERADE iptable_nat nf_nat autofs4 hidp rfcomm l2cap sunrpc bridge dummy nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables cpufreq_ondemand video sbs i2c_ec dock battery asus_acpi backlight ac ipv6 parport_pc lp parport snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device hci_usb snd_pcm_oss sr_mod cdrom bluetooth snd_mixer_oss fw_ohci e100 mii i2c_i801 snd_pcm iTCO_wdt iTCO_vendor_support fw_core i2c_core ipw3945 ieee80211 ieee80211_crypt sdhci snd_timer serio_raw ata_piix snd soundcore snd_page_alloc mmc_core ata_generic joydev sg dm_snapshot dm_zero dm_mirror dm_mod ahci libata sd_mod scsi_mod ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd CPU:1 EIP:0060:[]Not tainted VLI EFLAGS: 00210207 (2.6.19-1.2913.fc7 #1) EIP is at vmx_vcpu_load+0x49/0xc1 [kvm_intel] eax: c3c63d24 ebx: e71d047c ecx: 018e2100 edx: c075eb48 esi: 0001 edi: c3c63dc0 ebp: c3c63d3c esp: c3c63d14 ds: 007b es: 007b ss: 0068 Process qemu (pid: 12413, ti=c3c63000 task=e656a030 task.ti=c3c63000) Stack: 22311000 c3c63dc0 c3c63d3c e71d0484 e71d047c c3c63d4c f8e6dae0 f8e6debf fffe c3c63f44 f8e6e0c7 0200 bfca8a68 e71d f7fffa80 f7fffa80 f4ac9138 c3c63d98 c0473860 Call Trace: [] show_trace_log_lvl+0x1a/0x2f [] show_stack_log_lvl+0x9b/0xa3 [] show_registers+0x194/0x26a [] die+0x12d/0x242 [] do_trap+0x79/0x91 [] do_invalid_op+0x97/0xa1 [] error_code+0x7c/0x84 [] vcpu_load+0x3b/0x3f [kvm] [] kvm_dev_ioctl+0x208/0x117a [kvm] [] do_ioctl+0x22/0x67 [] vfs_ioctl+0x252/0x265 [] sys_ioctl+0x49/0x64 [] syscall_call+0x7/0xb === Code: 00 40 39 73 48 89 45 e8 74 07 89 d8 e8 5d ff ff ff 8b 0c b5 80 b3 71 c0 ba 48 eb 75 c0 8b 43 04 39 04 0a 74 31 89 04 0a 8d 45 e8 <0f> c7 30 0f 96 c0 84 c0 74 21 8b 45 e8 8b 55 ec c7 04 24 a3 c4 EIP: [] vmx_vcpu_load+0x49/0xc1 [kvm_intel] SS:ESP 0068:c3c63d14 Jeremy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFT] kvm host suspend/resume
Avi Kivity wrote: > I've committed kvm support for host suspend-to-disk (and hopefully > resume too). This means you can suspend your machine with running vms, > and resume it later will all vms returning to the saved state. This > should please laptop owners. So testing with trunk (r4365) + 2.6.20-rc5-ish, I'm able to suspend and resume with the modules loaded. Starting a guest after resume gets the following oops in the host; guest is in the grub menu at that point. kvm: msrs: 1 invalid opcode: [#1] SMP last sysfs file: /class/net/eth0/carrier Modules linked in: snd_hda_intel snd_hda_codec button kvm_intel kvm rfcomm hidp l2cap i915 drm ipt_MASQUERADE iptable_nat nf_nat ipv6 autofs4 sunrpc bridge dummy nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables cpufreq_ondemand video sbs i2c_ec dock battery asus_acpi backlight ac parport_pc lp parport sr_mod cdrom snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss hci_usb fw_ohci snd_pcm e100 mii bluetooth sdhci ata_piix fw_core ipw3945 mmc_core sg serio_raw i2c_i801 iTCO_wdt iTCO_vendor_support snd_timer ieee80211 ieee80211_crypt ata_generic i2c_core snd soundcore snd_page_alloc joydev dm_snapshot dm_zero dm_mirror dm_mod ahci libata sd_mod scsi_mod ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd CPU:1 EIP:0060:[]Not tainted VLI EFLAGS: 00010207 (2.6.19-1.2913.fc7 #1) EIP is at vmx_vcpu_load+0x49/0xc1 [kvm_intel] eax: db452cbc ebx: f2f5847c ecx: 018e2100 edx: c075eb2c esi: 0001 edi: db452dc0 ebp: db452cd4 esp: db452cac ds: 007b es: 007b ss: 0068 Process qemu (pid: 21176, ti=db452000 task=e2020030 task.ti=db452000) Stack: 144d9000 db452dc0 db452cd4 f2f58484 f2f5847c db452ce4 f8e61ad6 f2f5847c f2f5847c db452cf0 f8e6322f 0001 db452d4c f8d3cc69 c0603728 0002 c0603751 f2f58484 Call Trace: [] show_trace_log_lvl+0x1a/0x2f [] show_stack_log_lvl+0x9b/0xa3 [] show_registers+0x194/0x26a [] die+0x12d/0x242 [] do_trap+0x79/0x91 [] do_invalid_op+0x97/0xa1 [] error_code+0x7c/0x84 [] vcpu_load+0x3b/0x3f [kvm] [] kvm_resched+0x20/0x23 [kvm] [] kvm_vmx_return+0x1d0/0x1df [kvm_intel] [] kvm_dev_ioctl+0x284/0x117a [kvm] [] do_ioctl+0x22/0x67 [] vfs_ioctl+0x252/0x265 [] sys_ioctl+0x49/0x64 [] syscall_call+0x7/0xb === Code: 00 40 39 73 48 89 45 e8 74 07 89 d8 e8 5d ff ff ff 8b 0c b5 80 b3 71 c0 ba 2c eb 75 c0 8b 43 04 39 04 0a 74 31 89 04 0a 8d 45 e8 <0f> c7 30 0f 96 c0 84 c0 74 21 8b 45 e8 8b 55 ec c7 04 24 a3 d4 EIP: [] vmx_vcpu_load+0x49/0xc1 [kvm_intel] SS:ESP 0068:db452cac Jeremy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Oops after resume from suspend
Avi Kivity wrote:
Jeremy Katz wrote:
When using kvm on my laptop, I get the following oops if I try using kvm
after a suspend (ACPI S3)/resume cycle. At first I thought it went away
if I unloaded the module before suspending and then reloading it
afterwards, but I can't reproduce that working now, so I might have just
been hallucinating. Thoughts of things to try?
Module unload/reload should work. Can you try adding printks in
hardware_disable() and hardware_enable()?
Okay, what was going wrong with reloading was the difference between -
and _ with module naming :-/ *sigh* Actually getting the module
unloaded then makes things work fine.
For real suspend support, we need to flush any cached state on Intel
cpus (vmcs_clear), and to do the hardware_disable()/hardware_enable()
cycle. Should be easy.
The obvious approach (attached) fails to resume -- there may be console
output, but hard to tell on my laptop. I'll dig up a box with a serial
port to try there and see if I get something across serial console with it.
Jeremy
Index: kvm_main.c
===
--- kvm_main.c (revision 4328)
+++ kvm_main.c (working copy)
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2052,6 +2053,29 @@
.priority = 0,
};
+static int kvm_suspend(struct sys_device *dev, pm_message_t state)
+{
+on_each_cpu(kvm_arch_ops->hardware_disable, 0, 0, 1);
+return 0;
+}
+
+static int kvm_resume(struct sys_device *dev)
+{
+on_each_cpu(kvm_arch_ops->hardware_enable, 0, 0, 1);
+return 0;
+}
+
+static struct sysdev_class kvm_sysclass = {
+ .resume = kvm_resume,
+ .suspend = kvm_suspend,
+ set_kset_name("kvm"),
+};
+
+static struct sys_device kvm_sysdevice = {
+.id = 0,
+.cls = &kvm_sysclass,
+};
+
static __init void kvm_init_debug(void)
{
struct kvm_stats_debugfs_item *p;
@@ -2100,6 +2124,13 @@
on_each_cpu(kvm_arch_ops->hardware_enable, 0, 0, 1);
register_reboot_notifier(&kvm_reboot_notifier);
+r = sysdev_class_register(&kvm_sysclass);
+if (r)
+return r;
+r = sysdev_register(&kvm_sysdevice);
+if (r)
+return r;
+
kvm_chardev_ops.owner = module;
r = misc_register(&kvm_dev);
@@ -2121,6 +2152,9 @@
{
misc_deregister(&kvm_dev);
+sysdev_unregister(&kvm_sysdevice);
+sysdev_class_unregister(&kvm_sysclass);
+
unregister_reboot_notifier(&kvm_reboot_notifier);
on_each_cpu(kvm_arch_ops->hardware_disable, 0, 0, 1);
kvm_arch_ops->hardware_unsetup();
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Oops after resume from suspend
When using kvm on my laptop, I get the following oops if I try using kvm after a suspend (ACPI S3)/resume cycle. At first I thought it went away if I unloaded the module before suspending and then reloading it afterwards, but I can't reproduce that working now, so I might have just been hallucinating. Thoughts of things to try? invalid opcode: [#1] SMP last sysfs file: /class/net/lo/ifindex Modules linked in: ipw3945 ieee80211 ieee80211_crypt rfcomm hidp l2cap ohci1394 ieee1394 button kvm_intel tun kvm i915 drm autofs4 sunrpc bridge dummy nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables cpufreq_ondemand video sbs i2c_ec dock battery asus_acpi backlight ac ipv6 parport_pc lp parport snd_hda_intel snd_hda_codec snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss hci_usb snd_mixer_oss sr_mod snd_pcm cdrom sdhci e100 snd_timer bluetooth serio_raw mmc_core mii snd soundcore snd_page_alloc iTCO_wdt iTCO_vendor_support ata_piix i2c_i801 i2c_core ata_generic joydev sg dm_snapshot dm_zero dm_mirror dm_mod ahci libata sd_mod scsi_mod ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010286 (2.6.19-1.2909.fc7 #1) EIP is at vmcs_clear+0x1b/0x46 [kvm_intel] eax: ef399d34 ebx: e6459000 ecx: e6459000 edx: 0400 esi: f0efc47c edi: ebp: ef399d3c esp: ef399d24 ds: 007b es: 007b ss: 0068 Process qemu-kvm (pid: 5834, ti=ef399000 task=f0712030 task.ti=ef399000) Stack: f0efc47c ef399d3c f8fb8c2f 26459000 ef399d4c f8fb92e8 f0efc47c f0efc484 ef399f44 f8ee1f3c f0efc000 f72bba84 f185ef90 ef399db0 c04cffbd c21c336c 000a 004c Call Trace: [] show_trace_log_lvl+0x1a/0x2f [] show_stack_log_lvl+0x9b/0xa3 [] show_registers+0x194/0x26a [] die+0x12d/0x242 [] do_trap+0x79/0x91 [] do_invalid_op+0x97/0xa1 [] error_code+0x7c/0x84 [] vmx_create_vcpu+0x54/0x97 [kvm_intel] [] kvm_dev_ioctl+0x16a/0x1150 [kvm] [] do_ioctl+0x22/0x67 [] vfs_ioctl+0x252/0x265 [] sys_ioctl+0x49/0x64 [] syscall_call+0x7/0xb === Code: c0 ff 05 20 da ee f8 eb 05 b8 01 00 00 00 5d c3 55 89 c1 89 e5 83 ec 18 8d 80 00 00 00 40 89 45 f8 8d 45 f8 c7 45 fc 00 00 00 00 <66> 0f c7 30 0f 96 c0 84 c0 74 1e 8b 45 f8 8b 55 fc 89 4c 24 04 EIP: [] vmcs_clear+0x1b/0x46 [kvm_intel] SS:ESP 0068:ef399d24 Jeremy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Match virtual machine processor vendor to that of the host
On Thu, 2006-12-21 at 16:26 +0200, Avi Kivity wrote:
> Jeremy Katz wrote:
> > On Thu, 2006-12-21 at 11:20 +0200, Avi Kivity wrote:
> >> Jeremy Katz wrote:
> >>> Currently, kvm ends up just using the standard qemu cpu initialization.
> >>> This means that all x86_64 virtual machines appear to have an
> >>> AuthenticAMD (AMD64) processor. This ends up causing a problem when
> >>> booting some x86_64 Linux kernels as they attempt to do AMD64 specific
> >>> initialization for things like performance counters. Since those MSRs
> >>> aren't supported on the Intel host, the virtual machine is halted.
> >>>
> >>> The attached patch makes it so that we check the actual cpu type of the
> >>> host and then provide the same cpu type for the virtual machine.
> >>>
> >> Windows crashes immediately with this patch (STOP: 0x7E (0xc005
> >> 0xF724879C 0xF7A168DC 0xF7A165D8) for those who know how to decode
> >> BSODs), so either it's doing too much or not enough.
> >>
> > 32 or 64 bit and what are you running for the host? There's definitely
> > more that _could_ be mirrored.
> >
>
> Host 64-bit Intel Pentium D; guest is 32-bit Windows XP Pro (64-bit
> Windows depends on the next qemu merge).
>
> >> Note that we support migration from Intel to AMD and vice versa, so it
> >> would be good to supply a command line parameter to set the cpuid (to a
> >> least common denominator CPU).
> >
> > The problem is that with current CPUs, I don't know that there really is
> > a least common denominator anymore. Both Intel and AMD have their own
> > implementation of a number of things which aren't "core" bits --
> > performance counters, things to handle microcode updates, etc. :-/
> >
>
> One way around is to report a non-AMD, non-Intel processor ('FakeKVM'
> signature?)
I'm not sure how different OS's will actually respond to that, either...
I have a sinking suspicion that it would definitely throw some for a
loop based on prior experiences with a new processor rollout :/
> But usually guests test for the feature using cpuid, so we just have to
> turn off a lot of bits there.
There are a lot of things which aren't exposed as explicit features via
cpuid that an OS can and will care about. Using cpuid to mask sse3 or
the like should be fine, but really doesn't take care of the breadth of
what's needed.
> Note that qemu manages to run most hosts without emulating all those
> weird features, so it shouldn't be too hard.
For i386 qemu, it emulates a processor before a lot of the
vendor-specific features were really available (it looks like it
pretends to be a PentiumII). x86_64 is much more of a state where there
are differences between the Intel and AMD chips and the "right" thing is
switched at runtime.
> > Are there any docs for the current state of migration? Depending on how
> > it's done,
>
> Migration just moves the cpu state, the hardware state, and memory to
> another host. Live migration does this in parallel with execution.
>
> What do you mean by "current state of migration"? How to run it for
> testing?
Yep
> > this may not at least make things any "worse" for the
> > migration case since we're only changing things at CPU startup, not
> > runtime calls to cpuid.
> >
>
> If you tell the host, for instance, that you support the AMD performance
> counters and then you migrate to Intel, things will break. Best to tell
> the guest that you don't support performance counters at all (this is
> necessary from an isolation point of view as well).
The only thing that keys supporting the specific processor
features/msrs, though, is the vendor and model. eg, see
arch/x86_64/kernel/nmi.c:setup_apic_nmi_watchdog(). It's not only
things that are expressed specifically from the cpuid (eg, mmx or sse)
> Having said all that, I think the problem with your patch is just some
> minor internal inconsistency that causes Windows to barf. Decoding the
> oops from the microsoft docs will probably shed some light on the matter.
Indeed -- I'll try to find a Windows CD so that I can take a look this
afternoon.
Jeremy
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] Match virtual machine processor vendor to that of the host
On Thu, 2006-12-21 at 11:20 +0200, Avi Kivity wrote: > Jeremy Katz wrote: > > Currently, kvm ends up just using the standard qemu cpu initialization. > > This means that all x86_64 virtual machines appear to have an > > AuthenticAMD (AMD64) processor. This ends up causing a problem when > > booting some x86_64 Linux kernels as they attempt to do AMD64 specific > > initialization for things like performance counters. Since those MSRs > > aren't supported on the Intel host, the virtual machine is halted. > > > > The attached patch makes it so that we check the actual cpu type of the > > host and then provide the same cpu type for the virtual machine. > > Windows crashes immediately with this patch (STOP: 0x7E (0xc005 > 0xF724879C 0xF7A168DC 0xF7A165D8) for those who know how to decode > BSODs), so either it's doing too much or not enough. 32 or 64 bit and what are you running for the host? There's definitely more that _could_ be mirrored. > Note that we support migration from Intel to AMD and vice versa, so it > would be good to supply a command line parameter to set the cpuid (to a > least common denominator CPU). The problem is that with current CPUs, I don't know that there really is a least common denominator anymore. Both Intel and AMD have their own implementation of a number of things which aren't "core" bits -- performance counters, things to handle microcode updates, etc. :-/ Are there any docs for the current state of migration? Depending on how it's done, this may not at least make things any "worse" for the migration case since we're only changing things at CPU startup, not runtime calls to cpuid. Jeremy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] Match virtual machine processor vendor to that of the host
Currently, kvm ends up just using the standard qemu cpu initialization.
This means that all x86_64 virtual machines appear to have an
AuthenticAMD (AMD64) processor. This ends up causing a problem when
booting some x86_64 Linux kernels as they attempt to do AMD64 specific
initialization for things like performance counters. Since those MSRs
aren't supported on the Intel host, the virtual machine is halted.
The attached patch makes it so that we check the actual cpu type of the
host and then provide the same cpu type for the virtual machine.
Jeremy
Index: qemu/exec-all.h
===
--- qemu/exec-all.h (revision 4142)
+++ qemu/exec-all.h (working copy)
@@ -603,3 +603,7 @@
}
#endif
+
+#ifdef USE_KVM
+#include "qemu-kvm.h"
+#endif
--- qemu/target-i386/helper2.c (revision 4142)
+++ qemu/target-i386/helper2.c (working copy)
@@ -141,6 +141,9 @@
#ifdef USE_KQEMU
kqemu_init(env);
#endif
+#ifdef USE_KVM
+kvm_cpu_init(env);
+#endif
return env;
}
--- qemu/qemu-kvm.c (revision 4142)
+++ qemu/qemu-kvm.c (working copy)
@@ -590,6 +590,56 @@
.io_window = kvm_io_window,
};
+static inline unsigned int cpuid_ebx(unsigned int op)
+{
+unsigned int eax, ebx;
+__asm__ volatile
+ ("movl %%ebx, %%esi\n\t"
+ "cpuid\n\t"
+ "xchgl %%ebx, %%esi"
+ : "=a" (eax), "=S" (ebx)
+ : "0" (op));
+return ebx;
+}
+
+static void kvm_update_cpuid(CPUState *env)
+{
+int family, model, stepping;
+
+/* we need to differentiate intel vs amd processors here.
+ * FIXME: should match more cpuid capabilities here */
+switch (cpuid_ebx(0)) {
+case 0x756e6547: /* Intel */
+env->cpuid_vendor1 = 0x756e6547; /* "Genu" */
+env->cpuid_vendor2 = 0x49656e69; /* "ineI" */
+env->cpuid_vendor3 = 0x6c65746e; /* "ntel" */
+family = 6;
+model = 15;
+stepping = 3;
+break;
+case 0x68747541: /* AMD */
+env->cpuid_vendor1 = 0x68747541; /* "Auth" */
+env->cpuid_vendor2 = 0x69746e65; /* "enti" */
+env->cpuid_vendor3 = 0x444d4163; /* "cAMD" */
+family = 6;
+model = 2;
+stepping = 3;
+break;
+default:
+/* we don't know what it is, just return */
+return;
+break;
+}
+
+env->cpuid_version = (family << 8) | (model << 4) | stepping;
+}
+
+int kvm_cpu_init(CPUState *env)
+{
+kvm_update_cpuid(env);
+return 0;
+}
+
int kvm_qemu_init()
{
/* Try to initialize kvm */
Index: qemu/qemu-kvm.h
===
--- qemu/qemu-kvm.h (revision 4142)
+++ qemu/qemu-kvm.h (working copy)
@@ -10,4 +10,6 @@
int kvm_cpu_exec(CPUState *env);
int kvm_update_debugger(CPUState *env);
+int kvm_cpu_init(CPUState *env);
+
#endif
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
