On 8 October 2018 at 23:17, Stefano Stabellini <sstabell...@kernel.org> wrote: > I double-checked all the addresses and they are correct. For some reason > after starting the guest, ATS12NSOPW starts to fail for > ffffffc006f91628, which is the same virtual address corresponding to the > same runstate region allocated in Linux. > > I added a couple of printf's to QEMU and Xen: > > (XEN) DEBUG do_vcpu_op 1458 area.v=ffffffc006f91628 > ### This is the virtual address as passed by Linux > [...] > (QEMU) DEBUG do_ats_write 2256 ret=1 phys_addr=200 value=ffffffc006f91628 > (QEMU) DEBUG do_ats_write 2326 par64=80b > ### This is the output from QEMU, I added the printks to do_ats_write, line > numbers 2256 and 2326 > (XEN) p2m.c:1426: d1v0: gvirt_to_maddr failed va=0xffffffc006f91628 flags=0x1 > par=0x80b > (XEN) DEBUG translate_get_page 42 addr=ffffffc006f91628 linear=1 write=1 > (XEN) DEBUG raw_copy_to_guest 120 > caller=domain.c#update_runstate_area+0x78/0x10c > (XEN) DEBUG update_runstate_area 294 > ### This is Xen failing the copy_to_guest in update_runstate_area. > > > Do you have any ideas on what's wrong? I am happy to run more tests > with QEMU to get more data.
We'd need to look at why do_ats_write is returning a failure: the simplest way to do that is just to step through it in a debugger watching as it does the page table walks, to see where it does something wrong... (If you can repro the failure eg under 'rr' then you can use its reverse-debug to go backwards from "oops it failed" to find out why.) thanks -- PMM
