From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:40655)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <peter.maydell@linaro.org>) id 1Ufpc0-00006s-Rm
	for qemu-devel@nongnu.org; Fri, 24 May 2013 06:52:43 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <peter.maydell@linaro.org>) id 1Ufpbz-0008NB-0E
	for qemu-devel@nongnu.org; Fri, 24 May 2013 06:52:40 -0400
Received: from mail-la0-x22c.google.com ([2a00:1450:4010:c03::22c]:61592)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <peter.maydell@linaro.org>) id 1Ufpby-0008Mp-P0
	for qemu-devel@nongnu.org; Fri, 24 May 2013 06:52:38 -0400
Received: by mail-la0-f44.google.com with SMTP id fr10so4305552lab.3
	for <qemu-devel@nongnu.org>; Fri, 24 May 2013 03:52:37 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <519F1E7E.7050700@redhat.com>
References: <1369133851-1894-1-git-send-email-pbonzini@redhat.com>
	<1369133851-1894-16-git-send-email-pbonzini@redhat.com>
	<CAFEAcA-LTgN_W_2kSKUoBPtgyuEV0h=GDABAh+gqo6FHHQTshw@mail.gmail.com>
	<519F1E7E.7050700@redhat.com>
From: Peter Maydell <peter.maydell@linaro.org>
Date: Fri, 24 May 2013 11:52:17 +0100
Message-ID: <CAFEAcA_0dAud4Fh3p5GMHo1kKjDcrHwvKruHdA+ed9vE2AGbNQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [Qemu-devel] [PATCH 15/30] memory: add address_space_valid
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: David Gibson <david@gibson.dropbear.id.au>, qemu-devel@nongnu.org, jan.kiszka@gmail.com

On 24 May 2013 09:02, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 23/05/2013 20:04, Peter Maydell ha scritto:
>> Shouldn't we be calling the MemoryRegionOps
>> accepts() callback here? What about access alignment constraints
>> and access size restrictions?
>
> Yes, we should.
>
>> What if the validity of the range
>> changes between the time you asked and when you actually do the
>> access?
>
> If that's a concern, you shouldn't use this API, you should just do the
> access and rely on the return value of address_space_rw & friends.

So when *is* it a good idea to use this API? In real
hardware you don't usually get a "tell me whether this
access would succeed if I did it" bus operation -- you
just do the operation and the memory transaction either
succeeds or it doesn't. Are we modelling something that
really exists in hardware on spapr here?

thanks
-- PMM