> 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 0x0000000000508bd2 in tb_invalidate_phys_page_fast (start=229376, len=4) at /tmp/chenwj/qemu-0.13.0/exec.c:1112 #2 0x000000000050c69b in notdirty_mem_writel (opaque=0x0, ram_addr=229376, val=0) at /tmp/chenwj/qemu-0.13.0/exec.c:3120 #3 0x000000000054e3c1 in io_writel (physaddr=229376, val=0, addr=229376, retaddr=0x40016031) at /tmp/chenwj/qemu-0.13.0/softmmu_template.h:213 #4 0x000000000054e4ab 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