From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:52163)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <fred.konrad@greensocs.com>) id 1YBkSR-00020l-6o
	for qemu-devel@nongnu.org; Thu, 15 Jan 2015 08:27:35 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <fred.konrad@greensocs.com>) id 1YBkSN-0002K6-St
	for qemu-devel@nongnu.org; Thu, 15 Jan 2015 08:27:31 -0500
Received: from [2001:41d0:8:2b42::1] (port=49158 helo=greensocs.com)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <fred.konrad@greensocs.com>) id 1YBkSN-0002K0-As
	for qemu-devel@nongnu.org; Thu, 15 Jan 2015 08:27:27 -0500
Message-ID: <54B7C03D.3050003@greensocs.com>
Date: Thu, 15 Jan 2015 14:27:25 +0100
From: Frederic Konrad <fred.konrad@greensocs.com>
MIME-Version: 1.0
References: <54B7958D.2040108@greensocs.com> <54B7A0B6.60903@redhat.com>
	<54B7B7D0.3010308@greensocs.com> <54B7B8F7.1000206@redhat.com>
In-Reply-To: <54B7B8F7.1000206@redhat.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] global_mutex and multithread.
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>, mttcg@listserver.greensocs.com, qemu-devel <qemu-devel@nongnu.org>
Cc: Peter Maydell <peter.maydell@linaro.org>, Mark Burton <mark.burton@greensocs.com>, Alexander Graf <agraf@suse.de>

On 15/01/2015 13:56, Paolo Bonzini wrote:
>
> On 15/01/2015 13:51, Frederic Konrad wrote:
>>
>> Thanks for the reply.
>>
>> As I understand the idea of Jan is to unlock the global_mutex during tcg
>> execution.
>> Is that right?
>> So that means it's currently not the case and we won't be able to run
>> two TCG
>> threads at the same time?
> Yes.
>
>> About the RCU, is there a lot of device which change the memory map?
> All PCI devices (when you program their BARs), but apart from that not
> much.  As a first approximation, the patches on github which use
> CPU_INTERRUPT_TLBFLUSH should work even for multiple TCG threads.

Ok that makes sense. Thanks!

Fred

PS: Any idea why listserver is dropped from listserver.greensocs.com?
>
> I'll clean them up a bit further so that CPU_INTERRUPT_TLBFLUSH is used
> for CPUs other than the running one; the running CPU instead uses
> tlb_flush directly.
>
> If anyone can sum up how cpu_resume_from_signal works, that would also
> be helpful.
>
> Paolo