CC: [email protected]
On Wed, Jul 15, 2026 at 5:57 PM Peter Maydell <[email protected]> wrote: > > On Wed, 15 Jul 2026 at 07:52, Jim Shu <[email protected]> wrote: > > > > 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'. > > 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
