überXMHF (pc-intel-x86-32): Convert into a üobject collection with a single üobject task?

Hoping to replicate some of the ongoing work in converting the rpi3 version of the uberXMHF into a üobject collection by leveraging the next-gen uberspark framework, but adapted for the pc-intel-x86-32 version (see überXMHF (rpi3-armv8_32): Convert into a üobject collection with a single üobject).

Hopefully this will help update the existing x86 version of the micro hypervisor to be more in line with the future rpi3 version.

Linked PRs:


I also have some questions about the best way to start approaching this:

  1. Should the namespace and templars be something along the lines of uberspark/uobjcoll/platform/x86/uxmhf?
  2. I am assuming that arch is x86_32, cpu can be generic for now, and hpl should be hyp, but I am unsure about the sentinels.
  3. Should I also try to add the bootloader folder to the collection?

Thanks for the help!

Hey Ethan,

Thanks for initiating this task! I have moved it into the appropriate task category and have assigned it to you.

My responses to you inline:

Let us use the uberspark/uobjcoll/platform/pc/uxmhf namespace

Your arch, cpu and hpl specifications are correct. Leave the sentinels as “call” as in the armv8_32 branch

Good point. Leave out the bootloader for now, it will be replaced by a loader soon.

Thanks again for taking up this task to migrate the x86 version to the new bleeding-edge tool-chain!

Feel free to throw in other questions as you plow forward :wink:

Awesome, thanks for the help!
I did some work yesterday and I’m starting to think that it would be better to preserve the modularity of the uxmhf and instead of converting everything into a single uobject we should keep each uobject separate but still create a single collection.

It also seems like a logical first step is to convert the libxmhfgeec library to a uobjrtl, since every uxmhf uobject includes <xmhfgeec.h>. Would I be able to follow the same format as the crt library manifest, or do the casm files complicate things?

Hey Ethan,

Those are some good insights. My comments follow:

Indeed. The eventual goal is to be able to carve out individual uobjects for each folder of the uxmhf/xmhf-uobjs top-level folder.

However, for the first iteration, it would be good to just build a uobject collection with a single uobject so we don’t get in over our heads with sentinel debugging (inter-uobject flow) to start with. The idea would be to test a baremetal loader with the resulting uobject collection (with a single uobject) before moving on to splitting the uobject collection into multiple uobjects.

For the time-being you can still preserve the modularity by preserving the source folder organization within uxmhf/xmhf-uobjs when you make your uobject collection with a single uobject. Look into the arm uobject collection task to get an idea of how this is done using the manifest:

This one is a little tricky. libxmhfgeec provides wrappers to the uobject entry point as well as sentinel calls. This feature is now part of the next-generation tool-chain which automatically generate those stubs. Let us leave this library out for the time-being and proceed with the migration. We can revisit it when we hit a related hurdle…

Also use the following list of folders within the uxmhf/xmhf-uobjs top-level folder to start with:


Hey Amit,
That sounds good, thanks for the clarification. I’ve replaced all the headers and created a manifest for the uobjcollection and the main uobj, but now I’m running into an internal error “Not_found” when I run uberspark uobjcoll build (see attached verbose output) build_out.txt (10.4 KB)

I’ve pushed my work so far to the x86-uobjcol branch of my fork:

I believe that we’ll also need to work on a hyp sentinel for x86 as well. Currently I just switched the hpl to any to see if it will build, so I’m not sure if that’s what is causing the error above.


Hey, I think that you are getting that error because you need to define your main public method. In your main/uberspark.json

