[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[QUESTION] tcg: Is concurrent storing and code translation of the same c
[QUESTION] tcg: Is concurrent storing and code translation of the same code page considered as racing in MTTCG?
Sun, 31 Jan 2021 19:38:55 +0800
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
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!
- [QUESTION] tcg: Is concurrent storing and code translation of the same code page considered as racing in MTTCG?,
Liren Wei <=