[Qemu-devel] What TARGET_HAS_PRECISE_SMC means?

[Qemu-devel] What TARGET_HAS_PRECISE_SMC means?

[陳韋任]

Hi all,

  I see only x86 define TARGET_HAS_PRECISE_SMC (target-i386/cpu.h), and the
comment says,

/* support for self modifying code even if the modified instruction is
   close to the modifying instruction */
#define TARGET_HAS_PRECISE_SMC

  I would like to know what it means and want to know more about it, but
googling doesn't help. Would you mind to shed some light on that? 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

Re: [Qemu-devel] What TARGET_HAS_PRECISE_SMC means?

[Peter Maydell]

On 10 May 2012 09:10, 陳韋任 <chenwj@iis.sinica.edu.tw> wrote:
>  I see only x86 define TARGET_HAS_PRECISE_SMC (target-i386/cpu.h), and the
> comment says,
>
> /* support for self modifying code even if the modified instruction is
>   close to the modifying instruction */
> #define TARGET_HAS_PRECISE_SMC
>
>  I would like to know what it means and want to know more about it, but
> googling doesn't help. Would you mind to shed some light on that? Thanks.

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.

-- PMM

Re: [Qemu-devel] What TARGET_HAS_PRECISE_SMC means?

[陳韋任]

> 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, &current_pc, &current_cs_base,
                                     &current_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

Re: [Qemu-devel] What TARGET_HAS_PRECISE_SMC means?

[Peter Maydell]

On 10 May 2012 12:29, 陳韋任 <chenwj@iis.sinica.edu.tw> wrote:
> From the backtrace I observed, the argument "is_cpu_write_access" is one only
> when guest is doing MMIO (see below).

It's one when the reason we got here is that the guest CPU did a write
instruction...

> ---
> #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
> ---

...as we can see from your backtrace, which started off in __stl_mmu.

-- PMM