The new bugfixed version (together with other improvements and bugfixes) is now available on itch.io!

It has the bugfix mentioned above in it, so should be able to POST the Compaq Deskpro 386 once again!

superfury wrote on 2021-06-09, 15:18:

The new bugfixed version (together with other improvements and bugfixes) is now available on itch.io!

It has the bugfix mentioned above in it, so should be able to POST the Compaq Deskpro 386 once again!

Yep that did the trick! I can boot with the BIOS now and my MBR boots as well.

Thanks for the help!

Hi superfury, a quick question about memory configuration. How would I go about to give the guest 128MB of memory? (That's just as an example)
There's the file memorylimit.txt which currently contains "4M" and in the SETTINGS.INI file (i440fx section) there's a line with "memory=4290248704".
But looks like that leads to the guest having 16MB, so I guess something else is at play here...

mr.cat wrote on 2021-07-06, 18:24:

Hi superfury, a quick question about memory configuration. How would I go about to give the guest 128MB of memory? (That's just as an example)
There's the file memorylimit.txt which currently contains "4M" and in the SETTINGS.INI file (i440fx section) there's a line with "memory=4290248704".
But looks like that leads to the guest having 16MB, so I guess something else it at play here...

UniPCemu tries to use the specified size (in bytes). Although it limits the amount of installed memory depending on the architecture and installed CPU(XT or up to 186 CPU 1MB, AT/Compaq up to 80386 CPU(80286 CPU only supporting 16MB, 80386/80486 CPU is limited by Compaq BIOS itself, not the CPU) 16MB, i430fx architecture (requiring Pentium or newer by the BIOS) 128MB, i440fx 1GB (Requires Pentium Pro or newer if I remember the BIOS specs correctly) ). It tries to use up to the maximum the CPU and emulated motherboard support.

There's also the alternative of XT or AT with 80386 or 80486, which uses the Inboard 80386 or Inboard 80486 chipset, which doesn't have a hard limit on RAM(other than 4GB because of a IA-32 CPU being emulated).
And there's also the thing with the memory holes, although the i430fx and i440fx can configure this through the emulated BIOS.

OK, thank you.
I should note that this is with Bochs BIOS, although I don't know if that matters any.
I don't think Linux needs any BIOS support, but I thought to mention that because I may have overlooked something.
(Things like, I don't know if memory initialization is a one-time event that is performed by BIOS and only by BIOS.)

EDIT: I've now tried changing the memory setting, but it doesn't seem to make a difference.
I'm actually trying to boot Debian 3.1r8 (Sarge) install CD, it looks like it hangs. I'm not sure if adding memory will alleviate that issue, but it requires 22MB at a minimum.
With qemu, it manages to boot to installation menus with the measly 22MB (it complains about low memory though and removes some features).
(I'm not sure if it's possible to actually complete the install with that.)

Also tried Debian 4.0r9 (Etch), that one panics with a message:
This kernel doesn't support CPU's with broken WP. Recompile it for a 386!
(Bit cryptic, but apparently the meaning of this message is also the same. It's just Debian's way of saying that there's not enough memory to install)

EDIT2: Memtest86+ 5.01 from gparted iso starts and detects P2, i440FX, and 15MB memory (so yeah even this test program runs, it's just very slow on my hw).
I was suspecting this memory problem could be ulimit related, but that can't be it (running UniPCemu as root, it's the same).

EDIT3: Well I'm on a booting spree here it seems...Debian 2.2r7 (Potato) and 3.0r6 (Woody) both successfully boot and bring up the installation menus.
Potato complains about dependencies, but it does that with qemu too. Decompressing is very slow in both.

EDIT4: FreeBSD DVDs seem to be the quickest way to check that memory info, it's one of the first things they print out. Currently needs something like 96MB to actually get the install going.

I now got SeaBIOS going (the non-Bochs version) and it's like you said, it boots fine just no VGA (or anything else).
It's still nice because it prints huge swaths of information out. Just needs quite a lot of tweaking (via "make menuconfig") to get it booting.

The VGA problem could be simply because of missing optroms, but I may have found a piece of missing hardware here.
Take a look at this short clip from the QEMU SeaBIOS boot:

.. === PCI device probing === PCI probe PCI device 00:00.0 (vd=8086:1237 c=0600) PCI device 00:01.0 (vd=8086:7000 c=0601) PCI de […]
Show full quote

..
=== PCI device probing ===
PCI probe
PCI device 00:00.0 (vd=8086:1237 c=0600)
PCI device 00:01.0 (vd=8086:7000 c=0601)
PCI device 00:01.1 (vd=8086:7010 c=0101)
PCI device 00:01.3 (vd=8086:7113 c=0680)
PCI device 00:02.0 (vd=1234:1111 c=0300)
..
Using pmtimer, ioport 0x608
PCI: init bdf=00:02.0 id=1234:1111
PCI: Using 00:02.0 for primary VGA
..

That 1234:1111 device is QEMU's virtual VGA. Shouldn't there be something like that present in UniPCemu too?

The memory bit it also special for QEMU (CMOS is not used here):

.. Found QEMU fw_cfg QEMU fw_cfg DMA interface supported qemu/e820: addr 0x0000000000000000 len 0x0000000001000000 [RAM] qemu/e8 […]
Show full quote

..
Found QEMU fw_cfg
QEMU fw_cfg DMA interface supported
qemu/e820: addr 0x0000000000000000 len 0x0000000001000000 [RAM]
qemu/e820: RamSize: 0x01000000
qemu/e820: RamSizeOver4G: 0x0000000000000000
malloc preinit
..

(That's with 16MB RAM configuration, but RamSize seems to be correct with other values)

So I guess the question is then what your overall vision is (or, how "virtual" you want to get with UniPCemu hardware).

mr.cat wrote on 2021-07-10, 15:45:

I now got SeaBIOS going (the non-Bochs version) and it's like you said, it boots fine just no VGA (or anything else). It's still […]
Show full quote

I now got SeaBIOS going (the non-Bochs version) and it's like you said, it boots fine just no VGA (or anything else).
It's still nice because it prints huge swaths of information out. Just needs quite a lot of tweaking (via "make menuconfig") to get it booting.

The VGA problem could be simply because of missing optroms, but I may have found a piece of missing hardware here.
Take a look at this short clip from the QEMU SeaBIOS boot:

.. === PCI device probing === PCI probe PCI device 00:00.0 (vd=8086:1237 c=0600) PCI device 00:01.0 (vd=8086:7000 c=0601) PCI de […]
Show full quote

..
=== PCI device probing ===
PCI probe
PCI device 00:00.0 (vd=8086:1237 c=0600)
PCI device 00:01.0 (vd=8086:7000 c=0601)
PCI device 00:01.1 (vd=8086:7010 c=0101)
PCI device 00:01.3 (vd=8086:7113 c=0680)
PCI device 00:02.0 (vd=1234:1111 c=0300)
..
Using pmtimer, ioport 0x608
PCI: init bdf=00:02.0 id=1234:1111
PCI: Using 00:02.0 for primary VGA
..

That 1234:1111 device is QEMU's virtual VGA. Shouldn't there be something like that present in UniPCemu too?

The memory bit it also special for QEMU (CMOS is not used here):

.. Found QEMU fw_cfg QEMU fw_cfg DMA interface supported qemu/e820: addr 0x0000000000000000 len 0x0000000001000000 [RAM] qemu/e8 […]
Show full quote

..
Found QEMU fw_cfg
QEMU fw_cfg DMA interface supported
qemu/e820: addr 0x0000000000000000 len 0x0000000001000000 [RAM]
qemu/e820: RamSize: 0x01000000
qemu/e820: RamSizeOver4G: 0x0000000000000000
malloc preinit
..

(That's with 16MB RAM configuration, but RamSize seems to be correct with other values)

So I guess the question is then what your overall vision is (or, how "virtual" you want to get with UniPCemu hardware).

The 1234:1111 device isn't present on the PCI configuration space, so it shouldn't find it? None of UniPCemu's supported graphics cards are PCI (all ISA, meaning: MDA/CGA, EGA, VGA, ET3000AX, ET4000 and ET4000/W32(i) are all that are supported).

Also, a way to max out memory is simply set the contents of the memorylimit.txt to 4G or 1G.
Then, the architecture will limit to it when redetecting installed memory (you can use the settings menu option to make it pending. Then simply save the settings and restart the app). Another way using a text editor you can set the memory setting to 0 and then start the emulator's architecture, which has the same effect(which is exactly the way the option in the settings menu works: it sets the active architecture's memory size to 0 and forces a reboot to happen when saving the settings).

SeaBIOS should be made for real hardware, can't you just inject a EGA/VGA/ET3000/ET4000(/W32) bios in there)?

Thanks! Yes that's actually what I meant: Isn't the PCI configuration space the responsibility of the 440FX motherboard?
It's possible that I just don't know enough about PCI (so for me it would be interesting to see how this SeaBIOS log would look like in a real physical hw that has only PCI),
but on PCI-e systems those "internal" VGAs are present (even Intel iGPU I think).
I'm not sure how that configuration space is actually used by OSes (or indeed, if it is required at all), but it sure looks like at least SeaBIOS needs it to find GPUs.
Also, since Bochs legacy BIOS manages without, maybe there is some difference between 16-bit and 32-bit systems.
In Bochs BIOS there's a call to int 0x10 that inits VGA. That's missing in SeaBIOS (so I guess it's the job of the optrom, but since optroms aren't found this init code is never run?)

So far I haven't been successful with the optroms. Maybe coreboot is needed for the blob injecting (so far I've been playing with the SeaBIOS source from GitHub, that doesn't include coreboot).
I agree that would probably lead to some better insight into this.
EDIT: Holy macaroni! The coreboot source weighs in at 1.7GB (and probably a few gigs more when compiled). Half of it goes to the cross-compiler.
That's the current one though. Older versions are quite a bit lighter (plus they produce a smaller binary).

As for memory, that "setting memory=0" was a good tip! Unfortunately it didn't help.
I'm starting to feel I should read me some source codes to see how that detection is done.

EDIT: This here says "INT 15H, AH=88H", but looks like it's capped at 64MB (and apparently, can be stuck at 16MB depending on the mobo/bios). New kernels use something else.
http://fxr.watson.org/fxr/source/i386/boot/bi … s.S?v=FREEBSD22

EDIT2: OK I've now found out why my memory seemed to be limited to max 16MB with Bochs BIOS.
Reading rombios.c from line 4678 (case 0xe8) onwards shows that the extended memory size is read from CMOS positions RAM34 and RAM35. Those were zeroed out in my SETTINGS.INI.
And yes, with more memory Sarge can now boot to installation menus. It's just too slow to be useful...

mr.cat wrote on 2021-07-11, 19:01:

Thanks! Yes that's actually what I meant: Isn't the PCI configuration space the responsibility of the 440FX motherboard? It's po […]
Show full quote

Thanks! Yes that's actually what I meant: Isn't the PCI configuration space the responsibility of the 440FX motherboard?
It's possible that I just don't know enough about PCI (so for me it would be interesting to see how this SeaBIOS log would look like in a real physical hw that has only PCI),
but on PCI-e systems those "internal" VGAs are present (even Intel iGPU I think).
I'm not sure how that configuration space is actually used by OSes (or indeed, if it is required at all), but it sure looks like at least SeaBIOS needs it to find GPUs.
Also, since Bochs legacy BIOS manages without, maybe there is some difference between 16-bit and 32-bit systems.
In Bochs BIOS there's a call to int 0x10 that inits VGA. That's missing in SeaBIOS (so I guess it's the job of the optrom, but since optroms aren't found this init code is never run?)

So far I haven't been successful with the optroms. Maybe coreboot is needed for the blob injecting (so far I've been playing with the SeaBIOS source from GitHub, that doesn't include coreboot).
I agree that would probably lead to some better insight into this.

As for memory, that "setting memory=0" was a good tip! Unfortunately it didn't help.
I'm starting to feel I should read me some source codes to see how that detection is done.

I could make the EGA/(S)VGA BIOS appear with that ID on PCI, although would that be correct behaviour for ISA cards? Perhaps something special is needed(Some PCI to ISA adapter for the ROM, much like the PCI to ISA bridge)?

Yes for ISA definitely some bridging is needed, but I'm woefully ignorant on these matters so can't really advise.
Btw perhaps VGA will work once the OS drivers take the wheel, but I've not managed to test it. Still would be nice to have it from the get-go.

Please note that the PCI ID numbers probably carry some significance.
If you designate the vendor as qemu, it's possible that it could result to some weirdness (then again Bochs is also using these, so maybe it's ok).
These would probably be better for Tseng: https://pci-ids.ucw.cz/read/PC/100c

EDIT: Looks like the PCI IDs are included in the optrom. You can use the "romheaders" cli program (part of fcode-utils package) to dump the headers out.
The VGA roms that come with Bochs carry the qemu id, so from that pov it might be easier to start with that.
(And of course ISA roms know nothing about PCI, so idk how that's supposed to be arranged...)

Perhaps you've noticed it, but I'm getting to like UniPCemu quite a bit 😁
Huge respect for the work so far!

Hi again! Here's some results from Tilck testing (with Bochs BIOS).
UniPCemu actually manages to boot this a little bit further than PCem/86Box,
but ultimately the boot sequence ends up in a kernel panic, with an error message adorned with #TS and #GP.

That the #TS exception is there means it's either a kernel bug or a hw problem right?
I tracked it down to kernel/arch/i386/gdt.c, function load_tss() in the Tilck source. These exceptions get triggered by the ltr instruction there.
In UniPCemu/cpu/multitasking.c function CPU_switchtask(), the type of "source" descriptor is 0x02 (AVL_SYSTEM_LDT) but there is no such case for the switch clause (line 407 or so).
Therefore the descriptor is deemed invalid here, and #TS is thrown (invalidsrctask).

AVL_SYSTEM_LDT seems to originate from cpu/cpu.c (line 1313).
The initial value for TR desc.AccessRights is 0x82 and it's based on sandpile.org docs, but it looks like it's wrong?

Changing the value to 0x8b gets rid of #TS, and seems to me this is what both qemu and bochs are using for TR too. For example, here's what qemu's "info registers" shows about it:

1LDT=0000 00000000 0000ffff 00008200
2TR =0000 00000000 0000ffff 00008b00

(the values present while in the boot menu, before pressing 'b' to boot)

As for the #GP, my brain got kinda lost in that if jungle that starts at line 948 in protection.c.
One way this problem can be bypassed is by forcing DPL RPL to 0 in Tilck load_tss() call (instead of the original 3 there), or vice versa (defining GDT_ACCESS_PL3 for TSS).
But that isn't a correct fix (as can be seen from the fact that qemu seems to cope just fine without this modification).

There's a comparison where MAX() is used to find out the least privileged one of CPL/RPL (which will be 3 here, because RPL is 3).
The result is then compared to DPL (that has a value of zero, leading to #GP).

CPL is supposed to be 0 anyways, so that leaves the value of RPL being the main suspect here? That originates from the LTR instruction handling in opcodes_80286.c.
The RPL value of 3 is based on the new value of the TR (0x2b, which is the value we are trying to write by ltr) and not the current one in TR (which would be zero)?
That sounds like a bug to me, but I don't know an easy way to put that theory into test. (And as I've said, I don't have a firm grip on this stuff...)

So, interesting outcome huh?
Bypassing these exceptions (or better yet, fixing them), forcing hypervisor mode and disabling sb16 module seems to be enough to get Tilck to boot all the way to Tilck logo & busybox shell.

mr.cat wrote on 2021-07-25, 22:46:

Hi again! Here's some results from Tilck testing (with Bochs BIOS). UniPCemu actually manages to boot this a little bit further […]
Show full quote

Hi again! Here's some results from Tilck testing (with Bochs BIOS).
UniPCemu actually manages to boot this a little bit further than PCem/86Box,
but ultimately the boot sequence ends up in a kernel panic, with an error message adorned with #TS and #GP.

That the #TS exception is there means it's either a kernel bug or a hw problem right?
I tracked it down to kernel/arch/i386/gdt.c, function load_tss() in the Tilck source. These exceptions get triggered by the ltr instruction there.
In UniPCemu/cpu/multitasking.c function CPU_switchtask(), the type of "source" descriptor is 0x02 (AVL_SYSTEM_LDT) but there is no such case for the switch clause (line 407 or so).
Therefore the descriptor is deemed invalid here, and #TS is thrown (invalidsrctask).

AVL_SYSTEM_LDT seems to originate from cpu/cpu.c (line 1313).
The initial value for TR desc.AccessRights is 0x82 and it's based on sandpile.org docs, but it looks like it's wrong?

Changing the value to 0x8b gets rid of #TS, and seems to me this is what both qemu and bochs are using for TR too. For example, here's what qemu's "info registers" shows about it:

Copy code to clipboard

1LDT=0000 00000000 0000ffff 00008200
2TR =0000 00000000 0000ffff 00008b00

(the values present while in the boot menu, before pressing 'b' to boot)

As for the #GP, my brain got kinda lost in that if jungle that starts at line 948 in protection.c.
One way this problem can be bypassed is by forcing DPL to 0 in Tilck load_tss call (instead of the original 3 there), or vice versa (defining GDT_ACCESS_PL3 for TSS).
But that isn't a correct fix (as can be seen from the fact that qemu seems to cope just fine without this modification).

There's a comparison where MAX() is used to find out the least privileged one of CPL/RPL (which will be 3 here, because RPL is 3). The result is then compared to DPL (and that leads to #GP).
CPL is supposed to be 0 anyways, so that leaves the value of RPL being the main suspect here? That originates from the LTR instruction handling in opcodes_80286.c.
The RPL value of 3 is based on the new value of the TR (0x2b, which is the value we are trying to write by ltr) and not the current one in TR (which would be zero)?
That sounds like a bug to me, but I don't know an easy way to put that theory into test. (And as I've said, I don't have a firm grip on this stuff...)

So, interesting outcome huh?
Bypassing these exceptions (or better yet, fixing them), forcing hypervisor mode and disabling sb16 module seems to be enough to get Tilck to boot all the way to Tilck logo & busybox shell.

The #TS seems to be correct? It's illegal to l0ad a LDT descriptor into TR! Only TSS descriptors are allowed to be loaded during task switches!

If MAX(RPL,CPL)>DPL, LTR would cause a #GP fault. But since DPL=3, that shouldn't happen because of that? Afaik DPL=0 with RPL=3 would always fault because of this (which is the required RPL purpose, since it lowers CPL)? So 3>0, which faults. But if DPL=3, that wouldn't happen(3>3 doesn't fault).

So since the switchtask faults, that means that a proper LTR that doesn't fault has never been done since the last CPU INIT/RESET signal before triggering the task switch.
The 0x82/0x02 on INIT/RESET means that the source descriptor(the current task it's switching from) is invalid to switch from. The descriptor doesn't hold a valid linear address to store the outgoing task state into, which is actually correct behaviour for a task switch(otherwise it's storing it into a non-initialized address (probably 0) and it can't return to it(TR has probably a NULL value(0x0000 through 0x0003))).

Thanks, that's food for thought. I'm guessing Tilck isn't used a whole lot on real hardware (yet), it's just qemu for now. From that pov it might not be the best test case ever.
But the comparison vs. qemu could be useful.

#TS would be correct for LDT.
But the faulting LTR here is supposed to be for TSS (and it is the initial setup for TSS, after reset).
There were some LDT references in Tilck's kernel source, but those functions didn't seem to be in use.
(AVL_SYSTEM_LDT is on the UniPCemu side of things, it's the lower nibble of TR access byte reseted/init value 0x82, aka descriptor type)
The UniPCemu name for descriptor type 0x0b is AVL_SYSTEM_BUSY_TSS32BIT btw...sounds like a bit better fit for TR?
Well these names are ofc arbitrary, but I assume they're based on Intel docs. I don't know the real reason why qemu/Bochs use 0x8b and not 0x82 as init value for TR access byte.

I spotted a little mixup with RPL and DPL in my post above, sorry about that (fixed in the post now).
Using "all original parts" DPL isn't actually 3, it's 0. So the comparison is 3>0 and that will fault.
Changing the privilege level for Tilck's load_tss() call changes the RPL value (not DPL).
So, if we change it to zero then the comparison becomes 0>0 (doesn't fault).

Booting Tilck on physical hw could provide the missing pieces:

• If it boots successfully, UniPCemu needs some patching.
• If it fails with #GP, then the current UniPCemu LTR handling could be correct (and qemu/Tilck need some patching).
• If it fails with #TS also, that means qemu's init values are only relevant for virtual hw.

(assuming there aren't other issues with physical hw, ofc).

I've just changed LTR and task switching (just before the committing of the destination task's TSS, which also sets the B-bit in the descriptor cache and RAM) and loads the descriptor into the descriptor cache during that step.
When performing checks like descriptor type etc. inside getsegment_seg, it won't check CPL vs DPL vs RPL anymore when loading TR(So both for LTR and task switches just before committing to the destination task) and won't throw any fault because of CPL, DPL or RPL anymore.
I looked at the 8o386 programmer's reference manual and it didn't seem to mention anything about privilege levels on loading TR during those? So perhaps they're indeed fully ignored (JMP/CALL and gates are still handled those because they're using CS instead, the same for IRET). Task switches also ignore them now (since that's using gates for those checks(unaffected) and task switching still perform checks as documented itself because of CS being used).

Edit: Hmmm...

The Embedded Pentium Processor Developer's manual says that (I/G/L)DTR/TSS(TR?) descriptor caches are set to "P, R/W" while the data segments (DS, ES, FE(FS?), GS, SS are set to "P, R/W, A". So that means that the data segments become 0x93(as is known), while IDTR/GDTR/LDTR/TR are set to 0x92(no accessed bit. Also no TSS type or anything like clearing bit 4 that because it doesn't have a R/W bit for those).

Sounds reasonable. LTR is a privileged instruction and typically only used in the startup code. And UniPCemu isn't targeting the cloud either...
In the unlikely event that some protection code actually needs to be added, that can always be done afterwards.

UniPCemu still #TS faults when task switching without LTR successfully having executed first after INIT/RESET was asserted.
Would that be correct behaviour? Or should it ignore the outgoing task state entirely? Or some other behaviour is required? Bochs&Dosbox don't seem to check the outgoing task at all, just using the TR/TSS descriptor cache as if it were present and valid (including effectively clearing the NULL descriptor's B-bit and writing outgoing state to RAM(linear address 0, since it's documented RESET/INIT state of the cache))?

Also, does the OS run now with UniPCemu's latest changes?

Edit: Just changed the TR descriptor cache access rights byte on a 80286 to be a busy 16-bit TSS and a 32-bit busy TSS during RESET/INIT on 80386 and up.
So that should theoretically fix those bugs you've mentioned?
Can you check the latest code and see if the OS boots?
Edit: Hmmm... Sandpile seems to agree somewhat?
https://www.sandpile.org/x86/desc.htm

Since the TR.ar.V bit is set to 0 during a processor RESET or INIT, it should act like a valid bit, and cause a #TS(0) exception on all implicit TSS accesses (stack switch, task switch, TSS32.IOPB, or TSS32.IRB). Most processors don't implement that behavior though.

Thanks! Yes seems OK now 😁
Using UniPCemu-git-e5c540ef and Tilck-git-18381962, Tilck now manages to boot until it hangs at kb8042 kernel module.
There are some in_hypervisor() calls in Tilck that would need to be patched to get it to boot all the way, so that hang is expected behavior.
The kernel panic in my previous testing occurred at an earlier stage (while initing kernel console).

EDIT: To expand a little on the in_hypervisor() patch, it's only a matter of changing the return value to true instead of x86_cpu_features.ecx1.hypervisor.
I guess it will then skip over some timing loops.

mr.cat wrote on 2021-07-30, 10:31:

Thanks! Yes seems OK now :D Using UniPCemu-git-e5c540ef and Tilck-git-18381962, Tilck now manages to boot until it hangs at kb80 […]
Show full quote

Thanks! Yes seems OK now 😁
Using UniPCemu-git-e5c540ef and Tilck-git-18381962, Tilck now manages to boot until it hangs at kb8042 kernel module.
There are some in_hypervisor() calls in Tilck that would need to be patched to get it to boot all the way, so that hang is expected behavior.
The kernel panic occurred in an earlier stage (while initing kernel console).

Is there a problem with the 8042? Or is there just an issue with the way it handles the 8042 chip(regarding real hardware, like the Bochs' BIOS issues)?
Or is it some weird UniPCemu CPU bug that's showing itself?

I've just been thinking...
Does the same regarding TR vs CPL vs DPL vs RPL (TR privilege level handling) also apply to the LDTR? When looking at the LLDT instruction, it looks much like the LTR instruction, minus the busy bit of the descriptor(which doesn't exist for the LDTR)?

Edit: It l00ks like that's true, as far as the 80286 and 80386 programmer's reference manuals are concerned.
So that's another bug fixed.

Any changes in the OS?

Commit 65ffa33f seems fine also (similar behavior to e5c540ef).
About that i8042 "hang" this code clip from Tilck's modules/kb8042/generic_x86/i8042.c may be illuminating:

1static NO_INLINE void i8042_io_wait(void)
2{
3   if (in_hypervisor())
4      return;
5
6   delay_us(1);
7}

So no, I wouldn't say it's that weird 😁