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