Question on video modes

[lonnietc]

Hi NIls,

I have been booting up the "boot/vmmng" for testing and have noticed a could of things that I wanted to ask about.

What I have actually done is to play with things a bit by taking the "vmmng" and making a new one called "vmmtest" that takes out the linux and escape and just has cycleburner and tinycore. It's basically the same things, but just swapped in cycleburner.

Anyway, when it boot, I see a couple of interesting messages come up in the serial screen:

First is about the pcicfg:

[ pcicfg] Object not found: Unable to find APCI table 'MCFG' #0 [ timer] TIMER: Found 1 usable timers. [ timer] TIMER: HPET ticks with 100000000 HZ. [ timer] TIMER: 34+1611/8192 TSC ticks per timer tick. [ timer] TIMER: timestamp: 1626636949 secs [ timer] TIMER: date: TIMER: date: 18.07.2021 19:35:49 [ timer] TIMER: Timer 0 -> IRQ 2 (assigned 0x4 ack 0x0). [ timer] Listening to GSI 2

Can you please tell me more about what that means since I am guessing that it is related to pci passthrough, etc.

Second is about the VBE Video:

[ console] Found VBE: [ console] Version: 0x300 [ console] Tag: 0x41534556 [ console] Memory size: 0x1000000 [ console] OEM: SeaBIOS VBE(C) 2011 [ console] Vendor: SeaBIOS Developers [ console] Product: SeaBIOS VBE Adapter [ console] Product revision: Rev. 1

The console service shows me about 74 video modes available and I was wondering how to:

1. Initiate one of them for the whole system, and/or
2. Initiate one of them for an application.

For (1), would that be in the HYPERVISOR_PARAMS sent during boot using novaboot parsing and also for (2) would that be on the params for cycleburner or vancouver, for example.

I am just trying to get a feel for how to use the available console video modes that the console service is showing me and could be way off base above in my questioning but wanted to ask for you input and guidance on this.

One addition note:

for a test, I boosted up the QEMU memory to 8GB:

nre$ more boot/vmmtest

!tools/novaboot

QEMU_FLAGS=-m 8192 -smp 4 -netdev user,id=mynet0 -device ne2k_pci,netdev=mynet0 HYPERVISOR_PARAMS=spinner serial bin/apps/root bin/apps/acpi provides=acpi bin/apps/keyboard provides=keyboard bin/apps/reboot provides=reboot bin/apps/pcicfg provides=pcicfg bin/apps/timer provides=timer bin/apps/console provides=console bin/apps/network provides=network bin/apps/sysinfo bin/apps/vmmng mods=all lastmod bin/apps/vancouver bin/apps/cycleburner bin/apps/guest_munich dist/imgs/bzImage-3.1.0-32 dist/imgs/initrd-js.lzma dist/imgs/tinycore-vmlinuz dist/imgs/tinycore-core.gz cycleburner.vmconfig <<EOF rom://bin/apps/cycleburner EOF tinycore-linux.vmconfig <<EOF rom://bin/apps/vancouver m:128 ncpu:1 PC_PS2 intel82576vf rom://bin/apps/guest_munich rom://dist/imgs/tinycore-vmlinuz noapic console=ttyS0 rom://dist/imgs/tinycore-core.gz EOF

then fired up the vmmtest (vmmng) and started up Tinycore but NRE reported an error:

[vancouve: 1] Killed EC:0xffffffff82094a60 SC:0xffffffff82038e40 V:0xfc CR0:0x11 CR3:0x0 CR4:0x0 (vTLB addressing limit exceeded)

I think that this is actually coming from NOVA in a limitation on the address level. It also almost seems like NOVA is behaving as a 32-bit application even thought it is compiled as a 64-bit app that should have much more address space available.

Maybe this means that I will have to upgrade the NOVA kernel or something but wanted to also ask you about this too.

Cheers and have a great day

[Nils-TUD]

First is about the pcicfg:

[ pcicfg] Object not found: Unable to find APCI table 'MCFG' #0 [ timer] TIMER: Found 1 usable timers. [ timer] TIMER: HPET ticks with 100000000 HZ. [ timer] TIMER: 34+1611/8192 TSC ticks per timer tick. [ timer] TIMER: timestamp: 1626636949 secs [ timer] TIMER: date: TIMER: date: 18.07.2021 19:35:49 [ timer] TIMER: Timer 0 -> IRQ 2 (assigned 0x4 ack 0x0). [ timer] Listening to GSI 2

Can you please tell me more about what that means since I am guessing that it is related to pci passthrough, etc.

