[5/5] arm64: dts: qcom: x1e/x1p: Add EL2 overlay for WoA devices

WoA devices using x1e/x1p use android firmware to boot, which notably
includes Gunyah hypervisor. This means that, so far, Linux-based OS
could only boot in EL1 on those devices.

However Windows can replace Gunyah upon boot with it's own hypervisor,
and with the use of tools such as "slbounce", it's possible to do the
same for Linux-based OS, in which case some modifications to the DT are
necessary to facilitate the absence of Gunyah services.

Add a EL2-specific DT overlay and apply it to x1e/x1p WoA devices to
create -el2.dtb for each of them alongside "normal" dtb.

Signed-off-by: Nikita Travkin <nikita@trvn.ru>
---
 arch/arm64/boot/dts/qcom/Makefile      | 36 +++++++++++++++++---------
 arch/arm64/boot/dts/qcom/x1-el2.dtso   | 46 ++++++++++++++++++++++++++++++++++
 arch/arm64/boot/dts/qcom/x1e80100.dtsi |  2 +-
 3 files changed, 71 insertions(+), 13 deletions(-)

On Thu, 01 May 2025 18:03:45 +0100,
Nikita Travkin <nikita@trvn.ru> wrote:
> 
> WoA devices using x1e/x1p use android firmware to boot, which notably
> includes Gunyah hypervisor. This means that, so far, Linux-based OS
> could only boot in EL1 on those devices.
> 
> However Windows can replace Gunyah upon boot with it's own hypervisor,
> and with the use of tools such as "slbounce", it's possible to do the
> same for Linux-based OS, in which case some modifications to the DT are
> necessary to facilitate the absence of Gunyah services.
> 
> Add a EL2-specific DT overlay and apply it to x1e/x1p WoA devices to
> create -el2.dtb for each of them alongside "normal" dtb.
> 
> Signed-off-by: Nikita Travkin <nikita@trvn.ru>
> ---
>  arch/arm64/boot/dts/qcom/Makefile      | 36 +++++++++++++++++---------
>  arch/arm64/boot/dts/qcom/x1-el2.dtso   | 46 ++++++++++++++++++++++++++++++++++
>  arch/arm64/boot/dts/qcom/x1e80100.dtsi |  2 +-
>  3 files changed, 71 insertions(+), 13 deletions(-)
>

[...]

> diff --git a/arch/arm64/boot/dts/qcom/x1-el2.dtso b/arch/arm64/boot/dts/qcom/x1-el2.dtso
> new file mode 100644
> index 0000000000000000000000000000000000000000..7a818045ef098b44632df45253d32e31c5c7aeed
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/x1-el2.dtso
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +
> +/*
> + * x1 specific modifications required to boot in EL2.
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +/* We can't and don't need to use zap shader in EL2 as linux can zap the gpu on it's own. */
> +&gpu_zap_shader {
> +	status = "disabled";
> +};
> +
> +/*
> + * When running under Gunyah, this IOMMU is controlled by the firmware,
> + * however when we take ownership of it in EL2, we need to configure
> + * it properly to use PCIe.
> + */
> +&pcie3 {
> +	iommu-map = <0 &pcie_smmu 0x30000 0x10000>;
> +};
> +
> +&pcie4 {
> +	iommu-map = <0 &pcie_smmu 0x40000 0x10000>;
> +};
> +
> +&pcie5 {
> +	iommu-map = <0 &pcie_smmu 0x50000 0x10000>;
> +};
> +
> +&pcie6a {
> +	iommu-map = <0 &pcie_smmu 0x60000 0x10000>;
> +};
> +
> +&pcie_smmu {
> +	status = "okay";
> +};
> +
> +/*
> + * The "SBSA watchdog" is implemented in software in Gunyah
> + * and can't be used when running in EL2.
> + */
> +&sbsa_watchdog {
> +	status = "disabled";
> +};

I also carry this [1] patch to correctly route MSIs from pcie5 to the
ITS. There is no reason not to. The same treatment could be applied to
pcie3, but I never tried it.

Thanks,

	M.

