[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: Avi Kivity
Subject: Re: [Qemu-devel] [RFC] Plan for moving forward with QOM
Date: Wed, 14 Dec 2011 16:50:48 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0

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

reply via email to

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