[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC] Plan for moving forward with QOM
Date: Wed, 14 Dec 2011 08:46:07 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13

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

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 

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).


Anthony Liguori

reply via email to

[Prev in Thread] Current Thread [Next in Thread]