[PATCH] platform: generic: spacemit: k3: deny S-mode access to the reset vectors

[Troy Mitchell]

On Thu Nov 12, 2026 at 9:13 AM GMT, liutong wrote:
> On Thu, 12 Nov 2026 07:59:32 +0000, Xiang W wrote:
>> The PMP granularity on K3 is 4 KiB, so a mapping size smaller than
>> that will be ignored.
>>
>> Could you clarify how this case should be handled?
>
> Thanks, and thanks to Han Gao for putting it on hardware. You are
> right.
>
> The region order comes out of sbi_domain_memregion_init() without
> reference to the PMP granularity, and both protection backends then
> drop a region whose order is below it:
>
> 	if (pmp_log2gran <= reg->order && pmp_addr < pmp_addr_max)
> 		...program the entry...
> 	else
> 		sbi_printf("Can not configure pmp for domain %s ...
>
> (lib/sbi/sbi_hart_pmp.c:209 and :390). So with a 4 KiB granularity the
> 1 KiB region in my patch is never programmed and the firmware boots on
> with one line printed. The patch was a no-op on your board. I had only
> tested on qemu virt, where the granularity is 4 bytes and any size
> passes.
>
> Rounding up to the page is not a fix either, and this is the part I had
> wrong. The page at 0xd4282000 also holds the APMU block, which upstream
> Linux drives directly from S-mode:
>
> 	syscon_apmu: system-controller at d4282800 {
> 		compatible = "spacemit,k3-syscon-apmu";
> 		reg = <0x0 0xd4282800 0x0 0x400>;
> 		#clock-cells = <1>;
> 		#power-domain-cells = <1>;
> 	};
>
> (arch/riscv/boot/dts/spacemit/k3.dtsi, with drivers/clk/spacemit/ccu-k3.c
> behind it). Denying S-mode the page on its own would take out the clock,
> reset and power domain provider for the whole board.
>
> SpaceMit's k3-br-v1.0.y does not only register the region. It also
> installs emulate_load and emulate_store, which translate the faulting
> S-mode address and perform the access in M-mode, except for an
> m_only_ranges list that it refuses to emulate - and that list is exactly
> the four RVBADDR pairs plus the PMU CAP and CX idle and wakeup
> registers. The comment on the barriers in that emulator names the kernel
> CCU driver's recalc_rate loop, so the S-mode traffic is expected there by
> design. Upstream already has the hooks for that
> (sbi_platform_operations.emulate_load and emulate_store), although no
> in-tree platform uses them yet.
>
> That two part shape is what makes the protection safe on that branch,
> and my patch carried over only the first part. I am dropping it rather
> than sending a v2 that would break clocks.
>
> Troy, Xianbin: would you be interested in upstreaming that protection
> from k3-br-v1.0.y?

Yes, I'd be happy to take this over.

Anup and Xiang, would you be open to this approach (using emulate_load or
emulate_store for the shared page)? If so, I can send out an RFC first
to get your feedback.
>
> One smaller thing this exposed, separate from K3: a region below the PMP
> granularity is dropped with a single printf and boot continues, so a
> platform author gets no signal that the protection they registered is
> not in effect. That is how I missed it. Whether it should be louder, or
> rounded up, looks like its own discussion and I did not want to fold it
> into this thread.
>
> Thanks again for catching this before it went in.
>
> liutong


-- 
Troy Mitchell

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/opensbi/attachments/20261112/4419839f/attachment.sig>