* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Nicolas Frattaroli @ 2026-03-27 12:56 UTC (permalink / raw)
To: Maxime Ripard, Ville Syrjälä
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Thomas Zimmermann, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Sandy Huang, Heiko Stübner, Andy Yan,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Dmitry Baryshkov, Sascha Hauer, Rob Herring, Jonathan Corbet,
Shuah Khan, kernel, amd-gfx, dri-devel, linux-kernel,
linux-arm-kernel, linux-rockchip, intel-gfx, intel-xe, linux-doc,
Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <acVzwRyk_J24GrJ4@intel.com>
On Thursday, 26 March 2026 18:58:25 Central European Standard Time Ville Syrjälä wrote:
> On Thu, Mar 26, 2026 at 06:02:47PM +0100, Maxime Ripard wrote:
> > On Wed, Mar 25, 2026 at 08:43:15PM +0200, Ville Syrjälä wrote:
> > > On Wed, Mar 25, 2026 at 03:56:58PM +0100, Maxime Ripard wrote:
> > > > On Wed, Mar 25, 2026 at 01:03:07PM +0200, Ville Syrjälä wrote:
> > > > > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > > > > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > > > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > > +enum drm_connector_color_format {
> > > > > > > > > > + /**
> > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > > > > > > > > > + * helpers should pick a suitable color format. All implementations of a
> > > > > > > > > > + * specific display protocol must behave the same way with "AUTO", but
> > > > > > > > > > + * different display protocols do not necessarily have the same "AUTO"
> > > > > > > > > > + * semantics.
> > > > > > > > > > + *
> > > > > > > > > > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > > > > > > > > > + * bandwidth required for full-scale RGB is not available, or the mode
> > > > > > > > > > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > > > > > > > > > + * YCbCr 4:2:0.
> > > > > > > > > > + *
> > > > > > > > > > + * For display protocols other than HDMI, the recursive bridge chain
> > > > > > > > > > + * format selection picks the first chain of bridge formats that works,
> > > > > > > > > > + * as has already been the case before the introduction of the "color
> > > > > > > > > > + * format" property. Non-HDMI bridges should therefore either sort their
> > > > > > > > > > + * bus output formats by preference, or agree on a unified auto format
> > > > > > > > > > + * selection logic that's implemented in a common state helper (like
> > > > > > > > > > + * how HDMI does it).
> > > > > > > > > > + */
> > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
> > > > > > > > > > +
> > > > > > > > > > + /**
> > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format
> > > > > > > > > > + */
> > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > > > > > +
> > > > > > > > > > + /**
> > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > > > > > + * not subsampled)
> > > > > > > > > > + */
> > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > > > > > +
> > > > > > > > > > + /**
> > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > > > > > + * with horizontal subsampling)
> > > > > > > > > > + */
> > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > > > > > +
> > > > > > > > > > + /**
> > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > > > > > + * with horizontal and vertical subsampling)
> > > > > > > > > > + */
> > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > > > > > >
> > > > > > > > > Seems like this should document what the quantization range
> > > > > > > > > should be for each format.
> > > > > > > > >
> > > > > > > >
> > > > > > > > I don't think so? If you want per-component bit depth values,
> > > > > > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > > > > > enum is more abstract than that, and is there to communicate
> > > > > > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > > > > > by other properties.
> > > > > > > >
> > > > > > > > If you mean the factor used for subsampling, then that'd only be
> > > > > > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > > > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > > > > > be added; no digital display protocol standard supports it to my
> > > > > > > > knowledge, and hopefully none ever will.
> > > > > > >
> > > > > > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > > > > > >
> > > > > > > The i915 behaviour is that YCbCr is always limited range,
> > > > > > > RGB can either be full or limited range depending on the
> > > > > > > "Broadcast RGB" property and other related factors.
> > > > > >
> > > > > > So far the HDMI state has both the format and quantization range as
> > > > > > different fields. I'm not sure we need to document the range in the
> > > > > > format field, maybe only mention it's not part of the format but has a
> > > > > > field of its own?
> > > > >
> > > > > I think we only have it for RGB (on some drivers only?). For YCbCr
> > > > > I think the assumption is limited range everywhere.
> > > > >
> > > > > But I'm not really concerned about documenting struct members.
> > > > > What I'm talking about is the *uapi* docs. Surely userspace
> > > > > will want to know what the new property actually does so the
> > > > > uapi needs to be documented properly. And down the line some
> > > > > new driver might also implement the wrong behaviour if there
> > > > > is no clear specification.
> > > >
> > > > Ack
> > > >
> > > > > So I'm thinking (or perhaps hoping) the rule might be something like:
> > > > > - YCbCr limited range
> > > > > - RGB full range if "Broadcast RGB" property is not present
> > > >
> > > > Isn't it much more complicated than that for HDMI though? My
> > > > recollection was that any VIC but VIC1 would be limited range, and
> > > > anything else full range?
> > >
> > > Do we have some driver that implements the CTA-861 CE vs. IT mode
> > > logic but doesn't expose the "Broadcast RGB" property? I was hoping
> > > those would always go hand in hand now.
> >
> > I'm not sure. i915 and the HDMI state helpers handle it properly (I
> > think?) but it looks like only vc4 registers the Broadcast RGB property
> > and uses the HDMI state helpers.
> >
> > And it looks like amdgpu registers Broadcast RGB but doesn't use
> > drm_default_rgb_quant_range() which seems suspicious?
>
> If they want just manual full vs. limited then they should
> limit the property to not expose the "auto" option at all.
>
> amdgpu also ties this in with the "colorspace" property, which
> originally in i915 only controlled the infoframes/etc. But on
> amdgpu it now controls various aspects of output color
> transformation. The end result is that the property is a complete
> mess with most of the values making no sense. And for whatever
> reason everyone involved refused to remove/deprecate the
> nonsensical values :/
>
> Looks like this series should make sure the documentation for
> the "colorspace" property is in sync with the new property
> as well. Currently now it's giving conflicting information.
>
I take it the problematic information is in
* DOC: standard connector properties
*
* Colorspace:
and probably specifically BT2020_YCC's (and BT2020_RGB's?) insistence
that they "produce RGB content".
I think we probably just have to change the statement "The variants
BT2020_RGB and BT2020_YCC are equivalent and the driver chooses between
RGB and YCbCr on its own."
The "on its own" here would get turned into "based on the color format
property".
Speaking of i915, that patch is one of the very few (5) patches in
this series still lacking a review (hint hint nudge nudge). I'd like
to get some more feedback on the remaining patches before I send out
another revision, so that it's hopefully not just docs changes (I
know better than to think those patches must be perfect and won't
need revision.)
If `drm/bridge: Act on the DRM color format property` and
`drm/atomic-helper: Add HDMI bridge output bus formats helper` get a
reviewed-by/acked-by and it's still crickets on the amdgpu and i915
front, then I will just drop the amdgpu/i915 implementations so that
they don't block this from landing.
Kind regards,
Nicolas Frattaroli
^ permalink raw reply
* Re: [PATCH v1] arm64: mm: __ptep_set_access_flags must hint correct TTL
From: Catalin Marinas @ 2026-03-27 12:54 UTC (permalink / raw)
To: Will Deacon, Anshuman Khandual, Linu Cherian, Ryan Roberts
Cc: linux-arm-kernel, linux-kernel, Aishwarya TCV
In-Reply-To: <20260323163918.2028109-1-ryan.roberts@arm.com>
On Mon, 23 Mar 2026 16:39:16 +0000, Ryan Roberts wrote:
> It has been reported that since commit 752a0d1d483e9 ("arm64: mm:
> Provide level hint for flush_tlb_page()"), the arm64
> check_hugetlb_options selftest has been locking up while running "Check
> child hugetlb memory with private mapping, sync error mode and mmap
> memory".
>
> This is due to hugetlb (and THP) helpers casting their PMD/PUD entries
> to PTE and calling __ptep_set_access_flags(), which issues a
> __flush_tlb_page(). Now that this is hinted for level 3, in this case,
> the TLB entry does not get evicted and we end up in a spurious fault
> loop.
>
> [...]
Applied to arm64 (for-next/tlbflush), thanks!
[1/1] arm64: mm: __ptep_set_access_flags must hint correct TTL
https://git.kernel.org/arm64/c/b7d9d2e3a8ab
^ permalink raw reply
* Re: [PATCH v5 0/4] arm64: dts: rockchip: Fix vdec register blocks order on RK3576/RK3588
From: Cristian Ciocaltea @ 2026-03-27 12:51 UTC (permalink / raw)
To: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Detlev Casanova, Ezequiel Garcia, Mauro Carvalho Chehab,
Nicolas Dufresne, Hans Verkuil
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Conor Dooley, linux-media, Conor Dooley,
Krzysztof Kozlowski
In-Reply-To: <4358847.1IzOArtZ34@phil>
On 3/10/26 10:44 AM, Heiko Stuebner wrote:
> Am Mittwoch, 4. März 2026, 22:00:39 Mitteleuropäische Normalzeit schrieb Cristian Ciocaltea:
>> When building device trees for the RK3576 based boards, DTC shows the
>> following complaint:
>>
>> rk3576.dtsi:1282.30-1304.5: Warning (simple_bus_reg): /soc/video-codec@27b00000: simple-bus unit address format error, expected "27b00100"
>
> [...]
>
>> Cristian Ciocaltea (4):
>> media: dt-bindings: rockchip,vdec: Mark reg-names required for RK35{76,88}
>> media: dt-bindings: rockchip,vdec: Add alternative reg-names order for RK35{76,88}
>
> due to media "applied" messages most of the time not reaching all Cc'ed
> recipients, please tell me once the binding patches landed somewhere.
Yeah, sadly I also haven't received any notification so far, but just noticed
the binding patches are now in next-20260326, as a result of merging branch
'next' of https://git.linuxtv.org/media-ci/media-pending.git:
a11db8d8b403 ("media: dt-bindings: rockchip,vdec: Mark reg-names required for RK35{76,88}")
35c8178ed2bd ("media: dt-bindings: rockchip,vdec: Add alternative reg-names order for RK35{76,88}")
Thanks,
Cristian
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: arm: marvell: Convert armada-380-mpcore-soc-ctrl to DT Schema
From: Andrew Lunn @ 2026-03-27 12:24 UTC (permalink / raw)
To: Padmashree S S
Cc: gregory.clement, sebastian.hesselbarth, robh, krzk+dt, conor+dt,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260327114653.593582-1-padmashreess2006@gmail.com>
> +maintainers:
> + - Andrew Lunn <andrew@lunn.ch>
> + - Gregory Clement <gregory.clement@bootlin.com>
> + - Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Please drop Sebastian. He has not been active for many years.
Andrew
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: arm: marvell: Convert armada-380-mpcore-soc-ctrl to DT Schema
From: Andrew Lunn @ 2026-03-27 12:23 UTC (permalink / raw)
To: Padmashree S S
Cc: gregory.clement, sebastian.hesselbarth, robh, krzk+dt, conor+dt,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260327114653.593582-1-padmashreess2006@gmail.com>
On Fri, Mar 27, 2026 at 05:16:53PM +0530, Padmashree S S wrote:
> Convert armada-380-mpcore-soc-ctrl to DT schema
You have already been asked once to slow down. Please don't ignore
Reviewers/Maintainer comments.
Please don't post new versions of a patch within 24 hours. And 24
hours can be too fast, particularly at the weekend.
> Signed-off-by: Padmashree S S <padmashreess2006@gmail.com>
> ---
Here, under the --- you should indicate what changed since the last
version of the patch.
Andrew
^ permalink raw reply
* Re: [PATCH] net: ti: icssg-prueth: fix missing data copy and wrong recycle in ZC RX dispatch
From: patchwork-bot+netdevbpf @ 2026-03-27 12:10 UTC (permalink / raw)
To: David CARLIER
Cc: danishanwar, rogerq, andrew+netdev, davem, edumazet, kuba, pabeni,
m-malladi, jacob.e.keller, horms, linux-arm-kernel, netdev,
linux-kernel
In-Reply-To: <20260325125131.53399-1-devnexen@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by David S. Miller <davem@davemloft.net>:
On Wed, 25 Mar 2026 12:51:30 +0000 you wrote:
> emac_dispatch_skb_zc() allocates a new skb via napi_alloc_skb() but
> never copies the packet data from the XDP buffer into it. The skb is
> passed up the stack containing uninitialized heap memory instead of
> the actual received packet, leaking kernel heap contents to userspace.
>
> Copy the received packet data from the XDP buffer into the skb using
> skb_copy_to_linear_data().
>
> [...]
Here is the summary with links:
- net: ti: icssg-prueth: fix missing data copy and wrong recycle in ZC RX dispatch
https://git.kernel.org/netdev/net/c/5597dd284ff8
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [GIT PULL] arm64: dts: juno/fvp: Updates for v7.1
From: Krzysztof Kozlowski @ 2026-03-27 12:00 UTC (permalink / raw)
To: Sudeep Holla
Cc: ARM SoC Team, SoC Team, ALKML, Arnd Bergmann, Lorenzo Pieralisi,
Liviu Dudau
In-Reply-To: <20260325160027.4115793-1-sudeep.holla@kernel.org>
On Wed, Mar 25, 2026 at 04:00:21PM +0000, Sudeep Holla wrote:
> Hi ARM SoC Team,
>
> Please pull !
>
> Regards,
> Sudeep
>
> -->8
>
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/juno-updates-7.1
>
> for you to fetch changes up to 87599f1843d3baa4083dc9dd01c95826b536de24:
>
> arm64: dts: arm/corstone1000: Add corstone-1000-a320 (2026-03-23 10:03:28 +0000)
>
> ----------------------------------------------------------------
> Armv8 Juno/FVP/Vexpress updates for v7.1
>
> 1. The primary addition is initial support for Zena CSS that includes:
> a new binding compatibility, a shared `zena-css.dtsi` description, and
> an FVP device tree.
>
> 2. Extension of Corstone-1000 FVP platform support with binding updates
> to add the new `arm,corstone1000-a320-fvp` platform, and the
> `arm,corstone1000-ethos-u85` NPU integration.
>
> Overall, this combines new platform enablement with some DTS layout
> cleanup for Arm reference FVP based systems.
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL v2] Rockchip dts fixes for 7.0 #1
From: Krzysztof Kozlowski @ 2026-03-27 11:57 UTC (permalink / raw)
To: Heiko Stuebner; +Cc: arm, soc, linux-rockchip, linux-arm-kernel
In-Reply-To: <5057236.GXAFRqVoOG@phil>
On Mon, Mar 23, 2026 at 10:58:16PM +0100, Heiko Stuebner wrote:
> Hi SoC maintainers,
>
> As requested by Krzysztof, here is a more condensed PR.
>
> Changes in v2 are that I dropped fixes for dt-schema errors and fixes
> for commits introduced not closesly to the current release. These have
> been moved to the current branches.
>
> The Pinebook regression fix actually also is for a commit from august
> last year, but fixes an actively tracked regression, so maybe carries
> a bit more weight.
>
>
> Please pull
>
> Thanks
> Heiko
>
>
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v7.0-rockchip-dtsfixes1-v2
>
> for you to fetch changes up to 29d1f56c4f3001b7f547123e0a307c009ac717f8:
>
> Revert "arm64: dts: rockchip: Further describe the WiFi for the Pinebook Pro" (2026-02-22 23:28:06 +0100)
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL 1/2] Broadcom devicetree changes for 7.1
From: Krzysztof Kozlowski @ 2026-03-27 11:53 UTC (permalink / raw)
To: Florian Fainelli
Cc: soc, Rosen Penev, Rob Herring, Linus Walleij, Linus Walleij,
William Zhang, Miquel Raynal, Rafał Miłecki,
linux-arm-kernel, arnd, khilman, bcm-kernel-feedback-list
In-Reply-To: <20260323190239.1890505-1-florian.fainelli@broadcom.com>
On Mon, Mar 23, 2026 at 12:02:38PM -0700, Florian Fainelli wrote:
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://github.com/Broadcom/stblinux.git tags/arm-soc/for-7.1/devicetree
>
> for you to fetch changes up to 220bdfcb4b4788f57faa2c28454d8b2dd3bcab6c:
>
> ARM: dts: BCM5301X: EA9200: specify partitions (2026-03-20 16:57:31 -0700)
Four days after:
Days in linux-next:
----------------------------------------
0 | ++++++++++++++++ (16)
...
Commits with 0 days in linux-next (16 of 19: 84.2%)...
Are you sure your tree is included in the next?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL] i.MX fixes for 7.0 (v2)
From: Krzysztof Kozlowski @ 2026-03-27 11:51 UTC (permalink / raw)
To: Frank Li; +Cc: soc, arm, Fabio Estevam, kernel, imx, linux-arm-kernel
In-Reply-To: <20260323162849.1203617-1-Frank.Li@nxp.com>
On Mon, Mar 23, 2026 at 12:28:46PM -0400, Frank Li wrote:
> From: Frank Li <Frank.li@nxp.com>
>
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux.git tags/imx-fixes-7.0
>
> for you to fetch changes up to 511f76bf1dce5acf8907b65a7d1bc8f7e7c0d637:
>
> arm64: dts: imx8mq-librem5: Bump BUCK1 suspend voltage up to 0.85V (2026-03-17 23:24:44 -0400)
>
> ----------------------------------------------------------------
> i.MX fixes for 7.0:
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT,PULL,1/2] MediaTek ARM64 Device Tree updates for v7.1
From: Krzysztof Kozlowski @ 2026-03-27 11:48 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: arm-soc, soc, linux-arm-kernel, linux-mediatek, matthias.bgg
In-Reply-To: <20260320085641.15843-1-angelogioacchino.delregno@collabora.com>
On Fri, Mar 20, 2026 at 09:56:38AM +0100, AngeloGioacchino Del Regno wrote:
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux.git tags/mtk-dts64-for-v7.1
>
> for you to fetch changes up to 820ed0c1a13c5fafb36232538d793f99a0986ef3:
>
> arm64: dts: mediatek: mt7986a: Fix gpio-ranges pin count (2026-03-12 13:32:17 +0100)
>
> ----------------------------------------------------------------
> MediaTek ARM64 DeviceTree updates
Thanks, applied both.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2] dt-bindings: arm: marvell: Convert armada-380-mpcore-soc-ctrl to DT Schema
From: Padmashree S S @ 2026-03-27 11:46 UTC (permalink / raw)
To: andrew, gregory.clement, sebastian.hesselbarth
Cc: robh, krzk+dt, conor+dt, linux-arm-kernel, devicetree,
linux-kernel, Padmashree S S
Convert armada-380-mpcore-soc-ctrl to DT schema
Signed-off-by: Padmashree S S <padmashreess2006@gmail.com>
---
.../marvell/armada-380-mpcore-soc-ctrl.txt | 14 --------
.../marvell/armada-380-mpcore-soc-ctrl.yaml | 32 +++++++++++++++++++
2 files changed, 32 insertions(+), 14 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.txt
create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.yaml
diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.txt b/Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.txt
deleted file mode 100644
index 8781073029e9..000000000000
--- a/Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-Marvell Armada 38x CA9 MPcore SoC Controller
-============================================
-
-Required properties:
-
-- compatible: Should be "marvell,armada-380-mpcore-soc-ctrl".
-
-- reg: should be the register base and length as documented in the
- datasheet for the CA9 MPcore SoC Control registers
-
-mpcore-soc-ctrl@20d20 {
- compatible = "marvell,armada-380-mpcore-soc-ctrl";
- reg = <0x20d20 0x6c>;
-};
diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.yaml
new file mode 100644
index 000000000000..a897d4ba4e32
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.yaml
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/marvell/armada-380-mpcore-soc-ctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada 38x CA9 MPcore SoC Controller
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Gregory Clement <gregory.clement@bootlin.com>
+ - Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
+
+properties:
+ compatible:
+ const: marvell,armada-380-mpcore-soc-ctrl
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ mpcore-soc-ctrl@20d20 {
+ compatible = "marvell,armada-380-mpcore-soc-ctrl";
+ reg = <0x20d20 0x6c>;
+ };
--
2.43.0
^ permalink raw reply related
* [PATCH v3 1/1] arm64: defconfig: Enable CIX Sky1 pinctrl, PCIe host, and Cadence GPIO
From: Peter Chen @ 2026-03-27 11:46 UTC (permalink / raw)
To: arnd
Cc: krzysztof.kozlowski, geert+renesas, linux-kernel,
linux-arm-kernel, cix-kernel-upstream, Peter Chen, Yunseong Kim
Enable the CIX Sky1 pinctrl driver (PINCTRL_SKY1), CIX Sky1 PCIe host
controller (PCI_SKY1_HOST), and Cadence GPIO controller (GPIO_CADENCE)
for the Radxa Orion O6 board which uses the CIX Sky1 SoC.
The pinctrl driver is a dependency for other on-SoC peripherals. The
Cadence-based PCIe host controller enables use of PCIe peripherals on
the board. The Cadence GPIO controller provides GPIO support for the
SoC.
Cc: Yunseong Kim <ysk@kzalloc.com>
Signed-off-by: Peter Chen <peter.chen@cixtech.com>
---
Changes for v3:
- Use specific driver names (CIX Sky1 pinctrl, CIX Sky1 PCIe host
controller, Cadence GPIO) in subject and commit message instead of
generic terms.
- Remove external Debian bug reference; explain rationale directly.
- Remove NVMe mention since only PCIe host controller is enabled.
Changes for v2:
- Delete CIX HDA configurations due to it is not used at current
Orion O6 board device tree.
arch/arm64/configs/defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index b67d5b1fc45b..f9be52484008 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -241,6 +241,7 @@ CONFIG_PCIE_XILINX_DMA_PL=y
CONFIG_PCIE_XILINX_NWL=y
CONFIG_PCIE_XILINX_CPM=y
CONFIG_PCI_J721E_HOST=m
+CONFIG_PCI_SKY1_HOST=m
CONFIG_PCI_IMX6_HOST=y
CONFIG_PCI_LAYERSCAPE=y
CONFIG_PCI_HISI=y
@@ -676,6 +677,7 @@ CONFIG_PINCTRL_SDM660=y
CONFIG_PINCTRL_SDM670=y
CONFIG_PINCTRL_SDM845=y
CONFIG_PINCTRL_SDX75=y
+CONFIG_PINCTRL_SKY1=y
CONFIG_PINCTRL_SM4450=y
CONFIG_PINCTRL_SM6115=y
CONFIG_PINCTRL_SM6125=y
@@ -701,6 +703,7 @@ CONFIG_PINCTRL_SM8550_LPASS_LPI=m
CONFIG_PINCTRL_SM8650_LPASS_LPI=m
CONFIG_PINCTRL_SOPHGO_SG2000=y
CONFIG_GPIO_ALTERA=m
+CONFIG_GPIO_CADENCE=m
CONFIG_GPIO_DAVINCI=y
CONFIG_GPIO_DWAPB=y
CONFIG_GPIO_MB86S7X=y
--
2.50.1
^ permalink raw reply related
* Re: [PATCH v2 1/3] pinctrl: sunxi: a523: Remove unneeded IRQ remuxing flag
From: Jernej Škrabec @ 2026-03-27 11:39 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Andre Przywara
Cc: linux-gpio, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
In-Reply-To: <20260327113006.3135663-2-andre.przywara@arm.com>
Dne petek, 27. marec 2026 ob 12:30:04 Srednjeevropski standardni čas je Andre Przywara napisal(a):
> The Allwinner A10 and H3 SoCs cannot read the state of a GPIO line when
> that line is muxed for IRQ triggering (muxval 6), but only if it's
> explicitly muxed for GPIO input (muxval 0). Other SoCs do not show this
> behaviour, so we added a optional workaround, triggered by a quirk bit,
> which triggers remuxing the pin when it's configured for IRQ, while we
> need to read its value.
>
> For some reasons this quirk flag was copied over to newer SoCs, even
> though they don't show this behaviour, and the GPIO data register
> reflects the true GPIO state even with a pin muxed to IRQ trigger.
>
> Remove the unneeded quirk from the A523 family, where it's definitely
> not needed (confirmed by experiments), and where it actually breaks,
> because the workaround is not compatible with the newer generation
> pinctrl IP used in that chip.
>
> Together with a DT change this fixes GPIO IRQ operation on the A523
> family of SoCs, as for instance used for the SD card detection.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Fixes: b8a51e95b376 ("pinctrl: sunxi: Add support for the secondary A523 GPIO ports")
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: allwinner: a523: Add missing GPIO interrupt
From: Jernej Škrabec @ 2026-03-27 11:42 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Andre Przywara
Cc: linux-gpio, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
In-Reply-To: <20260327113006.3135663-4-andre.przywara@arm.com>
Dne petek, 27. marec 2026 ob 12:30:06 Srednjeevropski standardni čas je Andre Przywara napisal(a):
> Even though the Allwinner A523 SoC implements 10 GPIO banks, it has
> actually registers for 11 IRQ banks, and even an interrupt assigned to
> the first, non-implemented IRQ bank.
> Add that first interrupt to the list of GPIO interrupts, to correct the
> association between IRQs and GPIO banks.
>
> This fixes GPIO IRQ operation on boards with A523 SoCs, as seen by
> broken SD card detect functionality, for instance.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Fixes: 35ac96f79664 ("arm64: dts: allwinner: Add Allwinner A523 .dtsi file")
> Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: pinctrl: sun55i-a523: increase IRQ banks number
From: Jernej Škrabec @ 2026-03-27 11:41 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Andre Przywara
Cc: linux-gpio, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
In-Reply-To: <20260327113006.3135663-3-andre.przywara@arm.com>
Dne petek, 27. marec 2026 ob 12:30:05 Srednjeevropski standardni čas je Andre Przywara napisal(a):
> The Allwinner A523 SoC implements 10 GPIO banks in the first pinctrl
> instance, but it skips the first bank (PortA), so their index goes from
> 1 to 10. The same is actually true for the IRQ banks: there are registers
> for 11 banks, though the first bank is not implemented (RAZ/WI).
> In contrast to previous SoCs, the count of the IRQ banks starts with this
> first unimplemented bank, so we need to provide an interrupt for it.
> And indeed the A523 user manual lists an interrupt number for PortA, so we
> need to increase the maximum number of interrupts per pin controller to 11,
> to be able to assign the correct interrupt number for each bank.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH v5 00/15] hwspinlock: move device alloc into core and refactor includes
From: Wolfram Sang @ 2026-03-27 11:43 UTC (permalink / raw)
To: linux-renesas-soc
Cc: linux-kernel, Alexandre Torgue, Andy Shevchenko, Antonio Borneo,
Arnd Bergmann, Baolin Wang, Bjorn Andersson, Boqun Feng,
Chen-Yu Tsai, Chunyan Zhang, Danilo Krummrich, David Lechner,
driver-core, Greg Kroah-Hartman, Ingo Molnar, Jernej Skrabec,
Jonathan Cameron, Jonathan Corbet, Konrad Dybcio, Lee Jones,
Linus Walleij, linux-arm-kernel, linux-arm-msm, linux-doc,
linux-gpio, linux-iio, linux-omap, linux-remoteproc, linux-spi,
linux-stm32, linux-sunxi, Mark Brown, Maxime Coquelin,
Nuno Sá, Orson Zhai, Peter Zijlstra, Rafael J. Wysocki,
Samuel Holland, Shuah Khan, Srinivas Kandagatla, Thomas Gleixner,
Waiman Long, Wilken Gottwalt, Will Deacon
In-Reply-To: <20260319105947.6237-1-wsa+renesas@sang-engineering.com>
On Thu, Mar 19, 2026 at 11:59:22AM +0100, Wolfram Sang wrote:
> Changes since v4:
>
> * update Documentation, too, when ABI gets changed (Thanks Antonio!)
> * rebased to 7.0-rc4
> * added more tags (Thanks!)
>
> My ultimate goal is to allow hwspinlock provider drivers outside of the
> subsystem directory. It turned out that a simple split of the headers
> files into a public provider and a public consumer header file is not
> enough because core internal structures need to stay hidden. Even more,
> their opaqueness could and should even be increased. That would also
> allow the core to handle the de-/allocation of the hwspinlock device
> itself.
>
> This series does all that. Patches 1-2 remove the meanwhile unused
> platform_data to ease further refactoring. Patches 3-9 abstract access
> to internal structures away using helpers. Patch 10 then moves
> hwspinlock device handling to the core, simplifying drivers. The
> remaining patches refactor the headers until the internal one is gone
> and the public ones are divided into provider and consumer parts. More
> details are given in the patch descriptions.
>
> One note about using a callback to initialize hwspinlock priv: I also
> experimented with a dedicated 'set_priv' helper function. It felt a bit
> clumsy to me. Drivers would need to save the 'bank' pointer again and
> iterate over it. Because most drivers will only have a simple callback
> anyhow, it looked leaner to me.
>
> This series has been tested on a Renesas SparrowHawk board (R-Car V4H)
> with a yet-to-be-upstreamed hwspinlock driver for the MFIS IP core. A
> branch can be found here (without the MFIS driver currently):
>
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/hwspinlock/refactor-alloc-buildtest
>
> Build bots reported success.
Sashiko found some valid issues[1], so I am already working on a v6.
[1] https://sashiko.dev/#/patchset/20260319105947.6237-1-wsa%2Brenesas%40sang-engineering.com
^ permalink raw reply
* Re: [RFC PATCH] dmaengine: xilinx_dma: Fix per-channel direction reporting via device_caps
From: Michal Simek @ 2026-03-27 11:43 UTC (permalink / raw)
To: Rahul Navale, dmaengine, Gupta, Suraj
Cc: Rahul Navale, dev, linux-arm-kernel, linux-kernel, vkoul,
Frank.Li, suraj.gupta2, thomas.gessler, radhey.shyam.pandey,
tomi.valkeinen, marex, marex
In-Reply-To: <20260325142300.3680-1-rahulnavale04@gmail.com>
+Suraj,
On 3/25/26 15:22, Rahul Navale wrote:
> From: Rahul Navale <rahul.navale@ifm.com>
>
> @Xilinx/AMD maintainers:
>
> Quick status: the ASoC playback regression is still present.
> when 7e01511443c3 ("dmaengine: xilinx_dma: Set dma_device directions")
> is present. Reverting 7e01511443c3 restores normal playback.
>
> Could you please advice the next steps / preferred fix direction to address
> this regression upstream?
Suraj will take a look at it soon.
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH v2 1/3] pinctrl: sunxi: a523: Remove unneeded IRQ remuxing flag
From: Chen-Yu Tsai @ 2026-03-27 11:38 UTC (permalink / raw)
To: Andre Przywara
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jernej Skrabec,
Samuel Holland, linux-gpio, devicetree, linux-arm-kernel,
linux-sunxi, linux-kernel
In-Reply-To: <20260327113006.3135663-2-andre.przywara@arm.com>
On Fri, Mar 27, 2026 at 7:30 PM Andre Przywara <andre.przywara@arm.com> wrote:
>
> The Allwinner A10 and H3 SoCs cannot read the state of a GPIO line when
> that line is muxed for IRQ triggering (muxval 6), but only if it's
> explicitly muxed for GPIO input (muxval 0). Other SoCs do not show this
> behaviour, so we added a optional workaround, triggered by a quirk bit,
> which triggers remuxing the pin when it's configured for IRQ, while we
> need to read its value.
>
> For some reasons this quirk flag was copied over to newer SoCs, even
> though they don't show this behaviour, and the GPIO data register
> reflects the true GPIO state even with a pin muxed to IRQ trigger.
>
> Remove the unneeded quirk from the A523 family, where it's definitely
> not needed (confirmed by experiments), and where it actually breaks,
> because the workaround is not compatible with the newer generation
> pinctrl IP used in that chip.
>
> Together with a DT change this fixes GPIO IRQ operation on the A523
> family of SoCs, as for instance used for the SD card detection.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Fixes: b8a51e95b376 ("pinctrl: sunxi: Add support for the secondary A523 GPIO ports")
Acked-by: Chen-Yu Tsai <wens@kernel.org>
> ---
> drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c | 1 -
> drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c
> index 69cd2b4ebd7d..462aa1c4a5fa 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c
> @@ -26,7 +26,6 @@ static const u8 a523_r_irq_bank_muxes[SUNXI_PINCTRL_MAX_BANKS] =
> static struct sunxi_pinctrl_desc a523_r_pinctrl_data = {
> .irq_banks = ARRAY_SIZE(a523_r_irq_bank_map),
> .irq_bank_map = a523_r_irq_bank_map,
> - .irq_read_needs_mux = true,
> .io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_SEL,
> .pin_base = PL_BASE,
> };
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c
> index 7d2308c37d29..b6f78f1f30ac 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c
> @@ -26,7 +26,6 @@ static const u8 a523_irq_bank_muxes[SUNXI_PINCTRL_MAX_BANKS] =
> static struct sunxi_pinctrl_desc a523_pinctrl_data = {
> .irq_banks = ARRAY_SIZE(a523_irq_bank_map),
> .irq_bank_map = a523_irq_bank_map,
> - .irq_read_needs_mux = true,
> .io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_SEL,
> };
>
> --
> 2.43.0
>
^ permalink raw reply
* [PATCH v2 30/30] KVM: arm64: Convert gmem_abort() to struct kvm_s2_fault_desc
From: Marc Zyngier @ 2026-03-27 11:36 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel, kvm
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Fuad Tabba, Will Deacon, Quentin Perret
In-Reply-To: <20260327113618.4051534-1-maz@kernel.org>
Having fully converted user_mem_abort() to kvm_s2_fault_desc and
co, convert gmem_abort() to it as well. The change is obviously
much simpler.
Tested-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/mmu.c | 41 +++++++++++++++++++----------------------
1 file changed, 19 insertions(+), 22 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index f4c8f72642e02..1fe7182be45ac 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1575,33 +1575,31 @@ struct kvm_s2_fault_desc {
unsigned long hva;
};
-static int gmem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
- struct kvm_s2_trans *nested,
- struct kvm_memory_slot *memslot, bool is_perm)
+static int gmem_abort(const struct kvm_s2_fault_desc *s2fd)
{
bool write_fault, exec_fault;
enum kvm_pgtable_walk_flags flags = KVM_PGTABLE_WALK_SHARED;
enum kvm_pgtable_prot prot = KVM_PGTABLE_PROT_R;
- struct kvm_pgtable *pgt = vcpu->arch.hw_mmu->pgt;
+ struct kvm_pgtable *pgt = s2fd->vcpu->arch.hw_mmu->pgt;
unsigned long mmu_seq;
struct page *page;
- struct kvm *kvm = vcpu->kvm;
+ struct kvm *kvm = s2fd->vcpu->kvm;
void *memcache;
kvm_pfn_t pfn;
gfn_t gfn;
int ret;
- ret = prepare_mmu_memcache(vcpu, true, &memcache);
+ ret = prepare_mmu_memcache(s2fd->vcpu, true, &memcache);
if (ret)
return ret;
- if (nested)
- gfn = kvm_s2_trans_output(nested) >> PAGE_SHIFT;
+ if (s2fd->nested)
+ gfn = kvm_s2_trans_output(s2fd->nested) >> PAGE_SHIFT;
else
- gfn = fault_ipa >> PAGE_SHIFT;
+ gfn = s2fd->fault_ipa >> PAGE_SHIFT;
- write_fault = kvm_is_write_fault(vcpu);
- exec_fault = kvm_vcpu_trap_is_exec_fault(vcpu);
+ write_fault = kvm_is_write_fault(s2fd->vcpu);
+ exec_fault = kvm_vcpu_trap_is_exec_fault(s2fd->vcpu);
VM_WARN_ON_ONCE(write_fault && exec_fault);
@@ -1609,24 +1607,24 @@ static int gmem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
/* Pairs with the smp_wmb() in kvm_mmu_invalidate_end(). */
smp_rmb();
- ret = kvm_gmem_get_pfn(kvm, memslot, gfn, &pfn, &page, NULL);
+ ret = kvm_gmem_get_pfn(kvm, s2fd->memslot, gfn, &pfn, &page, NULL);
if (ret) {
- kvm_prepare_memory_fault_exit(vcpu, fault_ipa, PAGE_SIZE,
+ kvm_prepare_memory_fault_exit(s2fd->vcpu, s2fd->fault_ipa, PAGE_SIZE,
write_fault, exec_fault, false);
return ret;
}
- if (!(memslot->flags & KVM_MEM_READONLY))
+ if (!(s2fd->memslot->flags & KVM_MEM_READONLY))
prot |= KVM_PGTABLE_PROT_W;
- if (nested)
- prot = adjust_nested_fault_perms(nested, prot);
+ if (s2fd->nested)
+ prot = adjust_nested_fault_perms(s2fd->nested, prot);
if (exec_fault || cpus_have_final_cap(ARM64_HAS_CACHE_DIC))
prot |= KVM_PGTABLE_PROT_X;
- if (nested)
- prot = adjust_nested_exec_perms(kvm, nested, prot);
+ if (s2fd->nested)
+ prot = adjust_nested_exec_perms(kvm, s2fd->nested, prot);
kvm_fault_lock(kvm);
if (mmu_invalidate_retry(kvm, mmu_seq)) {
@@ -1634,7 +1632,7 @@ static int gmem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
goto out_unlock;
}
- ret = KVM_PGT_FN(kvm_pgtable_stage2_map)(pgt, fault_ipa, PAGE_SIZE,
+ ret = KVM_PGT_FN(kvm_pgtable_stage2_map)(pgt, s2fd->fault_ipa, PAGE_SIZE,
__pfn_to_phys(pfn), prot,
memcache, flags);
@@ -1643,7 +1641,7 @@ static int gmem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
kvm_fault_unlock(kvm);
if ((prot & KVM_PGTABLE_PROT_W) && !ret)
- mark_page_dirty_in_slot(kvm, memslot, gfn);
+ mark_page_dirty_in_slot(kvm, s2fd->memslot, gfn);
return ret != -EAGAIN ? ret : 0;
}
@@ -2300,8 +2298,7 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu)
};
if (kvm_slot_has_gmem(memslot))
- ret = gmem_abort(vcpu, fault_ipa, nested, memslot,
- esr_fsc_is_permission_fault(esr));
+ ret = gmem_abort(&s2fd);
else
ret = user_mem_abort(&s2fd);
--
2.47.3
^ permalink raw reply related
* [PATCH v2 28/30] KVM: arm64: Directly expose mapping prot and kill kvm_s2_fault
From: Marc Zyngier @ 2026-03-27 11:36 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel, kvm
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Fuad Tabba, Will Deacon, Quentin Perret
In-Reply-To: <20260327113618.4051534-1-maz@kernel.org>
The 'prot' field is the only one left in kvm_s2_fault. Expose it
directly to the functions needing it, and get rid of kvm_s2_fault.
It has served us well during this refactoring, but it is now no
longer needed.
Tested-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/mmu.c | 45 +++++++++++++++++++++-----------------------
1 file changed, 21 insertions(+), 24 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 23245ee7b1ec2..0fbdac77b1140 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1729,10 +1729,6 @@ static short kvm_s2_resolve_vma_size(const struct kvm_s2_fault_desc *s2fd,
return vma_shift;
}
-struct kvm_s2_fault {
- enum kvm_pgtable_prot prot;
-};
-
static bool kvm_s2_fault_is_perm(const struct kvm_s2_fault_desc *s2fd)
{
return kvm_vcpu_trap_is_permission_fault(s2fd->vcpu);
@@ -1856,8 +1852,8 @@ static int kvm_s2_fault_pin_pfn(const struct kvm_s2_fault_desc *s2fd,
}
static int kvm_s2_fault_compute_prot(const struct kvm_s2_fault_desc *s2fd,
- struct kvm_s2_fault *fault,
- const struct kvm_s2_fault_vma_info *s2vi)
+ const struct kvm_s2_fault_vma_info *s2vi,
+ enum kvm_pgtable_prot *prot)
{
struct kvm *kvm = s2fd->vcpu->kvm;
bool writable = s2vi->map_writable;
@@ -1885,23 +1881,25 @@ static int kvm_s2_fault_compute_prot(const struct kvm_s2_fault_desc *s2fd,
return 1;
}
+ *prot = KVM_PGTABLE_PROT_R;
+
if (s2fd->nested)
- adjust_nested_fault_perms(s2fd->nested, &fault->prot, &writable);
+ adjust_nested_fault_perms(s2fd->nested, prot, &writable);
if (writable)
- fault->prot |= KVM_PGTABLE_PROT_W;
+ *prot |= KVM_PGTABLE_PROT_W;
if (kvm_vcpu_trap_is_exec_fault(s2fd->vcpu))
- fault->prot |= KVM_PGTABLE_PROT_X;
+ *prot |= KVM_PGTABLE_PROT_X;
if (s2vi->map_non_cacheable)
- fault->prot |= (s2vi->vm_flags & VM_ALLOW_ANY_UNCACHED) ?
- KVM_PGTABLE_PROT_NORMAL_NC : KVM_PGTABLE_PROT_DEVICE;
+ *prot |= (s2vi->vm_flags & VM_ALLOW_ANY_UNCACHED) ?
+ KVM_PGTABLE_PROT_NORMAL_NC : KVM_PGTABLE_PROT_DEVICE;
else if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC))
- fault->prot |= KVM_PGTABLE_PROT_X;
+ *prot |= KVM_PGTABLE_PROT_X;
if (s2fd->nested)
- adjust_nested_exec_perms(kvm, s2fd->nested, &fault->prot);
+ adjust_nested_exec_perms(kvm, s2fd->nested, prot);
if (!kvm_s2_fault_is_perm(s2fd) && !s2vi->map_non_cacheable && kvm_has_mte(kvm)) {
/* Check the VMM hasn't introduced a new disallowed VMA */
@@ -1913,11 +1911,12 @@ static int kvm_s2_fault_compute_prot(const struct kvm_s2_fault_desc *s2fd,
}
static int kvm_s2_fault_map(const struct kvm_s2_fault_desc *s2fd,
- struct kvm_s2_fault *fault,
- const struct kvm_s2_fault_vma_info *s2vi, void *memcache)
+ const struct kvm_s2_fault_vma_info *s2vi,
+ enum kvm_pgtable_prot prot,
+ void *memcache)
{
enum kvm_pgtable_walk_flags flags = KVM_PGTABLE_WALK_SHARED;
- bool writable = fault->prot & KVM_PGTABLE_PROT_W;
+ bool writable = prot & KVM_PGTABLE_PROT_W;
struct kvm *kvm = s2fd->vcpu->kvm;
struct kvm_pgtable *pgt;
long perm_fault_granule;
@@ -1970,12 +1969,12 @@ static int kvm_s2_fault_map(const struct kvm_s2_fault_desc *s2fd,
* Drop the SW bits in favour of those stored in the
* PTE, which will be preserved.
*/
- fault->prot &= ~KVM_NV_GUEST_MAP_SZ;
+ prot &= ~KVM_NV_GUEST_MAP_SZ;
ret = KVM_PGT_FN(kvm_pgtable_stage2_relax_perms)(pgt, gfn_to_gpa(gfn),
- fault->prot, flags);
+ prot, flags);
} else {
ret = KVM_PGT_FN(kvm_pgtable_stage2_map)(pgt, gfn_to_gpa(gfn), mapping_size,
- __pfn_to_phys(pfn), fault->prot,
+ __pfn_to_phys(pfn), prot,
memcache, flags);
}
@@ -2003,9 +2002,7 @@ static int user_mem_abort(const struct kvm_s2_fault_desc *s2fd)
{
bool perm_fault = kvm_vcpu_trap_is_permission_fault(s2fd->vcpu);
struct kvm_s2_fault_vma_info s2vi = {};
- struct kvm_s2_fault fault = {
- .prot = KVM_PGTABLE_PROT_R,
- };
+ enum kvm_pgtable_prot prot;
void *memcache = NULL;
int ret;
@@ -2030,13 +2027,13 @@ static int user_mem_abort(const struct kvm_s2_fault_desc *s2fd)
if (ret != 1)
return ret;
- ret = kvm_s2_fault_compute_prot(s2fd, &fault, &s2vi);
+ ret = kvm_s2_fault_compute_prot(s2fd, &s2vi, &prot);
if (ret) {
kvm_release_page_unused(s2vi.page);
return ret;
}
- return kvm_s2_fault_map(s2fd, &fault, &s2vi, memcache);
+ return kvm_s2_fault_map(s2fd, &s2vi, prot, memcache);
}
/* Resolve the access fault by making the page young again. */
--
2.47.3
^ permalink raw reply related
* [PATCH v2 29/30] KVM: arm64: Simplify integration of adjust_nested_*_perms()
From: Marc Zyngier @ 2026-03-27 11:36 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel, kvm
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Fuad Tabba, Will Deacon, Quentin Perret
In-Reply-To: <20260327113618.4051534-1-maz@kernel.org>
Instead of passing pointers to adjust_nested_*_perms(), allow
them to return a new set of permissions.
With some careful moving around so that the canonical permissions
are computed before the nested ones are applied, we end-up with
a bit less code, and something a bit more readable.
Tested-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/mmu.c | 62 +++++++++++++++++++-------------------------
1 file changed, 27 insertions(+), 35 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 0fbdac77b1140..f4c8f72642e02 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1544,25 +1544,27 @@ static int prepare_mmu_memcache(struct kvm_vcpu *vcpu, bool topup_memcache,
* TLB invalidation from the guest and used to limit the invalidation scope if a
* TTL hint or a range isn't provided.
*/
-static void adjust_nested_fault_perms(struct kvm_s2_trans *nested,
- enum kvm_pgtable_prot *prot,
- bool *writable)
+static enum kvm_pgtable_prot adjust_nested_fault_perms(struct kvm_s2_trans *nested,
+ enum kvm_pgtable_prot prot)
{
- *writable &= kvm_s2_trans_writable(nested);
+ if (!kvm_s2_trans_writable(nested))
+ prot &= ~KVM_PGTABLE_PROT_W;
if (!kvm_s2_trans_readable(nested))
- *prot &= ~KVM_PGTABLE_PROT_R;
+ prot &= ~KVM_PGTABLE_PROT_R;
- *prot |= kvm_encode_nested_level(nested);
+ return prot | kvm_encode_nested_level(nested);
}
-static void adjust_nested_exec_perms(struct kvm *kvm,
- struct kvm_s2_trans *nested,
- enum kvm_pgtable_prot *prot)
+static enum kvm_pgtable_prot adjust_nested_exec_perms(struct kvm *kvm,
+ struct kvm_s2_trans *nested,
+ enum kvm_pgtable_prot prot)
{
if (!kvm_s2_trans_exec_el0(kvm, nested))
- *prot &= ~KVM_PGTABLE_PROT_UX;
+ prot &= ~KVM_PGTABLE_PROT_UX;
if (!kvm_s2_trans_exec_el1(kvm, nested))
- *prot &= ~KVM_PGTABLE_PROT_PX;
+ prot &= ~KVM_PGTABLE_PROT_PX;
+
+ return prot;
}
struct kvm_s2_fault_desc {
@@ -1577,7 +1579,7 @@ static int gmem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
struct kvm_s2_trans *nested,
struct kvm_memory_slot *memslot, bool is_perm)
{
- bool write_fault, exec_fault, writable;
+ bool write_fault, exec_fault;
enum kvm_pgtable_walk_flags flags = KVM_PGTABLE_WALK_SHARED;
enum kvm_pgtable_prot prot = KVM_PGTABLE_PROT_R;
struct kvm_pgtable *pgt = vcpu->arch.hw_mmu->pgt;
@@ -1614,19 +1616,17 @@ static int gmem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
return ret;
}
- writable = !(memslot->flags & KVM_MEM_READONLY);
+ if (!(memslot->flags & KVM_MEM_READONLY))
+ prot |= KVM_PGTABLE_PROT_W;
if (nested)
- adjust_nested_fault_perms(nested, &prot, &writable);
-
- if (writable)
- prot |= KVM_PGTABLE_PROT_W;
+ prot = adjust_nested_fault_perms(nested, prot);
if (exec_fault || cpus_have_final_cap(ARM64_HAS_CACHE_DIC))
prot |= KVM_PGTABLE_PROT_X;
if (nested)
- adjust_nested_exec_perms(kvm, nested, &prot);
+ prot = adjust_nested_exec_perms(kvm, nested, prot);
kvm_fault_lock(kvm);
if (mmu_invalidate_retry(kvm, mmu_seq)) {
@@ -1639,10 +1639,10 @@ static int gmem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
memcache, flags);
out_unlock:
- kvm_release_faultin_page(kvm, page, !!ret, writable);
+ kvm_release_faultin_page(kvm, page, !!ret, prot & KVM_PGTABLE_PROT_W);
kvm_fault_unlock(kvm);
- if (writable && !ret)
+ if ((prot & KVM_PGTABLE_PROT_W) && !ret)
mark_page_dirty_in_slot(kvm, memslot, gfn);
return ret != -EAGAIN ? ret : 0;
@@ -1856,16 +1856,6 @@ static int kvm_s2_fault_compute_prot(const struct kvm_s2_fault_desc *s2fd,
enum kvm_pgtable_prot *prot)
{
struct kvm *kvm = s2fd->vcpu->kvm;
- bool writable = s2vi->map_writable;
-
- if (!s2vi->device && memslot_is_logging(s2fd->memslot) &&
- !kvm_is_write_fault(s2fd->vcpu)) {
- /*
- * Only actually map the page as writable if this was a write
- * fault.
- */
- writable = false;
- }
if (kvm_vcpu_trap_is_exec_fault(s2fd->vcpu) && s2vi->map_non_cacheable)
return -ENOEXEC;
@@ -1883,12 +1873,14 @@ static int kvm_s2_fault_compute_prot(const struct kvm_s2_fault_desc *s2fd,
*prot = KVM_PGTABLE_PROT_R;
- if (s2fd->nested)
- adjust_nested_fault_perms(s2fd->nested, prot, &writable);
-
- if (writable)
+ if (s2vi->map_writable && (s2vi->device ||
+ !memslot_is_logging(s2fd->memslot) ||
+ kvm_is_write_fault(s2fd->vcpu)))
*prot |= KVM_PGTABLE_PROT_W;
+ if (s2fd->nested)
+ *prot = adjust_nested_fault_perms(s2fd->nested, *prot);
+
if (kvm_vcpu_trap_is_exec_fault(s2fd->vcpu))
*prot |= KVM_PGTABLE_PROT_X;
@@ -1899,7 +1891,7 @@ static int kvm_s2_fault_compute_prot(const struct kvm_s2_fault_desc *s2fd,
*prot |= KVM_PGTABLE_PROT_X;
if (s2fd->nested)
- adjust_nested_exec_perms(kvm, s2fd->nested, prot);
+ *prot = adjust_nested_exec_perms(kvm, s2fd->nested, *prot);
if (!kvm_s2_fault_is_perm(s2fd) && !s2vi->map_non_cacheable && kvm_has_mte(kvm)) {
/* Check the VMM hasn't introduced a new disallowed VMA */
--
2.47.3
^ permalink raw reply related
* [PATCH v2 26/30] KVM: arm64: Replace force_pte with a max_map_size attribute
From: Marc Zyngier @ 2026-03-27 11:36 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel, kvm
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Fuad Tabba, Will Deacon, Quentin Perret
In-Reply-To: <20260327113618.4051534-1-maz@kernel.org>
force_pte is annoyingly limited in what it expresses, and we'd
be better off with a more generic primitive. Introduce max_map_size
instead, which does the trick and can be moved into the vma_info
structure. This firther allows it to reduce the scopes in which
it is mutable.
Tested-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/mmu.c | 23 +++++++++++++----------
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 39f01dd59259c..61b979365c6ee 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1652,6 +1652,7 @@ struct kvm_s2_fault_vma_info {
unsigned long mmu_seq;
long vma_pagesize;
vm_flags_t vm_flags;
+ unsigned long max_map_size;
struct page *page;
kvm_pfn_t pfn;
gfn_t gfn;
@@ -1661,14 +1662,18 @@ struct kvm_s2_fault_vma_info {
};
static short kvm_s2_resolve_vma_size(const struct kvm_s2_fault_desc *s2fd,
- struct vm_area_struct *vma, bool *force_pte)
+ struct kvm_s2_fault_vma_info *s2vi,
+ struct vm_area_struct *vma)
{
short vma_shift;
- if (*force_pte)
+ if (memslot_is_logging(s2fd->memslot)) {
+ s2vi->max_map_size = PAGE_SIZE;
vma_shift = PAGE_SHIFT;
- else
+ } else {
+ s2vi->max_map_size = PUD_SIZE;
vma_shift = get_vma_page_shift(vma, s2fd->hva);
+ }
switch (vma_shift) {
#ifndef __PAGETABLE_PMD_FOLDED
@@ -1686,7 +1691,7 @@ static short kvm_s2_resolve_vma_size(const struct kvm_s2_fault_desc *s2fd,
fallthrough;
case CONT_PTE_SHIFT:
vma_shift = PAGE_SHIFT;
- *force_pte = true;
+ s2vi->max_map_size = PAGE_SIZE;
fallthrough;
case PAGE_SHIFT:
break;
@@ -1697,7 +1702,7 @@ static short kvm_s2_resolve_vma_size(const struct kvm_s2_fault_desc *s2fd,
if (s2fd->nested) {
unsigned long max_map_size;
- max_map_size = *force_pte ? PAGE_SIZE : PUD_SIZE;
+ max_map_size = min(s2vi->max_map_size, PUD_SIZE);
/*
* If we're about to create a shadow stage 2 entry, then we
@@ -1715,7 +1720,7 @@ static short kvm_s2_resolve_vma_size(const struct kvm_s2_fault_desc *s2fd,
else if (max_map_size >= PAGE_SIZE && max_map_size < PMD_SIZE)
max_map_size = PAGE_SIZE;
- *force_pte = (max_map_size == PAGE_SIZE);
+ s2vi->max_map_size = max_map_size;
vma_shift = min_t(short, vma_shift, __ffs(max_map_size));
}
@@ -1724,7 +1729,6 @@ static short kvm_s2_resolve_vma_size(const struct kvm_s2_fault_desc *s2fd,
struct kvm_s2_fault {
bool s2_force_noncacheable;
- bool force_pte;
enum kvm_pgtable_prot prot;
};
@@ -1748,7 +1752,7 @@ static int kvm_s2_fault_get_vma_info(const struct kvm_s2_fault_desc *s2fd,
return -EFAULT;
}
- s2vi->vma_pagesize = BIT(kvm_s2_resolve_vma_size(s2fd, vma, &fault->force_pte));
+ s2vi->vma_pagesize = BIT(kvm_s2_resolve_vma_size(s2fd, s2vi, vma));
/*
* Both the canonical IPA and fault IPA must be aligned to the
@@ -1933,7 +1937,7 @@ static int kvm_s2_fault_map(const struct kvm_s2_fault_desc *s2fd,
* backed by a THP and thus use block mapping if possible.
*/
if (mapping_size == PAGE_SIZE &&
- !(fault->force_pte || fault->s2_force_noncacheable)) {
+ !(s2vi->max_map_size == PAGE_SIZE || fault->s2_force_noncacheable)) {
if (perm_fault_granule > PAGE_SIZE) {
mapping_size = perm_fault_granule;
} else {
@@ -1994,7 +1998,6 @@ static int user_mem_abort(const struct kvm_s2_fault_desc *s2fd)
bool perm_fault = kvm_vcpu_trap_is_permission_fault(s2fd->vcpu);
struct kvm_s2_fault_vma_info s2vi = {};
struct kvm_s2_fault fault = {
- .force_pte = memslot_is_logging(s2fd->memslot),
.prot = KVM_PGTABLE_PROT_R,
};
void *memcache = NULL;
--
2.47.3
^ permalink raw reply related
* [PATCH v2 27/30] KVM: arm64: Move device mapping management into kvm_s2_fault_pin_pfn()
From: Marc Zyngier @ 2026-03-27 11:36 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel, kvm
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Fuad Tabba, Will Deacon, Quentin Perret
In-Reply-To: <20260327113618.4051534-1-maz@kernel.org>
Attributes computed for devices are computed very late in the fault
handling process, meanning they are mutable for that long.
Introduce both 'device' and 'map_non_cacheable' attributes to the
vma_info structure, allowing that information to be set in stone
earlier, in kvm_s2_fault_pin_pfn().
Tested-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/mmu.c | 52 ++++++++++++++++++++++++--------------------
1 file changed, 29 insertions(+), 23 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 61b979365c6ee..23245ee7b1ec2 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1656,9 +1656,11 @@ struct kvm_s2_fault_vma_info {
struct page *page;
kvm_pfn_t pfn;
gfn_t gfn;
+ bool device;
bool mte_allowed;
bool is_vma_cacheable;
bool map_writable;
+ bool map_non_cacheable;
};
static short kvm_s2_resolve_vma_size(const struct kvm_s2_fault_desc *s2fd,
@@ -1728,7 +1730,6 @@ static short kvm_s2_resolve_vma_size(const struct kvm_s2_fault_desc *s2fd,
}
struct kvm_s2_fault {
- bool s2_force_noncacheable;
enum kvm_pgtable_prot prot;
};
@@ -1738,7 +1739,6 @@ static bool kvm_s2_fault_is_perm(const struct kvm_s2_fault_desc *s2fd)
}
static int kvm_s2_fault_get_vma_info(const struct kvm_s2_fault_desc *s2fd,
- struct kvm_s2_fault *fault,
struct kvm_s2_fault_vma_info *s2vi)
{
struct vm_area_struct *vma;
@@ -1794,12 +1794,11 @@ static gfn_t get_canonical_gfn(const struct kvm_s2_fault_desc *s2fd,
}
static int kvm_s2_fault_pin_pfn(const struct kvm_s2_fault_desc *s2fd,
- struct kvm_s2_fault *fault,
struct kvm_s2_fault_vma_info *s2vi)
{
int ret;
- ret = kvm_s2_fault_get_vma_info(s2fd, fault, s2vi);
+ ret = kvm_s2_fault_get_vma_info(s2fd, s2vi);
if (ret)
return ret;
@@ -1814,16 +1813,6 @@ static int kvm_s2_fault_pin_pfn(const struct kvm_s2_fault_desc *s2fd,
return -EFAULT;
}
- return 1;
-}
-
-static int kvm_s2_fault_compute_prot(const struct kvm_s2_fault_desc *s2fd,
- struct kvm_s2_fault *fault,
- const struct kvm_s2_fault_vma_info *s2vi)
-{
- struct kvm *kvm = s2fd->vcpu->kvm;
- bool writable = s2vi->map_writable;
-
/*
* Check if this is non-struct page memory PFN, and cannot support
* CMOs. It could potentially be unsafe to access as cacheable.
@@ -1842,8 +1831,10 @@ static int kvm_s2_fault_compute_prot(const struct kvm_s2_fault_desc *s2fd,
* S2FWB and CACHE DIC are mandatory to avoid the need for
* cache maintenance.
*/
- if (!kvm_supports_cacheable_pfnmap())
+ if (!kvm_supports_cacheable_pfnmap()) {
+ kvm_release_faultin_page(s2fd->vcpu->kvm, s2vi->page, true, false);
return -EFAULT;
+ }
} else {
/*
* If the page was identified as device early by looking at
@@ -1855,9 +1846,24 @@ static int kvm_s2_fault_compute_prot(const struct kvm_s2_fault_desc *s2fd,
* In both cases, we don't let transparent_hugepage_adjust()
* change things at the last minute.
*/
- fault->s2_force_noncacheable = true;
+ s2vi->map_non_cacheable = true;
}
- } else if (memslot_is_logging(s2fd->memslot) && !kvm_is_write_fault(s2fd->vcpu)) {
+
+ s2vi->device = true;
+ }
+
+ return 1;
+}
+
+static int kvm_s2_fault_compute_prot(const struct kvm_s2_fault_desc *s2fd,
+ struct kvm_s2_fault *fault,
+ const struct kvm_s2_fault_vma_info *s2vi)
+{
+ struct kvm *kvm = s2fd->vcpu->kvm;
+ bool writable = s2vi->map_writable;
+
+ if (!s2vi->device && memslot_is_logging(s2fd->memslot) &&
+ !kvm_is_write_fault(s2fd->vcpu)) {
/*
* Only actually map the page as writable if this was a write
* fault.
@@ -1865,7 +1871,7 @@ static int kvm_s2_fault_compute_prot(const struct kvm_s2_fault_desc *s2fd,
writable = false;
}
- if (kvm_vcpu_trap_is_exec_fault(s2fd->vcpu) && fault->s2_force_noncacheable)
+ if (kvm_vcpu_trap_is_exec_fault(s2fd->vcpu) && s2vi->map_non_cacheable)
return -ENOEXEC;
/*
@@ -1888,7 +1894,7 @@ static int kvm_s2_fault_compute_prot(const struct kvm_s2_fault_desc *s2fd,
if (kvm_vcpu_trap_is_exec_fault(s2fd->vcpu))
fault->prot |= KVM_PGTABLE_PROT_X;
- if (fault->s2_force_noncacheable)
+ if (s2vi->map_non_cacheable)
fault->prot |= (s2vi->vm_flags & VM_ALLOW_ANY_UNCACHED) ?
KVM_PGTABLE_PROT_NORMAL_NC : KVM_PGTABLE_PROT_DEVICE;
else if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC))
@@ -1897,7 +1903,7 @@ static int kvm_s2_fault_compute_prot(const struct kvm_s2_fault_desc *s2fd,
if (s2fd->nested)
adjust_nested_exec_perms(kvm, s2fd->nested, &fault->prot);
- if (!kvm_s2_fault_is_perm(s2fd) && !fault->s2_force_noncacheable && kvm_has_mte(kvm)) {
+ if (!kvm_s2_fault_is_perm(s2fd) && !s2vi->map_non_cacheable && kvm_has_mte(kvm)) {
/* Check the VMM hasn't introduced a new disallowed VMA */
if (!s2vi->mte_allowed)
return -EFAULT;
@@ -1937,7 +1943,7 @@ static int kvm_s2_fault_map(const struct kvm_s2_fault_desc *s2fd,
* backed by a THP and thus use block mapping if possible.
*/
if (mapping_size == PAGE_SIZE &&
- !(s2vi->max_map_size == PAGE_SIZE || fault->s2_force_noncacheable)) {
+ !(s2vi->max_map_size == PAGE_SIZE || s2vi->map_non_cacheable)) {
if (perm_fault_granule > PAGE_SIZE) {
mapping_size = perm_fault_granule;
} else {
@@ -1951,7 +1957,7 @@ static int kvm_s2_fault_map(const struct kvm_s2_fault_desc *s2fd,
}
}
- if (!perm_fault_granule && !fault->s2_force_noncacheable && kvm_has_mte(kvm))
+ if (!perm_fault_granule && !s2vi->map_non_cacheable && kvm_has_mte(kvm))
sanitise_mte_tags(kvm, pfn, mapping_size);
/*
@@ -2020,7 +2026,7 @@ static int user_mem_abort(const struct kvm_s2_fault_desc *s2fd)
* Let's check if we will get back a huge page backed by hugetlbfs, or
* get block mapping for device MMIO region.
*/
- ret = kvm_s2_fault_pin_pfn(s2fd, &fault, &s2vi);
+ ret = kvm_s2_fault_pin_pfn(s2fd, &s2vi);
if (ret != 1)
return ret;
--
2.47.3
^ permalink raw reply related
* [PATCH v2 16/30] KVM: arm64: Move fault context to const structure
From: Marc Zyngier @ 2026-03-27 11:36 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel, kvm
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Fuad Tabba, Will Deacon, Quentin Perret
In-Reply-To: <20260327113618.4051534-1-maz@kernel.org>
In order to make it clearer what gets updated or not during fault
handling, move a set of information that losely represents the
fault context.
This gets populated early, from handle_mem_abort(), and gets passed
along as a const pointer. user_mem_abort()'s signature is majorly
improved in doing so, and kvm_s2_fault loses a bunch of fields.
gmem_abort() will get a similar treatment down the line.
Tested-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/mmu.c | 133 ++++++++++++++++++++++---------------------
1 file changed, 69 insertions(+), 64 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 496bf5903ed3d..09e32f08028e4 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1565,6 +1565,14 @@ static void adjust_nested_exec_perms(struct kvm *kvm,
*prot &= ~KVM_PGTABLE_PROT_PX;
}
+struct kvm_s2_fault_desc {
+ struct kvm_vcpu *vcpu;
+ phys_addr_t fault_ipa;
+ struct kvm_s2_trans *nested;
+ struct kvm_memory_slot *memslot;
+ unsigned long hva;
+};
+
static int gmem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
struct kvm_s2_trans *nested,
struct kvm_memory_slot *memslot, bool is_perm)
@@ -1640,23 +1648,20 @@ static int gmem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
return ret != -EAGAIN ? ret : 0;
}
-static short kvm_s2_resolve_vma_size(struct vm_area_struct *vma,
- unsigned long hva,
- struct kvm_memory_slot *memslot,
- struct kvm_s2_trans *nested,
- bool *force_pte)
+static short kvm_s2_resolve_vma_size(const struct kvm_s2_fault_desc *s2fd,
+ struct vm_area_struct *vma, bool *force_pte)
{
short vma_shift;
if (*force_pte)
vma_shift = PAGE_SHIFT;
else
- vma_shift = get_vma_page_shift(vma, hva);
+ vma_shift = get_vma_page_shift(vma, s2fd->hva);
switch (vma_shift) {
#ifndef __PAGETABLE_PMD_FOLDED
case PUD_SHIFT:
- if (fault_supports_stage2_huge_mapping(memslot, hva, PUD_SIZE))
+ if (fault_supports_stage2_huge_mapping(s2fd->memslot, s2fd->hva, PUD_SIZE))
break;
fallthrough;
#endif
@@ -1664,7 +1669,7 @@ static short kvm_s2_resolve_vma_size(struct vm_area_struct *vma,
vma_shift = PMD_SHIFT;
fallthrough;
case PMD_SHIFT:
- if (fault_supports_stage2_huge_mapping(memslot, hva, PMD_SIZE))
+ if (fault_supports_stage2_huge_mapping(s2fd->memslot, s2fd->hva, PMD_SIZE))
break;
fallthrough;
case CONT_PTE_SHIFT:
@@ -1677,7 +1682,7 @@ static short kvm_s2_resolve_vma_size(struct vm_area_struct *vma,
WARN_ONCE(1, "Unknown vma_shift %d", vma_shift);
}
- if (nested) {
+ if (s2fd->nested) {
unsigned long max_map_size;
max_map_size = *force_pte ? PAGE_SIZE : PUD_SIZE;
@@ -1687,7 +1692,7 @@ static short kvm_s2_resolve_vma_size(struct vm_area_struct *vma,
* can only create a block mapping if the guest stage 2 page
* table uses at least as big a mapping.
*/
- max_map_size = min(kvm_s2_trans_size(nested), max_map_size);
+ max_map_size = min(kvm_s2_trans_size(s2fd->nested), max_map_size);
/*
* Be careful that if the mapping size falls between
@@ -1706,11 +1711,6 @@ static short kvm_s2_resolve_vma_size(struct vm_area_struct *vma,
}
struct kvm_s2_fault {
- struct kvm_vcpu *vcpu;
- phys_addr_t fault_ipa;
- struct kvm_s2_trans *nested;
- struct kvm_memory_slot *memslot;
- unsigned long hva;
bool fault_is_perm;
bool write_fault;
@@ -1732,28 +1732,28 @@ struct kvm_s2_fault {
vm_flags_t vm_flags;
};
-static int kvm_s2_fault_get_vma_info(struct kvm_s2_fault *fault)
+static int kvm_s2_fault_get_vma_info(const struct kvm_s2_fault_desc *s2fd,
+ struct kvm_s2_fault *fault)
{
struct vm_area_struct *vma;
- struct kvm *kvm = fault->vcpu->kvm;
+ struct kvm *kvm = s2fd->vcpu->kvm;
mmap_read_lock(current->mm);
- vma = vma_lookup(current->mm, fault->hva);
+ vma = vma_lookup(current->mm, s2fd->hva);
if (unlikely(!vma)) {
- kvm_err("Failed to find VMA for fault->hva 0x%lx\n", fault->hva);
+ kvm_err("Failed to find VMA for hva 0x%lx\n", s2fd->hva);
mmap_read_unlock(current->mm);
return -EFAULT;
}
- fault->vma_pagesize = 1UL << kvm_s2_resolve_vma_size(vma, fault->hva, fault->memslot,
- fault->nested, &fault->force_pte);
+ fault->vma_pagesize = BIT(kvm_s2_resolve_vma_size(s2fd, vma, &fault->force_pte));
/*
* Both the canonical IPA and fault IPA must be aligned to the
* mapping size to ensure we find the right PFN and lay down the
* mapping in the right place.
*/
- fault->gfn = ALIGN_DOWN(fault->fault_ipa, fault->vma_pagesize) >> PAGE_SHIFT;
+ fault->gfn = ALIGN_DOWN(s2fd->fault_ipa, fault->vma_pagesize) >> PAGE_SHIFT;
fault->mte_allowed = kvm_vma_mte_allowed(vma);
@@ -1775,31 +1775,33 @@ static int kvm_s2_fault_get_vma_info(struct kvm_s2_fault *fault)
return 0;
}
-static gfn_t get_canonical_gfn(struct kvm_s2_fault *fault)
+static gfn_t get_canonical_gfn(const struct kvm_s2_fault_desc *s2fd,
+ const struct kvm_s2_fault *fault)
{
phys_addr_t ipa;
- if (!fault->nested)
+ if (!s2fd->nested)
return fault->gfn;
- ipa = kvm_s2_trans_output(fault->nested);
+ ipa = kvm_s2_trans_output(s2fd->nested);
return ALIGN_DOWN(ipa, fault->vma_pagesize) >> PAGE_SHIFT;
}
-static int kvm_s2_fault_pin_pfn(struct kvm_s2_fault *fault)
+static int kvm_s2_fault_pin_pfn(const struct kvm_s2_fault_desc *s2fd,
+ struct kvm_s2_fault *fault)
{
int ret;
- ret = kvm_s2_fault_get_vma_info(fault);
+ ret = kvm_s2_fault_get_vma_info(s2fd, fault);
if (ret)
return ret;
- fault->pfn = __kvm_faultin_pfn(fault->memslot, get_canonical_gfn(fault),
+ fault->pfn = __kvm_faultin_pfn(s2fd->memslot, get_canonical_gfn(s2fd, fault),
fault->write_fault ? FOLL_WRITE : 0,
&fault->writable, &fault->page);
if (unlikely(is_error_noslot_pfn(fault->pfn))) {
if (fault->pfn == KVM_PFN_ERR_HWPOISON) {
- kvm_send_hwpoison_signal(fault->hva, __ffs(fault->vma_pagesize));
+ kvm_send_hwpoison_signal(s2fd->hva, __ffs(fault->vma_pagesize));
return 0;
}
return -EFAULT;
@@ -1808,9 +1810,10 @@ static int kvm_s2_fault_pin_pfn(struct kvm_s2_fault *fault)
return 1;
}
-static int kvm_s2_fault_compute_prot(struct kvm_s2_fault *fault)
+static int kvm_s2_fault_compute_prot(const struct kvm_s2_fault_desc *s2fd,
+ struct kvm_s2_fault *fault)
{
- struct kvm *kvm = fault->vcpu->kvm;
+ struct kvm *kvm = s2fd->vcpu->kvm;
/*
* Check if this is non-struct page memory PFN, and cannot support
@@ -1862,13 +1865,13 @@ static int kvm_s2_fault_compute_prot(struct kvm_s2_fault *fault)
* and trigger the exception here. Since the memslot is valid, inject
* the fault back to the guest.
*/
- if (esr_fsc_is_excl_atomic_fault(kvm_vcpu_get_esr(fault->vcpu))) {
- kvm_inject_dabt_excl_atomic(fault->vcpu, kvm_vcpu_get_hfar(fault->vcpu));
+ if (esr_fsc_is_excl_atomic_fault(kvm_vcpu_get_esr(s2fd->vcpu))) {
+ kvm_inject_dabt_excl_atomic(s2fd->vcpu, kvm_vcpu_get_hfar(s2fd->vcpu));
return 1;
}
- if (fault->nested)
- adjust_nested_fault_perms(fault->nested, &fault->prot, &fault->writable);
+ if (s2fd->nested)
+ adjust_nested_fault_perms(s2fd->nested, &fault->prot, &fault->writable);
if (fault->writable)
fault->prot |= KVM_PGTABLE_PROT_W;
@@ -1882,8 +1885,8 @@ static int kvm_s2_fault_compute_prot(struct kvm_s2_fault *fault)
else if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC))
fault->prot |= KVM_PGTABLE_PROT_X;
- if (fault->nested)
- adjust_nested_exec_perms(kvm, fault->nested, &fault->prot);
+ if (s2fd->nested)
+ adjust_nested_exec_perms(kvm, s2fd->nested, &fault->prot);
if (!fault->fault_is_perm && !fault->s2_force_noncacheable && kvm_has_mte(kvm)) {
/* Check the VMM hasn't introduced a new disallowed VMA */
@@ -1899,15 +1902,16 @@ static phys_addr_t get_ipa(const struct kvm_s2_fault *fault)
return gfn_to_gpa(fault->gfn);
}
-static int kvm_s2_fault_map(struct kvm_s2_fault *fault, void *memcache)
+static int kvm_s2_fault_map(const struct kvm_s2_fault_desc *s2fd,
+ struct kvm_s2_fault *fault, void *memcache)
{
- struct kvm *kvm = fault->vcpu->kvm;
+ struct kvm *kvm = s2fd->vcpu->kvm;
struct kvm_pgtable *pgt;
int ret;
enum kvm_pgtable_walk_flags flags = KVM_PGTABLE_WALK_SHARED;
kvm_fault_lock(kvm);
- pgt = fault->vcpu->arch.hw_mmu->pgt;
+ pgt = s2fd->vcpu->arch.hw_mmu->pgt;
ret = -EAGAIN;
if (mmu_invalidate_retry(kvm, fault->mmu_seq))
goto out_unlock;
@@ -1921,8 +1925,8 @@ static int kvm_s2_fault_map(struct kvm_s2_fault *fault, void *memcache)
if (fault->fault_is_perm && fault->fault_granule > PAGE_SIZE) {
fault->vma_pagesize = fault->fault_granule;
} else {
- fault->vma_pagesize = transparent_hugepage_adjust(kvm, fault->memslot,
- fault->hva, &fault->pfn,
+ fault->vma_pagesize = transparent_hugepage_adjust(kvm, s2fd->memslot,
+ s2fd->hva, &fault->pfn,
&fault->gfn);
if (fault->vma_pagesize < 0) {
@@ -1960,34 +1964,27 @@ static int kvm_s2_fault_map(struct kvm_s2_fault *fault, void *memcache)
/* Mark the page dirty only if the fault is handled successfully */
if (fault->writable && !ret)
- mark_page_dirty_in_slot(kvm, fault->memslot, get_canonical_gfn(fault));
+ mark_page_dirty_in_slot(kvm, s2fd->memslot, get_canonical_gfn(s2fd, fault));
if (ret != -EAGAIN)
return ret;
return 0;
}
-static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
- struct kvm_s2_trans *nested,
- struct kvm_memory_slot *memslot, unsigned long hva,
- bool fault_is_perm)
+static int user_mem_abort(const struct kvm_s2_fault_desc *s2fd)
{
- bool write_fault = kvm_is_write_fault(vcpu);
- bool logging_active = memslot_is_logging(memslot);
+ bool perm_fault = kvm_vcpu_trap_is_permission_fault(s2fd->vcpu);
+ bool write_fault = kvm_is_write_fault(s2fd->vcpu);
+ bool logging_active = memslot_is_logging(s2fd->memslot);
struct kvm_s2_fault fault = {
- .vcpu = vcpu,
- .fault_ipa = fault_ipa,
- .nested = nested,
- .memslot = memslot,
- .hva = hva,
- .fault_is_perm = fault_is_perm,
+ .fault_is_perm = perm_fault,
.logging_active = logging_active,
.force_pte = logging_active,
.prot = KVM_PGTABLE_PROT_R,
- .fault_granule = fault_is_perm ? kvm_vcpu_trap_get_perm_fault_granule(vcpu) : 0,
+ .fault_granule = perm_fault ? kvm_vcpu_trap_get_perm_fault_granule(s2fd->vcpu) : 0,
.write_fault = write_fault,
- .exec_fault = kvm_vcpu_trap_is_exec_fault(vcpu),
- .topup_memcache = !fault_is_perm || (logging_active && write_fault),
+ .exec_fault = kvm_vcpu_trap_is_exec_fault(s2fd->vcpu),
+ .topup_memcache = !perm_fault || (logging_active && write_fault),
};
void *memcache;
int ret;
@@ -2000,7 +1997,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
* only exception to this is when dirty logging is enabled at runtime
* and a write fault needs to collapse a block entry into a table.
*/
- ret = prepare_mmu_memcache(vcpu, fault.topup_memcache, &memcache);
+ ret = prepare_mmu_memcache(s2fd->vcpu, fault.topup_memcache, &memcache);
if (ret)
return ret;
@@ -2008,17 +2005,17 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
* Let's check if we will get back a huge page backed by hugetlbfs, or
* get block mapping for device MMIO region.
*/
- ret = kvm_s2_fault_pin_pfn(&fault);
+ ret = kvm_s2_fault_pin_pfn(s2fd, &fault);
if (ret != 1)
return ret;
- ret = kvm_s2_fault_compute_prot(&fault);
+ ret = kvm_s2_fault_compute_prot(s2fd, &fault);
if (ret) {
kvm_release_page_unused(fault.page);
return ret;
}
- return kvm_s2_fault_map(&fault, memcache);
+ return kvm_s2_fault_map(s2fd, &fault, memcache);
}
/* Resolve the access fault by making the page young again. */
@@ -2284,12 +2281,20 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu)
VM_WARN_ON_ONCE(kvm_vcpu_trap_is_permission_fault(vcpu) &&
!write_fault && !kvm_vcpu_trap_is_exec_fault(vcpu));
+ const struct kvm_s2_fault_desc s2fd = {
+ .vcpu = vcpu,
+ .fault_ipa = fault_ipa,
+ .nested = nested,
+ .memslot = memslot,
+ .hva = hva,
+ };
+
if (kvm_slot_has_gmem(memslot))
ret = gmem_abort(vcpu, fault_ipa, nested, memslot,
esr_fsc_is_permission_fault(esr));
else
- ret = user_mem_abort(vcpu, fault_ipa, nested, memslot, hva,
- esr_fsc_is_permission_fault(esr));
+ ret = user_mem_abort(&s2fd);
+
if (ret == 0)
ret = 1;
out:
--
2.47.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox