QEMU 5

[andreafioraldi]

I had some trouble porting to QEMU 4. It works but the exec/sec decrease drammatically.
For example, on tcpdump exec/sec are dropped from ~1650 to ~60.
I can't figure out why this happens and if someone will find why please tag me.

As a note for the future, I didn' use the QEMU helpers cause a patched version of tcg_gen_callN (tcg_gen_afl_maybe_log_call) that only generates calls to afl_maybe_log is faster. It avoids an hashtable lookup for flags and sizemask (I hardcoded them) and many operations related to arguments preparation will be simplified by the compiler.

[vanhauser-thc]

referencing PR #39 I accepted ... might influence this (at least for a decision :) )

[andreafioraldi]

Yeah i see now the PR #39 , the fix is included in QEMU 4.1.0 (the release of 2 days ago) and so I think that the fix fro afl++ will be the transition to this version.

[andreafioraldi]

QEMU 4.1.0 seems to ignore the cached blocks in the parent.
If I disable parent caching in QEMU 3.1.0 I get the same bad performance.
The code that handle blocks translation is very similar between the two versions of QEMU and I can't figure out why this happens.

[andreafioraldi]

tb_htable_lookup always returns NULL in the parent, even if called just after tb_gen_code.
E.g.

        mmap_lock();
        tb = tb_gen_code(cpu, t.tb.pc, t.tb.cs_base, t.tb.flags, t.tb.cf_mask);
        fprintf(stderr, " GEN CODE %d  %p : %lx %lx %lx %lx \n", getpid(), tb, t.tb.pc, t.tb.cs_base, t.tb.flags, t.tb.cf_mask);
        tb = tb_htable_lookup(cpu, t.tb.pc, t.tb.cs_base, t.tb.flags, 0);
        fprintf(stderr, " LOOKUP %p : %lx %lx %lx %lx \n", tb, t.tb.pc, t.tb.cs_base, t.tb.flags, t.tb.cf_mask);
        mmap_unlock();

Gives:

 GEN CODE 25779  0x555555cd1740 : 400000c728 0 40c0b3 0 
 LOOKUP (nil) : 400000c728 0 40c0b3 0 

[andreafioraldi]

Porting the 3.1.0 tb_gen_code() routine to 4.1.0 seems to solve this issue and now the speed is double (160 exec/s vs. 80 exec/s) but not already comparable with 3.1.0 speed (1000 exec/s).
Seems that QEMU 4.1.0 instroduced shitty code to handle buffer overflows during translation.

[andreafioraldi]

This is going to be an hell...

[vanhauser-thc]

qemu 5 is out now, maybe the performance is better now?