You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a Hyper-V "Generation 1" VM (on Win11 Pro 22H2), ToaruOS 2.2.0 hangs at the "T" boot logo (and, in VGA Text Mode, at "Jumping to kernel...", with no serial output when booting with "Debug output" selected.)
The hang occurs during timestamp counter calibration in arch_clock_initialize. Hyper-V's emulation lacks a PC speaker and experimentally it appears that that it also doesn't change the output of bit 5 of ioport 0x61 when the PIT channel 2 one-shot timer counts down, so the calibration loop spins forever.
The HyperV Top Level Functional Specification does have an MSR (HV_X64_MSR_TSC_FREQUENCY) for the guest OS to retrieve the TSC frequency; by implementing this in place of the calibration loop, I'm able to boot successfully. An alternative generic fix (if you didn't want to call a HyperV-specific MSR) might be to poll on the countdown value instead? (Note that "Generation 2" VMs lack a PIT entirely, among other legacy PC features. I expect a lot of work would be necessary before ToaruOS could run in that environment.)
Other, more minor stuff I ran into:
Mouse input would cause both keyboard and mouse input to drop. Investigating this, it appears that that Hyper-V's PS/2 emulation only asserts an interrupt when it pushes a byte into the datastream, which means that the "read then ack" order in ps2hid's mouse_handler acknowledges on the second byte of a multi-byte mouse message. At that point, we lose all PS/2 input (mouse and keyboard) because we no longer get interrupted. Reversing the order to ack-then-read resolves this.
There's no network, but that's simply due to lack of driver support-- Hyper-V's "legacy network adapter" is a DEC 21140 (PCI ID 1011:0009) instead of the venerable Intel E1000 that VirtualBox/VMware/QEMU emulate-- so I'd call that "expected" for now I guess.
The text was updated successfully, but these errors were encountered:
I do not have access to Hyper-V and thus have no ability to test any changes to support it. I don’t want to leave issue reports like this open, so I am inclined to close this as not planned to reflect that state.
No problem. I mostly just wanted to report my findings in this issue. I suspected that, between your reluctance to accept outside PRs on this project and your inability to test on Hyper-V, supporting this was probably not likely going to be in-scope.
In a Hyper-V "Generation 1" VM (on Win11 Pro 22H2), ToaruOS 2.2.0 hangs at the "T" boot logo (and, in VGA Text Mode, at "Jumping to kernel...", with no serial output when booting with "Debug output" selected.)
The hang occurs during timestamp counter calibration in
arch_clock_initialize
. Hyper-V's emulation lacks a PC speaker and experimentally it appears that that it also doesn't change the output of bit 5 of ioport 0x61 when the PIT channel 2 one-shot timer counts down, so the calibration loop spins forever.The HyperV Top Level Functional Specification does have an MSR (
HV_X64_MSR_TSC_FREQUENCY
) for the guest OS to retrieve the TSC frequency; by implementing this in place of the calibration loop, I'm able to boot successfully. An alternative generic fix (if you didn't want to call a HyperV-specific MSR) might be to poll on the countdown value instead? (Note that "Generation 2" VMs lack a PIT entirely, among other legacy PC features. I expect a lot of work would be necessary before ToaruOS could run in that environment.)Other, more minor stuff I ran into:
Mouse input would cause both keyboard and mouse input to drop. Investigating this, it appears that that Hyper-V's PS/2 emulation only asserts an interrupt when it pushes a byte into the datastream, which means that the "read then ack" order in
ps2hid
'smouse_handler
acknowledges on the second byte of a multi-byte mouse message. At that point, we lose all PS/2 input (mouse and keyboard) because we no longer get interrupted. Reversing the order to ack-then-read resolves this.There's no network, but that's simply due to lack of driver support-- Hyper-V's "legacy network adapter" is a DEC 21140 (PCI ID
1011:0009
) instead of the venerable Intel E1000 that VirtualBox/VMware/QEMU emulate-- so I'd call that "expected" for now I guess.The text was updated successfully, but these errors were encountered: