Paolo Bonzini <pbonz...@redhat.com> writes: > 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.
I too am on holiday but I'll get the notes tidied up and posted later in the week when the kids are back to school ;-) > > Paolo > > > -----Original Message----- > From: Mark Burton [mark.bur...@greensocs.com] > Received: mercoledì, 26 ago 2015, 14:21 > To: KONRAD Frédéric [fred.kon...@greensocs.com] > CC: qemu-devel [qemu-devel@nongnu.org]; Alex Bennée [alex.ben...@linaro.org]; > mt...@greensocs.com, Paolo Bonzini [pbonz...@redhat.com]; Guillaume Delbergue > [guillaume.delber...@greensocs.com]; Edgar E. Iglesias > [edgar.igles...@gmail.com]; Emilio G. Cota [c...@braap.org] > 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 <fred.kon...@greensocs.com> 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 -- Alex Bennée
