vit9696
commented
5 years ago Well, um, could you explain how to read the core count with KVM and these CPUIDs? I checked the article, but failed to find it quickly.
Closed Leoyzen closed 5 years ago
vit9696
commented
5 years ago Well, um, could you explain how to read the core count with KVM and these CPUIDs? I checked the article, but failed to find it quickly.
Leoyzen
commented
5 years ago @vit9696 according to the link and some search, should check cpu ecx bit 31 to determine if is in a vm. sample code
static inline int cpuid_hv_bit() {
int ecx;
__asm__ volatile("cpuid" \
: "=c"(ecx) \
: "a"(0x01));
return (ecx >> 31) & 0x1;
}If it in a vm (QEMU/VMWare), it should be the same as Penryn to get topology( from CpuidCacheEax I suppose). So the key is determine if opencore running in a VM (by the hypervisor bit I mentioned)., then do the same as Penryn (which works for us). I'm not quite familar with cpuid programming.
Also I've found when using opencore with amd vm, it fails with same issues ( opencore get topology from "0x8000001E" but it hangs there.
Leoyzen
commented
5 years ago I found that passthrough AMD cpu to vm is similar with this issue which K10_PSTATE_STATUS does not simluate by QEMU/KVM, then the CoreFrequencyID/CoreDivisorID will be zero, and the bus ratio divide brokes then.
It will be nice to add visualization support like hypervisor flags indicate.
vit9696
commented
5 years ago I believe we resolved this by now, thank you for the patch!
steeve
commented
4 years ago @Leoyzen could you share your qemu command line? I'm trying to get it to work with qemu+hvf, but it ends with a X64 exception.
Here is my command line:
QEMU_CPU_FLAGS="+pcid,+ssse3,+sse4.2,+popcnt,+avx,+aes,+xsave,+xsaveopt,check"
QEMU_CPU="Penryn,vendor=GenuineIntel,+invtsc,vmware-cpuid-freq=on,${QEMU_CPU_FLAGS}"
args=(
"-show-cursor"
"-accel hvf"
"-serial file:/tmp/oc.log"
"-machine pc-q35-2.11"
"-cpu ${QEMU_CPU}"
"-m 4096"
"-smp 4,cores=2"
"-rtc base=localtime,clock=host,driftfix=slew"
"-usb"
"-device usb-tablet"
"-smbios type=2"
"-drive if=pflash,format=raw,readonly,file=OVMF_CODE-pure-efi.fd"
"-drive if=pflash,format=raw,readonly,file=OVMF_VARS-pure-efi.fd"
"-device ich9-ahci,id=sata"
"-device ide-hd,bus=sata.0,drive=bootloader"
"-drive id=bootloader,if=none,format=raw,file=oc.raw"
"-device ide-hd,bus=sata.1,drive=macos"
"-drive id=macos,if=none,format=raw,file=mojave.raw"
)See the attached OpenCore log
When using QEMU smp or libvirt topology and cpu model newer than Penryn, the kernel panic will occur.
When digging to the code I found that opencore get the topology from msr 0x35 which KVM not implemented yet and then get wrong topology (1 core 1thread) which makes the kernel panic.
Maybe we should check Penryn or "Hypervisor" cpuid feature(details from here to make topology works.
code snippet related:
The oc boot logs: LEFT: Penyn with topology: RIGHT: IvyBridge with topology:
The Kernel panic: