Please find the boot-up serial log. x86_startup.txt (24.4 KB)
Looking at the log it seems like the micro-hypervisor is restarting during startup due to some failure. Is that the full log? The last line I am seeing is: gp_s5_setupcpustate[6]: Reloaded segment registers
that is the full log.
Is hardware virtualization enabled in the BIOS and how many cores are enabled? Can you ensure hyper-threading is enabled? Also please boot into the vanilla OS (without hypervisor) and post the output of cat /proc/cpuinfo once you have enabled hyperthreading.
Thanks!
Yes, virtualization support is enabled, and all cores are enabled.
I’m not sure about hyper-threading being enabled (in the BIOS I don’t have a hyper-threading option, I have Intel SpeedStep and Intel TurboBoost–but looking at the Dell documentation these seem to be different from hyper-threading).
cpuinfo.txt (4.5 KB)
Aight. Lets try the following.
Can you rebuild the micro-hypervisor by passing --disable-drt and --disable-dmap to the configure option, boot it, and post the resulting serial log?
Thanks!
It seems that my CPU might not support hyper-threading: i5-4590
When I tried to build the hypervisor with these earlier, I ran into issues with the --disable-drt option.
Makefile: 47: recipe for target 'init.o' failed
make[1]: *** [init.o] Error 2
Makefile: 87: recipe for target 'uxmhf-bootloader' failed
make: *** [uxmhf-bootloader] Errror 2
Can you post the full build log for this error? Thanks!
And as a note, I when I try and boot with only --diable-dmap I get the following serial output.
x86_startup_disablt-dmap.txt (20.6 KB)
This sounds like it is an expected result with vt-d. Where you can have the following combinations:
drt | dmap | Allowed?
--------------------------
y | y | y
y | n | y
n | n | y
Ok. I just submitted a PR for fixing the build error when --disable-drt and --disable-dmap is provided to configure.
See: überXMHF (pc-intel-x86_32): fix build error when specifying configure --disable-drt parameter
Would be great if you can test. Thanks!
@amitvasudevan,
Thanks! I have rebuild the hypervisor using --disable-drt --disable-dmap. However, I am still experiencing errors booting. See output serial log: x86_startup_disable-drt-dmap.txt (18.6 KB)
Ok, I just tried booting uberXMHF from the branch in the aforementioned PR (as is with no added changes) with the default configure options (--enable-debug-serial=0x3f8) and was able to boot successfully. My machine is a Dell Optiplex 9020 with Intel Core i7-4770 and 4GB of memory. I have attached the serial log for the successful boot below:
uxmhf-x86-drtdmap-bootup.log (65.1 KB)
Can you try booting uberXMHF built from the branch in the PR and compare?
Doing a diff of our serial outputs, it seems that around line 109 (mine), 120 (yours) that there is a difference in the TXT.ERRORCODE=. Mine has a value of
80000000
processor error 0
while yours is just 0
----- update -------
We also have different values for rdsp.checksum. I have 30 while you have 20
rdsp.rsdtaddress, rdsp.xsdtaddress, gp_s1_scaniommu len=, rsdt.length, rsdt.checksum, gp_s1_scaniommu: dmar table addr=, gp_s2_sdminitdevmap: numentries_sysdev_mmioregions=, bytesgp_s2_setupgdt: setup TSS CPU idx={1,3,5,7}
It seems that I experience an error somewhere around the gp_s5_setupcpustate[3]: Setup VMX state, as I never see these outputs:
gp_s5_setupcpustate[2]: TR loaded
slab_main[2]: IDT loaded
========= more updates ==============
As I look closer, it looks like this is a loop that goes through all of the processors.
It appears that my log succeeds for cpu=2 and then fails when attempting to run gp_s5_* for cpu=4.
I’m curious if this is because my CPU doesn’t support hyper-threading, and only has 4 cores (thus no CPU=4)?
Ok, I think I know what the issue is. Stay tuned for a PR…
Aight @Cap. Please find the PR here: überXMHF(pc-intel-x86_32): add support for non linear CPU id mappings setup by some BIOSes
Can you give it a whirl and see where you land up with the default configure options (i.e., with DRT and DMAP enabled)?
Thanks!
Thanks! I tried this new PR. I am making additional progress. But it seems that my boot is stalling after setting up the VMX state on each CPU. Looking at your log, I don’t ever get an XC_INIT[5]: got control: ESP=0ae1cf28
Log attached: x86_startup_pr.log (26.7 KB)
Ok, I have pushed another changeset to the PR. This adds a configure option --with-debug-serial-maxcpus that allows you to specify the number of CPUs (cores) on your platform when debugging is turned on.
Please rebuild the micro-hypervisor using configure --enable-debug-serial=0x3f8 --with-debug-serial-maxcpus=4 and give it a whirl again.
Thanks!
1 Like
I think that this has solved my loading the hypervisor issues. I now just need to debug a grub related issue when grub is invoked the second time.