For example for uxmhf-rpi3 it looks like:

		/* public methods */
		"publicmethods" : {
			"main" : [
				"(uint32_t r0, uint32_t id, struct atag *at, uint32_t cpuid)", 

Thanks for the insight @Cap, can’t believe I forgot to add main lol

Unfortunately I’m still getting the same error even when main is defined: build_out.txt (11.4 KB)

I also noticed that there is another error earlier in the build process:

uberspark >> loading ld-bridge settings from file: /home/yeeb16/uberspark/bridges/ld-bridge/container/amd64/x86_32/generic/gnu-ld/v2.26.1/uberspark.json
uberspark >> ERROR: could not find valid header within manifest!

uberspark >> loaded ld_bridge settings

even though the ld_bridge builds successfully a couple lines later…

Unsure if this has anything to do with the error or if it even affects the build.

When you run uberspark staging create <platform> did you set platform to pc?

Yeah, all the commands I used are in the Makefile:

uberspark staging create uxmhf-pc
uberspark staging config-set --setting-name=bridge_cc_bridge --setting-value=container/amd64/x86_32/generic/gcc/v5.4.0
uberspark staging config-set --setting-name=bridge_as_bridge --setting-value=container/amd64/x86_32/generic/gnu-as/v2.26.1
uberspark staging config-set --setting-name=bridge_ld_bridge --setting-value=container/amd64/x86_32/generic/gnu-ld/v2.26.1


uberspark staging switch uxmhf-pc
uberspark uobjcoll build -v --platform=pc --arch=x86_32 --cpu=generic .

So after adding a bunch of debug print statements to the uberspark_uobjcoll.ml I found the issue, it was a little mistake on my part :sweat_smile:

I forgot to change the uobjcoll public method namespace from platform/x86 to platform/pc… Apparently this resulted in the uobj publicmethod hashtable returning a Not_found error since uberspark tried searching for the wrong namespace.

I noticed that there are a lot of configurable variables that get defined through a Makefile in the uxmhf code, and I’m wondering what the best way to set them using the new framework is.

Just to test I added some flags to the param field in the cc-bridge manifest (e.g. "-D__XMHFGEEC_TOTAL_UHSLABS__=1"), and while I make additional progress this doesn’t seem like a great way of implementing the configurables.

Great stuff Ethan! Thanks for your help @Cap

The new framework does not have this built-in yet, so for the time-being we will have to hard-code the defines in.

For the immediate short term we can perhaps add a new header file that defines these configuration variables instead of modifying the cc-bridge definitions.

I will setup a new task where I plan to work on adding this capability into the new tool-chain.


Alright, awesome!

The main error I’m running into now is that there are a lot of types that are defined in the libxmhfhw library, and a few from the xmhf-hwm.h include.
I converted the old hwm folder to an uobject, though I saw that there is an hwm namespace in the next-gen toolkit and I’m not sure how to convert it into that. I’m also wondering if we’ll need to port over libxmhfhw for the types and casm functions.


The hwm folder should not be converted into a üobject. It is part of the core überSpark framework and will go into the hwm namespace eventually.

This is perhaps a good first task to undertake. I have created the task for this conversion here:


Branch off current überSpark develop branch for the task above. We can merge it back into überSpark develop once you are done with the libxmhfhw migration as a üobject runtime library and then continue with the überXMHF branch for this task.

Let me know if you have any further questions. The libxmhfhw task referenced above should be the discussion thread for libxmhfhw migration related questions.

Thanks @yeeb!

Hey Ethan,

Great work on the hardware model (überSpark: Add x86_32 hardware model to next-gen toolkit) and hardware uobject runtime library (überSpark: Add x86_32 hardware üobject runtime library) tasks which have now been completed and merged!

Can you please refresh this thread with the current status and what you think are next steps of the x86_32 micro-hypervisor uobj collection build?


Hey Amit,

The current hurdle is decoupling the xmhfgeec library from the hypervisor. A couple of files rely on the slab_params_t struct defined in the geec library, and there are a couple of function calls and define references to the library as well.

build.txt (122.5 KB)
I’ve attached the build log if you want to get a better idea of the progress. There’s a couple of linker warnings for the casm files in the hw uobjrtl and some -Wint-conversion warnings that might turn into errors later on, but we should probably focus on the geec library for now.

Do you think removing all refences to the xmhfgeec library is a good start? It’s been a while since I’ve worked on the uxmhf so let me know what you think the best path is.


Thanks for the update Ethan!

How about we just inline the contents of xmhfgeec library into the uobj collection for now? i.e., include the source files and headers into the main uobj manifest. We could bring it in as a folder xmhfgeec/* within the main uobj. Thoughts?

Sounds good. I’ll update the thread once I hit another problem.