[QUESTION] tcg: Is concurrent storing and code translation of the same code page considered as racing in MTTCG?

[Liren Wei]

Hi,

After reading related source code and discussions in the mailing list,
I understand that:

1. tb_page_add() calls tlb_protect_code() to clear the code page by
setting TLB_NOTDIRTY in .addr_write field of corresponding CPUTLBEntry
*of all vCPUs*.

2. Updating and accessing (even from TCG-generated code) of .addr_write
is atomic and therefore does NOT result in any undefined behavior.

3. .addr_write field with TLB_NOTDIRTY forces qemu_st to execute the
so-called "slow path", in which TBs in the modified portion of the
code page is invalidated, so the modified code will be re-translated.

However, similar to the situation described in:
https://lists.nongnu.org/archive/html/qemu-devel/2018-02/msg02529.html

When we have 2 vCPUs with one of them writing to the code page while
the other just translated some code within that same page, the following
situation might happen:

   vCPU thread 1 - writing      vCPU thread 2 - translating
   -----------------------      -----------------------
   TLB check -> slow path
     notdirty_write()
       set dirty flag
     write to RAM
                                tb_gen_code()
                                  tb_page_add()
                                    tlb_protect_code()

   TLB check -> fast path
                                      set TLB_NOTDIRTY
     write to RAM
executing unmodified code for this time
                                and maybe also for the next time, never
                                re-translate modified TBs.


My question is:
  Should the situation described above be considered as a bug or,
  an intended behavior for QEMU (, so it's the programmer's fault
  for not flushing the icache after modifying shared code page)?

Looking forward for your reply, and thanks in advance!

--
Liren Wei