qemu-devel
[Top][All Lists]
Advanced

[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:01:56 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0

On 12/14/2011 03:53 PM, Anthony Liguori wrote:
>> The fact that serial.c (which really should be called 16550.c)
>> contains ISA
>> specific IO callback routines feels like ISASerial isn't doing its job
>> proberly to start with :-)
>
>
> It's not really ISA specific callbacks but I need to think through
> interaction with the memory API.
>
> In my qom-next branch, serial.c exposes a
> serial_ioport_read/serial_ioport_write function.  isa-serial.c and
> mm-serial.c create MemoryRegions based on thin wrappers around that
> callback.
>
> Ideally, serial.c would export a MemoryRegion directly for the
> registers it supported and isa-serial.c and mm-serial.c could bridge
> that to the appropriate address space.
>
> I think the problem here ends up being itl_shift.  I think Avi's
> trying to avoid having a non-flat dispatch space so you can't really
> create a MemoryRegion that dispatches to another MemoryRegion.

In fact I want the ability to create new address spaces.  For example
index/data style interfaces, as found in RTC, IOAPIC, and PCI 0xcf8
style config space, can be hooked to drive an RTC MemoryRegion, an
IOAPIC MemoryRegion, and the PCI config space address space.

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

-- 
error compiling committee.c: too many arguments to function




reply via email to

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