[RFC PATCH 0/3] dt-bindings: riscv: Add RISC-V Worlds and SiFive WorldGuard DT bindings

[RFC PATCH 0/3] dt-bindings: riscv: Add RISC-V Worlds and SiFive WorldGuard DT bindings

[Yu-Chien Peter Lin]

Add device tree bindings for RISC-V Worlds, a standard extension that tags
every transaction with a World ID for fine-grained isolation. SiFive's
WorldGuard Checker is a hardware firewall in the system interconnect that
inspects transaction WIDs and enforces per-World access policies on memory
and MMIO devices.

The three patches add: Worlds ISA extension properties (riscv,nworlds and
sifive,trustedwid on /cpus), per-hart World ID constraints (riscv,pmwid,
riscv,pmwidlist, riscv,pmlwidlist on cpu@X nodes), and the wgchecker2
binding with access-controller specifiers.

The access-controllers specifier carries range, permission and config fields
to support three use cases: 
1. single range device protection
2. discontiguous range device protection
3. sub-range memory partitioning.

Link: https://github.com/riscvarchive/security/blob/main/papers/worldguard%20proposal.pdf

Yu-Chien Peter Lin (3):
  dt-bindings: riscv: Add Worlds ISA extensions
  dt-bindings: riscv: Add Worlds per-hart properties
  dt-bindings: sifive: Add WorldGuard Checker

 .../devicetree/bindings/riscv/cpus.yaml       |  21 ++
 .../devicetree/bindings/riscv/extensions.yaml |  29 +++
 .../devicetree/bindings/riscv/worlds.yaml     |  86 +++++++
 .../bindings/sifive/sifive,wgchecker2.yaml    | 237 ++++++++++++++++++
 4 files changed, 373 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/riscv/worlds.yaml
 create mode 100644 Documentation/devicetree/bindings/sifive/sifive,wgchecker2.yaml

-- 
2.43.7

[RFC PATCH 1/3] dt-bindings: riscv: Add Worlds ISA extensions

[Yu-Chien Peter Lin]

Add DT bindings for RISC-V Worlds ISA extensions to tag
transactions with World IDs that hardware uses to enforce
world-based isolation across execution contexts.

Signed-off-by: Yu-Chien Peter Lin <peter.lin@sifive.com>
---
 .../devicetree/bindings/riscv/extensions.yaml | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
index 2b0a8a93bb21..1bc8b1aa67c0 100644
--- a/Documentation/devicetree/bindings/riscv/extensions.yaml
+++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
@@ -193,12 +193,35 @@ properties:
             ratified at commit d70011dde6c2 ("Update to ratified state")
             of riscv-j-extension.
 
