From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56722) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZHFJ1-0006B9-E2 for qemu-devel@nongnu.org; Mon, 20 Jul 2015 13:56:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZHFIw-0005gL-DK for qemu-devel@nongnu.org; Mon, 20 Jul 2015 13:56:47 -0400 Received: from greensocs.com ([193.104.36.180]:56349) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZHFIw-0005g7-2D for qemu-devel@nongnu.org; Mon, 20 Jul 2015 13:56:42 -0400 Message-ID: <55AD3466.50608@greensocs.com> Date: Mon, 20 Jul 2015 19:48:22 +0200 From: Frederic Konrad MIME-Version: 1.0 References: <87k2tuu7lh.fsf@linaro.org> In-Reply-To: <87k2tuu7lh.fsf@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Summary MTTCG related patch sets List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QWxleCBCZW5uw6ll?= , mttcg@listserver.greensocs.com, Alvise Rigo , pbonzini@redhat.com, Jan Kiszka Cc: Mark Burton , claudio.fontana@huawei.com, qemu-devel@nongnu.org On 20/07/2015 18:17, Alex Benn=C3=A9e wrote: > Hi, > > Following this afternoons call I thought I'd summarise the state of the > various patch series and their relative dependencies. We re-stated the > aim should be to get what is up-streamable through the review process > and heading for merge so the delta for a full working MTTCG can be as > low as possible. There was some concern about the practicality of > submitting patches where the full benefit will not be seen until MTTCG > is finally merged. > > On the patch submission note could I encourage posting public git trees > along with the patches for ease of review? > > BQL lock breaking patches, Paolo/Jan > - required for working virt-io in MTTCG > - supersedes some of Fred's patches > - merged upstream as of -rc0 > > TCG async_safe_work, Fred > - http://git.greensocs.com/fkonrad/mttcg.git async_work_v3 > - [1437144337-21442-1-git-send-email-fred.konrad@greensocs.com] > - split from earlier MTTCG patch series > - needed for cross-cpu sync mechanism for main series and slow-path > - candidate for upstreaming, but only MTTCG uses for now? > > Slow-path for atomic instruction translation, Alvise > - [1436516626-8322-1-git-send-email-a.rigo@virtualopensystems.com] > - Needs re-basing to use TCG async_safe_work > - Earlier part of series (pre MTTCG) could be upstreamed as is > - Concern about performance impact in non-MTTCG scenarios > - Single CPU thread impact may be minimal with latest version, needs > benchmarking > - Also incomplete backend support, would BACKEND_HAS_LLSC_OPS be > acceptable to maintainers while support added by more knowledgable > backend people for non-x86/arm backends? > =20 > Multi-threaded TCG V6, Fred > - git@git.greensocs.com:fkonrad/mttcg.git branch multi_tcg_v6 > - [1435330053-18733-1-git-send-email-fred.konrad@greensocs.com] > - Needs re-basing on top of latest -rc (BQL breaking) > - Contains the rest of the MTTCG work (tb locking, tlb stuff etc) > - Currently target-arm only, other builds broken > > As far as balancing the desire to get things upstreamed versus having a > stable base for testing I suggest we try an approach like this: > > - select the current upstream -rc as the common base point > - create a branch from -rc with: > - stuff submitted for upstream (reviewed, not nacked) > - doesn't break any tree > - has minimal performance impact > > Then both Fred and Alvise could base their trees of this point and we > aim to rebase onto a new branch each time the patches get merged into a > new upstream RC. The question then become how to deal with any > cross-dependencies between the slow-path and the main MTTCG branches? > > I suspect the initial common branch point would just be > 2.4.0-rc1+safe_async. > > Does that sound workable? > Yes it seems a good idea. Which commit do you want to rebase on? Can you provide any hashtag? Thanks, Fred