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

Philippe Mathieu-Daudé <[email protected]> writes:

> 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/
>
> (see also a suggestion in
> https://lore.kernel.org/qemu-devel/[email protected]/)

Also somewhat related:

  Message-Id: <[email protected]>
  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