Define QCOM_XBL_CONFIG in machine conf for XBL config selection by vkraleti · Pull Request #2289 · qualcomm-linux/meta-qcom

vkraleti · 2026-05-25T17:26:02Z

Avoid hardcoding XBL configuration selection in image_types_qcom.bbclass, which limits flexibility to
enable KVM selectively across boards.

Define QCOM_XBL_CONFIG in machine configuration files to select the appropriate XBL config based on DISTRO_FEATURES. This enables per-board control of XBL configuration when KVM is enabled.

github-actions · 2026-05-25T20:08:15Z

Test run workflow

Test jobs for commit `d9c74ed`

qcom-distro
Pass: 259 | Fail: 1 | Total: 291

nodistro
Pass: 9 | Fail: 0 | Total: 9

qcom-distro_linux-qcom-6.18
Pass: 220 | Fail: 8 | Total: 249

test-reporting-app · 2026-05-25T20:08:38Z

Test Results

103 files ± 0 632 suites - 1 5h 10m 48s ⏱️ - 1h 40m 36s
128 tests - 3 102 ✅ - 7 0 💤 ±0 26 ❌ + 4
5 990 runs - 28 5 896 ✅ - 53 45 💤 +4 49 ❌ +21

For more details on these failures, see this check.

Results for commit 8a9f743. ± Comparison against base commit e89eaea.

This pull request removes 5 and adds 2 tests. Note that renamed tests count towards both.

