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=e2xjyxamtgo3z6q6dhgqka...@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 > >