+        - const: smlwid
+          description: |
+            The standard Smlwid extension for M-mode control of lower
+            privilege World ID via the mlwid CSR as ratified at commit
+            TBD ("TBD") of riscv-worlds.
+
+        - const: smlwidlist
+          description: |
+            The standard Smlwidlist extension for M-mode control of lower
+            privilege World IDs via the mlwidlist CSR as ratified at commit
+            TBD ("TBD") of riscv-worlds.
+
         - const: smstateen
           description: |
             The standard Smstateen extension for controlling access to CSRs
             added by other RISC-V extensions in H/S/VS/U/VU modes and as
             ratified at commit a28bfae (Ratified (#7)) of riscv-state-enable.
 
+        - const: smwdeleg
+          description: |
+            The standard Smwdeleg extension for M-mode delegation of lower
+            privilege World ID control to S-mode via the mwiddeleg CSR, as
+            ratified at commit TBD ("TBD") of riscv-worlds.
+
+        - const: smwid
+          description: |
+            The standard Smwid extension for M-mode World ID control via the
+            mwid CSR as ratified at commit TBD ("TBD") of riscv-worlds.
+
         - const: ssaia
           description: |
             The standard Ssaia supervisor-level extension for the advanced
@@ -262,6 +285,12 @@ properties:
             ratified in RISC-V Profiles Version 1.0, with commit b1d806605f87
             ("Updated to ratified state.")
 
+        - const: sswid
+          description: |
+            The standard Sswid extension for S-mode control of lower
+            privilege World IDs via the slwid CSR as ratified at commit
+            TBD ("TBD") of riscv-worlds.
+
         - const: supm
           description: |
             The standard Supm extension for pointer masking support in user
-- 
2.43.7

[RFC PATCH 2/3] dt-bindings: riscv: Add Worlds per-hart properties

[Yu-Chien Peter Lin]

Add per-hart DT properties for RISC-V Worlds architecture:
riscv,pmwid, riscv,pmwidlist, and riscv,pmlwidlist. These
platform-defined values are primarily used by M-mode firmware
to configure World ID CSRs and restrict WID usage across
privilege levels.

Signed-off-by: Yu-Chien Peter Lin <peter.lin@sifive.com>
---
 .../devicetree/bindings/riscv/cpus.yaml       | 21 +++++
 .../devicetree/bindings/riscv/worlds.yaml     | 77 +++++++++++++++++++
 2 files changed, 98 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/riscv/worlds.yaml

diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
index 5feeb2203050..4b5778b6d3e7 100644
--- a/Documentation/devicetree/bindings/riscv/cpus.yaml
+++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
@@ -26,6 +26,7 @@ description: |
 allOf:
   - $ref: /schemas/cpu.yaml#
   - $ref: extensions.yaml
+  - $ref: worlds.yaml
   - if:
       not:
         properties:
@@ -120,11 +121,31 @@ properties:
       thead systems where the vector register length is not identical on all harts, or
       the vlenb CSR is not available.
 
+  riscv,pmwid:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      Platform-defined M-mode World ID (WID) assigned to this hart.
+    minimum: 0
+    maximum: 63
+
+  riscv,pmwidlist:
+    $ref: /schemas/types.yaml#/definitions/uint64
+    description:
+      Platform-defined bitmap of M-mode World IDs (WIDs) that this hart may use.
+
+  riscv,pmlwidlist:
+    $ref: /schemas/types.yaml#/definitions/uint64
+    description:
+      Platform-defined bitmap of World IDs (WIDs) that S-mode and U-mode may use
+      on this hart.
+
   # RISC-V has multiple properties for cache op block sizes as the sizes
   # differ between individual CBO extensions
   cache-op-block-size: false
   # RISC-V requires 'timebase-frequency' in /cpus, so disallow it here
   timebase-frequency: false
+  # RISC-V requires 'riscv,nworlds' in /cpus, so disallow it here
+  riscv,nworlds: false
 
   interrupt-controller:
     type: object
diff --git a/Documentation/devicetree/bindings/riscv/worlds.yaml b/Documentation/devicetree/bindings/riscv/worlds.yaml
new file mode 100644
index 000000000000..cc8b3747591e
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/worlds.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0 OR MIT)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/worlds.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RISC-V Worlds Extension
+
+maintainers:
+  - Yu-Chien Peter Lin <peter.lin@sifive.com>
+
+description: |
+  The RISC-V Worlds ISA extension, as described in the RISC-V Privileged
+  Specification, adds World ID tagging for context isolation.
+
+  This binding describes the system-wide Worlds configuration for the /cpus node
+  and is used alongside per-hart Worlds-related properties such as riscv,pmwid in
+  the RISC-V CPU binding and Worlds-related ISA extensions enumerated via
+  riscv,isa-extensions.
+
+select:
+  properties:
+    $nodename:
+      pattern: "^cpus$"
+
+properties:
+  riscv,nworlds:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description: |
+      Number of World IDs (WIDs) supported by the platform. This is a system-wide
+      property that describes the total number of isolation contexts available.
+      Hardware components such as the WorldGuard Checker use this to determine
+      the valid range of WID values.
+    minimum: 2
+    maximum: 64
+
+additionalProperties: true
+
+examples:
+  - |
+    // Example: System with 4 World IDs
+    cpus {
+        #address-cells = <1>;
+        #size-cells = <0>;
+        timebase-frequency = <1000000>;
+        riscv,nworlds = <4>;
+
+        cpu@0 {
+            device_type = "cpu";
+            reg = <0>;
+            compatible = "sifive,bullet0", "riscv";
+            riscv,isa-base = "rv64i";
+            riscv,isa-extensions = "i", "m", "a", "f", "d", "c";
+            riscv,pmwid = <0>;
+
+            interrupt-controller {
+                #interrupt-cells = <1>;
+                compatible = "riscv,cpu-intc";
+                interrupt-controller;
+            };
+        };
+
+        cpu@1 {
+            device_type = "cpu";
+            reg = <1>;
+            compatible = "sifive,bullet0", "riscv";
+            riscv,isa-base = "rv64i";
+            riscv,isa-extensions = "i", "m", "a", "f", "d", "c";
+            riscv,pmwid = <1>;
+
+            interrupt-controller {
+                #interrupt-cells = <1>;
+                compatible = "riscv,cpu-intc";
+                interrupt-controller;
+            };
+        };
+    };
-- 
2.43.7

[RFC PATCH 3/3] dt-bindings: sifive: Add WorldGuard Checker

[Yu-Chien Peter Lin]

Add DT binding for SiFive wgChecker2, a hardware firewall enforcing
WID-based access control in RISC-V Worlds. Provides checker slots to
program per-WID permissions for downstream resources, with optional
sub-range partitioning.

Link: https://github.com/riscvarchive/security/blob/main/papers/worldguard%20proposal.pdf
Signed-off-by: Yu-Chien Peter Lin <peter.lin@sifive.com>
Reviewed-by: Zong Li <zong.li@sifive.com>
Reviewed-by: Jim Shu <jim.shu@sifive.com>
---
 .../devicetree/bindings/riscv/worlds.yaml     |   9 +
 .../bindings/sifive/sifive,wgchecker2.yaml    | 237 ++++++++++++++++++
 2 files changed, 246 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sifive/sifive,wgchecker2.yaml

diff --git a/Documentation/devicetree/bindings/riscv/worlds.yaml b/Documentation/devicetree/bindings/riscv/worlds.yaml
index cc8b3747591e..c39a06c2dd8d 100644
--- a/Documentation/devicetree/bindings/riscv/worlds.yaml
+++ b/Documentation/devicetree/bindings/riscv/worlds.yaml
@@ -34,6 +34,14 @@ properties:
     minimum: 2
     maximum: 64
 
+  sifive,trustedwid:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    maximum: 31
+    description: |
+      The World ID (WID) designated as the trusted WID for this platform.
+      Transactions tagged with this WID are authorized to access and configure
+      WorldGuard blocks, including wgCheckers and wgMarkers.
+
 additionalProperties: true
 
 examples:
@@ -44,6 +52,7 @@ examples:
         #size-cells = <0>;
         timebase-frequency = <1000000>;
         riscv,nworlds = <4>;
+        sifive,trustedwid = <3>;
 
         cpu@0 {
             device_type = "cpu";
diff --git a/Documentation/devicetree/bindings/sifive/sifive,wgchecker2.yaml b/Documentation/devicetree/bindings/sifive/sifive,wgchecker2.yaml
new file mode 100644
index 000000000000..043c748385ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/sifive/sifive,wgchecker2.yaml
@@ -0,0 +1,237 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2026 SiFive, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sifive/sifive,wgchecker2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SiFive WorldGuard Checker
+
+maintainers:
+  - Yu-Chien Peter Lin <peter.lin@sifive.com>
+
+description: |
+  The RISC-V Worlds ISA extension defines World IDs (WIDs) as architectural
+  identifiers that tag each system transaction with its originating context.
+  System integrators assign WIDs to execution contexts such as privilege modes,
+  trusted execution environments, or other isolation boundaries.
+
+  The SiFive WorldGuard Checker is a hardware firewall positioned in the
+  system interconnect fabric. It inspects every transaction, evaluating the
+  WID against access control policies encoded in checker slots for each
+  protected resource. Transactions from unauthorized WIDs are blocked and
+  reported as bus errors, interrupts, or both.
+
+  This enables spatial partitioning of memory regions and memory-mapped devices
+  across execution contexts. Different address ranges can enforce distinct
+  policies, allowing isolated workloads to coexist with hardware-enforced
+  protection.
+
+  The wgChecker acts as an access-controller provider as defined in the
+  access-controllers framework. Protected devices are consumers that declare
+  their access policy via the access-controllers property. The hardware
+  supports up to 32 World IDs.
+
+  The World ID authorized to configure WorldGuard blocks is specified by the
+  sifive,trustedwid property in the /cpus node.
+
+allOf:
+  - $ref: /schemas/access-controllers/access-controllers.yaml#
+
+properties:
+  compatible:
+    const: sifive,wgchecker2
+
+  reg:
+    maxItems: 1
+    description:
+      Base address and size of the wgChecker memory-mapped I/O registers.
+
+  interrupts:
+    maxItems: 1
+    description:
+      Interrupt line asserted when a WID access violation is detected and
+      interrupt reporting is enabled in the slot configuration (IR or IW
+      bits set).
+
+  '#access-controller-cells':
+    const: 7
+    description: |
+      Specifier for one access-control rule, encoded as seven u32 cells:
+        <addr-hi addr-lo size-hi size-lo perm-hi perm-lo config>
+
+      where:
+        - addr-hi, addr-lo: 64-bit base address of the protected region.
+        - size-hi, size-lo: 64-bit size of the protected region in bytes.
+        - perm-hi: Permission bitmap for WIDs 16..31. Two bits per WID:
+                     bit 2*(WID-16)   = Read  permission
+                     bit 2*(WID-16)+1 = Write permission
+                   Set bits grant access. Use 0x0 for systems with
+                   riscv,nworlds <= 16.
+        - perm-lo: Permission bitmap for WIDs 0..15. Two bits per WID:
+                     bit 2*WID   = Read  permission
+                     bit 2*WID+1 = Write permission
+                   Set bits grant access.
+        - config:  Slot configuration bits:
+                     Bit 0 (ER): Report read  violations as bus errors
+                     Bit 1 (EW): Report write violations as bus errors
+                     Bit 2 (IR): Report read  violations via interrupt
+                     Bit 3 (IW): Report write violations via interrupt
+                     Bit 4 (L):  Lock bit - prevents further modification
+                   Bits 5..31 are reserved and must be zero.
+
+      Multiple entries may be listed to apply different policies to
+      different address ranges, including sub-ranges within a single
+      physical resource.
+
+required:
+  - compatible
+  - reg
+  - '#access-controller-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+
+    // Example 1: Single device protection
+    // WID 0 and WID 3 have RW access to UART; errors and IRQs reported.
+
+    cpus {
+        #address-cells = <1>;
+        #size-cells = <0>;
+        timebase-frequency = <1000000>;
+        riscv,nworlds = <4>;
+        sifive,trustedwid = <3>;
+
+        cpu@0 {
+            device_type = "cpu";
+            reg = <0>;
+            compatible = "riscv";
+            riscv,isa = "rv64imac";
+        };
+    };
+
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        uart: uart@1c1000 {
+            compatible = "ns16550a";
+            reg = <0x0 0x001c1000 0x0 0x1000>;
+            reg-names = "control";
+            interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
+            // WID 0,3 RW; report errors+IRQs
+            access-controllers = <&wgchecker0
+                                  0x0 0x001c1000 0x0 0x00001000
+                                  0x0 0x000000c3 0x0f>;
+        };
+
+        wgchecker0: wgchecker@1c2000 {
+            compatible = "sifive,wgchecker2";
+            reg = <0x0 0x001c2000 0x0 0x1000>;
+            #access-controller-cells = <7>;
+            interrupts = <80 IRQ_TYPE_LEVEL_HIGH>;
+            interrupt-parent = <&aplic_m>;
+        };
+    };
+
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+
+    // Example 2: Multi-reg device with separate per-range rules
+    // m_mode: WID 3 only; s_mode: WID 0,3 RW.
+
+    cpus {
+        #address-cells = <1>;
+        #size-cells = <0>;
+        timebase-frequency = <1000000>;
+        riscv,nworlds = <16>;
+        sifive,trustedwid = <3>;
+
+        cpu@0 {
+            device_type = "cpu";
+            reg = <0>;
+            compatible = "riscv";
+            riscv,isa = "rv64imac";
+        };
+    };
+
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        device: device@10000 {
+            compatible = "vendor,soc1-ip";
+            reg = <0x0 0x00010000 0x0 0x8000>,
+                  <0x0 0x00a00000 0x0 0x4000>;
+            reg-names = "m_mode", "s_mode";
+            // m_mode: WID 3 only; s_mode: WID 0,3 RW
+            access-controllers = <&wgchecker1
+                                  0x0 0x00010000 0x0 0x00008000
+                                  0x0 0x000000c0 0x0f>,
+                                 <&wgchecker1
+                                  0x0 0x00a00000 0x0 0x00004000
+                                  0x0 0x000000c3 0x0f>;
+        };
+
+        wgchecker1: wgchecker@35000 {
+            compatible = "sifive,wgchecker2";
+            reg = <0x0 0x00035000 0x0 0x1000>;
+            #access-controller-cells = <7>;
+            interrupts = <81 IRQ_TYPE_LEVEL_HIGH>;
+            interrupt-parent = <&aplic_m>;
+        };
+    };
+
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+
+    // Example 3: DRAM partitioning with secure enclave
+    // Sub-range 1 [0x80000000, 0xC0000000): WID 0,1,3 RW
+    // Sub-range 2 [0xC0000000, 0xC1000000): WID 1,3 only (secure enclave)
+    // Sub-range 3 [0xC1000000, 0x100000000): WID 0,1,3 RW
+
+    cpus {
+        #address-cells = <1>;
+        #size-cells = <0>;
+        timebase-frequency = <1000000>;
+        riscv,nworlds = <4>;
+        sifive,trustedwid = <3>;
+
+        cpu@0 {
+            device_type = "cpu";
+            reg = <0>;
+            compatible = "riscv";
+            riscv,isa = "rv64imac";
+        };
+    };
+
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        ddr: memory@80000000 {
+            device_type = "memory";
+            reg = <0x0 0x80000000 0x0 0x80000000>;
+            access-controllers =
+                <&wgchecker2
+                 0x0 0x80000000 0x0 0x40000000
+                 0x0 0x000000cf 0x0f>,
+                <&wgchecker2
+                 0x0 0xc0000000 0x0 0x01000000
+                 0x0 0x000000cc 0x0f>,
+                <&wgchecker2
+                 0x0 0xc1000000 0x0 0x3f000000
+                 0x0 0x000000cf 0x0f>;
+        };
+
+        wgchecker2: wgchecker@40000000 {
+            compatible = "sifive,wgchecker2";
+            reg = <0x0 0x40000000 0x0 0x1000>;
+            #access-controller-cells = <7>;
+            interrupts = <82 IRQ_TYPE_LEVEL_HIGH>;
+            interrupt-parent = <&aplic_m>;
+        };
+    };
-- 
2.43.7

