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

[Anthony Liguori <anthony@codemonkey.ws>]

On 05/01/2012 09:09 AM, Avi Kivity wrote:
> On 05/01/2012 04:50 PM, Anthony Liguori wrote:
>> 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<avi@redhat.com>   wrote:
>>>>> On 05/01/2012 03:43 PM, Peter Maydell wrote:
>>>>>> On 1 May 2012 13:42, Avi Kivity<avi@redhat.com>   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.
>
> Indeed I wanted to make it_shift as part of the memory core.  But a
> mutator?  It doesn't change in real hardware, so this looks artificial.
> So far all mutators really change at runtime.

QOM has a concept of initialization and realize.  You can change properties 
after initialization but not before realize.

So as long as it_shift can be set after initialization but before realize (which 
I think is roughly memory_region_add_subregion) it doesn't need to be a mutator.

> What is the problem with delaying region initialization until realize?

We need to initialize the MemoryRegion in order to expose it as a property.  We 
want to do that during initialize.  Here's an example:

qom-create isa-i8259 foo
qom-set /peripheral/foo/io it_shift 1
qom-set /peripheral/foo/realize true

For this to work, it_shift needs to be a QOM property of the "io" MemoryRegion. 
  The MemoryRegion needs to be created in instance_init.

>> 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.
>
> These days region names are purely for debugging.  The ABI bit was moved
> to a separate function.

Fair enough.

BTW, in the branch I've posted, I've got a number of memory API conversions or 
removal of legacy interfaces.

Regards,

Anthony Liguori