The pcicfg service provides clients information about PCI devices. IIRC, the devices are always found via port I/O, but the configuration is sometimes accessed via memory and sometimes via port I/O. In your case, the MCFG ACPI table was not found, so that the configuration is accessed via port I/O.

Second is about the VBE Video:

[ console] Found VBE: [ console] Version: 0x300 [ console] Tag: 0x41534556 [ console] Memory size: 0x1000000 [ console] OEM: SeaBIOS VBE(C) 2011 [ console] Vendor: SeaBIOS Developers [ console] Product: SeaBIOS VBE Adapter [ console] Product revision: Rev. 1

The console service shows me about 74 video modes available and I was wondering how to:

1. Initiate one of them for the whole system, and/or
2. Initiate one of them for an application.

For (1), would that be in the HYPERVISOR_PARAMS sent during boot using novaboot parsing and also for (2) would that be on the params for cycleburner or vancouver, for example.

I am just trying to get a feel for how to use the available console video modes that the console service is showing me and could be way off base above in my questioning but wanted to ask for you input and guidance on this.

At the moment, this cannot be specified by the user, I think. The mode is provided when a session is created at the console service. So, each client can specify the desired mode. For example, you could extend vmmng to take the mode number as a command line argument.

The HYPERVISOR_PARAMS cannot be used as they are only passed to NOVA, which doesn't know anything about video modes.

One addition note:

for a test, I boosted up the QEMU memory to 8GB:

nre$ more boot/vmmtest

!tools/novaboot

QEMU_FLAGS=-m 8192 -smp 4 -netdev user,id=mynet0 -device ne2k_pci,netdev=mynet0 HYPERVISOR_PARAMS=spinner serial bin/apps/root bin/apps/acpi provides=acpi bin/apps/keyboard provides=keyboard bin/apps/reboot provides=reboot bin/apps/pcicfg provides=pcicfg bin/apps/timer provides=timer bin/apps/console provides=console bin/apps/network provides=network bin/apps/sysinfo bin/apps/vmmng mods=all lastmod bin/apps/vancouver bin/apps/cycleburner bin/apps/guest_munich dist/imgs/bzImage-3.1.0-32 dist/imgs/initrd-js.lzma dist/imgs/tinycore-vmlinuz dist/imgs/tinycore-core.gz cycleburner.vmconfig <<EOF rom://bin/apps/cycleburner EOF tinycore-linux.vmconfig <<EOF rom://bin/apps/vancouver m:128 ncpu:1 PC_PS2 intel82576vf rom://bin/apps/guest_munich rom://dist/imgs/tinycore-vmlinuz noapic console=ttyS0 rom://dist/imgs/tinycore-core.gz EOF

then fired up the vmmtest (vmmng) and started up Tinycore but NRE reported an error:

[vancouve: 1] Killed EC:0xffffffff82094a60 SC:0xffffffff82038e40 V:0xfc CR0:0x11 CR3:0x0 CR4:0x0 (vTLB addressing limit exceeded)

I think that this is actually coming from NOVA in a limitation on the address level. It also almost seems like NOVA is behaving as a 32-bit application even thought it is compiled as a 64-bit app that should have much more address space available.

Maybe this means that I will have to upgrade the NOVA kernel or something but wanted to also ask you about this too.

Yes, that seems to be a NOVA limitation. Not sure about the details, though.

[lonnietc]

Thanks for getting back to me on these questions.

1. The pcicfg information is very helpful.

2. I would like to see how to extend the vmmng to enable a video mode for it and will try to look through the code more on this. If you have any ideas then I'm happy to give the ma try.

3. This limitation in NOVA is of great concern to me as the whole hypervisor project is predicated on being able to access larger address spaces in RAM and also maybe later digging into an idea of some type of swap space (as an idea but for much further along)

I also sent Udo a message over at his main NOVA site:

https://github.com/udosteinberg/NOVA

but have not heard back yet. Hope fully he will be willing to answer and give us some ideas.

This may require that a complete upgrade from the current NOVA that NRE uses over to a newer one as I know that Udo seems to be actively upgrading those NOVA versions. This might be needed, but I also think that the ABI has changed from the NOVA that you have to the NOVA that Udo has as well so it is looking like one more thing to add to the project list to get completed.

The port of musl clib is coming along although I am also finding that you have some of the core functions already implemented in NRE so I am trying to re-direct the musl calls over to your NRE calls to make things work better. You have some of this for the "printf" type call in your ConsoleStream.cc and OStream.cc files.

Still trying to get a handle on the best way to go about it all, but am wanting to keep your NRE call and just modify the musl clib calls to call the NRE calls (mostly).

Thanks again

[Nils-TUD]

2. I would like to see how to extend the vmmng to enable a video mode for it and will try to look through the code more on this. If you have any ideas then I'm happy to give the ma try.

Look at the constructor in services/Console.h. It takes a fourth argument that you can take from the command line arguments in the vmmng.cc (see services/console/console.cc for an example).

3. This limitation in NOVA is of great concern to me as the whole hypervisor project is predicated on being able to access larger address spaces in RAM and also maybe later digging into an idea of some type of swap space (as an idea but for much further along)

I also sent Udo a message over at his main NOVA site:

https://github.com/udosteinberg/NOVA

but have not heard back yet. Hope fully he will be willing to answer and give us some ideas.

This may require that a complete upgrade from the current NOVA that NRE uses over to a newer one as I know that Udo seems to be actively upgrading those NOVA versions. This might be needed, but I also think that the ABI has changed from the NOVA that you have to the NOVA that Udo has as well so it is looking like one more thing to add to the project list to get completed.

As it seems, Udo completely removed the vTLB and always uses nested paging now. So, this issue might be irrelevant (unless you want to use devices that don't support nested paging).

[lonnietc]

Will look at the Console.h for more details. Thanks.

The concern with NOVA is that the only change that I did when testing vmmng was to give QEMU 8GB of memory instead of 2GB and then the Tinycore from within vmmng (vmmtest) would not start.

Is this not a memory addressing problem with NOVA?

I am not clear on how, and why, the external change to the QEMU amount of memory prevented Tinycore from starting up within vmmng when additional external RAM allocation was the only change. Will this make it a problem on real hardware, is the question that I am trying to determine since I would not expect that NOVA should have a problem just by adding more RAM which is over the 2GB limit that 32-bit systems have as a limitation.

Maybe I missed something here in the understanding, but I would not expect the increase in RAM to make vmmng not able to boot Tinycore as it does very easily if I stay as 2GB or less in QEMU.

This just seems strange to me, my friend.

[lonnietc]

A quick question on the Console.h class and invocation.

I see that vmmng reads some .vmconfig files that are built up so that it has information on the apps and I wonder about modifying vmmng.cc to accept command like arguments as I have not see any examples that show this this is allowed.

I did see in boot/vmmng something like:

bin/apps/vmmng mods=all lastmod

What do the "mods=all lastmod" do as I have also seen it in boot/linux as:

bin/apps/vancouver mods=following lastmod m:128 ncpu:1 PC_PS2 ahci:0xe0800000,14,0x30 drive:0,1,2

The part that follows after "mods=following lastmod" are command like parameters to vancouver but I am not certain what the purpose of the "mods=following lastmod" is for?

Cheers,

[Nils-TUD]

The concern with NOVA is that the only change that I did when testing vmmng was to give QEMU 8GB of memory instead of 2GB and then the Tinycore from within vmmng (vmmtest) would not start.

Is this not a memory addressing problem with NOVA?

I am not clear on how, and why, the external change to the QEMU amount of memory prevented Tinycore from starting up within vmmng when additional external RAM allocation was the only change. Will this make it a problem on real hardware, is the question that I am trying to determine since I would not expect that NOVA should have a problem just by adding more RAM which is over the 2GB limit that 32-bit systems have as a limitation.

Maybe I missed something here in the understanding, but I would not expect the increase in RAM to make vmmng not able to boot Tinycore as it does very easily if I stay as 2GB or less in QEMU.

Look at the code that leads to the "vTLB addressing limit exceeded" error. It is a check that probably exists, because the code is not prepared for that. I think that NRE just uses all available memory and passes it to its components, so that in the end, the VM tries to access physical memory beyond 4G, which leads to the error.

However, as I said, this should be irrelevant if you are using nested paging.

Also keep in mind that this is a research prototype. So, expect such little limitations here and there. These should mostly be relatively straight forward to remove (read: not require a redesign, but just more engineering effort), though ;)

[lonnietc]

Also, I did fin the location to call with the mode in the console class and was thinking that maybe an idea is to be able to put it on a command like in the vancouver call:

bin/apps/vmmng mods=following lastmod mode=10 (for example)

[lonnietc]

Thanks for the info on the vTLB and you are right in that I do expect some limitations but am just trying to find them now as I investigate things so that they might be addressed going forward with the project.

appreciate your help, my friend.