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

Viswanath Kraleti (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 to select the appropriate XBL config based on COMBINED_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

Dmitry Baryshkov (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.

Viswanath Kraleti (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.

Dmitry Baryshkov (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.

Viswanath Kraleti (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.

Koen Kooi (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.

Koen Kooi (@koenkooi) Dmitry Baryshkov (@lumag) Ricardo Salveti (@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 qcom-common.inc 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

Ricardo Salveti (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.

Viswanath Kraleti (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>

Viswanath Kraleti (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.

Dmitry Baryshkov (lumag) · 2026-05-30T14:21:27Z

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

…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>

Viswanath Kraleti (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 qcom-common.inc 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

Viswanath Kraleti (vkraleti) · 2026-06-03T08:06:33Z

Ricardo Salveti (@ricardosalveti) Dmitry Baryshkov (@lumag) if there are no concerns with this approach, can you review this PR? This don't have any functional impact, as it is just reordering things.

Ricardo Salveti (ricardosalveti) · 2026-06-03T23:16:46Z

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

I don't see the need to have a gunyah distro features if all that is needed is the selection of the xbl binary to use, which could be done as part of the if / else check based on KVM. Distro features for kvm has a direct impact in meta-virtualization, but I don't see that as a direct conflict for gunyah.

Ricardo Salveti (ricardosalveti) · 2026-06-03T23:19:50Z

+local_conf_header:
+  kvm: |
+        MACHINE_FEATURES:append = " kvm"
+        DISTRO_FEATURES:append = " kvm"


We can set kvm in distro features by default and change image_types_qcom.bbclass to use combined for kvm, and when not available use gunyah by default, then you add the kvm machine feature to the machine you want to switch to kvm by default.

For machines that have KVM by default, we also need to provide an alternate build in CI with Gunyah, just like how we are providing a KVM build as of today. If gunyah distro feature is not defined, KAS configuration needs to have DISTRO_FEATURES:remove = "kvm" which is objected #2289 (comment).

Current PR is still modifying MACHINE_FEATURES & DISTRO_FEATURES in KAS config but this is a temporary change to facilitate switching. IT'll will be reverted as soon as meta-qcom-distro supports KVM by default.

Avoid hardcoding XBL configuration logic in image_types_qcom, which limits flexibility for per-board virtualization control. Define QCOM_XBL_CONFIG in qcom-common.inc to select the appropriate XBL config based on COMBINED_FEATURES. This enables consistent KVM selection while allowing machine-level overrides when required. Signed-off-by: Viswanath Kraleti <viswanath.kraleti@oss.qualcomm.com>

Viswanath Kraleti (vkraleti) · 2026-06-04T06:52:50Z

Ricardo Salveti (@ricardosalveti) Dmitry Baryshkov (@lumag) Thank you for the offline discussion. As suggested, moved all changes to #2251. This PR can be dropped for now.

Viswanath Kraleti (vkraleti) requested review from Anuj Mittal (anujm1), Koen Kooi (koenkooi), Dmitry Baryshkov (lumag), Milosz Wasilewski (mwasilew), Nicolas Dechesne (ndechesne), Jose Quaresma (quaresmajose), Ricardo Salveti (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

Draft

Enable KVM by default on Lemans and Monaco Platforms #2251

Merged

Dmitry Baryshkov (lumag) requested changes May 25, 2026

View reviewed changes

Comment thread ci/kvm.yml Outdated

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

Dmitry Baryshkov (lumag) requested changes May 26, 2026

View reviewed changes

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

Koen Kooi (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

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

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

Viswanath Kraleti (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

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

Viswanath Kraleti (vkraleti) force-pushed the drop-kvm-distro branch from 8a9f743 to 79ca897 Compare June 3, 2026 07:59

Ricardo Salveti (ricardosalveti) reviewed Jun 3, 2026

View reviewed changes

Comment thread conf/machine/glymur-crd.conf Outdated

Viswanath Kraleti (vkraleti) force-pushed the drop-kvm-distro branch from 79ca897 to f518aa0 Compare June 4, 2026 02:14

Viswanath Kraleti (vkraleti) changed the title ~~Define QCOM_XBL_CONFIG in machine conf for XBL config selection~~ Define QCOM_XBL_CONFIG in qcom-common.inc for XBL config selection Jun 4, 2026

Ricardo Salveti (ricardosalveti) closed this Jun 4, 2026

Viswanath Kraleti (vkraleti) deleted the drop-kvm-distro branch June 5, 2026 07:09

Viswanath Kraleti (vkraleti) removed the backport wrynose label Jun 5, 2026

Uh oh!

Conversation

Viswanath Kraleti (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!

Dmitry Baryshkov (lumag) left a comment

Choose a reason for hiding this comment

Uh oh!

Viswanath Kraleti (vkraleti) commented May 26, 2026

Uh oh!

Dmitry Baryshkov (lumag) commented May 26, 2026

Uh oh!

Viswanath Kraleti (vkraleti) commented May 26, 2026

Uh oh!

Koen Kooi (koenkooi) May 26, 2026

Choose a reason for hiding this comment

Uh oh!

Viswanath Kraleti (vkraleti) May 26, 2026

Choose a reason for hiding this comment

Uh oh!

Viswanath Kraleti (vkraleti) May 28, 2026

Choose a reason for hiding this comment

Uh oh!

Dmitry Baryshkov (lumag) May 28, 2026

Choose a reason for hiding this comment

Uh oh!

Viswanath Kraleti (vkraleti) May 28, 2026

Choose a reason for hiding this comment

Uh oh!

Dmitry Baryshkov (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!

Viswanath Kraleti (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!

Ricardo Salveti (ricardosalveti) commented May 29, 2026

Uh oh!

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

Uh oh!

Uh oh!

Viswanath Kraleti (vkraleti) commented May 30, 2026

Uh oh!

Dmitry Baryshkov (lumag) commented May 30, 2026

Uh oh!

Viswanath Kraleti (vkraleti) commented May 30, 2026

Uh oh!

github-actions Bot commented May 30, 2026

Test run workflow

Test jobs for commit 8a9f743

Uh oh!

Viswanath Kraleti (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`

Dmitry Baryshkov (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`

Viswanath Kraleti (vkraleti) commented May 30, 2026 •

edited

Loading

Test jobs for commit `8a9f743`

Viswanath Kraleti (vkraleti) Jun 4, 2026 •

edited

Loading

Viswanath Kraleti (vkraleti) Jun 4, 2026 •

edited

Loading