> This enables support for handling the case where a guest instruction
> modifies the memory corresponding to the QEMU TB which it is in.
> For most CPU architectures this will (on hardware) give unpredictable
> results because of hardware prefetch / pipelining / caching, and so
> there's no need for QEMU to go to great lengths to support it (typically
> the CPU architecture requires some explicit act like a cache flush
> before starting to execute the modified code, which is where QEMU will
> flush its translation cache).
> On x86 actions like "modify the next instruction" have historically
> worked and so QEMU has to actually handle this.
I am trying to understand tb_invalidate_phys_page_range (exec.c) which has
TARGET_HAS_PRECISE_SMC macro inside.
---
void tb_invalidate_phys_page_range(tb_page_addr_t start, tb_page_addr_t end,
int is_cpu_write_access)
{
#ifdef TARGET_HAS_PRECISE_SMC
int current_tb_not_found = is_cpu_write_access;
#endif /* TARGET_HAS_PRECISE_SMC */
... snip ...
#ifdef TARGET_HAS_PRECISE_SMC
if (current_tb_not_found) {
current_tb_not_found = 0;
current_tb = NULL;
if (env->mem_io_pc) {
/* now we have a real cpu fault */
current_tb = tb_find_pc(env->mem_io_pc);
}
}
if (current_tb == tb &&
(current_tb->cflags & CF_COUNT_MASK) != 1) {
current_tb_modified = 1;
cpu_restore_state(current_tb, env,
env->mem_io_pc, NULL);
cpu_get_tb_cpu_state(env, ¤t_pc, ¤t_cs_base,
¤t_flags);
}
#endif /* TARGET_HAS_PRECISE_SMC */
}
---
>From the backtrace I observed, the argument "is_cpu_write_access" is one only
when guest is doing MMIO (see below). And the part of
tb_invalidate_phys_page_range
involved TARGET_HAS_PRECISE_SMC get executed only when current_tb_not_found is
one
(equal to is_cpu_write_access). I mean only then it finds current_tb, and
executes
cpu_restore_state ... etc, otherwise it skips the whole thing. My question is,
does MMIO change guest instructions? Because you said,
This enables support for handling the case where a guest instruction modifies
the memory corresponding to the QEMU TB which it is in.
I am not expect it's MMIO modifies the guest memory.
---
#0 tb_invalidate_phys_page_range (start=229376, end=229380,
is_cpu_write_access=1) at /tmp/chenwj/qemu-0.13.0/exec.c:985
#1 0x00508bd2 in tb_invalidate_phys_page_fast (start=229376, len=4) at
/tmp/chenwj/qemu-0.13.0/exec.c:1112
#2 0x0050c69b in notdirty_mem_writel (opaque=0x0, ram_addr=229376,
val=0) at /tmp/chenwj/qemu-0.13.0/exec.c:3120
#3 0x0054e3c1 in io_writel (physaddr=229376, val=0, addr=229376,
retaddr=0x40016031) at /tmp/chenwj/qemu-0.13.0/softmmu_template.h:213
#4 0x0054e4ab in __stl_mmu (addr=229376, val=0, mmu_idx=0) at
/tmp/chenwj/qemu-0.13.0/softmmu_template.h:245
---
Thanks!
Regards,
chenwj
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj
