Re: [Qemu-devel] Memory API: handling unassigned physical memory

[Anthony Liguori]

On 05/01/2012 08:01 AM, Avi Kivity wrote:
> On 05/01/2012 03:49 PM, Peter Maydell wrote:
> > On 1 May 2012 13:48, Avi Kivity<address@hidden>  wrote:
> > > On 05/01/2012 03:43 PM, Peter Maydell wrote:
> > > > On 1 May 2012 13:42, Avi Kivity<address@hidden>  wrote:
> > > > > sysbus should just die.
> > > >
> > > > Totally agreed. It's not going to go quietly though...
> > >
> > > Not if you keep suggesting workarounds when I tell unsuspecting
> > > developers to qomify their devices.
> >
> > When QOM supports (1) exporting gpio signals and

This is trivial.  It'll come in as soon as 1.2 opens up.  If folks want to start 
working on a branch with it:

https://github.com/aliguori/qemu/tree/qom-pin.4

> > (2) exporting memory regions, then it will be providing the
> > main things that sysbus provides.

This is a little tricky.  Here's the problems I've encountered so far:

a) A lot of devices need the equivalent of it_shift.  it_shift affects how 
addresses are decoded and the size of the memory region.  it_shift usually needs 
to be a device property.

Since we need to know the size of the memory region to initialize it, we need to 
know the value of it_shift before we can initialize it which means we have to 
delay the initialization of the mmemory region until realize.

I think a nice fix would be to make it_shift as memory region mutator and allow 
it to be set after initialization.

b) There's some duplication in MemoryRegions with respect to QOM.  Memory 
regions want to have a name but with QOM they'll be addressable via a path.  I 
go back and forth about how aggressively we want to refactor MemoryRegions.

If someone wants to spend some time converting MemoryRegion to QOM, that would 
certainly be helpful.  So far, I've been avoiding it but we'll eventually need 
to do it.

Regards,

Anthony Liguori