On 4/8/25 15:46, Pierrick Bouvier wrote:
On 4/8/25 14:38, Pierrick Bouvier wrote:
On 4/8/25 11:03, Yannis Bolliger wrote:
static void vcpu_mem(unsigned int cpu_index, qemu_plugin_meminfo_t info,
uint64_t vaddr, void *udata) {
if (!qemu_plugin_log_is_enabled()) {
return;
}
CPU *c = cpus + cpu_index;
if (qemu_plugin_mem_is_store(info)) {
c->record.store = 1;
} else {
c->record.store = 0;
}
struct qemu_plugin_hwaddr *hwaddr = qemu_plugin_get_hwaddr(info, vaddr);
if (qemu_plugin_hwaddr_is_io(hwaddr)) {
return;
}
Could you try logging those ones as well?
They should not be there, but better to check this.
You can compare to:
qemu-system-aarch64 -plugin
./build/tests/tcg/plugins/libmem.so,print-accesses=on -d plugin
This plugin prints all accesses inconditionally.
I've been using the mem plugin when booting a linux kernel.
Using QEMU gdbstub, I stopped in __arch_copy_to_user or
__arch_copy_from_user (aarch64 implementation).
After stepping through every instruction, I can correctly see a new
entry added in the plugin log, matching the loads/stores.
If you want to reproduce (you just need podman on your machine).
$ sudo apt update && sudo apt install -y podman
$ git clone https://github.com/pbo-linaro/qemu-linux-stack
$ cd qemu-linux-stack
$ ./container.sh ./build.sh
$ q=/path/to/qemu/build
$ ./debug.sh $q/qemu-system-aarch64 \
-plugin $q/tests/tcg/plugins/libmem.so,print-accesses=on \
-d plugin -D log
Then, from the spawned gdb:
$ b __arch_copy_to_user
$ c
When breakpoint is hit, in another terminal:
$ tail -f -n 0 log
And from gdb, repeat stepi command, until reaching the load/store
sequence in assembly code.
You should see the associated loads/stores in log.
Note: to leave QEMU after debugging, use Ctrl-a + x.
As well, you can switch to QEMU monitor (Ctrl-a + c), and gva2gpa will
work as expected, as the ran cpu has the correct context when execution
is blocked on breakpoint.
