From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:48536)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1TNqiF-0005RJ-5q
	for qemu-devel@nongnu.org; Mon, 15 Oct 2012 15:52:32 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1TNqiE-0008Aq-4G
	for qemu-devel@nongnu.org; Mon, 15 Oct 2012 15:52:31 -0400
Received: from gate.crashing.org ([63.228.1.57]:34947)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1TNqiD-0008AX-RW
	for qemu-devel@nongnu.org; Mon, 15 Oct 2012 15:52:30 -0400
Message-ID: <1350330738.4678.4.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Tue, 16 Oct 2012 06:52:18 +1100
In-Reply-To: <507BE941.7000205@redhat.com>
References: <1349962023-560-1-git-send-email-avi@redhat.com>
	<1350009361.20486.131.camel@pasglop> <507BE941.7000205@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0
Subject: Re: [Qemu-devel] [RFC v1 0/7] IOMMU support
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: Avi Kivity <avi@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>, liu ping fan <qemulist@gmail.com>, qemu-devel@nongnu.org, Blue Swirl <blauwirbel@gmail.com>, Alex Williamson <alex.williamson@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>, Paolo Bonzini <pbonzini@redhat.com>

On Mon, 2012-10-15 at 12:45 +0200, Avi Kivity wrote:
> > I haven't had a chance to review in details yet, but one thing I
> noticed
> > is that you basically have a single read/write protection
> information
> > for a translation.
> > 
> > This is a loss of functionality to some extent (well, maybe not from
> the
> > existing iommu layer but from what could be done by our HW) in that
> we
> > have separate read and write permission bits.
> > 
> > This is actually worth fixing I think. Catching incorrect reads from
> > write-only regions is probably worth it in term of debugging
> drivers.
> > 
> 
> I do have an is_write parameter to translate, in fact I added it in
> order to implement the spapr iommu.  Or do you mean something else?

Hrm, sort of. "is_write" means you can only express RO vs RW. Two
parameter for read and write allow to express WO. The only difference is
going to be if something does one translate for several R and W.

Not a huge deal, since mostly translate is used for atomic accesses so
one translate = one access... except with map. It's useful to
differenciate the map with 3 states: RO, WO, RW.

Cheers,
Ben.