[Top][All Lists]

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

[QUESTION] tcg: Is concurrent storing and code translation of the same c

From: Liren Wei
Subject: [QUESTION] tcg: Is concurrent storing and code translation of the same code page considered as racing in MTTCG?
Date: Sun, 31 Jan 2021 19:38:55 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0


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:

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
       set dirty flag
     write to RAM

   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

reply via email to

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