From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42384) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOAxK-0003Xb-Li for qemu-devel@nongnu.org; Sun, 22 May 2011 11:52:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOAxJ-0006fv-Nr for qemu-devel@nongnu.org; Sun, 22 May 2011 11:52:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50884) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOAxJ-0006fr-Fh for qemu-devel@nongnu.org; Sun, 22 May 2011 11:52:37 -0400 Message-ID: <4DD9313D.9070701@redhat.com> Date: Sun, 22 May 2011 18:52:29 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1305814352-15044-1-git-send-email-avi@redhat.com> <1305814352-15044-2-git-send-email-avi@redhat.com> <4DD580FD.2030409@codemonkey.ws> <4DD6331E.8000105@redhat.com> <4DD67563.9080803@twiddle.net> <4DD67B2F.5080907@codemonkey.ws> <4DD67D50.30706@twiddle.net> <4DD67EB8.8050602@codemonkey.ws> <4DD8AF8C.5030305@redhat.com> <4DD92FBB.7030700@codemonkey.ws> In-Reply-To: <4DD92FBB.7030700@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v1] Add declarations for hierarchical memory region API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, Richard Henderson On 05/22/2011 06:46 PM, Anthony Liguori wrote: >> MemoryRegion *is* the dispatch path. Only done declaratively so we can >> flatten it whenever it changes. > > > We don't want dispatch to be 100% declarative. That's what will cause > the API to get horrendously ugly. > > An example is PCI-bus level endianness conversion. I also believe the > Sparc IOMMU has an xor engine. > > You could add a 'bool swap_endian' and an 'uint32_t xor_mask' in > MemoryRegion but now you're adding a ton of platform specific > knowledge to what should be an independent layer. > Currently containers do not use the read/write function pointers. We could make them (or perhaps others) act as transformations on the data as it passes. So it's still declarative (the entire flow is known at registration time) but it doesn't embed platform magic. Byteswap is sufficiently generic to add as a region property, IMO. btw, wrt iommu emulation, the API finally allows us to determine the path between any two devices, so we can apply the right iommu transformations. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.