überXMHF (x86_32): add support for debug output to memory

This task will:

1. add support for intel 9900K and z390 chipset (without DRTM because my testbed has no TXT configs)
2. Add a configuration to print strings to memory instead of using serial output. The reason is that my testbed has no serial output or SOL.

Related discussion threads:

  1. Add x64 support

PRs:


Merges:


In uberspark, if I modify “src-nextgen/loaders/baremetal/x86_32/grub-legacy/debug/dbgapi.c” or “src-nextgen/loaders/baremetal/x86_32/grub-legacy/init.lds” or any files in loaders folder, should I make uberspark again or just make install?

Compilation ignores my intentional compilation errors in these files, so I guess I can just make install, right?

Could I increase the MAX CPUS beyond 8 (e.g., to be 64)? Newer CPUs have 12 cores or more.

Just make install will suffice. Do note that the changes you make to the loader should support any class of x86_32 processors. So if there is a need for a specific gen 9 setup, we should discuss more on how to organize the loader.

Correct, your compilation errors will only be caught when the loader is built as part of the uobjcoll build. So you can just do make install to plug in the loader and then test the loader build via uobjcoll build. In the future, we should probably introduce a way to just build the loader for development and testing purposes…

I would be careful here since every CPU has allocated stack, so the memory map can get large and you may need to tweak the size of the uobjcoll (which are all doable currently). I would say, we should base MAX CPUS on the number of cores we see for the platforms we support currently. So if we support a 12 core platform, it makes sense to have MAX CPUS bumped up to 12.

I see, then I’ll set it to 16 for 9900K.

See the PRs:


Example outputs:

C:\Users\Superymk\Desktop\amtterm>cmd
Microsoft Windows [Version 10.0.19041.867]
© 2020 Microsoft Corporation. All rights reserved.

C:\Users\Superymk\Desktop\amtterm>run.bat

C:\Users\Superymk\Desktop\amtterm>testbed1.bat

C:\Users\Superymk\Desktop\amtterm>amtterm.exe -p pas0@Testbed1 192.168.1.24
amtterm: NONE -> CONNECT (connection to host)
ipv4 192.168.1.24:16994 [192.168.1.24] 16994 open
amtterm: CONNECT -> INIT (redirection initialization)
amtterm: INIT -> AUTH (session authentication)
amtterm: AUTH -> INIT_SOL (serial-over-lan initialization)
amtterm: INIT_SOL -> RUN_SOL (serial-over-lan active)
serial-over-lan redirection ok
connected now, use ^] to escape

Log memory address:0x1E19000 <------ Add this line now

eXtensible Modular Hypervisor Framework (XMHF) 6.0.0
Build revision: you-gotta-have-faith-not-in-who-you-are-but-who-you-can-be
XMHF boot-loader: initializing, total modules=2

So the debug prints go both to serial and memory?

Right. One has to know the base address of the log memory. For example, I need to use this address to locate logs in memory via Intel System Debugger.
Currently I use serial instead of VGA because the loader may use UEFI instead of grub later

So what happens on a platform without any serial (like your test-bed), where do the serial outputs go?

It might be beneficial to have them as separate configuration options. e.g., DEBUG_MEMORY and DEBUG_SERIAL. We could then enable both or just one as needed.

In this case, separating DEBUG_MEMORY and DEBUG_SERIAL does not help. Currently my testbed hangs because it has 16 cores, and violate the assertion of <=8 cores.

To find out this reason, I use the old 2540p to print the base address of log memory first. Then I run uxmhf on the 9900k testbed and inspect the memory at this address. This improves the situation as no logs can be recorded before.

I agree that it is still problematic for a machine without serial. Maybe we have to go VGA as an intermediate step…

Ok I see your situation now. Regardless, it might still make sense for us to introduce them as seperate config options just to stay modular for now. Of course, in your situation you will need to enable both to have things working, which is fine.

Please see reviews on the code within the PR as linked in the OP.

You will also need to add:

 { "name": "debug_memory", "value": "@@FALSE@@"},

within uxmhf/uobjcoll/uberspark.json within the uberspark.uobjcoll.configdefs node.

This can also be computed using the generated elf binary after build, correct?

Right. One related question: how to get the symbols of uxmhf? So I can load them in the debugger and see not only the disassembly but also the vars and funcs.

And sure, will fix it :slight_smile:

_triage/uberspark/uobjcoll/platform/pc/uxmhf/uobjcoll.exe is an ELF executable of the micro-hypervisor image (with debug symbols). So feel free to load it into your debugger of choice and load it at the preferred load address of uberXMHF 0x06200000 (as defined in uxmhf/uobjcoll/uobjs/main/include/xmhf-config.h) :slight_smile:

Can you also update the uxmhf documentation as below?

  1. docs\pc-intel-x86_32\build\build-core.rst --> add debug_memory option and explanation

  2. docs\pc-intel-x86_32\debugging.rst --> add section on debugging with DCI and no serial support. Would be great if you added (some) contents from your existing post on DCI debugging and some discussion on this thread on how to grab the memory log buffer address via ELF dumps.

Thanks!

Sure, I’ll update these docs.

New questions about the code:
(1) In <geec_prime.h> line 199, the CPU stacks are allocated for 256 cores. If so, I’ll directly modify grub-legacy/init.c line 1085 to be “HALT_ON_ERRORCOND(xslbootinfo->cpuinfo_numentries <= MAX_PLATFORM_CPUS);”

Ahh, so it was already set to 256 :). Yes please go ahead and change the assertion. However, remember xmhf_config_debug_serial_max_cpus must still be set to the correct number of cores for your platform, else it will freeze with debugging enabled