[BUG] Automatic KVM exception VM stalls before EriX boot markers #60

New issue

Open

opened 2026-09-17 16:03:56 +02:00 by erikinkinen · 0 comments

erikinkinen commented

2026-09-17 16:03:56 +02:00

Owner

Summary

An additional local run of the existing double-fault scenario reaches its serial-silence deadline before any EriX boot marker when automatic acceleration resolves to KVM. An explicit TCG control passes the original exception assertions with the same Kernel ELF. The failing automatic run remains a failure; the guest or firmware cause and first affected revision are unestablished.

Reproduction

Use the isolated diagnostic component catalog and the unchanged subsystem-kernel-exception-int8-negative scenario with the standard scenario runner. On the observed Linux host, automatic acceleration selects KVM. Preserve the 60-second overall and 45-second serial-silence limits. Change only the scenario's accelerator selection to explicit TCG for the separate control.

Expected and actual behavior

Expected: reach the required IST marker and expected fatal exit within the original limits.

Actual automatic/KVM run: serial output contains firmware terminal-control sequences and no EriX boot marker. The existing silence watchdog terminates the VM; the outer command exits 1 and cleanup completes. The separate TCG control reaches confirmed double-fault IST handling and the expected fatal exit. This distinction does not establish a Kernel regression or justify weakening the watchdog.

Environment and identity

Integration scenario/runtime helper bytes: 110caecccf21ed7ae4ab66449c58c985f4c74695, in the isolated diagnostic checkout.
Kernel: d4a8921fa8530419c3d9790b80ff3c601217906d.
Bootloader: d48450b6bbccc80cbae3cfcf2feece3e6b04a347.
QEMU 10.2.2, q35, one CPU, Linux host, UEFI boot, release exception fixture.
Identical Kernel ELF SHA-256 in both observations: cb9ad957353d978604ecfebd393b8af73f6a66efd8f5fec93819b3b54a35f5d8.

Evidence and prior checks

Original image, EFI executable, firmware variable store, serial output, stderr and true command status are retained. Both builds have no warnings. The control changes acceleration only; deadlines, expected exit and required/forbidden markers remain. The original failed input was not retried unchanged. The three explicit-TCG native invocation, entry-direction and lifetime scenarios independently pass on the signed Kernel.

Tracking

Owning validation work: #1 and #12. Keep this local preboot failure separate from complete CI classification and later shell/storage watchdog defects. Next: bind the exact firmware and accelerator environment, establish the failing boot stage, and validate any correction under the original KVM configuration.

## Summary An additional local run of the existing double-fault scenario reaches its serial-silence deadline before any EriX boot marker when automatic acceleration resolves to KVM. An explicit TCG control passes the original exception assertions with the same Kernel ELF. The failing automatic run remains a failure; the guest or firmware cause and first affected revision are unestablished. ## Reproduction Use the isolated diagnostic component catalog and the unchanged `subsystem-kernel-exception-int8-negative` scenario with the standard scenario runner. On the observed Linux host, automatic acceleration selects KVM. Preserve the 60-second overall and 45-second serial-silence limits. Change only the scenario's accelerator selection to explicit TCG for the separate control. ## Expected and actual behavior Expected: reach the required IST marker and expected fatal exit within the original limits. Actual automatic/KVM run: serial output contains firmware terminal-control sequences and no EriX boot marker. The existing silence watchdog terminates the VM; the outer command exits 1 and cleanup completes. The separate TCG control reaches confirmed double-fault IST handling and the expected fatal exit. This distinction does not establish a Kernel regression or justify weakening the watchdog. ## Environment and identity - Integration scenario/runtime helper bytes: `110caecccf21ed7ae4ab66449c58c985f4c74695`, in the isolated diagnostic checkout. - Kernel: `d4a8921fa8530419c3d9790b80ff3c601217906d`. - Bootloader: `d48450b6bbccc80cbae3cfcf2feece3e6b04a347`. - QEMU 10.2.2, q35, one CPU, Linux host, UEFI boot, release exception fixture. - Identical Kernel ELF SHA-256 in both observations: `cb9ad957353d978604ecfebd393b8af73f6a66efd8f5fec93819b3b54a35f5d8`. ## Evidence and prior checks Original image, EFI executable, firmware variable store, serial output, stderr and true command status are retained. Both builds have no warnings. The control changes acceleration only; deadlines, expected exit and required/forbidden markers remain. The original failed input was not retried unchanged. The three explicit-TCG native invocation, entry-direction and lifetime scenarios independently pass on the signed Kernel. ## Tracking Owning validation work: https://git.erikinkinen.fi/erix/integration/issues/1 and https://git.erikinkinen.fi/erix/integration/pulls/12. Keep this local preboot failure separate from complete CI classification and later shell/storage watchdog defects. Next: bind the exact firmware and accelerator environment, establish the failing boot stage, and validate any correction under the original KVM configuration.

erikinkinen added the

bug

phase-6

labels

2026-09-17 16:03:56 +02:00

erikinkinen referenced this issue

2026-09-17 17:53:33 +02:00

[FEATURE] Freeze the complete source, build, ABI and self-hosting inventory #1

erikinkinen referenced this issue

2026-09-17 17:53:33 +02:00

WIP: Coordinate native authority, shell workspace and source transport #12

erikinkinen referenced this issue