From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58197) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZHFNZ-0006pU-O4 for qemu-devel@nongnu.org; Mon, 20 Jul 2015 14:01:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZHFNR-0007ny-Kw for qemu-devel@nongnu.org; Mon, 20 Jul 2015 14:01:29 -0400 Received: from greensocs.com ([193.104.36.180]:57145) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZHFNR-0007nV-At for qemu-devel@nongnu.org; Mon, 20 Jul 2015 14:01:21 -0400 Message-ID: <55AD376C.6020600@greensocs.com> Date: Mon, 20 Jul 2015 20:01:16 +0200 From: Frederic Konrad MIME-Version: 1.0 References: <87k2tuu7lh.fsf@linaro.org> In-Reply-To: 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: alvise rigo , =?UTF-8?B?QWxleCBCZW5uw6k=?= =?UTF-8?B?ZQ==?= Cc: mttcg@listserver.greensocs.com, Mark Burton , Claudio Fontana , QEMU Developers , Jan Kiszka , Paolo Bonzini On 20/07/2015 19:41, alvise rigo wrote: > Hi Alex, > > Thank you for this summary. > Some comments below. > > On Mon, Jul 20, 2015 at 6:17 PM, Alex Benn=C3=A9e wrote: >> Hi, >> >> Following this afternoons call I thought I'd summarise the state of th= e >> 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 tree= s >> 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 > I will create a branch for upstreaming (pre MTTCG) and another one > based on MTTCG. > >> - Concern about performance impact in non-MTTCG scenarios >> - Single CPU thread impact may be minimal with latest version, need= s >> 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? >> >> 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? > From my side I will take care of rebasing my patch series on the > latest MTTCG branch as often as possible. Up to now, there are not so > many cross-dependencies, so I don't see it as a big issue. Is this a > workable solution? > > Thank you, > alvise The RFC V3 you sent is based on MTTCG if I remember right. That's why you introduced this rendez-vous right? And the point was to use async_safe_work for this as I need it actually f= or tb_flush and tb_invalidate (if we don't find any other solution for=20 tb_invalidate). So this is the cross-dependency which we are talking of. But maybe and probably this is not needed with upstream as there is only=20 one TCG thread. Thanks, Fred >> >> I suspect the initial common branch point would just be >> 2.4.0-rc1+safe_async. >> >> Does that sound workable? >> >> -- >> Alex Benn=C3=A9e