From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45299) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTVaw-0006Yz-KI for qemu-devel@nongnu.org; Wed, 31 Oct 2012 06:32:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TTVar-0003g3-W9 for qemu-devel@nongnu.org; Wed, 31 Oct 2012 06:32:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19843) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTVar-0003fh-OB for qemu-devel@nongnu.org; Wed, 31 Oct 2012 06:32:17 -0400 Message-ID: <5090FE22.9080403@redhat.com> Date: Wed, 31 Oct 2012 12:32:02 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1351597670-23031-1-git-send-email-avi@redhat.com> <1351597670-23031-4-git-send-email-avi@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 3/7] memory: iommu support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: "Michael S. Tsirkin" , qemu-devel@nongnu.org, Alexander Graf , Alex Williamson , Anthony Liguori On 10/30/2012 09:11 PM, Blue Swirl wrote: > On Tue, Oct 30, 2012 at 11:47 AM, Avi Kivity wrote: >> Add a new memory region type that translates addresses it is given, >> then forwards them to a target address space. This is similar to >> an alias, except that the mapping is more flexible than a linear >> translation and trucation, and also less efficient since the >> translation happens at runtime. >> >> The implementation uses an AddressSpace mapping the target region to >> avoid hierarchical dispatch all the way to the resolved region; only >> iommu regions are looked up dynamically. >> >> + >> +static MemoryRegionOps memory_region_iommu_ops = { >> + .read = memory_region_iommu_read, >> + .write = memory_region_iommu_write, >> +#ifdef HOST_BIGENDIAN >> + .endianness = DEVICE_BIG_ENDIAN, > > Why couple this with host endianness? I'd expect IOMMU to operate at > target bus endianness, for example LE for PCI on PPC guest. This has nothing to do with device endianness; we're translating from a byte buffer (address_space_rw()) to a uint64_t (MemoryRegionOps::read/write()) so we need to take host endianess into account. This code cleverly makes use of memory core endian support to do the conversion for us. But it's probably too clever and should be replaced by an explicit call to a helper. -- error compiling committee.c: too many arguments to function