Re: [RFC PATCH 2/3] dt-bindings: riscv: Add Worlds per-hart properties

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 5527 bytes --]

On Fri, Jun 19, 2026 at 06:58:33PM +0800, Yu-Chien Peter Lin wrote:
> Add per-hart DT properties for RISC-V Worlds architecture:
> riscv,pmwid, riscv,pmwidlist, and riscv,pmlwidlist. These
> platform-defined values are primarily used by M-mode firmware
> to configure World ID CSRs and restrict WID usage across
> privilege levels.
> 
> Signed-off-by: Yu-Chien Peter Lin <peter.lin@sifive.com>
> ---
>  .../devicetree/bindings/riscv/cpus.yaml       | 21 +++++
>  .../devicetree/bindings/riscv/worlds.yaml     | 77 +++++++++++++++++++
>  2 files changed, 98 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/riscv/worlds.yaml
> 
> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> index 5feeb2203050..4b5778b6d3e7 100644
> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> @@ -26,6 +26,7 @@ description: |
>  allOf:
>    - $ref: /schemas/cpu.yaml#
>    - $ref: extensions.yaml
> +  - $ref: worlds.yaml
>    - if:
>        not:
>          properties:
> @@ -120,11 +121,31 @@ properties:
>        thead systems where the vector register length is not identical on all harts, or
>        the vlenb CSR is not available.
>  
> +  riscv,pmwid:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description:
> +      Platform-defined M-mode World ID (WID) assigned to this hart.
> +    minimum: 0
> +    maximum: 63
> +
> +  riscv,pmwidlist:
> +    $ref: /schemas/types.yaml#/definitions/uint64
> +    description:
> +      Platform-defined bitmap of M-mode World IDs (WIDs) that this hart may use.

