Re: [Qemu-devel] [PATCH memory v4 00/10] Memory Region QOMification

[Peter Crosthwaite]

On Sat, Jun 7, 2014 at 12:52 AM, Paolo Bonzini <address@hidden> wrote:
> Il 06/06/2014 15:36, Peter Crosthwaite ha scritto:
>
>>> However, I'd rather have the concept bake for a bit by starting with
>>> read-only properties.
>>
>>
>> The just a matter of pulling our the setters?
>
>
> Yes.  You can leave in all the preparatory refactoring.
>
>
>> I guess it can be done
>> but I don't fully understand the motivation.
>
>
> I'm not sure what the interactions should be between the setters and, for
> example, the "realized" property.

Realized of what? MR being just an OBJECT has no realized itself but I
suppose you could think about some correlation to the encapsulating
device (if one even exist - it wont for RAM).

In addition, some memory regions (for
> example PCI BARs) are meant to be moved around by the guest, not the host.
>

So the intention is the free-for-all nature of the non-DEVICE
properties solves this. Some users of MRs are dynamic and can change
setup at run time. That's ok. It leave two options:

1: Properties may be changed at any-time and run-time code (like
PCI-BAR control code) sets the QOM properties.
2: We preserve the current non-QOM API's (e.g.
memory_region_add_subregion) for run-time changers.

If we go with option #2 I guess we can lock down the setters post
realize. A sane policy might be:

1: If the ->owner is a TYPE_DEVICE, setting is OK until the owner is realized.
2: If the owner is not a device, no setting.

Although point 2 makes me sad because it means board code cant use QOM
to wire up RAM.

> By comparison, with getters only not many things can go wrong.
>

True. It's worth nothing however that the setters in the patch do not
change the underlying MR datastructures in any way and all existing
APIs are preserved without QOMification. My reasoning for not
QOMifying the regular MR usage API is pretty much your "let it bake
for a bit". Generally speaking, the setters are yet-to-be-used by
anyone except my follow up RFC work.

>
>>>  I think there are some concepts in the "container"
>>> property that can be generalized.
>>
>>
>> Can you elaborate this a little more?
>
>
> Basically the container property acts as a kind of "backdoor" to express
> many:1 relations (which are a bit ugly to express with the current QOM
> property model).  If object X is on the 1 side and object Y is on the "many"
> side, you then write the path to Y to a property of X.
>

I still maintain that this is valid. The notion that the address space
containers have awareness of the contained but the contained are
oblivious is something of an arbitrary QEMU implementation choice IMO.
It's perfectly valid in real hardware for a bus to be oblivious to
what's on it and the devices attach to it anonymously. The bus then
posts transaction to all attached devices and whoever responds
responds. That's the intended semantic of the 1 linking to the many.
Its the many that is "in the dark".

The 1 -> many linkage is simply inverted to many -> 1 once the
contained region is added to the parent list anyway - just not yet QOM
visible. I think it should work both ways if anything though.
Mandating the many -> 1 unidirectional linkage is awkward IMO.

> There are obvious similarity between the container/address/visible
> properties of a MemoryRegion are very similar to bus/addr/realized that we
> have for -device.

Are you referring to addr as used in Igor's new DIMM work?

  I think we should try and understand better what this
> similarity means, and whether this approach to many:1 relations could become
> a more central part of QOM.
>

Regards,
Peter

> Paolo
>