[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
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, (continued)
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Paul Brook, 2011/12/13
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Anthony Liguori, 2011/12/13
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Paul Brook, 2011/12/13
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Anthony Liguori, 2011/12/13
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Paul Brook, 2011/12/13
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Anthony Liguori, 2011/12/14
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Avi Kivity, 2011/12/14
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Anthony Liguori, 2011/12/14
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Avi Kivity, 2011/12/14
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Anthony Liguori, 2011/12/14
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM,
Avi Kivity <=
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Paul Brook, 2011/12/15
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Anthony Liguori, 2011/12/15
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Paul Brook, 2011/12/15
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Anthony Liguori, 2011/12/15
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Paul Brook, 2011/12/16
- Re: [Qemu-devel] [RFC] Plan for moving forward with QOM, Andreas Färber, 2011/12/14