[PATCH] exec: Add RISC-V WorldGuard WID field to MemTxAttrs

[PATCH] exec: Add RISC-V WorldGuard WID field to MemTxAttrs

[Jim Shu]

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/20251021155548.584543-1-jim.shu@sifive.com/

[2] Commit 5014e33b1e00d330f13df33c09a3932ac88f8d94
    Link: https://lore.kernel.org/r/20250121151322.171832-2-zhao1.liu@intel.com

Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Xu <peterx@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@linaro.org>
Cc: Richard Henderson <richard.henderson@linaro.org>
Cc: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Signed-off-by: Jim Shu <jim.shu@sifive.com>
---
 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;
 
 QEMU_BUILD_BUG_ON(sizeof(MemTxAttrs) > 8);
-- 
2.43.0

Re: [PATCH] exec: Add RISC-V WorldGuard WID field to MemTxAttrs

[Richard Henderson]

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/20251021155548.584543-1-jim.shu@sifive.com/
> 
> [2] Commit 5014e33b1e00d330f13df33c09a3932ac88f8d94
>      Link: https://lore.kernel.org/r/20250121151322.171832-2-zhao1.liu@intel.com
> 
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Peter Xu <peterx@redhat.com>
> Cc: Philippe Mathieu-Daudé <philmd@linaro.org>
> Cc: Richard Henderson <richard.henderson@linaro.org>
> Cc: Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
> Signed-off-by: Jim Shu <jim.shu@sifive.com>
> ---
>   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~

Re: [PATCH] exec: Add RISC-V WorldGuard WID field to MemTxAttrs

[Jim Shu]

On Tue, Feb 10, 2026 at 8:25 AM Richard Henderson
<richard.henderson@linaro.org> wrote:
...
> 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?
>

I can union the 'secure' and 'world_id' fields, as they are not used together.
However, I have no idea about the 'space' fields.

I have seen CPUTLBEntryFull has the extra union to support ARM-specific members.
Another idea is that also adding the extra union to MemTxAttrs to
place the RISC-V worid_id.
We can use this extra union to as SoC-specific signals in the bus,
like AXI AxUSER signal.
Do you think it is suitable?


Thanks,

Jim

Re: [PATCH] exec: Add RISC-V WorldGuard WID field to MemTxAttrs

[Philippe Mathieu-Daudé]

On 18/3/26 05:40, Jim Shu wrote:
> On Tue, Feb 10, 2026 at 8:25 AM Richard Henderson
> <richard.henderson@linaro.org> wrote:
> ...
>> 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?

Last discussion IIRC:
https://lore.kernel.org/qemu-devel/CAFEAcA8vKNkfKgp_Yymo9NA1=E2XJYXAMTgO3z6q6DHgqkAwRw@mail.gmail.com/

