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

Hi all,

I'd like to discuss this issue again.

On Wed, Mar 18, 2026 at 2:42 PM Philippe Mathieu-Daudé <[email protected]>
wrote:

> On 18/3/26 05:40, Jim Shu wrote:
> > On Tue, Feb 10, 2026 at 8:25 AM Richard Henderson
> > <[email protected]> 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/[email protected]/)
>
> >>
> >
> > 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
>
>