From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42250) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RaqAj-0007Jq-5H for qemu-devel@nongnu.org; Wed, 14 Dec 2011 09:51:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RaqAd-0001GA-DM for qemu-devel@nongnu.org; Wed, 14 Dec 2011 09:51:05 -0500 Received: from mx1.redhat.com ([209.132.183.28]:13558) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RaqAd-0001Fu-1n for qemu-devel@nongnu.org; Wed, 14 Dec 2011 09:50:59 -0500 Message-ID: <4EE8B7C8.8060707@redhat.com> Date: Wed, 14 Dec 2011 16:50:48 +0200 From: Avi Kivity 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> <4EE8B6AF.7050601@codemonkey.ws> In-Reply-To: <4EE8B6AF.7050601@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 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: Anthony Liguori Cc: Peter Maydell , Jan Kiszka , qemu-devel@nongnu.org, Markus Armbruster , Gerd Hoffmann , "Edgar E. Iglesias" , Paul Brook On 12/14/2011 04:46 PM, Anthony Liguori wrote: >> 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? Correct. We'd have N address spaces; mmio would dispatch into the first, pio into the second, and we'd have manual dispatch for the others. > > 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. For serial, yes. Just use it_shift during initialization. > > 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). It means duplicating the dispatch path; having an optimized path through a radix tree and a dynamic path which walks the MemoryRegion tree and considers ranges and priorities; this reduces maintainability. Creating an address space and associating it with a MemoryRegion should be one call, I don't think it will be that much of a burden. -- error compiling committee.c: too many arguments to function