I don't understand what the difference is between this property and the
one before it are.
Is this one meant to be used by m-mode software to then select one which
will appear in riscv,pmwid?

> +
> +  riscv,pmlwidlist:
> +    $ref: /schemas/types.yaml#/definitions/uint64
> +    description:
> +      Platform-defined bitmap of World IDs (WIDs) that S-mode and U-mode may use
> +      on this hart.
> +
>    # RISC-V has multiple properties for cache op block sizes as the sizes
>    # differ between individual CBO extensions
>    cache-op-block-size: false
>    # RISC-V requires 'timebase-frequency' in /cpus, so disallow it here
>    timebase-frequency: false

> +  # RISC-V requires 'riscv,nworlds' in /cpus, so disallow it here
> +  riscv,nworlds: false

Isn't this pointless? Nothing ever defines riscv,nworlds as a cpu level
property so there's no need to disallow it?

>  
>    interrupt-controller:
>      type: object
> diff --git a/Documentation/devicetree/bindings/riscv/worlds.yaml b/Documentation/devicetree/bindings/riscv/worlds.yaml
> new file mode 100644
> index 000000000000..cc8b3747591e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/riscv/worlds.yaml
> @@ -0,0 +1,77 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/riscv/worlds.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: RISC-V Worlds Extension
> +
> +maintainers:
> +  - Yu-Chien Peter Lin <peter.lin@sifive.com>
> +
> +description: |
> +  The RISC-V Worlds ISA extension, as described in the RISC-V Privileged
> +  Specification, adds World ID tagging for context isolation.
> +
> +  This binding describes the system-wide Worlds configuration for the /cpus node
> +  and is used alongside per-hart Worlds-related properties such as riscv,pmwid in
> +  the RISC-V CPU binding and Worlds-related ISA extensions enumerated via
> +  riscv,isa-extensions.
> +
> +select:
> +  properties:
> +    $nodename:
> +      pattern: "^cpus$"
> +
> +properties:
> +  riscv,nworlds:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description: |
> +      Number of World IDs (WIDs) supported by the platform. This is a system-wide
> +      property that describes the total number of isolation contexts available.
> +      Hardware components such as the WorldGuard Checker use this to determine
> +      the valid range of WID values.
> +    minimum: 2
> +    maximum: 64
> +
> +additionalProperties: true
> +
> +examples:
> +  - |
> +    // Example: System with 4 World IDs
> +    cpus {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +        timebase-frequency = <1000000>;
> +        riscv,nworlds = <4>;
> +
> +        cpu@0 {
> +            device_type = "cpu";
> +            reg = <0>;
> +            compatible = "sifive,bullet0", "riscv";
> +            riscv,isa-base = "rv64i";
> +            riscv,isa-extensions = "i", "m", "a", "f", "d", "c";
> +            riscv,pmwid = <0>;
> +
> +            interrupt-controller {
> +                #interrupt-cells = <1>;
> +                compatible = "riscv,cpu-intc";
> +                interrupt-controller;
> +            };
> +        };
> +
> +        cpu@1 {
> +            device_type = "cpu";
> +            reg = <1>;
> +            compatible = "sifive,bullet0", "riscv";
> +            riscv,isa-base = "rv64i";
> +            riscv,isa-extensions = "i", "m", "a", "f", "d", "c";
> +            riscv,pmwid = <1>;
> +
> +            interrupt-controller {
> +                #interrupt-cells = <1>;
> +                compatible = "riscv,cpu-intc";
> +                interrupt-controller;
> +            };
> +        };
> +    };
> -- 
> 2.43.7
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [RFC PATCH 3/3] dt-bindings: sifive: Add WorldGuard Checker

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 8912 bytes --]

On Fri, Jun 19, 2026 at 06:58:34PM +0800, Yu-Chien Peter Lin wrote:
> Add DT binding for SiFive wgChecker2, a hardware firewall enforcing
> WID-based access control in RISC-V Worlds. Provides checker slots to
> program per-WID permissions for downstream resources, with optional
> sub-range partitioning.
> 
> Link: https://github.com/riscvarchive/security/blob/main/papers/worldguard%20proposal.pdf
> Signed-off-by: Yu-Chien Peter Lin <peter.lin@sifive.com>
> Reviewed-by: Zong Li <zong.li@sifive.com>
> Reviewed-by: Jim Shu <jim.shu@sifive.com>
> ---
>  .../devicetree/bindings/riscv/worlds.yaml     |   9 +
>  .../bindings/sifive/sifive,wgchecker2.yaml    | 237 ++++++++++++++++++
>  2 files changed, 246 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/sifive/sifive,wgchecker2.yaml
> 
> diff --git a/Documentation/devicetree/bindings/riscv/worlds.yaml b/Documentation/devicetree/bindings/riscv/worlds.yaml
> index cc8b3747591e..c39a06c2dd8d 100644
> --- a/Documentation/devicetree/bindings/riscv/worlds.yaml
> +++ b/Documentation/devicetree/bindings/riscv/worlds.yaml
> @@ -34,6 +34,14 @@ properties:
>      minimum: 2
>      maximum: 64
>  
> +  sifive,trustedwid:

What's sifive specific about this? Wouldn't other vendors also have
trusted worlds?

> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    maximum: 31
> +    description: |
> +      The World ID (WID) designated as the trusted WID for this platform.
> +      Transactions tagged with this WID are authorized to access and configure
> +      WorldGuard blocks, including wgCheckers and wgMarkers.
> +
>  additionalProperties: true
>  
>  examples:
> @@ -44,6 +52,7 @@ examples:
>          #size-cells = <0>;
>          timebase-frequency = <1000000>;
>          riscv,nworlds = <4>;
> +        sifive,trustedwid = <3>;
>  
>          cpu@0 {
>              device_type = "cpu";
> diff --git a/Documentation/devicetree/bindings/sifive/sifive,wgchecker2.yaml b/Documentation/devicetree/bindings/sifive/sifive,wgchecker2.yaml
> new file mode 100644
> index 000000000000..043c748385ed
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sifive/sifive,wgchecker2.yaml
> @@ -0,0 +1,237 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2026 SiFive, Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sifive/sifive,wgchecker2.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: SiFive WorldGuard Checker
> +
> +maintainers:
> +  - Yu-Chien Peter Lin <peter.lin@sifive.com>
> +
> +description: |
> +  The RISC-V Worlds ISA extension defines World IDs (WIDs) as architectural
> +  identifiers that tag each system transaction with its originating context.
> +  System integrators assign WIDs to execution contexts such as privilege modes,
> +  trusted execution environments, or other isolation boundaries.
> +
> +  The SiFive WorldGuard Checker is a hardware firewall positioned in the
> +  system interconnect fabric. It inspects every transaction, evaluating the
> +  WID against access control policies encoded in checker slots for each
> +  protected resource. Transactions from unauthorized WIDs are blocked and
> +  reported as bus errors, interrupts, or both.
> +
> +  This enables spatial partitioning of memory regions and memory-mapped devices
> +  across execution contexts. Different address ranges can enforce distinct
> +  policies, allowing isolated workloads to coexist with hardware-enforced
> +  protection.
> +
> +  The wgChecker acts as an access-controller provider as defined in the
> +  access-controllers framework. Protected devices are consumers that declare
> +  their access policy via the access-controllers property. The hardware
> +  supports up to 32 World IDs.
> +
> +  The World ID authorized to configure WorldGuard blocks is specified by the
> +  sifive,trustedwid property in the /cpus node.
> +
> +allOf:
> +  - $ref: /schemas/access-controllers/access-controllers.yaml#
> +
> +properties:
> +  compatible:
> +    const: sifive,wgchecker2

Missing device specific compatibles.

> +
> +  reg:
> +    maxItems: 1
> +    description:
> +      Base address and size of the wgChecker memory-mapped I/O registers.
> +
> +  interrupts:
> +    maxItems: 1
> +    description:
> +      Interrupt line asserted when a WID access violation is detected and
> +      interrupt reporting is enabled in the slot configuration (IR or IW
> +      bits set).
> +
> +  '#access-controller-cells':
> +    const: 7
> +    description: |
> +      Specifier for one access-control rule, encoded as seven u32 cells:
> +        <addr-hi addr-lo size-hi size-lo perm-hi perm-lo config>
> +
> +      where:
> +        - addr-hi, addr-lo: 64-bit base address of the protected region.
> +        - size-hi, size-lo: 64-bit size of the protected region in bytes.

These two cells effectively just duplicate the reg property.

> +        - perm-hi: Permission bitmap for WIDs 16..31. Two bits per WID:
> +                     bit 2*(WID-16)   = Read  permission
> +                     bit 2*(WID-16)+1 = Write permission
> +                   Set bits grant access. Use 0x0 for systems with
> +                   riscv,nworlds <= 16.
> +        - perm-lo: Permission bitmap for WIDs 0..15. Two bits per WID:
> +                     bit 2*WID   = Read  permission
> +                     bit 2*WID+1 = Write permission
> +                   Set bits grant access.

And these two look like a layering violation to me. Why does the
consumer contain its own configuration information? If firmware provides
this to s-mode, it is either useless (because firmware has already done
the configuration) or it makes the access control pointless because
s-mode is expected to program its own access.
With that in mind, the first 4 cells can probably just be transmuted to
a single cell with platform-specific unique identifiers.
Surely the ecall involved with actually requesting access needs
something like that anyway?

The only value I can see in this is if some worlds that a bit of
software is running on can access a peripheral (or part thereof) and
others can't? Though platforms like that might benefit more from being
reworked to have homogeneous access! I've got no idea how a Linux driver
etc would handle the only some CPUs being permitted to access a register
region.

> +        - config:  Slot configuration bits:
> +                     Bit 0 (ER): Report read  violations as bus errors
> +                     Bit 1 (EW): Report write violations as bus errors
> +                     Bit 2 (IR): Report read  violations via interrupt
> +                     Bit 3 (IW): Report write violations via interrupt
> +                     Bit 4 (L):  Lock bit - prevents further modification
> +                   Bits 5..31 are reserved and must be zero.

For the next revision of this, I really would like to see the access
controller driver.

> +
> +      Multiple entries may be listed to apply different policies to
> +      different address ranges, including sub-ranges within a single
> +      physical resource.
> +
> +required:
> +  - compatible
> +  - reg
> +  - '#access-controller-cells'
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/interrupt-controller/irq.h>
> +
> +    // Example 1: Single device protection
> +    // WID 0 and WID 3 have RW access to UART; errors and IRQs reported.
> +
> +    cpus {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +        timebase-frequency = <1000000>;
> +        riscv,nworlds = <4>;
> +        sifive,trustedwid = <3>;
> +
> +        cpu@0 {
> +            device_type = "cpu";
> +            reg = <0>;
> +            compatible = "riscv";
> +            riscv,isa = "rv64imac";
> +        };
> +    };
> +
> +    soc {
> +        #address-cells = <2>;
> +        #size-cells = <2>;
> +
> +        uart: uart@1c1000 {
> +            compatible = "ns16550a";
> +            reg = <0x0 0x001c1000 0x0 0x1000>;
> +            reg-names = "control";
> +            interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
> +            // WID 0,3 RW; report errors+IRQs
> +            access-controllers = <&wgchecker0
> +                                  0x0 0x001c1000 0x0 0x00001000
> +                                  0x0 0x000000c3 0x0f>;
> +        };
> +
> +        wgchecker0: wgchecker@1c2000 {

I think this should be access-controller@

> +            compatible = "sifive,wgchecker2";
> +            reg = <0x0 0x001c2000 0x0 0x1000>;
> +            #access-controller-cells = <7>;
> +            interrupts = <80 IRQ_TYPE_LEVEL_HIGH>;
> +            interrupt-parent = <&aplic_m>;
> +        };
> +    };

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [RFC PATCH 2/3] dt-bindings: riscv: Add Worlds per-hart properties

[Yu-Chien Peter Lin]

Hi Conor,

On Mon, Jun 22, 2026 at 06:12:47PM +0100, Conor Dooley wrote:
> On Fri, Jun 19, 2026 at 06:58:33PM +0800, Yu-Chien Peter Lin wrote:
> > Add per-hart DT properties for RISC-V Worlds architecture:
> > riscv,pmwid, riscv,pmwidlist, and riscv,pmlwidlist. These
> > platform-defined values are primarily used by M-mode firmware
> > to configure World ID CSRs and restrict WID usage across
> > privilege levels.
> > 
> > Signed-off-by: Yu-Chien Peter Lin <peter.lin@sifive.com>
> > ---
> >  .../devicetree/bindings/riscv/cpus.yaml       | 21 +++++
> >  .../devicetree/bindings/riscv/worlds.yaml     | 77 +++++++++++++++++++
> >  2 files changed, 98 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/riscv/worlds.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > index 5feeb2203050..4b5778b6d3e7 100644
> > --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> > +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > @@ -26,6 +26,7 @@ description: |
> >  allOf:
> >    - $ref: /schemas/cpu.yaml#
> >    - $ref: extensions.yaml
> > +  - $ref: worlds.yaml
> >    - if:
> >        not:
> >          properties:
> > @@ -120,11 +121,31 @@ properties:
> >        thead systems where the vector register length is not identical on all harts, or
> >        the vlenb CSR is not available.
> >  
> > +  riscv,pmwid:
> > +    $ref: /schemas/types.yaml#/definitions/uint32
> > +    description:
> > +      Platform-defined M-mode World ID (WID) assigned to this hart.
> > +    minimum: 0
> > +    maximum: 63
> > +
> > +  riscv,pmwidlist:
> > +    $ref: /schemas/types.yaml#/definitions/uint64
> > +    description:
> > +      Platform-defined bitmap of M-mode World IDs (WIDs) that this hart may use.
> 
> I don't understand what the difference is between this property and the
> one before it are.
> Is this one meant to be used by m-mode software to then select one which
> will appear in riscv,pmwid?

pmwid (single value) is the reset default, while pmwidlist (bitmap)
defines the allowed set. The root-of-trust M-mode software may select
an allowed value from the pmwidlist and write it to the mwid CSR.

> 
> > +
> > +  riscv,pmlwidlist:
> > +    $ref: /schemas/types.yaml#/definitions/uint64
> > +    description:
> > +      Platform-defined bitmap of World IDs (WIDs) that S-mode and U-mode may use
> > +      on this hart.
> > +
> >    # RISC-V has multiple properties for cache op block sizes as the sizes
> >    # differ between individual CBO extensions
> >    cache-op-block-size: false
> >    # RISC-V requires 'timebase-frequency' in /cpus, so disallow it here
> >    timebase-frequency: false
> 
> > +  # RISC-V requires 'riscv,nworlds' in /cpus, so disallow it here
> > +  riscv,nworlds: false
> 
> Isn't this pointless? Nothing ever defines riscv,nworlds as a cpu level
> property so there's no need to disallow it?

Okay, thanks for the catch, will drop this.

Best regards,
Peter Lin

> 
> >  
> >    interrupt-controller:
> >      type: object
> > diff --git a/Documentation/devicetree/bindings/riscv/worlds.yaml b/Documentation/devicetree/bindings/riscv/worlds.yaml
> > new file mode 100644
> > index 000000000000..cc8b3747591e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/riscv/worlds.yaml
> > @@ -0,0 +1,77 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/riscv/worlds.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: RISC-V Worlds Extension
> > +
> > +maintainers:
> > +  - Yu-Chien Peter Lin <peter.lin@sifive.com>
> > +
> > +description: |
> > +  The RISC-V Worlds ISA extension, as described in the RISC-V Privileged
> > +  Specification, adds World ID tagging for context isolation.
> > +
> > +  This binding describes the system-wide Worlds configuration for the /cpus node
> > +  and is used alongside per-hart Worlds-related properties such as riscv,pmwid in
> > +  the RISC-V CPU binding and Worlds-related ISA extensions enumerated via
> > +  riscv,isa-extensions.
> > +
> > +select:
> > +  properties:
> > +    $nodename:
> > +      pattern: "^cpus$"
> > +
> > +properties:
> > +  riscv,nworlds:
> > +    $ref: /schemas/types.yaml#/definitions/uint32
> > +    description: |
> > +      Number of World IDs (WIDs) supported by the platform. This is a system-wide
> > +      property that describes the total number of isolation contexts available.
> > +      Hardware components such as the WorldGuard Checker use this to determine
> > +      the valid range of WID values.
> > +    minimum: 2
> > +    maximum: 64
> > +
> > +additionalProperties: true
> > +
> > +examples:
> > +  - |
> > +    // Example: System with 4 World IDs
> > +    cpus {
> > +        #address-cells = <1>;
> > +        #size-cells = <0>;
> > +        timebase-frequency = <1000000>;
> > +        riscv,nworlds = <4>;
> > +
> > +        cpu@0 {
> > +            device_type = "cpu";
> > +            reg = <0>;
> > +            compatible = "sifive,bullet0", "riscv";
> > +            riscv,isa-base = "rv64i";
> > +            riscv,isa-extensions = "i", "m", "a", "f", "d", "c";
> > +            riscv,pmwid = <0>;
> > +
> > +            interrupt-controller {
> > +                #interrupt-cells = <1>;
> > +                compatible = "riscv,cpu-intc";
> > +                interrupt-controller;
> > +            };
> > +        };
> > +
> > +        cpu@1 {
> > +            device_type = "cpu";
> > +            reg = <1>;
> > +            compatible = "sifive,bullet0", "riscv";
> > +            riscv,isa-base = "rv64i";
> > +            riscv,isa-extensions = "i", "m", "a", "f", "d", "c";
> > +            riscv,pmwid = <1>;
> > +
> > +            interrupt-controller {
> > +                #interrupt-cells = <1>;
> > +                compatible = "riscv,cpu-intc";
> > +                interrupt-controller;
> > +            };
> > +        };
> > +    };
> > -- 
> > 2.43.7
> > 

Re: [RFC PATCH 2/3] dt-bindings: riscv: Add Worlds per-hart properties

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 2729 bytes --]

