Re: [Qemu-devel] [RFC] Plan for moving forward with QOM

[Anthony Liguori]

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