* [Qemu-devel] flushing before updating pc.ram [not found] <1799079795.5917055.1455814432510.JavaMail.yahoo.ref@mail.yahoo.com> @ 2016-02-18 16:53 ` Egbert S. 2016-02-18 17:16 ` Paolo Bonzini 2016-02-19 5:30 ` TeLeMan 0 siblings, 2 replies; 3+ messages in thread From: Egbert S. @ 2016-02-18 16:53 UTC (permalink / raw) To: qemu-devel@nongnu.org [-- Attachment #1: Type: text/plain, Size: 1168 bytes --] I have here a case (over at GitHub unicorn-engine/unicorn tests/unit/test_tb_x86.c) that is running a stack-based Alpha-Mixed sample that contains an instruction that changed an operand of the next instruction, the one that QEMU does not detect nor execute properly (even with TARGET_HAS_PRECISE_SMC define compiled in). Stack-based writeable MemoryRegion "pc.ram" starts at 0x60000000. Live trace of QEMU is:ecx = 0x5ffffff8# Modify code location 60000028 to 0x10 from 0x51 60000021 304130 xor byte ptr [ocx + 0x30], al60000024 41 inc ecx60000025 6b414151 imul eax, dword ptr [ecx + 0x41], 0x51 In the notdirty_mem_write(), it does a tb_invalidate_phys_page_fast() firstly before writing directly to the "pc.ram". As a result, the newly reconstructed TB rebuilds the 'imul' micro-operation sequence , but still retrieving the original 0x51 immediate byte operand (and not the expected 0x10). Interestingly, doing a read operation of the exact 0x60000028 byte retrieves that updated (and correct) 0x10. Could it be that in the notdirty_mem_write(), that stX_p() must be performed firstly before the tb_invalidate_phys_page_fast()? [-- Attachment #2: Type: text/html, Size: 2183 bytes --] ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Qemu-devel] flushing before updating pc.ram 2016-02-18 16:53 ` [Qemu-devel] flushing before updating pc.ram Egbert S. @ 2016-02-18 17:16 ` Paolo Bonzini 2016-02-19 5:30 ` TeLeMan 1 sibling, 0 replies; 3+ messages in thread From: Paolo Bonzini @ 2016-02-18 17:16 UTC (permalink / raw) To: Egbert S., qemu-devel@nongnu.org Your solution seems sane, but I'd like a better understanding of what happens. Therefore... On 18/02/2016 17:53, Egbert S. wrote: > As a result, the newly reconstructed TB rebuilds the 'imul' > micro-operation sequence , but still retrieving the original 0x51 > immediate byte operand (and not the expected 0x10). ... can you provide the backtrace where QEMU translates the 'imul' from within tb_invalidate_phys_page_fast? Paolo ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Qemu-devel] flushing before updating pc.ram 2016-02-18 16:53 ` [Qemu-devel] flushing before updating pc.ram Egbert S. 2016-02-18 17:16 ` Paolo Bonzini @ 2016-02-19 5:30 ` TeLeMan 1 sibling, 0 replies; 3+ messages in thread From: TeLeMan @ 2016-02-19 5:30 UTC (permalink / raw) To: Egbert S.; +Cc: qemu-devel@nongnu.org On Fri, Feb 19, 2016 at 12:53 AM, Egbert S. <cjgd7-qemu@yahoo.com> wrote: > I have here a case (over at GitHub unicorn-engine/unicorn > tests/unit/test_tb_x86.c) that is running a stack-based Alpha-Mixed sample > that contains an instruction that changed an operand of the next > instruction, the one that QEMU does not detect nor execute properly (even > with TARGET_HAS_PRECISE_SMC define compiled in). Stack-based writeable > MemoryRegion "pc.ram" starts at 0x60000000. > > > Live trace of QEMU is: > ecx = 0x5ffffff8 > # Modify code location 60000028 to 0x10 from 0x51 > 60000021 304130 xor byte ptr [ocx + 0x30], al > 60000024 41 inc ecx > 60000025 6b414151 imul eax, dword ptr [ecx + 0x41], 0x51 > > In the notdirty_mem_write(), it does a tb_invalidate_phys_page_fast() > firstly before writing directly to the "pc.ram". > > As a result, the newly reconstructed TB rebuilds the 'imul' micro-operation > sequence , but still retrieving the original 0x51 immediate byte operand > (and not the expected 0x10). > > Interestingly, doing a read operation of the exact 0x60000028 byte retrieves > that updated (and correct) 0x10. > > Could it be that in the notdirty_mem_write(), that stX_p() must be performed > firstly before the tb_invalidate_phys_page_fast()? > I think it is same as the old issue: https://lists.nongnu.org/archive/html/qemu-devel/2014-08/msg02161.html ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-02-19 5:30 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1799079795.5917055.1455814432510.JavaMail.yahoo.ref@mail.yahoo.com>
2016-02-18 16:53 ` [Qemu-devel] flushing before updating pc.ram Egbert S.
2016-02-18 17:16 ` Paolo Bonzini
2016-02-19 5:30 ` TeLeMan
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.