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
