[kvm-devel] Problems with vmwarevga and graphical syslinux menus

2008-03-12 Thread Jeremy Katz
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

2008-01-02 Thread Jeremy Katz
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.

2007-12-03 Thread Jeremy Katz
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

2007-09-19 Thread Jeremy Katz
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 | BIOS_PRINTF_INFO, 1. Floppy\n);
+bios_printf(BIOS_PRINTF_SCREEN | BIOS_PRINTF_INFO, 2. Hard drive\n);
+bios_printf

Re: [kvm-devel] [PATCH] Add support for a basic boot menu to the bios

2007-09-12 Thread Jeremy Katz
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 passing extra LDFLAGS to qemu's configure

2007-08-20 Thread Jeremy Katz
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

2007-06-19 Thread Jeremy Katz
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] [RFT] kvm host suspend/resume

2007-01-31 Thread Jeremy Katz
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:[f8e2ac6a]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:
[c04051c9] show_trace_log_lvl+0x1a/0x2f
[c0405279] show_stack_log_lvl+0x9b/0xa3
[c0405415] show_registers+0x194/0x26a
[c0405618] die+0x12d/0x242
[c0605167] do_trap+0x79/0x91
[c0405bbb] do_invalid_op+0x97/0xa1
[c0604f3c] error_code+0x7c/0x84
[f8e6dae0] vcpu_load+0x3b/0x3f [kvm]
[f8e6e0c7] kvm_dev_ioctl+0x208/0x117a [kvm]
[c0482c36] do_ioctl+0x22/0x67
[c0482ecd] vfs_ioctl+0x252/0x265
[c0482f29] sys_ioctl+0x49/0x64
[c0404058] 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: [f8e2ac6a] 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.phpp=sourceforgeCID=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

2007-01-31 Thread Jeremy Katz

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=lnkkid=120709bid=263057dat=121642___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel


[kvm-devel] Oops after resume from suspend

2007-01-24 Thread Jeremy Katz
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:[f8fb814c]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:
 [c04051c9] show_trace_log_lvl+0x1a/0x2f
 [c0405279] show_stack_log_lvl+0x9b/0xa3
 [c0405415] show_registers+0x194/0x26a
 [c0405618] die+0x12d/0x242
 [c0605197] do_trap+0x79/0x91
 [c0405bbb] do_invalid_op+0x97/0xa1
 [c0604f6c] error_code+0x7c/0x84
 [f8fb92e8] vmx_create_vcpu+0x54/0x97 [kvm_intel]
 [f8ee1f3c] kvm_dev_ioctl+0x16a/0x1150 [kvm]
 [c0482e72] do_ioctl+0x22/0x67
 [c0483109] vfs_ioctl+0x252/0x265
 [c0483165] sys_ioctl+0x49/0x64
 [c0404058] 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: [f8fb814c] 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.phpp=sourceforgeCID=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

2006-12-21 Thread Jeremy Katz
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.phpp=sourceforgeCID=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

2006-12-20 Thread Jeremy Katz
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.phpp=sourceforgeCID=DEVDEV___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel