[Pedro Henrique Penna (ppenna)]

Makes the emulated 8254 PIT take each count of its low-then-high access mode low byte first, for microsoft/nvx#1063 and its duplicate microsoft/nvx#1146. In that mode, a counter's write flip-flop alternates between the low and the high byte of a count, and a control word for the counter resets it to the low byte, so a guest can write one count after another without a new control word, as Linux's PIT one-shot clock event device does for each event after its control word 0x38. Timer::write kept the low byte that it buffered once the high byte completed the count, so after the first count it took every byte as a high byte with that stale low byte.

One commit on c2c21ddb2, the head of feature/microvm/dev. microsoft/nvx#1551 pins this head.

Start each PIT low/high count with its low byte (5d656d854)

• Cause. In the RwMode::LOW_HIGH arm of Timer::write, if let Some(low) = self.state.cr_low read the buffered low byte without clearing it, and only set_control cleared it. Control word 0x30, then the counts 0 and 16, left counter 0 counting 65536 rather than 16 (chipset: PIT LSB/MSB access mode keeps the buffered LSB after the MSB write nvx#1063), and control word 0x34, then the counts 0x1234 and 0x5678, left the count register at 0x5634 (openvmm: consecutive PIT low/high writes reuse the preceding count's low byte nvx#1146): a wrong period or one-shot length, and IRQ0 at the wrong rate, for a guest that reloads a count without a control word.

• Change. self.state.cr_low.take(): the high byte takes the buffered low byte, which returns the flip-flop to the low byte of the next count. The low-byte-only and high-byte-only access modes, the reset by a control word, the counter latch and read-back commands, and the read flip-flop (read_high) are unchanged. The saved state already holds cr_low, so no field, format, or version changes. A state saved without this change after such a count holds the stale low byte, which a restore keeps, since it cannot tell it from a low byte that the guest wrote; the guest's next counts then go wrong until it writes a control word for the counter, as they did before.

• Tests.

  • low_high_access_takes_each_count_low_byte_first: in each of the six modes, after a control word and the count 0x1234, the counts 0x5678 and 0x9abc, written without a control word, each reach the count register.
  • low_high_access_reloads_a_count_without_a_control_word, through the I/O ports with VM time set tick by tick (chipset: PIT LSB/MSB access mode keeps the buffered LSB after the MSB write nvx#1063): control word 0x30, bytes 0x00 0x00 0x10 0x00; IRQ0 is still low after 16 ticks and high after 17, the tick that loads the count and its 16 counts.
  • low_high_access_reprograms_a_running_rate_generator, through the I/O ports (openvmm: consecutive PIT low/high writes reuse the preceding count's low byte nvx#1146): control word 0x34, bytes 0x34 0x12; one tick later the latched count is 0x1234; bytes 0x78 0x56 while it counts; at the end of the current period, 0x1234 ticks later, the latched count is 0x5678.

  Without the fix, the three fail: the count register holds 0x5634; IRQ0 is still low after 17 ticks, with the latched count 0xfff0 of a count of 65536; and the latched count is 0x5634.

Not in this change: in mode 0, the 8254 also stops counting and drives OUT low when the first byte of a two-byte count arrives, and loads the count on the clock after the second byte. Timer::write acts only on a complete count, so the previous count keeps running until the high byte arrives. That predates this change and is a separate behavior; this change does not alter what the first byte does.

Validation

With Rust 1.97.1, on Windows, for chipset: cargo check, cargo clippy --all-targets (clean apart from the environment's LNK4199 linker notices), cargo doc --no-deps, and cargo nextest run --profile agent (104 passed), then cargo xtask fmt --fix (rustfmt, lints, verify-fuzzers, and verify-flowey complete, no changes). At c2c21ddb2, the three new tests fail as the Tests item says, and the test attached to microsoft/nvx#1063 fails with "mode 0 with count 16 did not reach terminal count after 100 ticks (latched count 0xff9d)"; with this commit, both pass.

The PIT is OpenVMM's own on every backend, so this change is backend-independent; NVX's microVM tests on KVM, MSHV, and WHP run with it through the NVX pull request that pins this head.

See microsoft/nvx#1551.

[github-actions]

29 Petri tests failed (28 unstable)