From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56203) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXnFV-0008E7-M2 for qemu-devel@nongnu.org; Fri, 04 Sep 2015 05:25:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZXnFS-0001uI-AB for qemu-devel@nongnu.org; Fri, 04 Sep 2015 05:25:33 -0400 Received: from mail-wi0-x22f.google.com ([2a00:1450:400c:c05::22f]:33313) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXnFS-0001sW-1q for qemu-devel@nongnu.org; Fri, 04 Sep 2015 05:25:30 -0400 Received: by wiclk2 with SMTP id lk2so16012844wic.0 for ; Fri, 04 Sep 2015 02:25:29 -0700 (PDT) Sender: Paolo Bonzini References: <87fv2uipzf.fsf@linaro.org> From: Paolo Bonzini Message-ID: <55E9638D.4010006@redhat.com> Date: Fri, 4 Sep 2015 11:25:33 +0200 MIME-Version: 1.0 In-Reply-To: <87fv2uipzf.fsf@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] MTTCG Tasks (kvmforum summary) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?Q?Alex_Benn=c3=a9e?= , 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 , "Edgar E. Iglesias" , fred.konrad@greensocs.com On 04/09/2015 09:49, Alex Bennée wrote: > * Signal free qemu_cpu_kick (Paolo) > > I don't know much about this patch set but I assume this avoids the need > to catch signals and longjmp about just to wake up? It was part of Fred's patches, so I've extracted it to its own series. Removing 150 lines of code can't hurt. > * 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 ;-) Emilio has something about it in his own MTTCG implementation. > * 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. It's x86-specific (hardware interrupts push to the stack and can cause a page fault or other exception), so a unit test can be written for it. > * 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. Yes. > * 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. This, BTW, can be done for user-mode emulation first, so it can go in early. Same for RCU-ized code_gen_buffer. > * 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. That means Edgar. :) Paolo