Christian Borntraeger <borntrae...@de.ibm.com> writes:
> I sometimes got "Cannot access memory" when using the x command
> on the monitor. Turns out that the cpu env did contain stale data
> (e.g. wrong control register content for page table origin).
> We must synchronize the state of the CPU before walking the page
> tables. A similar issues happens for a remote gdb, so lets
> do the cpu_synchronize_state in cpu_memory_rw_debug.
>
> Signed-off-by: Christian Borntraeger <borntrae...@de.ibm.com>
> ---
> exec.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/exec.c b/exec.c
> index aabb035..e754a03 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -43,6 +43,7 @@
> #include "exec/ioport.h"
> #include "sysemu/dma.h"
> #include "sysemu/numa.h"
> +#include "sysemu/hw_accel.h"
> #include "exec/address-spaces.h"
> #include "sysemu/xen-mapcache.h"
> #include "trace-root.h"
> @@ -3309,6 +3310,7 @@ int cpu_memory_rw_debug(CPUState *cpu, target_ulong
> addr,
> hwaddr phys_addr;
> target_ulong page;
>
> + cpu_synchronize_state(cpu);
> while (len > 0) {
> int asidx;
> MemTxAttrs attrs;
This seems like the wrong place to put it. Would we end up doing a
potentially expensive sync operations for every byte/word we dump out?
Certainly when I was messing around with ARM KVM debug I did the
synchronise state as we entered the debug handling (e.g.
gdb_handle_packet/memory_dump)?
--
Alex Bennée
