PR 1208 | Job 269735 | SoC shikra-iqs-evk | Case 8

Failed case: KVM_Infra
LAVA job: https://lava-oss.qualcomm.com/scheduler/job/269735
Skill hint: qlijarvis-triage

Detailed analysis

Summary: The KVM_Infra test failure on Shikra IQS EVK is not a kernel regression or bug introduced by PR #1208 (which only modifies power management headers and reboot reason handling). The failure occurs because the platform is configured to boot under the Gunyah hypervisor, which occupies EL2 (hypervisor privilege level). KVM requires direct EL2 access to create virtual machines, but when Linux runs as a guest under Gunyah, EL2 is unavailable. The kernel correctly detects this and disables KVM initialization, resulting in /dev/kvm not being created. This is expected architectural behavior on hypervisor-based platforms.

Evidence from logs:

Hypervisor presence confirmed (line 2668): "Hypervisor cold boot, version: gunyah-mobile-98db777b6 perf (2026-09-24 04:12:27 UTC)" and "Gunyah based bootup" — the platform explicitly boots under Gunyah hypervisor, which runs at EL2.
KVM initialization correctly aborted (line 6290): "kvm [1]: HYP mode not available" — KVM's arm64 initialization code detects that EL2 is not accessible (because Gunyah is already using it) and gracefully fails initialization.
CONFIG_KVM enabled but device node absent (lines 6273-6288): The test confirms CONFIG_KVM=y in kernel config, but /dev/kvm is not present because the KVM subsystem never completed initialization due to missing HYP mode access.
PR #1208 is unrelated (pr.patch analysis): The PR only touches power management infrastructure (power_on_reason.h, hw_protection_trigger, reboot.c, thermal, regulator) and has zero overlap with KVM, virtualization, or ARM EL2 handling.
Platform architecture (multiple lines): Shikra IQS EVK (aarch64) running kernel 6.18.56-03363-gfd57c6093752 — this is a Qualcomm platform configured for Gunyah-based virtualization architecture.

Failure mechanism:

Boot stage: ABL/UEFI loads the Gunyah hypervisor first, which initializes at EL2 and takes control of the hardware virtualization extensions.
Kernel boot: Linux kernel boots as a guest VM under Gunyah, running at EL1 (not EL2).
KVM initialization (arch/arm64/kvm/arm.c): During subsys_initcall, KVM's kvm_arm_init() checks if the CPU is running at EL2 or has access to VHE (Virtualization Host Extensions). On this platform, the check fails because:
- CPU is at EL1 (guest mode under Gunyah)
- EL2 is occupied by Gunyah hypervisor
- Nested virtualization is not enabled/supported
Result: KVM prints "HYP mode not available" and returns early from initialization without registering the /dev/kvm character device.
Test execution: KVM_Infra test runs, finds CONFIG_KVM=y (correct), but /dev/kvm is absent (also correct given the hypervisor context), and incorrectly reports this as a FAIL instead of recognizing it as an expected platform limitation.

Alternative hypotheses considered:

Hypothesis 1: KVM driver bug or missing kernel config — Ruled out because CONFIG_KVM is enabled, and the "HYP mode not available" message is an intentional, correct detection of the hypervisor environment, not an error condition.
Hypothesis 2: PR #1208 broke KVM initialization — Ruled out because the PR only modifies power/reboot subsystems with no code path overlap with KVM or ARM virtualization extensions. The failure is architectural, not code-related.
Hypothesis 3: Device tree or firmware issue preventing EL2 access — Ruled out because the Gunyah hypervisor successfully initialized at EL2, proving the hardware and firmware support virtualization. The issue is that Gunyah is using EL2, not that EL2 is broken.

Validation plan:

Confirm hypervisor configuration: Check the ABL/UEFI boot configuration for Shikra IQS EVK — verify that Gunyah hypervisor boot is intentional for this platform's use case (likely for secure VM or protected VM support).
Verify test expectations: Review the LAVA test suite design — determine if KVM tests are intended to run on all platforms or should be conditional based on boot mode (native vs hypervisor-guest).
Check other platforms: Compare with LAVA results from platforms that boot natively (without Gunyah) — KVM tests should pass there, confirming this is platform-specific, not a kernel-wide regression.

Recommended fix plan:

Short-term mitigation: Update the LAVA test definition for KVM_Infra (and related KVM_Driver, KVM_EL2_DTB tests) to add a pre-flight check:

if dmesg | grep -q "Hypervisor cold boot\|Gunyah based bootup"; then
    echo "[SKIP] Platform boots under hypervisor — KVM requires native EL2 access"
    exit 0  # or appropriate LAVA skip signal
fi

This prevents false failures on hypervisor-based platforms.

Proper fix: Implement platform-aware test selection in the LAVA job definition:
- Add a platform metadata field indicating boot mode (native vs hypervisor-guest)
- For Shikra IQS EVK and other Gunyah-based platforms, exclude KVM tests from the test suite or mark them as "not applicable"
- Document that KVM tests are only valid on platforms with native EL2 access
Verification on this SoC/LAVA flow:
- After implementing the skip logic, re-run the LAVA job on Shikra IQS EVK
- Confirm KVM tests are marked SKIP (not FAIL) with appropriate reason
- Verify the same kernel build passes KVM tests on a non-hypervisor platform (e.g., a platform that boots Linux directly without Gunyah)
- Ensure no other tests are affected by the change

Raw agent output

Now let me systematically check each CoT for applicability. Based on my analysis, this is NOT a kernel crash, build load failure, or driver issue - it's an expected behavior where KVM cannot run under a hypervisor. Let me verify by checking the relevant CoTs:

Based on my complete analysis following the qlijarvis-triage skill workflow, I can now provide the required output:

[CASE_REPORT]

Failed Case: KVM_Infra — Test Infrastructure Limitation (Not a Kernel Bug)
Root Cause: The Shikra IQS EVK platform boots under the Gunyah hypervisor (gunyah-mobile-98db777b6), which runs at EL2 and prevents nested virtualization. KVM requires direct access to EL2 (HYP mode) to function, but when the kernel runs as a guest under Gunyah, EL2 is already occupied by the hypervisor. The kernel correctly detects this condition during KVM initialization and reports "kvm [1]: HYP mode not available", which prevents /dev/kvm from being created. This is expected architectural behavior, not a regression.
Fix: This is not a bug requiring a fix. The KVM_Infra test should be skipped on platforms configured to boot under the Gunyah hypervisor. Update the LAVA test definition to add a pre-condition check: if hypervisor boot is detected (check for "Gunyah based bootup" or "Hypervisor cold boot" in dmesg), mark KVM tests as SKIP with reason "Platform runs under hypervisor — nested virtualization not supported" rather than FAIL. [/CASE_REPORT]

[DETAILED_ANALYSIS] Summary: The KVM_Infra test failure on Shikra IQS EVK is not a kernel regression or bug introduced by PR #1208 (which only modifies power management headers and reboot reason handling). The failure occurs because the platform is configured to boot under the Gunyah hypervisor, which occupies EL2 (hypervisor privilege level). KVM requires direct EL2 access to create virtual machines, but when Linux runs as a guest under Gunyah, EL2 is unavailable. The kernel correctly detects this and disables KVM initialization, resulting in /dev/kvm not being created. This is expected architectural behavior on hypervisor-based platforms.