Add Gunyah-specific distro configuration

[vkraleti]

Define qcom-distro-gunyah modeled after the KVM variant. It enables the 'gunyah' DISTRO_FEATURE and provides a dedicated configuration for Gunyah-based builds.

[lumag]

No. The DISTRO_FEATURES are features of the distro. They should not depend on the machine. If you want to select something based on both, use COMBINED_FEATURES.

[vkraleti]

At present, KVM is a DISTRO_FEATURE, but not all boards are ready to support it.
The ask here is to:

1. Generate CI builds with KVM enabled for boards that are getting ready for KVM testing, and
2. Switch boards that are already validated to KVM by default.

Given that this is effectively an either-or decision per board, but not checking KVM through COMBINED_FEATURES for both.

If conditionally enabling DISTRO_FEATURES per machine is not recommended, should we instead move KVM checks entirely to MACHINE_FEATURES?

[lumag]

At present, KVM is a DISTRO_FEATURE, but not all boards are ready to support it. The ask here is to:

Well, you didn't write any of this in the commit message. That's why we are always asking to start the commit message from the description of the issue or the problem that is being solved.

1. Generate CI builds with KVM enabled for boards that are getting ready for KVM testing, and
2. Switch boards that are already validated to KVM by default.

Here you have two different items:

• Select whether to include KVM enablement into the generated kernel+rootfs image.
• Select whether to enable KVM-enabled XBL config in the flashable image.

Those two items (ideally) should be independent. The first one is (correctly) controlled by the kvm being a part of DISTRO_FEATURES. The second one is purely a part of the machine configuration.

Given that this is effectively an either-or decision per board, but not checking KVM through COMBINED_FEATURES for both.

If conditionally enabling DISTRO_FEATURES per machine is not recommended, should we instead move KVM checks entirely to MACHINE_FEATURES?

I think, the correct way to fix your problem would be to make machines use MACHINE_FEATURES to control kvm vs gunyah XBL config, enable kvm in qcom-distro's DISTRO_FEATURES and drop qcom-disto-kvm completely. I'm slowly implementing support for multi-config 'flash' image generation (which would get rid of this issue, letting us generate both KVM and Gunyah images at the same time, just in the different subfolders), but that will take some time to materialize.

[vkraleti]

There is only one place in image_types_qcom.bbclass where the KVM distro feature is checked.
Given that, it seems much simpler to introduce a conditional check that considers both MACHINE_FEATURES and DISTRO_FEATURES in this bbclass itself, rather than restructuring how the feature is assigned across multiple layers. I added a 2a9b412 in qualcomm-linux/meta-qcom#2251 to add this conditional check.

[lumag]

@vkraleti if you are switching to MACHINE_FEATURES, there is no need to check for DISTRO_FEATURES anymore.

[vkraleti]

@vkraleti if you are switching to MACHINE_FEATURES, there is no need to check for DISTRO_FEATURES anymore.

Agreed. Check of both MACHINE_FEATURES & DISTRO_FEATURES is needed in short term for transition till all KLMT boards are ready to switch to default KVM. Post that qcom-disto-kvm can be completely dropped.

[lumag]

@vkraleti if you are switching to MACHINE_FEATURES, there is no need to check for DISTRO_FEATURES anymore.

Agreed. Check of both MACHINE_FEATURES & DISTRO_FEATURES is needed in short term for transition till all KLMT boards are ready to switch to default KVM. Post that qcom-disto-kvm can be completely dropped.

No. We can drop it now. Enable KVM parts of the distro by default and let machines dictate if Gunyah or KVM XBL config is installed by default.

[lumag]

Why do we need :remove here? What is going to add those?

[vkraleti]

Not at this point. But when kvm is enabled by default in #314, both kvm and gunyah may endup in distro - - features. Moved :remove to PR#314 for better alignment.

[ricardosalveti]

I don't see why this is needed yet, nothing else depend on it.

[vkraleti]

POR is still to support both hypervisors. Once kvm is default, builds with gunyah are still needed for interested users. Thus this DISTRO_FEATURE is defined. A refrence usage is in qualcomm-linux/meta-qcom@4f52095

[vkraleti]

@ricardosalveti @lumag Thank you for the offline discussion. As suggested, we will hold this PR for now.

I’ve updated #314 to make kvm as a part of default DISTRO_FEATURES. We can revisit this PR once a dedicated Gunyah build is required.

[ricardosalveti]

Will move to draft then!