On 07/03/2017 15:19, Christian Borntraeger wrote:
> 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.
Makes sense (the bit missing from the commit message, at least the one
that I had to look up, is that cpu_memory_rw_debug takes virtual addresses).
Paolo
> 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;
>
