On Sat, Jun 7, 2014 at 12:52 AM, Paolo Bonzini <pbonz...@redhat.com> 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 >