On Fri, Jun 26, 2026 at 07:47:31PM +0800, Yu-Chien Peter Lin wrote:
> Hi Conor,
> 
> On Mon, Jun 22, 2026 at 06:12:47PM +0100, Conor Dooley wrote:
> > On Fri, Jun 19, 2026 at 06:58:33PM +0800, Yu-Chien Peter Lin wrote:
> > > Add per-hart DT properties for RISC-V Worlds architecture:
> > > riscv,pmwid, riscv,pmwidlist, and riscv,pmlwidlist. These
> > > platform-defined values are primarily used by M-mode firmware
> > > to configure World ID CSRs and restrict WID usage across
> > > privilege levels.
> > > 
> > > Signed-off-by: Yu-Chien Peter Lin <peter.lin@sifive.com>
> > > ---
> > >  .../devicetree/bindings/riscv/cpus.yaml       | 21 +++++
> > >  .../devicetree/bindings/riscv/worlds.yaml     | 77 +++++++++++++++++++
> > >  2 files changed, 98 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/riscv/worlds.yaml
> > > 
> > > diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > > index 5feeb2203050..4b5778b6d3e7 100644
> > > --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> > > +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > > @@ -26,6 +26,7 @@ description: |
> > >  allOf:
> > >    - $ref: /schemas/cpu.yaml#
> > >    - $ref: extensions.yaml
> > > +  - $ref: worlds.yaml
> > >    - if:
> > >        not:
> > >          properties:
> > > @@ -120,11 +121,31 @@ properties:
> > >        thead systems where the vector register length is not identical on all harts, or
> > >        the vlenb CSR is not available.
> > >  
> > > +  riscv,pmwid:
> > > +    $ref: /schemas/types.yaml#/definitions/uint32
> > > +    description:
> > > +      Platform-defined M-mode World ID (WID) assigned to this hart.
> > > +    minimum: 0
> > > +    maximum: 63
> > > +
> > > +  riscv,pmwidlist:
> > > +    $ref: /schemas/types.yaml#/definitions/uint64
> > > +    description:
> > > +      Platform-defined bitmap of M-mode World IDs (WIDs) that this hart may use.
> > 
> > I don't understand what the difference is between this property and the
> > one before it are.
> > Is this one meant to be used by m-mode software to then select one which
> > will appear in riscv,pmwid?
> 
> pmwid (single value) is the reset default, while pmwidlist (bitmap)
> defines the allowed set. The root-of-trust M-mode software may select
> an allowed value from the pmwidlist and write it to the mwid CSR.

