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