From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:48042)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1Utdj0-0001oo-FA
	for qemu-devel@nongnu.org; Mon, 01 Jul 2013 09:01:00 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1Utdiv-0000gA-Em
	for qemu-devel@nongnu.org; Mon, 01 Jul 2013 09:00:58 -0400
Received: from mail-gh0-f169.google.com ([209.85.160.169]:54079)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1Utdiv-0000fo-B6
	for qemu-devel@nongnu.org; Mon, 01 Jul 2013 09:00:53 -0400
Received: by mail-gh0-f169.google.com with SMTP id r1so1971021ghr.14
	for <qemu-devel@nongnu.org>; Mon, 01 Jul 2013 06:00:52 -0700 (PDT)
From: Anthony Liguori <anthony@codemonkey.ws>
In-Reply-To: <51D15830.5080504@redhat.com>
References: <1372444009-11544-1-git-send-email-pbonzini@redhat.com>
	<1372444009-11544-5-git-send-email-pbonzini@redhat.com>
	<8761wy9ded.fsf@codemonkey.ws> <51D15830.5080504@redhat.com>
Date: Mon, 01 Jul 2013 08:00:50 -0500
Message-ID: <87li5q4epp.fsf@codemonkey.ws>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [Qemu-devel] [PATCH 04/30] add a header file for atomic
	operations
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>
Cc: qemu-devel@nongnu.org

Paolo Bonzini <pbonzini@redhat.com> writes:

> Il 28/06/2013 22:41, Anthony Liguori ha scritto:
>> Tiny copy/paste error here: s/qemu memory/memory/g".
>> 
>> One thing I've been thinking about reviewing this code, what should we
>> be doing in virtio.c?
>> 
>> We have barriers but we're relying on st[u][wlb]_phys having atomic
>> semantics.  I think it's okay in practice but if we're taking a more
>> diligent approach here should we introduce atomic variants that work on
>> guest phys addresses?
>
> I think it's part of the semantics of stu?[wlb]_phys that they (a) are
> not CSE'd by the compiler (b) are atomic for aligned addresses.  I
> cannot find the commit exactly, but I think mst added specific code for
> that.

Right, I'm not questioning whether these functions have strong enough
semantics in their implementation, but asking what their contract should
be.

Either we should document that these functions have atomic semantics or
we should introduce another variant that guarantee atomic access.

I think the later makes more sense since the majority of users probably
don't need atomic semantics.

Regards,

Anthony Liguori

>
> Paolo