From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34862) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXm5I-0001u6-7H for qemu-devel@nongnu.org; Fri, 04 Sep 2015 04:10:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZXm5E-00070E-NF for qemu-devel@nongnu.org; Fri, 04 Sep 2015 04:10:55 -0400 Received: from greensocs.com ([193.104.36.180]:57291) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXm5E-0006z4-CC for qemu-devel@nongnu.org; Fri, 04 Sep 2015 04:10:52 -0400 Message-ID: <55E95204.1050408@greensocs.com> Date: Fri, 04 Sep 2015 10:10:44 +0200 From: Frederic Konrad MIME-Version: 1.0 References: <87fv2uipzf.fsf@linaro.org> In-Reply-To: <87fv2uipzf.fsf@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] MTTCG Tasks (kvmforum summary) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QWxleCBCZW5uw6ll?= , qemu-devel@nongnu.org, mttcg@listserver.greensocs.com Cc: mark.burton@greensocs.com, claudio.fontana@huawei.com, a.rigo@virtualopensystems.com, "Emilio G. Cota" , Alexander Spyridakis , Pbonzini@redhat.com Hi Alex, On 04/09/2015 09:49, Alex Benn=C3=A9e wrote: > Hi, > > At KVM Forum I sat down with Paolo and Frederic and we came up with the > current outstanding tasks on MTTCG. This is not comprehensive but > hopefully covers the big areas. They are sorted in rough order we'd lik= e > to get them up-streamed. > > * linux-user patches (Paolo) > > Paolo has already grabbed a bunch of Fred's patch set where it makes > sense on its own. They are up on the list and need review to expedite > there way into the main tree now it is open for pull requests. > > See thread: 1439397664-70734-1-git-send-email-pbonzini@redhat.com > > * TLB_EXCL based LL/SC patches (Alvise) > > I think our consensus is these provide a good basis for the solution to > modelling our atomics within TCG. I haven't had a chance to review > Emilio's series yet which may approach this problem differently. I thin= k > the core patches with the generic backend support make a good basis to > base development work on. > > We need to iterate and review the non-MTTCG variant of the patch set > with a view to up-streaming soon. > > * Signal free qemu_cpu_kick (Paolo) > > I don't know much about this patch set but I assume this avoids the nee= d > to catch signals and longjmp about just to wake up? > > * RCU tb_flush (needs writing) > > The idea has been floated to introduce an RCU based translation buffer > to flushes can be done lazily and the buffers dumped once all threads > have stopped using them. > > I have been pondering if looking into having translation regions would > be worth looking into so we can have translation buffers for contiguous > series of pages. That way we don't have to throw away all translations > on these big events. Currently every time we roll over the translation > buffer we throw a bunch of perfectly good code away. This may or may no= t > be orthogonal to using RCU? I'm still not sure tb_flush needs so much effort. tb_flush is happening very rarely just exiting everybody seems easier.. > > * Memory barrier support (need RFC for discussion) > > I came to KVM forum with a back of the envelope idea we could implement > one or two barrier ops (acquire/release?). Various suggestions of other > types of memory behaviour have been suggested. > > I'll try to pull together an RFC patch with design outline for > discussion. It would be nice to be able to demonstrate barrier failures > in my test cases as well ;-) > > * longjmp in cpu_exec > > Paolo is fairly sure that if you take page faults while IRQs happening > problems will occur with cpu->interrupt_request. Does it need to take > the BQL? > > I'd like to see if we can get a torture test to stress this code > although it will require IPI support in the unit tests. > > * tlb_flush and dmb behaviour (am I waiting for TLB flush?) > > I think this means we need explicit memory barriers to sync updates to > the tlb. > > * tb_find_fast outside the lock > > Currently it is a big performance win as the tb_find_fast has a lot of > contention with other threads. However there is concern it needs to be > properly protected. > > * Additional review comments on the Fred's branch > - page->code_bitmap isn't protected by lock > - cpu_breakpoint_insert needs locks Thoses one are OK, I didn't send all that yet. > - check gdbstub works > > * What to do about icount? > > What is the impact of multi-thread on icount? Do we need to disable it > for MTTCG or can it be correct per-cpu? Can it be updated lock-step? > > We need some input from the guys that use icount the most. > > Cheers, > Also we might want to have everything in a branch. So rebasing the=20 Atomics series on eg: 2.4.0 + 2 Paolo's series so I can rebase MTTCG on it and pick the=20 MTTCG atomic parts can be usefull. Thanks, Fred