[1] https://lore.kernel.org/linux-arm-kernel/20241024161814.1827514-1-maz@kernel.org/

Marc Zyngier писал(а) 02.05.2025 15:38:
> On Thu, 01 May 2025 18:03:45 +0100,
> Nikita Travkin <nikita@trvn.ru> wrote:
>> 
>> WoA devices using x1e/x1p use android firmware to boot, which notably
>> includes Gunyah hypervisor. This means that, so far, Linux-based OS
>> could only boot in EL1 on those devices.
>> 
>> However Windows can replace Gunyah upon boot with it's own hypervisor,
>> and with the use of tools such as "slbounce", it's possible to do the
>> same for Linux-based OS, in which case some modifications to the DT are
>> necessary to facilitate the absence of Gunyah services.
>> 
>> Add a EL2-specific DT overlay and apply it to x1e/x1p WoA devices to
>> create -el2.dtb for each of them alongside "normal" dtb.
>> 
>> Signed-off-by: Nikita Travkin <nikita@trvn.ru>
>> ---
>>  arch/arm64/boot/dts/qcom/Makefile      | 36 +++++++++++++++++---------
>>  arch/arm64/boot/dts/qcom/x1-el2.dtso   | 46 ++++++++++++++++++++++++++++++++++
>>  arch/arm64/boot/dts/qcom/x1e80100.dtsi |  2 +-
>>  3 files changed, 71 insertions(+), 13 deletions(-)
>>
> 
> [...]
> 
>> diff --git a/arch/arm64/boot/dts/qcom/x1-el2.dtso b/arch/arm64/boot/dts/qcom/x1-el2.dtso
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..7a818045ef098b44632df45253d32e31c5c7aeed
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/qcom/x1-el2.dtso
>> @@ -0,0 +1,46 @@
>> +// SPDX-License-Identifier: BSD-3-Clause
>> +
>> +/*
>> + * x1 specific modifications required to boot in EL2.
>> + */
>> +
>> +/dts-v1/;
>> +/plugin/;
>> +
>> +/* We can't and don't need to use zap shader in EL2 as linux can zap the gpu on it's own. */
>> +&gpu_zap_shader {
>> +	status = "disabled";
>> +};
>> +
>> +/*
>> + * When running under Gunyah, this IOMMU is controlled by the firmware,
>> + * however when we take ownership of it in EL2, we need to configure
>> + * it properly to use PCIe.
>> + */
>> +&pcie3 {
>> +	iommu-map = <0 &pcie_smmu 0x30000 0x10000>;
>> +};
>> +
>> +&pcie4 {
>> +	iommu-map = <0 &pcie_smmu 0x40000 0x10000>;
>> +};
>> +
>> +&pcie5 {
>> +	iommu-map = <0 &pcie_smmu 0x50000 0x10000>;
>> +};
>> +
>> +&pcie6a {
>> +	iommu-map = <0 &pcie_smmu 0x60000 0x10000>;
>> +};
>> +
>> +&pcie_smmu {
>> +	status = "okay";
>> +};
>> +
>> +/*
>> + * The "SBSA watchdog" is implemented in software in Gunyah
>> + * and can't be used when running in EL2.
>> + */
>> +&sbsa_watchdog {
>> +	status = "disabled";
>> +};
> 
> I also carry this [1] patch to correctly route MSIs from pcie5 to the
> ITS. There is no reason not to. The same treatment could be applied to
> pcie3, but I never tried it.
> 

Oh, interesting... I will add 

    &pcie3 { msi-map = <0 &gic_its 0xb0000 0x10000>; };
    &pcie5 { msi-map = <0 &gic_its 0xd0000 0x10000>; };

to the overlay then. (At least I hope the base value falls in line with
the rule so far, while I know how to confirm iommu-map via acpi tables,
not sure where this one is described, if at all)

Will send a v2 shortly, thanks!

Nikita

> Thanks,
> 
> 	M.
> 
> [1] https://lore.kernel.org/linux-arm-kernel/20241024161814.1827514-1-maz@kernel.org/