On Wed, 14 Sept 2022 at 17:50, Alex Bennée <alex.ben...@linaro.org> wrote: > > We currently have hacks across the hw/ to reference current_cpu to > work out what the current accessing CPU is. This breaks in some cases > including using gdbstub to access HW state. As we have MemTxAttrs to > describe details about the access lets extend it to mention if this is > a CPU access and which one it is. > > There are a number of places we need to fix up including: > > CPU helpers directly calling address_space_*() fns > models in hw/ fishing the data out of current_cpu > > I'll start addressing some of these in following patches.
> diff --git a/include/exec/memattrs.h b/include/exec/memattrs.h > index 9fb98bc1ef..3bccd5d291 100644 > --- a/include/exec/memattrs.h > +++ b/include/exec/memattrs.h > @@ -43,7 +43,9 @@ typedef struct MemTxAttrs { > * (see MEMTX_ACCESS_ERROR). > */ > unsigned int memory:1; > - /* Requester ID (for MSI for example) */ > + /* Requester is CPU (or as CPU, e.g. debug) */ > + unsigned int requester_cpu:1; > + /* Requester ID (for MSI for example) or cpu_index */ > unsigned int requester_id:16; This defines effectively two uses for requester_id, with a bool field differentiating between them, but the patch doesn't change any of the places that are currently using requester_id on the assumption that it's the MSI PCI ID to check that it's not actually a CPU ID instead. (Generally you don't want the guest CPU to be able to masquerade as a PCI device...) Also, I think we should look at how this is usually done in hardware. I'm pretty sure that in AXI, for instance, CPUs are not special -- every device that can generate memory transactions can specify an ID (and it's up to the SoC/system config to assign them sensibly.) -- PMM