Building x86 uberapp

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?


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!

Here is the build log: buildlog.txt (287.5 KB)

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!

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?

I’m still having my original error when I build using the default config. x86_startup.log (47.9 KB)

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

  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! 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.


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.

@amitvasudevan, thanks for all of the help debugging to ensure the hypervisor was booting. I can boot the hypervisor and run the existing hypapps (e.g., syscalllog).

I did some initial steps to port uhcalltest from rpi3 to x86 git branch. However, I am halting when I attempt to boot my modified hypervisor. newhypapp_halting.log (20.6 KB)

This looks like you have not defined your uberapp (uhcalltest) properly within the micro-hypervisor. Can you post your uxmhf/

do you mean /uxmhf/xmhf-uobjs/

Ahh yes indeed :slight_smile:

Ok as a first step, I would recommend replacing an existing extension (starting with xh_ prefix) within instead of adding a new one. This will help us get the shortest path towards getting your new extension in the mix.

So, perhaps replace xh_hyperdep with xh_uhcalltest