fix: enable THRE interrupt in emulate_serial_init for snapshot restore

[ejc3]

Problem

After snapshot restore, the serial console (ttyS0) stalls on x86_64. The guest 8250 driver stops transmitting — no output reaches Firecracker's stdout.

Root cause

emulate_serial_init() sets IER_RDA_BIT to re-enable the Received Data Available interrupt, but does not set IER_THR_EMPTY_BIT (Transmitter Holding Register Empty). vm-superio's Serial::write for IER_OFFSET only stores the value — it does not generate any interrupt. The guest 8250 driver uses interrupt-driven TX and waits for a THRE interrupt before sending each byte. After restore, that interrupt never fires, so TX stalls.

When the bug manifests

The stall only occurs when the snapshot is taken during active serial transmission — specifically when the guest's TX circular buffer has more than 16 bytes (port->fifosize):

1. serial8250_tx_chars() sends at most 16 bytes per THRE interrupt
2. With >16 bytes pending, UART_IER_THRI stays set in the guest driver's cached up->ier
3. After restore, serial8250_start_tx() sees THRI already set and skips the UART_BUG_TXEN fallback
4. vm-superio's IER only has RDA (no THRI), so no THRE interrupt fires
5. TX stalls permanently

When the snapshot is taken at idle (empty TX buffer), serial8250_stop_tx() has already cleared THRI from the cached IER. After restore, serial8250_start_tx() re-enables THRI via the UART_BUG_TXEN fallback which polls LSR directly — so the idle case works even without this fix. Real workloads (systemd, journald, application logging) frequently have >16 bytes buffered during active output.

Fix

1. Set both IER_RDA_BIT | IER_THR_EMPTY_BIT in emulate_serial_init() (both architectures).
2. On x86_64, write a byte to DATA_OFFSET to trigger thr_empty_interrupt(), which signals the eventfd → KVM irqfd → IRQ 4 → guest 8250 driver resumes TX.

The DATA write is only needed on x86_64 because ARM64's MMIO-based interrupt delivery picks up the THRE-enabled IER on the first guest TX attempt.

Tests

Unit test (test_emulate_serial_init_enables_thre_interrupt): Calls emulate_serial_init() directly and verifies IER has both bits set and the interrupt eventfd was signaled.

Integration test (test_serial_output_after_snapshot_during_active_tx): Reproduces the actual stall by snapshotting during active TX with dd bs=4096 to keep >16 bytes in the circular buffer, then checking for sustained output without sending any host input (which would mask the bug via RDA piggybacking).

	Without fix	With fix
Initial burst	9 bytes	148,812 bytes
Sustained output	0 bytes (10s timeout)	51 bytes (0.0s)
Result	FAIL	PASS

[Manciukic]

Hey @ejc3 , thanks again for reporting the issue! We'll take a deeper look in the next days. In the meanwhile, do you know what are the conditions to trigger this or how often this is happening for you? I don't think we've ever seen this issue, despite our testing.
We should also double check if restoring the entire serial state as mentioned in the comment above in the codebase is possible and would fix this issue.

[ilstam]

On x86 the test in commit 2 appears to be passing even without commit 1 being applied.

[ejc3]

Bleh, let me look more deeply. The manifestation was trying to get serial logs flowing after restore.

[ejc3]

Updated the PR with a new integration test and a clearer description of the reproduction conditions. Addressing both comments:

@ilstam — You were right that the old unit test passed without the fix. I replaced it with two tests:

1. A unit test that calls emulate_serial_init() directly and checks IER bits + eventfd signaling — this one fails without the fix (assert_eq!(ier & IER_THR_EMPTY_BIT, IER_THR_EMPTY_BIT) → left: 0, right: 2).

2. An integration test that reproduces the actual stall. The key insight: the bug only manifests when the snapshot is taken during active TX with >16 bytes in the circular buffer. At idle (shell prompt), serial8250_stop_tx() clears THRI from the guest driver's cached IER, and the UART_BUG_TXEN fallback in serial8250_start_tx() handles re-enabling — so idle-state tests pass without the fix. The new test uses dd bs=4096 to keep the buffer full, snapshots mid-stream, and checks for sustained output without sending any host input. Without the fix: 0 bytes after 10s. With the fix: output resumes immediately.

@Manciukic — The condition is: snapshot during active serial output where the TX circular buffer has >16 bytes. I experienced this in ejc3/fcvm when adding tests of systemd/journald logging. It didn't show up in test_serial_after_snapshot because that test snapshots at idle. Regarding full serial state restore — that would also fix this, but this targeted fix is simpler and sufficient since the only state that matters post-restore is IER (the guest driver re-establishes everything else via its cached register copies).