On Thu, Mar 24, 2022 at 7:52 PM Peter Maydell <peter.mayd...@linaro.org> wrote: > > On Thu, 24 Mar 2022 at 10:33, Alex Bennée <alex.ben...@linaro.org> wrote: > > I think we need to not use cpu_physical_memory_write (which is > > explicitly the system address space) but have a function that takes cpu > > so it can work out the correct address space to you > > address_space_read/write. If null we could probably reasonably use > > first_cpu as an approximation. > > It's not sufficient to use address_space_read/write, because the > devices in question are written to figure out the accessing CPU > using current_cpu, not by having different MemoryRegions in the > different per-CPU AddressSpaces. (You can see this because the bug > is present in the common "gdb gives us a virtual address" case which > goes via cpu_memory_rw_debug() and does thus use address_space_read(), > not only in the oddball 'treat addresses from gdb as physaddrs' case.) > > If we want to fix this without setting current_cpu, then we need to > rewrite these devices not to be accessing it, which we could do > in one of two ways: > * have the devices arrange to put different MRs in the ASes > for each CPU (this is possible today but a massive pain as > it would likely involve restructuring a lot of board and > SoC level code) > * have the MemTxAttrs tell the device what the accessing CPU is > (probably by extending the requester_id field); this is > somewhat analogous to how it happens in some cases on real > hardware, where the AXI bus signals include an ID field > indicating what initiated the transaction. This feels neater, > but it's still quite a bit of work for such an unimportant > corner case. > > Or we could work around things, by requiring that devices that > access current_cpu cope with it being NULL in some vaguely > plausible way. This means that even when you tell gdb or the > monitor "access this address using this CPU" you'll get CPU0's > view, of course. Some devices like hw/intc/openpic.c do this already. > > Or we could continue to ignore the bug, like we've done for the > past six years, on the basis that you only hit it if you've > done something slightly silly in gdb or the monitor in > the first place :-)
IMHO it's too bad to just ignore this bug forever. This is a valid use case. It's not about whether we intentionally want to inspect the GIC register value from gdb. The case is that when single stepping the source codes it triggers the core dump for no reason if the instructions involved contain load/store to any of the GIC registers. Regards, Bin
