I am on vacation so no calls for me, but I *might* be able to send a pull request with the linux-user patches (and signal-free kick if reviewed). My queue is already long, and Emilio had useful fixups so he obviously tested/reviewed them. It will not be signed though as I tend not to have the key with me when travelling.
Just one thing: do not squash too much into existing patches if possible. Leaving things protected by the BQL and only moving it to tb_lock in a subsequent patch is perfectly fine.
Alex, please post the to-do list when you have time. More parallelization of the work or possible, especially as the focus slowly moves from "getting it working" to covering more architectures.
Paolo
-----Original Message-----
From: Mark Burton address@hidden
Received: mercoledì, 26 ago 2015, 14:21
To: KONRAD Frédéric address@hidden
CC: qemu-devel address@hidden; Alex Bennée address@hidden; address@hidden, Paolo Bonzini address@hidden; Guillaume Delbergue address@hidden; Edgar E. Iglesias address@hidden; Emilio G. Cota address@hidden
Subject: Re: MTTCG next version?
Just to remind everybody as well - we’ll have a call next Monday to co-ordinate.
It would be good to make sure everybody knows which bit of this everybody else is committing to do, so we avoid replication and treading on each others patch sets.
Cheers
Mark.
> On 26 Aug 2015, at 14:18, Frederic Konrad <address@hidden> wrote:
>
> Hi everybody,
>
> I'm trying to do the next version of the MTTCG work:
>
> I would like to rebase on Alvise atomic instruction branch:
> - Alvise can you rebase it on the 2.4.0 version without MTTCG support and then
> point me to the MTTCG specific changes so I can include them in my tree?
> I will add Paolo's linux-user and signal free qemu_cpu_kick series as well.
>
> About tb_flush we think to do that without exiting:
> - Use two buffers for tbs.
> - Use a per tb invalidated flag.
> - when tb_flush just invalidate all tb from the buffer and swap to the second buffer:
> VCPU which are executing code will discard their tb_jmp_cache when they exit
> (eg: run_on_cpu).
>
> We need also to fix emulated data barrier so tlb_flush are finished before the
> instruction is executed. (That might be only data barrier breaks the TB).
>
> Protecting page->code_bitmap and cpu_breakpoint_insert changes will be squashed in the tb_lock patch.
>
> More tests must be done especially with gdbstub and icount.
>
> Do that make sense?
> Fred
+44 (0)20 7100 3485 x 210
+33 (0)5 33 52 01 77x 210
+33 (0)603762104
mark.burton