QEMU 1.2.0 boot fails since hrev45518

[korli]

on hrev45526. Boots OK when removing hrev45518.

(tested with GCC 4.6.3 and GCC 4.6.4) QEMU emulator version 1.2.0 (qemu-kvm-1.2.0+noroms-0ubuntu2.12.10.3, Debian)

Haiku revision: hrev45526
reserve_io_interrupt_vectors: reserved 2 vectors starting from 98
CPU 0: type 0 family 6 extended_family 0 model 3 extended_model 0 stepping 3, string 'GenuineIntel'
CPU 0: vendor 'Intel' model name 'QEMU Virtual CPU version 1.2.0'
CPU 0: features: fpu de pse tsc msr pae mce cx8 apic sep pge cmov pat mmx fxsr sse sse2 sse3 popcnt hypervisor dts ecmd aperfmperf epb
PANIC: Unexpected exception "General Protection Exception" occurred in kernel mode! Error code: 0x0

Welcome to Kernel Debugging Land...
Thread 0 "" running on CPU 0
stack trace for thread 0 ""
    kernel stack: 0x00000000 to 0x00000000
frame               caller     <image>:function + offset
 0 81004d1c (+  32) 801105a4  
 1 81004d3c (+  16) 8008309e  
 2 81004d4c (+  12) 80103a62  
 3 81004d58 (+  48) 80083af1  
 4 81004d88 (+  80) 8008477e  
 5 81004dd8 (+  64) 800849fa  
 6 81004e18 (+  32) 80084c5b  
 7 81004e38 (+ 176) 80111a28  
 8 81004ee8 (+  12) 8010647e  
kernel iframe at 0x81004ef4 (end = 0x81004f44)
 eax 0x80172d01    ebx 0x81004f88     ecx 0x1b0       edx 0x0
 esi 0x80172c80    edi 0x80172d0c     ebp 0x81004fb0  esp 0x81004f28
 eip 0x80103937 eflags 0x210092 
 vector: 0xd, error code: 0x0
 9 81004ef4 (+ 188) 80103937  
10 81004fb0 (+  32) 8004d159  
11 81004fd0 (+  32) 80056285  

[korli]

GCC2 also affected.

[pdziepak]

Strange thing is that I am not able to reproduce this bug and do not see anything that would cause general protection exception that early. CPU does rise that exception when reserved bits are set but NX-bit is enabled and used a bit later.

Anyway, hrev45541 fixes a problem with violation of reserved bits and I would appreciate if you could check whether it solves this problem. If it does not I would need a log with TRACE_BOOT enabled (in src/system/kernel/main.cpp).

[korli]

I tested a bit. It seems this version of QEMU falsely reports it supports Energy Perf Bias feature when the host CPU does. Removing the use of the corresponding MSR (line 742 of arch_cpu.cpp x86_read_msr(IA32_MSR_ENERGY_PERF_BIAS) ) or forcing a cpu type on the QEMU launch command line are valid workarounds.

We could check for the CPU name for this QEMU version "QEMU Virtual CPU version 1.2.0", but it's probably not so important, and could already be fixed in QEMU trunk. OK for closing as invalid.

[pdziepak]

Actually, it was our mistake. x86, when asked for a CPUID leaf it does not recognize, returns a value of the basic leaf with the highest number making Haiku incorrectly believe that IA32_MSR_ENERGY_PERF_BIAS is available.

Fixed in hrev45544.

[korli]

Confirmed fixed. Thanks!