qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] What TARGET_HAS_PRECISE_SMC means?


From: 陳韋任
Subject: Re: [Qemu-devel] What TARGET_HAS_PRECISE_SMC means?
Date: Thu, 10 May 2012 19:29:08 +0800
User-agent: Mutt/1.5.21 (2010-09-15)

> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]