From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:32841)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rth7680@gmail.com>) id 1bFRXJ-0002Kp-4g
	for qemu-devel@nongnu.org; Tue, 21 Jun 2016 15:40:38 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <rth7680@gmail.com>) id 1bFRXE-00011w-0P
	for qemu-devel@nongnu.org; Tue, 21 Jun 2016 15:40:36 -0400
Received: from mail-qk0-x244.google.com ([2607:f8b0:400d:c09::244]:33396)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rth7680@gmail.com>) id 1bFRXD-00011k-SX
	for qemu-devel@nongnu.org; Tue, 21 Jun 2016 15:40:31 -0400
Received: by mail-qk0-x244.google.com with SMTP id a186so5180138qkf.0
	for <qemu-devel@nongnu.org>; Tue, 21 Jun 2016 12:40:31 -0700 (PDT)
Sender: Richard Henderson <rth7680@gmail.com>
References: <87vb12qu3x.fsf@linaro.org>
From: Richard Henderson <rth@twiddle.net>
Message-ID: <c9760e05-f460-a367-550f-2c8b36c3b050@twiddle.net>
Date: Tue, 21 Jun 2016 12:40:27 -0700
MIME-Version: 1.0
In-Reply-To: <87vb12qu3x.fsf@linaro.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [Qemu-devel] [RFC v3 PATCH 01/14] Introduce TCGOpcode for
 memory barrier
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: =?UTF-8?Q?Alex_Benn=c3=a9e?= <alex.bennee@linaro.org>, Pranith Kumar <bobby.prani@gmail.com>
Cc: "open list:All patches CC here" <qemu-devel@nongnu.org>, Sergey Fedorov <serge.fdrv@gmail.com>

On 06/21/2016 11:23 AM, Alex Bennée wrote:
>> If you think I should rebase on mainine, I will do so with the changes
>> you suggested above.
>
> Well I'll be guided by what Richard thinks about the chances of this
> merging ahead of the main MTTCG patches. You were mentioning the trouble
> with testing with the kvm-unit-tests based tests which all need MTTCG
> system mode to trigger problems. However user mode emulation "works" now
> (even better since Peter's signal fixes) so it might be worth
> investigating if we can leverage some user-mode testing instead.
>
> Also generally keeping patch series clean and self contained stops too
> large a pile of patches getting pilled up waiting for the controversial
> bits to get reviewed and merged.

I'm willing to merge this before mttcg.  I'm with Alex that we should minimize 
the amount of code that gets blocked by that patch set.


r~