I don't understand the point of the property then. If it is the reset
default, just read it out of the register?
Unless I am missing something, it's useless to s-mode because it may
not be what m-mode chose and useless to m-mode that has access to
the csr.

Cheers,
Conor.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [RFC PATCH 2/3] dt-bindings: riscv: Add Worlds per-hart properties

[Yu-Chien Peter Lin]

Hi Conor,

On Fri, Jun 26, 2026 at 03:36:38PM +0100, Conor Dooley wrote:
> On Fri, Jun 26, 2026 at 07:47:31PM +0800, Yu-Chien Peter Lin wrote:
> > Hi Conor,
> > 
> > On Mon, Jun 22, 2026 at 06:12:47PM +0100, Conor Dooley wrote:
> > > On Fri, Jun 19, 2026 at 06:58:33PM +0800, Yu-Chien Peter Lin wrote:
> > > > Add per-hart DT properties for RISC-V Worlds architecture:
> > > > riscv,pmwid, riscv,pmwidlist, and riscv,pmlwidlist. These
> > > > platform-defined values are primarily used by M-mode firmware
> > > > to configure World ID CSRs and restrict WID usage across
> > > > privilege levels.
> > > > 
> > > > Signed-off-by: Yu-Chien Peter Lin <peter.lin@sifive.com>
> > > > ---
> > > >  .../devicetree/bindings/riscv/cpus.yaml       | 21 +++++
> > > >  .../devicetree/bindings/riscv/worlds.yaml     | 77 +++++++++++++++++++
> > > >  2 files changed, 98 insertions(+)
> > > >  create mode 100644 Documentation/devicetree/bindings/riscv/worlds.yaml
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > > > index 5feeb2203050..4b5778b6d3e7 100644
> > > > --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> > > > +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > > > @@ -26,6 +26,7 @@ description: |
> > > >  allOf:
> > > >    - $ref: /schemas/cpu.yaml#
> > > >    - $ref: extensions.yaml
> > > > +  - $ref: worlds.yaml
> > > >    - if:
> > > >        not:
> > > >          properties:
> > > > @@ -120,11 +121,31 @@ properties:
> > > >        thead systems where the vector register length is not identical on all harts, or
> > > >        the vlenb CSR is not available.
> > > >  
> > > > +  riscv,pmwid:
> > > > +    $ref: /schemas/types.yaml#/definitions/uint32
> > > > +    description:
> > > > +      Platform-defined M-mode World ID (WID) assigned to this hart.
> > > > +    minimum: 0
> > > > +    maximum: 63
> > > > +
> > > > +  riscv,pmwidlist:
> > > > +    $ref: /schemas/types.yaml#/definitions/uint64
> > > > +    description:
> > > > +      Platform-defined bitmap of M-mode World IDs (WIDs) that this hart may use.
> > > 
> > > I don't understand what the difference is between this property and the
> > > one before it are.
> > > Is this one meant to be used by m-mode software to then select one which
> > > will appear in riscv,pmwid?
> > 
> > pmwid (single value) is the reset default, while pmwidlist (bitmap)
> > defines the allowed set. The root-of-trust M-mode software may select
> > an allowed value from the pmwidlist and write it to the mwid CSR.
> 
> I don't understand the point of the property then. If it is the reset
> default, just read it out of the register?
> Unless I am missing something, it's useless to s-mode because it may
> not be what m-mode chose and useless to m-mode that has access to
> the csr.