14_Kubernetes_Kerne[ ‑ Kubernetes_Kernel_Config
lava ‑ 11_DSP_AudioPD
lava ‑ 1_CPUFreq_Validati[
lava ‑ lava-test-retry
lava ‑ lava-test-shell

3_AudioRecord_Config07 ‑ AudioRecord_Config09
lava ‑ 3_cdsp[

♻️ This comment has been updated with latest results.

github-actions · 2026-05-26T02:32:00Z

Test run workflow

Test jobs for commit `21b69ae`

qcom-distro
Pass: 238 | Fail: 1 | Total: 253

nodistro
Pass: 9 | Fail: 0 | Total: 9

qcom-distro_linux-qcom-6.18
Pass: 182 | Fail: 1 | Total: 209

lumag

Replace ci/qcom-distro-kvm.yml with a new ci/kvm.yml KAS

Why? What is the issue that you are trying to solve? I was under assumption that the machine configs are going to have the feature enabled. Now you are adding a config fragment to enable it.

vkraleti · 2026-05-26T04:58:41Z

Replace ci/qcom-distro-kvm.yml with a new ci/kvm.yml KAS

Why? What is the issue that you are trying to solve? I was under assumption that the machine configs are going to have the feature enabled. Now you are adding a config fragment to enable it.

Not all machine are ready to switch to KVM. Only Lemans and Monaco are tested and ready to switch. For Kodiak, Talos, Hamoa, Purwa meta-qcom still need to provide a parallel build for KVM verifications while continuing regular testing with Gunyah.

lumag · 2026-05-26T04:59:49Z

Replace ci/qcom-distro-kvm.yml with a new ci/kvm.yml KAS

Why? What is the issue that you are trying to solve? I was under assumption that the machine configs are going to have the feature enabled. Now you are adding a config fragment to enable it.

Not all machine are ready to switch to KVM. Only Lemans and Monaco are tested and ready to switch. For Kodiak, Talos, Hamoa, Purwa meta-qcom still need to provide a parallel build for KVM verifications while continuing regular testing with Gunyah.

Commit message.

vkraleti · 2026-05-26T06:44:29Z

Updated commit messages.

#2251 is the follow‑up PR to enable KVM by default for Lemans. Changes for Monaco, Kodiak, and Talos will be submitted shortly in separate PRs.

koenkooi · 2026-05-26T08:01:17Z

-distro: qcom-distro-kvm
+local_conf_header:
+  kvm: |
+      MACHINE_FEATURES:append = " kvm"


Having non-machines poking at MACHINE_FEATURES is a very bad idea

Yeah. But is there a better way to have two builds with and without a feature? We must have two builds with and without KVM till all SoCs are ready to migrate.

@koenkooi @lumag @ricardosalveti are you aligned to this approach? If not, is it fine to restore qualcomm-linux/meta-qcom-distro@32e7492 `

# Enable KVM distro feature if corresponding machine feature is set. # This allows users to enable KVM either via MACHINE_FEATURES or DISTRO_FEATURES. DISTRO_FEATURES:append = "${@bb.utils.contains('MACHINE_FEATURES', 'kvm', ' kvm', '', d)}"

Test teams are expecting KVM builds in CI for boards that are fully not ready.

No, setting DISTRO_FEATURES based on MACHINE_FEATURES is a clear NAK.

Ok, how about adding a check in image_types_qcom.bbclass to check for kvm either in machine or distro features?

if ${@bb.utils.contains('MACHINE_FEATURES', 'kvm', 'true', 'false', d)} || \ ${@bb.utils.contains('DISTRO_FEATURES', 'kvm', 'true', 'false', d)}; then xbl_config="xbl_config_kvm.elf" fi

What for? What does it logically mean? Should it be instead if ${bb.utils.contains('COMBINED_FEATURES', 'gunyah', 'true', 'false'} ; then ...

After exploring additional options, seems this transition needs to happen in incremental steps as listed below:

Move XBL config selection logic from image_types_qcom.bbclass to the respective machine .conf files.
This PR Define QCOM_XBL_CONFIG in machine conf for XBL config selection #2289 is updated for this change.

Introduce a Gunyah-specific distro to clearly model the alternate hypervisor use case.
Updated Add Gunyah-specific distro configuration meta-qcom-distro#306

For KVM-ready machines, update XBL config selection based on the Gunyah distro. Updated PR Enable KVM by default on Lemans and Monaco Platforms #2251

Once all machines are migrated, drop the KVM distro feature and standardize on the Gunyah distro for alternate hypervisor builds.

github-actions · 2026-05-26T09:23:41Z

Test run workflow

Test jobs for commit `04ccff6`

qcom-distro
Pass: 8 | Fail: 1 | Total: 9

nodistro
Pass: 9 | Fail: 0 | Total: 9

qcom-distro_linux-qcom-6.18
Pass: 216 | Fail: 3 | Total: 245

github-actions · 2026-05-27T09:37:06Z

Test run workflow

Test jobs for commit `04ccff6`

qcom-distro_linux-qcom-6.18
Pass: 221 | Fail: 2 | Total: 249

qcom-distro
Pass: 249 | Fail: 1 | Total: 278

nodistro
Pass: 9 | Fail: 0 | Total: 9

github-actions · 2026-05-28T04:33:10Z

Test run workflow

Test jobs for commit `04ccff6`

qcom-distro_linux-qcom-6.18
Pass: 221 | Fail: 2 | Total: 249

qcom-distro
Pass: 266 | Fail: 1 | Total: 296

nodistro
Pass: 9 | Fail: 0 | Total: 9

…BL selection Avoid hardcoding XBL configuration selection in image_types_qcom.bbclass, which limits flexibility to enable KVM selectively across boards. Define QCOM_XBL_CONFIG in machine configuration files to select the appropriate XBL config based on DISTRO_FEATURES. This enables per-board control of XBL configuration when KVM is enabled. Signed-off-by: Viswanath Kraleti <viswanath.kraleti@oss.qualcomm.com>

github-actions · 2026-05-29T20:19:22Z

Test run workflow

Test jobs for commit `265fd1d`

qcom-distro_linux-qcom-6.18
Pass: 226 | Fail: 0 | Total: 244

qcom-distro
Pass: 262 | Fail: 0 | Total: 286

nodistro
Pass: 9 | Fail: 0 | Total: 9

ricardosalveti · 2026-05-29T22:51:42Z

I find this all a bit confusing, and we are not really improving the current state of things here.

The configuration nobs we have in the end:

Machine specific decision to support either KVM or gunyah (based on the DTBs available and also based on the XBL config used by the machine, both are BSP specific decisions)
Distro specific decision that enables KVM support (as found in meta-virtualization)

Now for gunyah, do we need any distro specific policy to support it to the same way we support KVM? If indeed the case, then we should indeed have multiple distros and pick one by default (KVM). Here COMBINED_FEATURES would work better when deciding the XBL to flash (and done in a common file, not in every machine conf), but for this to work we would have to define a KVM/Gynuah machine feature.

vkraleti · 2026-05-30T05:53:38Z

Yes, Gunyah needs to be another distro feature, otherwise managing builds becomes really hard. qualcomm-linux/meta-qcom-distro#306 is defining this.

Once this distro feature is available, machine configurations can start making decisions like
6da7c10#diff-d0fec212e122859b520a519af2bcefb7be12afc7148c6df0f991115c362ea85cR38
QCOM_XBL_CONFIG ?= "${@bb.utils.contains("DISTRO_FEATURES", "gunyah", "xbl_config_gunyah.elf", "xbl_config_kvm.elf", d)}"

To convert KVM to a combined feature, first machine configs need to have the control on XBL config installations. Current PR (#2289) provides this control. Once this and gunyah distro feature are available, `kvm' can be added to DISTRO_FEATURES by default to facilitate combined feature checks.

Post that machine confs can define 'kvm' as a machine feature and convert the XBL config installation checks to use 'kvm' COMBINED_FEATURE.

All this juggling is to avoid CI breakages and to continue providing a secondary build for alternate hypervisor testing.

…BL selection Avoid hardcoding XBL configuration selection in image_types_qcom.bbclass, which limits flexibility to enable KVM selectively across boards. Define QCOM_XBL_CONFIG in machine configuration files to select the appropriate XBL config based on DISTRO_FEATURES. This enables per-board control of XBL configuration when KVM is enabled. Signed-off-by: Viswanath Kraleti <viswanath.kraleti@oss.qualcomm.com>

vkraleti · 2026-05-30T14:15:15Z

If you agree for a brief CI downtime, I can make changes to add kvm unconditionally to DISTRO_FEATURES and defining new qcom-distro-gunyah conf in one meta-qcom-distro PR, equivalent machine conf changes in one meta-qcom PR. meta-qcom-distro PR needs to merge by skipping CI. meta-qcom PR can validate e2e in CI.

lumag · 2026-05-30T14:21:27Z

@vkraleti I'd rather not. If something fails, we end up with broken CI or broken config.

Avoid hardcoding XBL configuration selection in image_types_qcom bbclass, which limits flexibility to enable KVM selectively across boards. Define QCOM_XBL_CONFIG in machine configuration files to select the appropriate XBL config based on `kvm` in COMBINED_FEATURES. This enables per-board control of XBL configuration selection. Signed-off-by: Viswanath Kraleti <viswanath.kraleti@oss.qualcomm.com>

Adjust CI to handle removal of qcom-distro-kvm configuration in meta-qcom-distro, where KVM is now enabled by default. Replace usage of the qcom-distro-kvm distro with explicit MACHINE_FEATURES and DISTRO_FEATURES additions to retain KVM-enabled builds during the transition. This is a temporary workaround until CI fully adopts the new KVM-by-default model. Signed-off-by: Viswanath Kraleti <viswanath.kraleti@oss.qualcomm.com>

…BL selection Avoid hardcoding XBL configuration selection in image_types_qcom bbclass, which limits flexibility to enable KVM selectively across boards. Define QCOM_XBL_CONFIG in machine configuration files to select the appropriate XBL config based on `kvm` in COMBINED_FEATURES. This enables per-board control of XBL configuration selection. Signed-off-by: Viswanath Kraleti <viswanath.kraleti@oss.qualcomm.com>

…stro-kvm Adjust CI to handle removal of qcom-distro-kvm configuration in meta-qcom-distro, where KVM is now enabled by default. Replace usage of the qcom-distro-kvm distro with explicit MACHINE_FEATURES and DISTRO_FEATURES additions to retain KVM-enabled builds during the transition. This is a temporary workaround until CI fully adopts the new KVM-by-default model. Signed-off-by: Viswanath Kraleti <viswanath.kraleti@oss.qualcomm.com>

vkraleti · 2026-05-30T18:21:40Z

Ok. PRs should be merged in following order to make the switch.

Add Gunyah-specific distro configuration meta-qcom-distro#306 (Defines qcom-distro-gunyah)
Define QCOM_XBL_CONFIG in machine conf for XBL config selection #2289 (Move XBL config selection to machine.conf & stop using qcom-distro-kvm)
Make KVM as a default distro feature meta-qcom-distro#314 (Drop qcom-distro-kvm and make kvm default part of DISTRO_FEATURES)
Enable KVM by default on Lemans and Monaco Platforms #2251 (Switch Leamans & Monaco to default KVM and introduce Gunyah builds for 2nd Hypervisor testing)
Similar changes to above for Kodaik, Talos and any other machine that needs to switch.
Drop all KVM references in CI KAS files.

github-actions · 2026-05-30T20:52:00Z

Test run workflow

Test jobs for commit `8a9f743`

qcom-distro_linux-qcom-6.18
Pass: 207 | Fail: 2 | Total: 231

qcom-distro
Pass: 253 | Fail: 2 | Total: 278

nodistro
Pass: 9 | Fail: 0 | Total: 9

vkraleti requested review from anujm1, koenkooi, lumag, mwasilew, ndechesne, quaresmajose, ricardosalveti and sbanerjeeqc as code owners May 25, 2026 17:26

This was referenced May 25, 2026

Add Gunyah-specific distro configuration qualcomm-linux/meta-qcom-distro#306

Open

Enable KVM by default on Lemans and Monaco Platforms #2251

Open

lumag requested changes May 25, 2026

View reviewed changes

Comment thread ci/kvm.yml Outdated

vkraleti force-pushed the drop-kvm-distro branch from d9c74ed to 21b69ae Compare May 25, 2026 23:34

lumag requested changes May 26, 2026

View reviewed changes

vkraleti force-pushed the drop-kvm-distro branch from 21b69ae to 04ccff6 Compare May 26, 2026 06:40

koenkooi requested changes May 26, 2026

View reviewed changes

sbanerjeeqc added the backport wrynose label May 29, 2026

sbanerjeeqc added this to the qli-2.0 GA pull-request freeze milestone May 29, 2026

vkraleti force-pushed the drop-kvm-distro branch from 04ccff6 to 265fd1d Compare May 29, 2026 09:05

vkraleti changed the title ~~Enable KVM via MACHINE_FEATURES~~ Define QCOM_XBL_CONFIG in machine conf for XBL selection May 29, 2026

vkraleti changed the title ~~Define QCOM_XBL_CONFIG in machine conf for XBL selection~~ Define QCOM_XBL_CONFIG in machine conf for XBL config selection May 29, 2026

vkraleti added 2 commits May 30, 2026 22:26

vkraleti force-pushed the drop-kvm-distro branch from 265fd1d to 8a9f743 Compare May 30, 2026 17:30

Conversation

vkraleti commented May 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented May 25, 2026

Test run workflow

Test jobs for commit d9c74ed

Uh oh!

test-reporting-app Bot commented May 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test Results

Uh oh!

Uh oh!

github-actions Bot commented May 26, 2026

Test run workflow

Test jobs for commit 21b69ae

Uh oh!

lumag left a comment

Choose a reason for hiding this comment

Uh oh!

vkraleti commented May 26, 2026

Uh oh!

lumag commented May 26, 2026

Uh oh!

vkraleti commented May 26, 2026

Uh oh!

koenkooi May 26, 2026

Choose a reason for hiding this comment

Uh oh!

vkraleti May 26, 2026

Choose a reason for hiding this comment

Uh oh!

vkraleti May 28, 2026

Choose a reason for hiding this comment

Uh oh!

lumag May 28, 2026

Choose a reason for hiding this comment

Uh oh!

vkraleti May 28, 2026

Choose a reason for hiding this comment

Uh oh!

lumag May 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vkraleti May 29, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented May 26, 2026

Test run workflow

Test jobs for commit 04ccff6

Uh oh!

github-actions Bot commented May 27, 2026

Test run workflow

Test jobs for commit 04ccff6

Uh oh!

github-actions Bot commented May 28, 2026

Test run workflow

Test jobs for commit 04ccff6

Uh oh!

github-actions Bot commented May 29, 2026

Test run workflow

Test jobs for commit 265fd1d

Uh oh!

ricardosalveti commented May 29, 2026

Uh oh!

vkraleti commented May 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vkraleti commented May 30, 2026

Uh oh!

lumag commented May 30, 2026

Uh oh!

vkraleti commented May 30, 2026

Uh oh!

github-actions Bot commented May 30, 2026

Test run workflow

Test jobs for commit 8a9f743

Uh oh!

Reviewers

vkraleti commented May 25, 2026 •

edited

Loading

Test jobs for commit `d9c74ed`

test-reporting-app Bot commented May 25, 2026 •

edited

Loading

Test jobs for commit `21b69ae`

lumag May 28, 2026 •

edited

Loading

Test jobs for commit `04ccff6`

Test jobs for commit `04ccff6`

Test jobs for commit `04ccff6`

Test jobs for commit `265fd1d`

vkraleti commented May 30, 2026 •

edited

Loading

Test jobs for commit `8a9f743`