feat(vmm-tests): add per-test Linux kernel version selection

[moor-coding]

Add infrastructure for tests to specify which Linux kernel version to use, enabling per-test kernel version pinning.

Changes

• Add LinuxDirectKernelVersion enum to petri_artifacts_vmm_test with V6_1 and V6_18 variants
• Add version-specific artifact IDs for kernel and vmlinux (LINUX_DIRECT_TEST_KERNEL_X64_6_1, etc.)
• Add linux_direct_with_version() and linux_direct_bzimage_with_version() methods to petri VM builder
• Extend #[vmm_test] macro to accept parenthesized kernel version syntax: linux_direct_x64(kernel_6_1)
• Update flowey to download all registered kernel versions and place them at versioned paths
• Add Linux6_18 variant to LinuxTestKernelVersion in flowey resolver

Motivation

The upcoming openvmm-deps 0.3.0-33 release adds Linux 6.18 kernel support. Some tests (e.g., pcie_devices) cannot run on 6.18 due to a known kernel bug in mana_gd_probe. This PR adds the ability to pin individual tests to a specific kernel version, so the default can be upgraded to 6.18 while problematic tests remain on 6.1.

A follow-up PR will flip the default kernel to 6.18 and pin pcie_devices to 6.1.

Usage

Tests can now specify a kernel version in the #[vmm_test] attribute:

#[vmm_test(linux_direct_x64(kernel_6_1))]
async fn my_test(config: PetriVmBuilder<PetriVmmHvLite>) -> anyhow::Result<()> {
    // runs with 6.1 kernel specifically
}

Unversioned linux_direct_x64 continues to use the default kernel version (currently 6.1).

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[smalis-msft]

This may be a maintainer question, but do we really want this functionality? Do we foresee a need to support more than one test kernel? I'd rather just do something like mark the one test unstable in order to update the test kernel to 6.18 everywhere, and then re stable it when a kernel fix is available.

[moor-coding]

This may be a maintainer question, but do we really want this functionality? Do we foresee a need to support more than one test kernel? I'd rather just do something like mark the one test unstable in order to update the test kernel to 6.18 everywhere, and then re stable it when a kernel fix is available.

This change is coming from a discussion with @benhillis, I'm not sure of what the long-term outlook for the testing approach is at this moment so would love to get input from him

[benhillis]

This may be a maintainer question, but do we really want this functionality? Do we foresee a need to support more than one test kernel? I'd rather just do something like mark the one test unstable in order to update the test kernel to 6.18 everywhere, and then re stable it when a kernel fix is available.

I wanted to discuss this yesterday in the maintainers sync but we didn't really have quorum. I don't think it would be a bad idea to have a number of different guest OS kernels, we do in Azure right?

[smalis-msft]

I mean we do, but we probably get better coverage of those by including full linux distros, since distros may include their own patches or build configs different from ours. Linux direct testing is meant for simple quick validation.

[github-actions]

1 Petri tests failed (1 unstable)