On 2/9/26 21:58, Jim Shu wrote:
RISC-V WorldGuard [1] will add 5-bit world_id (WID) to the each memory
transaction on the bus. The wgChecker in front of RAM or peripherals
MMIO could do the access control based on the WID. It is similar to ARM
TrustZone NS bit, but the WID is a 5-bit value.
WID is usually implemented in AXI AxUSER signal (user-defined signals)
in the AXI transaction. As we have a secure bit in MemTxAttrs to emulate
the TrustZone NS bit, which is implemented in AXI AxPROT[1] signal,
I'd like to propose to add world_id field into MemTxAttrs struct.
Since the '_reserved*' fields in MemTxAttr are for padding the struct
to be 8-byte [2], we change the reserved fields from 3 to 2 bytes when
adding 5-bit world_id field.
[1] RISC-V WG:
https://patchew.org/QEMU/[email protected]/
[2] Commit 5014e33b1e00d330f13df33c09a3932ac88f8d94
Link: https://lore.kernel.org/r/[email protected]
Cc: Paolo Bonzini <[email protected]>
Cc: Peter Xu <[email protected]>
Cc: Philippe Mathieu-Daudé <[email protected]>
Cc: Richard Henderson <[email protected]>
Cc: Daniel Henrique Barboza <[email protected]>
Signed-off-by: Jim Shu <[email protected]>
---
include/exec/memattrs.h | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/include/exec/memattrs.h b/include/exec/memattrs.h
index 52ee9552491..6bde90d482f 100644
--- a/include/exec/memattrs.h
+++ b/include/exec/memattrs.h
@@ -57,6 +57,11 @@ typedef struct MemTxAttrs {
/* PCI - IOMMU operations, see PCIAddressType */
unsigned int address_type:1;
+ /*
+ * RISC-V WorldGuard: the 5-bit WID field of memory access.
+ */
+ unsigned int world_id:5;
+
/*
* Bus masters which don't specify any attributes will get this
* (via the MEMTXATTRS_UNSPECIFIED constant), so that we can
@@ -66,8 +71,7 @@ typedef struct MemTxAttrs {
*/
bool unspecified;
- uint8_t _reserved1;
- uint16_t _reserved2;
+ uint16_t _reserved1;
} MemTxAttrs;
Hmm. This really overlaps the secure and space fields from arm, and possibly some of the
others as well (e.g. user, requester_id, pid).
I don't really have a good suggestion for that right now, but it would be nice to not keep
expanding the count of these sorts of fields that somehow specify the originator, but
clearly cannot overlap.
I'm reasonably sure we've had this discussion before, but nothing has come of
it.
Time to paint the bikeshed again?
r~