From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40120) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Raq60-0006NQ-7m for qemu-devel@nongnu.org; Wed, 14 Dec 2011 09:46:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Raq5y-0008Vf-Ue for qemu-devel@nongnu.org; Wed, 14 Dec 2011 09:46:12 -0500 Received: from mail-yw0-f45.google.com ([209.85.213.45]:61534) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Raq5y-0008Vb-S7 for qemu-devel@nongnu.org; Wed, 14 Dec 2011 09:46:10 -0500 Received: by yhgg71 with SMTP id g71so1534922yhg.4 for ; Wed, 14 Dec 2011 06:46:10 -0800 (PST) Message-ID: <4EE8B6AF.7050601@codemonkey.ws> Date: Wed, 14 Dec 2011 08:46:07 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4E70EC90.8000904@us.ibm.com> <201112132036.01441.paul@codesourcery.com> <4EE7C955.5000101@codemonkey.ws> <201112140039.05530.paul@codesourcery.com> <4EE8AA45.3070303@codemonkey.ws> <4EE8AC54.4080802@redhat.com> <4EE8AE7D.1030206@codemonkey.ws> <4EE8B414.5020809@redhat.com> In-Reply-To: <4EE8B414.5020809@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Plan for moving forward with QOM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Peter Maydell , Jan Kiszka , qemu-devel@nongnu.org, Markus Armbruster , Gerd Hoffmann , "Edgar E. Iglesias" , Paul Brook On 12/14/2011 08:35 AM, Avi Kivity wrote: > On 12/14/2011 04:11 PM, Anthony Liguori wrote: >>>> We discussed it before and I believe he was planning on adding >>>> itl_shift as a MemoryRegion mutator. >>> >>> I don't think it makes sense as a mutator, can it_shift change >>> dynamically? But as part of setup, yes. >>> >>>> Avi, did I understand that all correctly? >>> >>> If you mean that the interface between serial.c and isa-serial.c (or >>> however they're renamed) should be MemoryRegions exposed by one and >>> mapped by the other, then yes, I think that's the right interface. >> >> So I guess it's just a question of how to make it work. I actually >> think the most natural way is to have a MemoryRegion not attached to >> an AddressSpace and have the MemoryRegion bounce requests to another >> MemoryRegion. >> >> I think that violates the basic design of the memory API though. > > Well, that's exactly what I had in mind (except that you'd bounce the > I/O to an AddressSpace, which takes care of preparing the dispatch > tables etc. instead of searching dynamically through the hierarchy). But the I/O table for the AddressSpace would be independent of the system/io address space tables, correct? For these sort of virtual AddressSpaces, do we care about flattening things? For the serial device, you would: 1) Create a memory region using some form of addressing that makes sense for your device. For serial, it would be a 0-8 single byte addressing. 2) Create a virtual AddressSpace, add the MemoryRegion from (1) to the AddressSpace 3) Export the AddressSpace from your device. Serial would then expose an AddressSpace, not a MemoryRegion 4) MMSerial would create a MemoryRegion that implemented itl_shift by calling into the Serial device's AddressSpace Is this right? Honestly, it seems a bit complex to me without an obvious benefit. The use of AddressSpace seems to be overkill since we really don't care about creating a linear table for the Serial device. I actually think relaxing the requirement for MemoryRegions to be associated with an AddressSpace and having the ability to bounce from one MR to another is a bit more straight forward (with perhaps a loss in elegance). Regards, Anthony Liguori