Your message dated Sun, 18 Oct 2009 11:22:59 +0300
with message-id <[email protected]>
and subject line [solved] kvm regression: Vista fails to boot with kvm 70 but 
boots fine with 69
has caused the Debian Bug report #488555,
regarding kvm regression: Vista fails to boot with kvm 70 but boots fine with 69
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
488555: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488555
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: kvm
Version: 70+dfsg-1
Severity: important

I have a windows vista ultimate 64-bit virtual machine
installed with kvm 69 here. It installs, boots and works fine
with kvm 69, however since I upgraded to kvm 70 today, this
machine does not boot anymore.

It seems to stuck in the NT bootloader. It displays an error message
quickly (too quick to read) and then hangs showing a screen with random
colors and symbols.

Thinking that it could be a boot sector virus, I downgraded back to kvm 69
and the machine works fine again.

I don't know how to provide more useful information. Please tell me if
there is something I can do to help tracing the bug.

-- Package-specific info:


selected information from lshal(1):



/proc/cpuinfo:

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 16
model           : 2
model name      : AMD Phenom(tm) 8450 Triple-Core Processor
stepping        : 3
cpu MHz         : 1050.000
cache size      : 512 KB
physical id     : 0
siblings        : 3
core id         : 0
cpu cores       : 3
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb 
rdtscp lm 3dnowext 3dnow constant_tsc rep_good pni monitor cx16 popcnt lahf_lm 
cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs
bogomips        : 4212.10
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 16
model           : 2
model name      : AMD Phenom(tm) 8450 Triple-Core Processor
stepping        : 3
cpu MHz         : 1050.000
cache size      : 512 KB
physical id     : 0
siblings        : 3
core id         : 2
cpu cores       : 3
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb 
rdtscp lm 3dnowext 3dnow constant_tsc rep_good pni monitor cx16 popcnt lahf_lm 
cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs
bogomips        : 4209.24
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

processor       : 2
vendor_id       : AuthenticAMD
cpu family      : 16
model           : 2
model name      : AMD Phenom(tm) 8450 Triple-Core Processor
stepping        : 3
cpu MHz         : 1050.000
cache size      : 512 KB
physical id     : 0
siblings        : 3
core id         : 1
cpu cores       : 3
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb 
rdtscp lm 3dnowext 3dnow constant_tsc rep_good pni monitor cx16 popcnt lahf_lm 
cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs
bogomips        : 4209.06
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate




-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.25-gkserver-amd64 (SMP w/3 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



--- End Message ---
--- Begin Message ---
Hi,

After quite a long time, I decided to dig again into this issue out of 
curiosity and I found lots of information. However, this bug is 
overcomplicated and may even not be a bug in kvm/bochs bios itself, so I don't 
expect it to be fixed and thus I am closing this bug from the debian BTS. I 
will post here all the information that I found, just in case someone is 
interested. If you are not interested, you can stop reading here :)

So, here it goes. An important detail about the whole story is that the vista 
copy I had installed back then was a cracked one. I didn't crack it myself, so 
I didn't know, I just got a dvd that I thought it was the authentic 30-day 
trial edition, but it wasn't. (I didn't need it more anyway, I just wanted to 
compile a program I was developing to do some testing and then get rid of the 
vm). After I discovered that, I found and installed an authentic version, 
and... it worked!

So, I tried to analyze the nature of the crack. It is actually a modified 
version of grub4dos (but with no source code anywhere), which replaces the 
boot sector of the partition with the standard grub4dos boot sector code which 
loads the "grldr" (aka grub stage2) file from vista's boot partition, which is 
modified to do 2 extra functions: 1) load some extra bios code into a reserved 
memory area and 2) chainload vista's loader without checking for menu.lst or 
displaying a prompt. When vista loads, it reads the code from this reserved 
area, and it thinks this is an OEM bios, so it shows itself as activated.

I tried to play with the kvm bios to see if I can get any information from 
there. First I tried to find out what's the main difference in the bios code 
between kvm-69 and  kvm-70. The result is, there is no difference, but the 
important detail is that the kvm-69 debian package was built with gcc 4.2, 
while kvm-70 was built with gcc 4.3. So, I tried to build the kvm 70 bios 
(just bios.bin) with gcc 4.2 and it worked just fine!!! (For the record, 
gcc-4.4 doesn't work either, but gcc-3.x works.)

Then I tried to build the latest in debian (kvm-85) bios with gcc 4.2 to see 
if that works too. Unfortunately, this doesn't work. After lots of hours 
bisecting, I found out that reverting the commit 
3f2bafc58f9f2cfe1a635cd6815b18c04106ecb1 ("Add S3 state to DSDT. Handle resume 
event in the BIOS."), which originates from the bochs repository, fixes the 
problem again. So, applying the patch for the revert and a small modification 
in the makefile of the bios to use gcc-4.2, the bios builds and works fine with 
this vista loader.

But that still didn't give me enough information. I tried to install grub4dos 
on an authentic version of windows in kvm. This works fine, so the problem 
relies in the modifications... I tried to debug it using the qemu gdb 
integration. I found it stucks at two instructions:

At first it stucks here (stucks = the $eip register never changes):
0xd79a: rep movsb %ds:(%si),%es:(%di)

and then if I set $eip to the next instruction and continue, it stucks again 
at:
0xd80e: add    (%si),%cl

now if I set $eip to the next instruction again and continue, it boots fine.
I suspect that this code is inside the modified grub stage2 image, but I can't 
be sure of that.

But that still doesn't give any information, so I quit. I don't need to get it 
fixed anyway, as I don't use this virtual machine anymore (plus, if I need to 
install windows again in the future for a similar reason, I can use the 
authentic version, which works fine). It was just that geek curiosity in me 
that wanted to find out more :)

Sorry for the noise.
Regards,
George

PS: all the testing happened with kvm-85 and the gdb stuff was done with qemu 
0.10.6 (kvm doesn't work with gdb for some reason, should I file another bug? 
:P)


--- End Message ---

Reply via email to