From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53536) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWo6O-0005Ez-Mf for qemu-devel@nongnu.org; Tue, 01 Sep 2015 12:08:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZWo6K-0000oN-Cm for qemu-devel@nongnu.org; Tue, 01 Sep 2015 12:08:04 -0400 Received: from mail-wi0-f180.google.com ([209.85.212.180]:33914) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWo6K-0000kE-7G for qemu-devel@nongnu.org; Tue, 01 Sep 2015 12:08:00 -0400 Received: by wicjd9 with SMTP id jd9so38549833wic.1 for ; Tue, 01 Sep 2015 09:07:38 -0700 (PDT) References: <55DDAE90.6090101@greensocs.com> <1267437413.19435982.1440601647923.JavaMail.zimbra@zmail13.collab.prod.int.phx2.redhat.com> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: <1267437413.19435982.1440601647923.JavaMail.zimbra@zmail13.collab.prod.int.phx2.redhat.com> Date: Tue, 01 Sep 2015 17:07:34 +0100 Message-ID: <87lhcqi0mx.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] MTTCG next version? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: mark.burton@greensocs.com, qemu-devel@nongnu.org, cota@braap.org, guillaume.delbergue@greensocs.com, edgar.iglesias@gmail.com, fred.konrad@greensocs.com Paolo Bonzini 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.burton@greensocs.com] > Received: mercoledì, 26 ago 2015, 14:21 > To: KONRAD Frédéric [fred.konrad@greensocs.com] > CC: qemu-devel [qemu-devel@nongnu.org]; Alex Bennée [alex.bennee@linaro.org]; mttcg@greensocs.com, Paolo Bonzini [pbonzini@redhat.com]; Guillaume Delbergue [guillaume.delbergue@greensocs.com]; Edgar E. Iglesias [edgar.iglesias@gmail.com]; Emilio G. Cota [cota@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 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