Smwid is optional. In the no-Smwid case:
- M-mode's WID is fixed to pmwid (hardware-defined via fuse/pinstrap/SoC
  registers, exposed to software via riscv,pmwid DT property)
- S/U-mode's WID depends on opensbi-domain configuration [1]:
  - If next-wid is specified: S/U use that WID (via mlwid CSR)
  - If next-wid is absent   : S/U fall back to pmwid (M/S/U in same
    world)

So riscv,pmwid serves two purpose:
1. Source of truth for M-mode's WID when mwid CSR doesn't exist
2. Fallback value for OpenSBI to write to mlwid when domain config is
   absent.

[1] https://lists.infradead.org/pipermail/opensbi/2026-June/010090.html

Best regards,
Peter Lin

> 
> Cheers,
> Conor.

Re: [RFC PATCH 2/3] dt-bindings: riscv: Add Worlds per-hart properties

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 5425 bytes --]

On Tue, Jun 30, 2026 at 07:11:26PM +0800, Yu-Chien Peter Lin wrote:
> Hi Conor,
> 
> On Fri, Jun 26, 2026 at 03:36:38PM +0100, Conor Dooley wrote:
> > On Fri, Jun 26, 2026 at 07:47:31PM +0800, Yu-Chien Peter Lin wrote:
> > > Hi Conor,
> > > 
> > > On Mon, Jun 22, 2026 at 06:12:47PM +0100, Conor Dooley wrote:
> > > > On Fri, Jun 19, 2026 at 06:58:33PM +0800, Yu-Chien Peter Lin wrote:
> > > > > Add per-hart DT properties for RISC-V Worlds architecture:
> > > > > riscv,pmwid, riscv,pmwidlist, and riscv,pmlwidlist. These
> > > > > platform-defined values are primarily used by M-mode firmware
> > > > > to configure World ID CSRs and restrict WID usage across
> > > > > privilege levels.
> > > > > 
> > > > > Signed-off-by: Yu-Chien Peter Lin <peter.lin@sifive.com>
> > > > > ---
> > > > >  .../devicetree/bindings/riscv/cpus.yaml       | 21 +++++
> > > > >  .../devicetree/bindings/riscv/worlds.yaml     | 77 +++++++++++++++++++
> > > > >  2 files changed, 98 insertions(+)
> > > > >  create mode 100644 Documentation/devicetree/bindings/riscv/worlds.yaml
> > > > > 
> > > > > diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > > > > index 5feeb2203050..4b5778b6d3e7 100644
> > > > > --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> > > > > +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > > > > @@ -26,6 +26,7 @@ description: |
> > > > >  allOf:
> > > > >    - $ref: /schemas/cpu.yaml#
> > > > >    - $ref: extensions.yaml
> > > > > +  - $ref: worlds.yaml
> > > > >    - if:
> > > > >        not:
> > > > >          properties:
> > > > > @@ -120,11 +121,31 @@ properties:
> > > > >        thead systems where the vector register length is not identical on all harts, or
> > > > >        the vlenb CSR is not available.
> > > > >  
> > > > > +  riscv,pmwid:
> > > > > +    $ref: /schemas/types.yaml#/definitions/uint32
> > > > > +    description:
> > > > > +      Platform-defined M-mode World ID (WID) assigned to this hart.
> > > > > +    minimum: 0
> > > > > +    maximum: 63
> > > > > +
> > > > > +  riscv,pmwidlist:
> > > > > +    $ref: /schemas/types.yaml#/definitions/uint64
> > > > > +    description:
> > > > > +      Platform-defined bitmap of M-mode World IDs (WIDs) that this hart may use.
> > > > 
> > > > I don't understand what the difference is between this property and the
> > > > one before it are.
> > > > Is this one meant to be used by m-mode software to then select one which
> > > > will appear in riscv,pmwid?
> > > 
> > > pmwid (single value) is the reset default, while pmwidlist (bitmap)
> > > defines the allowed set. The root-of-trust M-mode software may select
> > > an allowed value from the pmwidlist and write it to the mwid CSR.
> > 
> > I don't understand the point of the property then. If it is the reset
> > default, just read it out of the register?
> > Unless I am missing something, it's useless to s-mode because it may
> > not be what m-mode chose and useless to m-mode that has access to
> > the csr.
> 
> Smwid is optional. In the no-Smwid case:
> - M-mode's WID is fixed to pmwid (hardware-defined via fuse/pinstrap/SoC
>   registers, exposed to software via riscv,pmwid DT property)
> - S/U-mode's WID depends on opensbi-domain configuration [1]:
>   - If next-wid is specified: S/U use that WID (via mlwid CSR)
>   - If next-wid is absent   : S/U fall back to pmwid (M/S/U in same
>     world)
> 
> So riscv,pmwid serves two purpose:
> 1. Source of truth for M-mode's WID when mwid CSR doesn't exist
> 2. Fallback value for OpenSBI to write to mlwid when domain config is
>    absent.

So it is not the default at reset at all then. The reset default is
something else entirely and this is used to overwrite that.

> - M-mode's WID is fixed to pmwid (hardware-defined via fuse/pinstrap/SoC
>   registers, exposed to software via riscv,pmwid DT property)

In this case, it seems like pmwidlist would just contain a single entry,
and there is no need for pwmid.

Quite frankly, it seems like you need to decouple these properties from
being 1:1 mappings to your extension's CSRs and both name and explain
how they are to be used by software.

For example, how is software to treat the value in riscv,pwmid when
Smwid is enabled? Must it be the same value? Is riscv,pwmidlist useless
in that scenario as a result and should not be populated? Should
riscv,pwmid not be used if Smwid is enabled?

There's a lot of extensions defined in this series, and there's no
clarity on how these properties behave depending on what's enabled in
the binding. There must be.

> - S/U-mode's WID depends on opensbi-domain configuration [1]:
>   - If next-wid is specified: S/U use that WID (via mlwid CSR)
>   - If next-wid is absent   : S/U fall back to pmwid (M/S/U in same
>     world)
> 
> So riscv,pmwid serves two purpose:
> 1. Source of truth for M-mode's WID when mwid CSR doesn't exist
> 2. Fallback value for OpenSBI to write to mlwid when domain config is
>    absent.

Again same point applies here, why can a single-entry riscv,pmwidlist
not suffice here?
Additionally, if it cannot, you may need to introduce mutual exclusion
and the relevant extensions because it doesn't seem like in your current
design that the two properties are intended to co-exist.

Cheers,
Conor.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]