From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4EA08239082; Fri, 2 May 2025 10:39:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746182342; cv=none; b=JfY5oYIujVqSrTaEn4R/eBWSH6C218xU6jjugjQ4FBVDsWnFDYTKLUEBsfaO1zQNiqV2FCl5aXAmBFweRlJjGGL8nypCiRoN9OMlsKABVD0EaH9FMuvalQ4hXHTlNZg7MMotFRwMpL/1h/qImN+vyX2fXIKbedIuAuoMl3+M2v0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746182342; c=relaxed/simple; bh=f7lGEWra8akwIBqJIdDB2Ng4TJev3lq1HYEQGeCLqaM=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=R7F5FEUiDSjzCgrphPp/MGRi/hPzkQ0mNEzgjk3VC62pRt9S5kjK8mKoslR36It0naaHxwfbZ9+VmE1gSqWwJ+x+6tgaIEOS3d9XDJyYmIiil9r8/9ZzAxL4/G5wazkrY/ZmQOnQXI8c9MtxK5NgrMnMcB8kfHOk8h4LHqvE6DI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jGbzGH5D; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jGbzGH5D" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BC3E5C4CEE4; Fri, 2 May 2025 10:39:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746182341; bh=f7lGEWra8akwIBqJIdDB2Ng4TJev3lq1HYEQGeCLqaM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=jGbzGH5DE4S+7Ga2FSmBFzvPVYlnNUId/ZuwQPwvXiwrn578RcqxykB1stEFAQTMx YV+Oi6V1RNEJmVfux5IOw97KnNflWZ8d5NoPJFJY54jYXd5TaSSYikXEPxLJjjgmh+ a8IGul716ov0eiZqwxqhTW8Y+YHkGth3Kjc1Tu0rVWTU4HubmglJl9WQhzE7g/raYp cYa3/gRNEEliI8QxK/TybV0QY7EtGI8ige1MxDdeQuPQNNyOu6NsbnhgjQAQA8rqnr aGlpuqzp0U2vuH07TBvnY+dkyqAr2EuSK10wSQIb3pgmdLHcSD+iJeV8IrUIM/aDnQ DeqEXC8HIAmvg== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1uAnnH-00AryN-Rp; Fri, 02 May 2025 11:38:59 +0100 Date: Fri, 02 May 2025 11:38:58 +0100 Message-ID: <86o6wbguv1.wl-maz@kernel.org> From: Marc Zyngier To: Nikita Travkin Cc: Bjorn Andersson , Konrad Dybcio , Rob Herring , Krzysztof Kozlowski , Conor Dooley , cros-qcom-dts-watchers@chromium.org, Jens Glathe , linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 5/5] arm64: dts: qcom: x1e/x1p: Add EL2 overlay for WoA devices In-Reply-To: <20250501-sc-el2-overlays-v1-5-9202e59e3348@trvn.ru> References: <20250501-sc-el2-overlays-v1-0-9202e59e3348@trvn.ru> <20250501-sc-el2-overlays-v1-5-9202e59e3348@trvn.ru> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: nikita@trvn.ru, andersson@kernel.org, konradybcio@kernel.org, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, cros-qcom-dts-watchers@chromium.org, jens.glathe@oldschoolsolutions.biz, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Thu, 01 May 2025 18:03:45 +0100, Nikita Travkin 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 > --- > 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/ -- Without deviation from the norm, progress is not possible.