From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:49308)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1ZUN56-0006by-Jo
	for qemu-devel@nongnu.org; Tue, 25 Aug 2015 18:52:41 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1ZUN51-0000pi-L1
	for qemu-devel@nongnu.org; Tue, 25 Aug 2015 18:52:40 -0400
Received: from mx6-phx2.redhat.com ([209.132.183.39]:34930)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1ZUN51-0000pe-Dk
	for qemu-devel@nongnu.org; Tue, 25 Aug 2015 18:52:35 -0400
Date: Tue, 25 Aug 2015 18:52:28 -0400 (EDT)
From: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <416201653.18984894.1440543148171.JavaMail.zimbra@redhat.com>
In-Reply-To: <20150825203612.GB29063@flamenco>
References: <1440375847-17603-1-git-send-email-cota@braap.org>
	<1440375847-17603-23-git-send-email-cota@braap.org>
	<55DA6EDC.1080603@redhat.com> <20150825203612.GB29063@flamenco>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RFC 22/38] cpu: update interrupt_request
	atomically
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: "Emilio G. Cota" <cota@braap.org>
Cc: mttcg@greensocs.com, mark burton <mark.burton@greensocs.com>, a rigo <a.rigo@virtualopensystems.com>, qemu-devel@nongnu.org, guillaume delbergue <guillaume.delbergue@greensocs.com>, alex bennee <alex.bennee@linaro.org>, Frederic Konrad <fred.konrad@greensocs.com>


> This patch is needed as is. One real risk this is protecting
> against is the call of cpu_interrupt(cpu_foo) when the calling
> thread is not cpu_foo's thread--this write to interrupt_request
> might race with other writes, e.g. another call to cpu_interrupt
> from another thread, or the clearing of interrupt_request by
> cpu_foo.

But it should be protected by the iothread lock.  That requires
a lot of auditing. :(

I prefer to go with patch 23 first and then optimize things on
top (not that I don't like the optimization, since it also affects
KVM!). :)

Paolo

> Patch 23 fixes another issue--bootup hangs without it. The amount
> of code wrapped by the iothread lock can be reduced, though.
> Will fix.