On Mon, Aug 27, 2012 at 8:15 PM, Steven <[email protected]> wrote: >> Guest code is accessed at the translation time by C functions and >> I guess there are other layers of address translation caching. I wouldn't >> try to interpret these _cmmu printouts and would instead instrument >> [cpu_]ld{{u,s}{b,w},l,q}_code macros. > yes, you are right. > Some ldub_code in x86 guest does not call __ldq_cmmu when the tlb hits. > By the way, when I use your patch, I saw too many log event for the > kernel data _mmu, ie., the addrs is > 0x7fff ffff ffff. There are too many such mmu event that the user mode > data can not be executed. So I have to setup a condition like > if (addr < 0x8000 0000 0000) > fprintf(stderr, "%s: %08x\n", __func__, addr); > Then my simple array access program can be finished.
You can also try to differentiate kernel/userspace by mmu_idx passed to helpers. > I am wondering whether you have met the similar problem or you have > any suggestion on this. I used simple samples (tests/tcg/xtensa testsuite), their memory access pattern didn't deviate from what I expected. > My final goal is to obtain the memory access trace for a particular > process in the guest, so your patch really helps, except for too many > kernel _mmu events. Wouldn't it be easier to use qemu-user for that? -- Thanks. -- Max