(see also a suggestion in 
https://lore.kernel.org/qemu-devel/Z4+P3eHXqcU4Dqdx@intel.com/)

>>
> 
> I can union the 'secure' and 'world_id' fields, as they are not used together.
> However, I have no idea about the 'space' fields.
> 
> I have seen CPUTLBEntryFull has the extra union to support ARM-specific members.
> Another idea is that also adding the extra union to MemTxAttrs to
> place the RISC-V worid_id.
> We can use this extra union to as SoC-specific signals in the bus,
> like AXI AxUSER signal.
> Do you think it is suitable?
> 
> 
> Thanks,
> 
> Jim

Re: [PATCH] exec: Add RISC-V WorldGuard WID field to MemTxAttrs

[Jim Shu]

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

Hi all,

I'd like to discuss this issue again.

On Wed, Mar 18, 2026 at 2:42 PM Philippe Mathieu-Daudé <philmd@linaro.org>
wrote:

> On 18/3/26 05:40, Jim Shu wrote:
> > On Tue, Feb 10, 2026 at 8:25 AM Richard Henderson
> > <richard.henderson@linaro.org> wrote:
> > ...
> >> 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?
>
> Last discussion IIRC:
>
> https://lore.kernel.org/qemu-devel/CAFEAcA8vKNkfKgp_Yymo9NA1=E2XJYXAMTgO3z6q6DHgqkAwRw@mail.gmail.com/
>

Follow the idea in the above thread. I'd plan to add the 'src_cpu_id' field
to 'MemTxAttr', so we can get the CPUState from MemTxAttr. Thus, we can
retrieve the RISC-V world_id from CPU and we don't need to add world_id to
'MemTxAttr'. If other security attributes are stored in CPU states, they
can also reuse this w/o adding more data to 'MemTxAttr'.

The whole plan is to add the following 2 fields
::
    unsigned int src_is_cpu:1;
    uint16_t src_cpu_id;

src_cpu_id is the CPU ID from 'CPUState->cpu_index'. src_is_cpu is a
boolean flag to check if the transaction is from CPU.

Moreover, I think this idea is extensible. DMA device transactions can also
have security attributes like world_id. We can also add src_device field to
'MemTxAttr' to store the 'DeviceState *', so we can get the DeviceState
from MemTxAttr to get security attributes. If 'DeviceState *' is too large
to add to 'MemTxAttr', re-use requester_id as DMA device ID is another
possible method to support this.
(p.s. DMA transactions world_id is NOT covered by my current patchset. I
just explain this concept for the discussion.)

Does anyone think it is an acceptable plan? Any feedback is welcome.

In the next series, I will implement this plan to add the cpu_id instead of
world_id if there is no problem about it.


Regards,
Jim



> (see also a suggestion in
> https://lore.kernel.org/qemu-devel/Z4+P3eHXqcU4Dqdx@intel.com/)
>
> >>
> >
> > I can union the 'secure' and 'world_id' fields, as they are not used
> together.
> > However, I have no idea about the 'space' fields.
> >
> > I have seen CPUTLBEntryFull has the extra union to support ARM-specific
> members.
> > Another idea is that also adding the extra union to MemTxAttrs to
> > place the RISC-V worid_id.
> > We can use this extra union to as SoC-specific signals in the bus,
> > like AXI AxUSER signal.
> > Do you think it is suitable?
> >
> >
> > Thanks,
> >
> > Jim
>
>

[-- Attachment #2: Type: text/html, Size: 5346 bytes --]

Re: [PATCH] exec: Add RISC-V WorldGuard WID field to MemTxAttrs

[Peter Maydell]

On Wed, 15 Jul 2026 at 07:52, Jim Shu <jim.shu@sifive.com> wrote:
>
> Hi all,
>
> I'd like to discuss this issue again.
>
> On Wed, Mar 18, 2026 at 2:42 PM Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
>>
>> On 18/3/26 05:40, Jim Shu wrote:
>> > On Tue, Feb 10, 2026 at 8:25 AM Richard Henderson
>> > <richard.henderson@linaro.org> wrote:
>> > ...
>> >> 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?
>>
>> Last discussion IIRC:
>> https://lore.kernel.org/qemu-devel/CAFEAcA8vKNkfKgp_Yymo9NA1=E2XJYXAMTgO3z6q6DHgqkAwRw@mail.gmail.com/
>
>
> Follow the idea in the above thread. I'd plan to add the 'src_cpu_id' field to 'MemTxAttr', so we can get the CPUState from MemTxAttr. Thus, we can retrieve the RISC-V world_id from CPU and we don't need to add world_id to 'MemTxAttr'. If other security attributes are stored in CPU states, they can also reuse this w/o adding more data to 'MemTxAttr'.

We already have a requester_id field, which is basically
"what is the thing that is sending this request?". We
shouldn't have memory transactions that happen to be
from CPUs indicate the source in a totally different way.

> The whole plan is to add the following 2 fields
> ::
>     unsigned int src_is_cpu:1;
>     uint16_t src_cpu_id;
>
> src_cpu_id is the CPU ID from 'CPUState->cpu_index'. src_is_cpu is a boolean flag to check if the transaction is from CPU.
>
> Moreover, I think this idea is extensible. DMA device transactions can also have security attributes like world_id. We can also add src_device field to 'MemTxAttr' to store the 'DeviceState *', so we can get the DeviceState from MemTxAttr to get security attributes. If 'DeviceState *' is too large to add to 'MemTxAttr', re-use requester_id as DMA device ID is another possible method to support this.

I don't think that having the thing that receives the memory
transaction get or get hold of a pointer to the source of the
transaction that it then uses to get the world ID is a good idea.
(Especially not putting a DeviceState* into MemTxAttrs: the
size of the type needs to be kept small so we can conveniently
pass it around by value: we currently assert that it is 8 bytes.)

I think we would do better to follow the way the hardware does
this to the extent that that's reasonable. On hardware the
bus/fabric is going to provide the world ID as a signal along
with the memory transaction, and we should accordingly put
it into the MemTxAttrs. The question for QEMU is then how
we organize our MemTxAttrs fields so that we can share between
different architectures the fields that are basically doing a
similar job, just with different terminology or semantics,
so that we keep the overall size of the type small.

thanks
-- PMM

Re: [PATCH] exec: Add RISC-V WorldGuard WID field to MemTxAttrs

[Jim Shu]

CC: philmd@mailo.com




On Wed, Jul 15, 2026 at 5:57 PM Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Wed, 15 Jul 2026 at 07:52, Jim Shu <jim.shu@sifive.com> wrote:
> >
> > Hi all,
> >
> > I'd like to discuss this issue again.
> >
> > On Wed, Mar 18, 2026 at 2:42 PM Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
> >>
> >> On 18/3/26 05:40, Jim Shu wrote:
> >> > On Tue, Feb 10, 2026 at 8:25 AM Richard Henderson
> >> > <richard.henderson@linaro.org> wrote:
> >> > ...
> >> >> 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?
> >>
> >> Last discussion IIRC:
> >> https://lore.kernel.org/qemu-devel/CAFEAcA8vKNkfKgp_Yymo9NA1=E2XJYXAMTgO3z6q6DHgqkAwRw@mail.gmail.com/
> >
> >
> > Follow the idea in the above thread. I'd plan to add the 'src_cpu_id' field to 'MemTxAttr', so we can get the CPUState from MemTxAttr. Thus, we can retrieve the RISC-V world_id from CPU and we don't need to add world_id to 'MemTxAttr'. If other security attributes are stored in CPU states, they can also reuse this w/o adding more data to 'MemTxAttr'.
>
> We already have a requester_id field, which is basically
> "what is the thing that is sending this request?". We
> shouldn't have memory transactions that happen to be
> from CPUs indicate the source in a totally different way.
>
> > The whole plan is to add the following 2 fields
> > ::
> >     unsigned int src_is_cpu:1;
> >     uint16_t src_cpu_id;
> >
> > src_cpu_id is the CPU ID from 'CPUState->cpu_index'. src_is_cpu is a boolean flag to check if the transaction is from CPU.
> >
> > Moreover, I think this idea is extensible. DMA device transactions can also have security attributes like world_id. We can also add src_device field to 'MemTxAttr' to store the 'DeviceState *', so we can get the DeviceState from MemTxAttr to get security attributes. If 'DeviceState *' is too large to add to 'MemTxAttr', re-use requester_id as DMA device ID is another possible method to support this.
>
> I don't think that having the thing that receives the memory
> transaction get or get hold of a pointer to the source of the
> transaction that it then uses to get the world ID is a good idea.
> (Especially not putting a DeviceState* into MemTxAttrs: the
> size of the type needs to be kept small so we can conveniently
> pass it around by value: we currently assert that it is 8 bytes.)
>
> I think we would do better to follow the way the hardware does
> this to the extent that that's reasonable. On hardware the
> bus/fabric is going to provide the world ID as a signal along
> with the memory transaction, and we should accordingly put
> it into the MemTxAttrs. The question for QEMU is then how
> we organize our MemTxAttrs fields so that we can share between
> different architectures the fields that are basically doing a
> similar job, just with different terminology or semantics,
> so that we keep the overall size of the type small.
>
> thanks
> -- PMM

Re: [PATCH] exec: Add RISC-V WorldGuard WID field to MemTxAttrs

[Jim Shu]

On Thu, Jul 16, 2026 at 10:47 AM Jim Shu <jim.shu@sifive.com> wrote:
>
> CC: philmd@mailo.com
>
>
>
>
> On Wed, Jul 15, 2026 at 5:57 PM Peter Maydell <peter.maydell@linaro.org> wrote:
> >
> > On Wed, 15 Jul 2026 at 07:52, Jim Shu <jim.shu@sifive.com> wrote:
> > >
> > > Hi all,
> > >
> > > I'd like to discuss this issue again.
> > >
> > > On Wed, Mar 18, 2026 at 2:42 PM Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
> > >>
> > >> On 18/3/26 05:40, Jim Shu wrote:
> > >> > On Tue, Feb 10, 2026 at 8:25 AM Richard Henderson
> > >> > <richard.henderson@linaro.org> wrote:
> > >> > ...
> > >> >> 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?
> > >>
> > >> Last discussion IIRC:
> > >> https://lore.kernel.org/qemu-devel/CAFEAcA8vKNkfKgp_Yymo9NA1=E2XJYXAMTgO3z6q6DHgqkAwRw@mail.gmail.com/
> > >
> > >
> > > Follow the idea in the above thread. I'd plan to add the 'src_cpu_id' field to 'MemTxAttr', so we can get the CPUState from MemTxAttr. Thus, we can retrieve the RISC-V world_id from CPU and we don't need to add world_id to 'MemTxAttr'. If other security attributes are stored in CPU states, they can also reuse this w/o adding more data to 'MemTxAttr'.
> >
> > We already have a requester_id field, which is basically
> > "what is the thing that is sending this request?". We
> > shouldn't have memory transactions that happen to be
> > from CPUs indicate the source in a totally different way.

Thanks for mentioning it! I think re-use requester_id is better.
Then, I think we only need a boolean flag `src_is_cpu` and we can
rename it to `requester_is_cpu` to match the naming of `requester_id`.

> >
> > > The whole plan is to add the following 2 fields
> > > ::
> > >     unsigned int src_is_cpu:1;
> > >     uint16_t src_cpu_id;
> > >
> > > src_cpu_id is the CPU ID from 'CPUState->cpu_index'. src_is_cpu is a boolean flag to check if the transaction is from CPU.
> > >
> > > Moreover, I think this idea is extensible. DMA device transactions can also have security attributes like world_id. We can also add src_device field to 'MemTxAttr' to store the 'DeviceState *', so we can get the DeviceState from MemTxAttr to get security attributes. If 'DeviceState *' is too large to add to 'MemTxAttr', re-use requester_id as DMA device ID is another possible method to support this.
> >
> > I don't think that having the thing that receives the memory
> > transaction get or get hold of a pointer to the source of the
> > transaction that it then uses to get the world ID is a good idea.
> > (Especially not putting a DeviceState* into MemTxAttrs: the
> > size of the type needs to be kept small so we can conveniently
> > pass it around by value: we currently assert that it is 8 bytes.)

OK, I think store the DMA device ID in the `requester_id` is another
way to keep the small size.
However, IIUC, the current SysbusDevice doesn't have the concept of a
device ID. We need to add an additional device ID to the device to
support this idea.

> >
> > I think we would do better to follow the way the hardware does
> > this to the extent that that's reasonable. On hardware the
> > bus/fabric is going to provide the world ID as a signal along
> > with the memory transaction, and we should accordingly put
> > it into the MemTxAttrs. The question for QEMU is then how
> > we organize our MemTxAttrs fields so that we can share between
> > different architectures the fields that are basically doing a
> > similar job, just with different terminology or semantics,
> > so that we keep the overall size of the type small.

OK. if we prefer to keep world_id / secure / space bits in MemTxAttrs
and conbine them together for smaller size instead of adding cpu_id, I
will try to plan for it.
Thanks for the feedback!


> >
> > thanks
> > -- PMM


Thanks
Jim

Re: [PATCH] exec: Add RISC-V WorldGuard WID field to MemTxAttrs

[Peter Maydell]

On Thu, 16 Jul 2026 at 04:12, Jim Shu <jim.shu@sifive.com> wrote:
>
> On Thu, Jul 16, 2026 at 10:47 AM Jim Shu <jim.shu@sifive.com> wrote:
> >
> > CC: philmd@mailo.com
> >
> >
> >
> >
> > On Wed, Jul 15, 2026 at 5:57 PM Peter Maydell <peter.maydell@linaro.org> wrote:
> > >
> > > On Wed, 15 Jul 2026 at 07:52, Jim Shu <jim.shu@sifive.com> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > I'd like to discuss this issue again.
> > > >
> > > > On Wed, Mar 18, 2026 at 2:42 PM Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
> > > >>
> > > >> On 18/3/26 05:40, Jim Shu wrote:
> > > >> > On Tue, Feb 10, 2026 at 8:25 AM Richard Henderson
> > > >> > <richard.henderson@linaro.org> wrote:
> > > >> > ...
> > > >> >> 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?
> > > >>
> > > >> Last discussion IIRC:
> > > >> https://lore.kernel.org/qemu-devel/CAFEAcA8vKNkfKgp_Yymo9NA1=E2XJYXAMTgO3z6q6DHgqkAwRw@mail.gmail.com/
> > > >
> > > >
> > > > Follow the idea in the above thread. I'd plan to add the 'src_cpu_id' field to 'MemTxAttr', so we can get the CPUState from MemTxAttr. Thus, we can retrieve the RISC-V world_id from CPU and we don't need to add world_id to 'MemTxAttr'. If other security attributes are stored in CPU states, they can also reuse this w/o adding more data to 'MemTxAttr'.
> > >
> > > We already have a requester_id field, which is basically
> > > "what is the thing that is sending this request?". We
> > > shouldn't have memory transactions that happen to be
> > > from CPUs indicate the source in a totally different way.
>
> Thanks for mentioning it! I think re-use requester_id is better.
> Then, I think we only need a boolean flag `src_is_cpu` and we can
> rename it to `requester_is_cpu` to match the naming of `requester_id`.

But, what do you now want it for? If we put the world ID in the
MemTxAttrs, do you still need a CPU ID? (There are some situations
where it might be useful, but if we don't need it right now we
shouldn't put doing that rework in the path of implementing
the worldguard work you want to do.)

> > > > The whole plan is to add the following 2 fields
> > > > ::
> > > >     unsigned int src_is_cpu:1;
> > > >     uint16_t src_cpu_id;
> > > >
> > > > src_cpu_id is the CPU ID from 'CPUState->cpu_index'. src_is_cpu is a boolean flag to check if the transaction is from CPU.
> > > >
> > > > Moreover, I think this idea is extensible. DMA device transactions can also have security attributes like world_id. We can also add src_device field to 'MemTxAttr' to store the 'DeviceState *', so we can get the DeviceState from MemTxAttr to get security attributes. If 'DeviceState *' is too large to add to 'MemTxAttr', re-use requester_id as DMA device ID is another possible method to support this.
> > >
> > > I don't think that having the thing that receives the memory
> > > transaction get or get hold of a pointer to the source of the
> > > transaction that it then uses to get the world ID is a good idea.
> > > (Especially not putting a DeviceState* into MemTxAttrs: the
> > > size of the type needs to be kept small so we can conveniently
> > > pass it around by value: we currently assert that it is 8 bytes.)
>
> OK, I think store the DMA device ID in the `requester_id` is another
> way to keep the small size.
> However, IIUC, the current SysbusDevice doesn't have the concept of a
> device ID. We need to add an additional device ID to the device to
> support this idea.

What exactly is it that you need a device ID for? Earlier you
suggest that you would want it to get the world ID -- but we
should just put the world ID directly in the MemTxAttrs.

thanks
-- PMM

Re: [PATCH] exec: Add RISC-V WorldGuard WID field to MemTxAttrs

[Alex Bennée]

Philippe Mathieu-Daudé <philmd@linaro.org> writes:

> On 18/3/26 05:40, Jim Shu wrote:
>> On Tue, Feb 10, 2026 at 8:25 AM Richard Henderson
>> <richard.henderson@linaro.org> wrote:
>> ...
>>> 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?
>
> Last discussion IIRC:
> https://lore.kernel.org/qemu-devel/CAFEAcA8vKNkfKgp_Yymo9NA1=E2XJYXAMTgO3z6q6DHgqkAwRw@mail.gmail.com/
>
> (see also a suggestion in
> https://lore.kernel.org/qemu-devel/Z4+P3eHXqcU4Dqdx@intel.com/)

Also somewhat related:

  Message-Id: <20221111182535.64844-1-alex.bennee@linaro.org>
  Date: Fri, 11 Nov 2022 18:25:15 +0000
  Subject: [PATCH for 8.0 v5 00/20] use MemTxAttrs to avoid current_cpu in hw/

Another case that was mentioned in a Core Collective meeting was
handling MMIO devices with IOMMUs (currently requester_id is tied to
PCI). I guess the WorldGuard WID field is a similar thing.

>
>>>
>> I can union the 'secure' and 'world_id' fields, as they are not used
>> together.
>> However, I have no idea about the 'space' fields.
>> I have seen CPUTLBEntryFull has the extra union to support
>> ARM-specific members.
>> Another idea is that also adding the extra union to MemTxAttrs to
>> place the RISC-V worid_id.
>> We can use this extra union to as SoC-specific signals in the bus,
>> like AXI AxUSER signal.
>> Do you think it is suitable?
>> Thanks,
>> Jim

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH] exec: Add RISC-V WorldGuard WID field to MemTxAttrs

[Peter Maydell]

On Fri, 17 Jul 2026 at 11:08, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> Philippe Mathieu-Daudé <philmd@linaro.org> writes:
>
> > On 18/3/26 05:40, Jim Shu wrote:
> >> On Tue, Feb 10, 2026 at 8:25 AM Richard Henderson
> >> <richard.henderson@linaro.org> wrote:
> >> ...
> >>> 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?
> >
> > Last discussion IIRC:
> > https://lore.kernel.org/qemu-devel/CAFEAcA8vKNkfKgp_Yymo9NA1=E2XJYXAMTgO3z6q6DHgqkAwRw@mail.gmail.com/
> >
> > (see also a suggestion in
> > https://lore.kernel.org/qemu-devel/Z4+P3eHXqcU4Dqdx@intel.com/)
>
> Also somewhat related:
>
>   Message-Id: <20221111182535.64844-1-alex.bennee@linaro.org>
>   Date: Fri, 11 Nov 2022 18:25:15 +0000
>   Subject: [PATCH for 8.0 v5 00/20] use MemTxAttrs to avoid current_cpu in hw/
>
> Another case that was mentioned in a Core Collective meeting was
> handling MMIO devices with IOMMUs (currently requester_id is tied to
> PCI). I guess the WorldGuard WID field is a similar thing.

The worldguard ID is more like the Arm security space field, as I
understand it -- it encodes what the request should or should
not be able to access, and multiple different transaction masters
might be able to send with the same worldguard ID. A requester_id
on the other hand is intended to identify a unique sender.
(In AXI these things turn up in different signals.)

I think the trick with requester_id is that we need to identify
what we need to encode here and make sure we don't confuse things.
(e.g. a CPU needs to not be able to emit something that looks like
a PCI request by accident, because some devices need to be able
to tell "this really did come from a PCI device" from "this is a
CPU doing a normal load/store insn"). So we probably want some
kind of "this is what the requester_id is" enum rather than just
a convention.

thanks
-- PMM

Re: [PATCH] exec: Add RISC-V WorldGuard WID field to MemTxAttrs

[Alex Bennée]

Peter Maydell <peter.maydell@linaro.org> writes:

> On Fri, 17 Jul 2026 at 11:08, Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>> Philippe Mathieu-Daudé <philmd@linaro.org> writes:
>>
>> > On 18/3/26 05:40, Jim Shu wrote:
>> >> On Tue, Feb 10, 2026 at 8:25 AM Richard Henderson
>> >> <richard.henderson@linaro.org> wrote:
>> >> ...
>> >>> 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?
>> >
>> > Last discussion IIRC:
>> > https://lore.kernel.org/qemu-devel/CAFEAcA8vKNkfKgp_Yymo9NA1=E2XJYXAMTgO3z6q6DHgqkAwRw@mail.gmail.com/
>> >
>> > (see also a suggestion in
>> > https://lore.kernel.org/qemu-devel/Z4+P3eHXqcU4Dqdx@intel.com/)
>>
>> Also somewhat related:
>>
>>   Message-Id: <20221111182535.64844-1-alex.bennee@linaro.org>
>>   Date: Fri, 11 Nov 2022 18:25:15 +0000
>>   Subject: [PATCH for 8.0 v5 00/20] use MemTxAttrs to avoid current_cpu in hw/
>>
>> Another case that was mentioned in a Core Collective meeting was
>> handling MMIO devices with IOMMUs (currently requester_id is tied to
>> PCI). I guess the WorldGuard WID field is a similar thing.
>
> The worldguard ID is more like the Arm security space field, as I
> understand it -- it encodes what the request should or should
> not be able to access, and multiple different transaction masters
> might be able to send with the same worldguard ID. A requester_id
> on the other hand is intended to identify a unique sender.
> (In AXI these things turn up in different signals.)
>
> I think the trick with requester_id is that we need to identify
> what we need to encode here and make sure we don't confuse things.
> (e.g. a CPU needs to not be able to emit something that looks like
> a PCI request by accident, because some devices need to be able
> to tell "this really did come from a PCI device" from "this is a
> CPU doing a normal load/store insn"). So we probably want some
> kind of "this is what the requester_id is" enum rather than just
> a convention.

Yeah I had a type:

  /**
   * typedef MemTxRequesterType - source of memory transaction
   *
   * Every memory transaction comes from a specific place which defines
   * how requester_id should be handled if at all.
   *
   * UNSPECIFIED: the default for otherwise undefined MemTxAttrs
   * CPU: requester_id is the global cpu_index
   *      This needs further processing if you need to work out which
   *      socket or complex it comes from
   * PCI: indicates the requester_id is a PCI id
   * MACHINE: indicates a machine specific encoding
   *          This will require further processing to decode into its
   *          constituent parts.
   */
  typedef enum MemTxRequesterType {
      MTRT_UNSPECIFIED = 0,
      MTRT_CPU,
      MTRT_PCI,
      MTRT_MACHINE
  } MemTxRequesterType;

  /**
   * typedef MemTxAttrs - attributes of a memory transaction
   *
   * Every memory transaction has associated with it a set of
   * attributes. Some of these are generic (such as the ID of
   * the bus master); some are specific to a particular kind of
   * bus (such as the ARM Secure/NonSecure bit). We define them
   * all as non-overlapping bitfields in a single struct to avoid
   * confusion if different parts of QEMU used the same bit for
   * different semantics.
   */
  typedef struct MemTxAttrs {
      /* Requester type (e.g. CPU or PCI MSI) */
      MemTxRequesterType requester_type:2;
      /* Requester ID */
      unsigned int requester_id:16;
      /*
       * ARM/AMBA: TrustZone Secure access
       * x86: System Management Mode access
       */
      unsigned int secure:1;
      /*
       * ARM: ArmSecuritySpace.  This partially overlaps secure, but it is
       * easier to have both fields to assist code that does not understand
       * ARMv9 RME, or no specific knowledge of ARM at all (e.g. pflash).
       */
      unsigned int space:2;
      /* Memory access is usermode (unprivileged) */
      unsigned int user:1;
      /*
       * Bus interconnect and peripherals can access anything (memories,
       * devices) by default. By setting the 'memory' bit, bus transaction
       * are restricted to "normal" memories (per the AMBA documentation)
       * versus devices. Access to devices will be logged and rejected
       * (see MEMTX_ACCESS_ERROR).
       */
      unsigned int memory:1;
      /* Debug access that can even write to ROM. */
      unsigned int debug:1;
      /*
       * PID (PCI PASID) support: Limited to 8 bits process identifier.
       */
      unsigned int pid:8;

      /* PCI - IOMMU operations, see PCIAddressType */
      unsigned int address_type:1;

      uint8_t _reserved1;
      uint16_t _reserved2;
  } MemTxAttrs;

But I suspect MTRT_MACHINE might be a bit too much of a blunt
instrument. I never used in my series but the idea is it would call back
to the machine to work out how it interpreted requester_id.

>
> thanks
> -- PMM

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro