On 11/24/2017 01:46 PM, Cornelia Huck wrote: > On Thu, 23 Nov 2017 14:33:56 +0100 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> Having an adequate representation for the css in QOM would be certainly >> interesting, but at the same time (IMHO) is somewhat challenging. Let me >> make some observations, which should some of my concerns. >> >> We already have virtual-css-bridge which is the QOM type/object that >> kind of conceptually stands for the channel subsystem as subsystem (not >> for the images but for the big whole). >> >> The virtual-css-bridge is however non-user-creatable (inherited this from >> sysbus-device-type), so I doubt it can be used for specifying properties >> on the command line. That is no good for something like specifying the >> default css (image, not the big whole). What we usually do is pull up the >> property to the machine level. But this comes at a cost. > > It might be better to not have inherit this from sysbus (at the price > of doing some stuff like reset handling ourselves.) Not sure if that > helps for this concrete issue, though. >
My point was: I'm not comfortable with our QOM interfaces. I would like to become comfortable with them, but I we should make it a pre-req for solving the problem at hand (management software support for vfio-ccw). Thus I would prefer to resume this discussion later. I will argue whit whatever I disagree though (in this reply), just to not forget. >> >> A small digression, Christian pointed me to the -set cmd line option. >> I've done a quick PoC (assigned an id in code and did the command line) >> but I failed. >> >> Furthermore the (canonical) QOM path of virtual-css-bridge is >> /machine/unattached/device[2] (there is a link from sysbus but the child >> property is connecting it to unattached, see [1]). I would prefer seeing >> and working wit something like /machine/css/default_css. > > That's because the parent reference is not set up before registering > the device. It should do a object_property_add_child() (as e.g. the > flic does) so that it will show up as attached to the machine. > I read it as this is a bug. >> >> Under the virtual-css-bridge there is a virtual-css-bus called >> QOM-path-ly virtual-css, so it's canonical path is >> /machine/unattached/device[2]/virtual-css. The virtual-css-bus is in qdev >> a bus however. AFAIU buses are not very suitable for hosting properties >> (as one can't attach/add buses directly only via devices. >> >> Another interesting fact is that virtio-ccw devices are QOMly only linked >> to their qdev parent bus, the virtual-ccs-bus, and are a QOMly children >> of /machine/peripheral (see [2]). > > That's true of anything added via qdev_device_add(). > > [As an aside, that's why the autogenerated net devices show up as > unattached as well. Not sure if it is worth doing anything about it.] > I think, in the meanwhile I understood why. >> >> To sum it up: I'm pretty confused with the QOM view of things. >> >> My intuition would be that the object/device has to be somewhere between >> /machine and the vrtio-ccw devices in the children graph. And since we >> want to do a command line controllable properties on the css object, the >> object probably needs to be a device. >> >> Given what we currently have I don't see a good place for this css >> object. > > I don't think qom is supposed to map the hardware hierarchy (I might be > mistaken, though.) I disagree. Have a look at: https://wiki.qemu.org/Features/QOM#Naming_in_QOM The example pretty much looks like it is supposed to reflect the devices and buses structure. QOM is a hierarchy, if it does not map to the hardware hierarchy to what hierarchy is it supposed to map? See also: > I don't see anything speaking against a css object > attached to the machine (if we can't use the css bridge for that > purpose.) > >> >> Furthermore I'm currently under the impression that every non-abstract >> device is user creatable (but some can be created only implicitly). Some >> seem to go even further and say should workwith device-add [3]. > > There are quite a number of devices for which being user-createable > does not make any sense at all. > I disagree. A device that can not be created (by the user, only user create devices) is useless. You are probably speaking about implicit/ explicit. In my interpretation the virtual-css-bridge is created by the user. If the user specifies a machine deriving form s390-virtio-ccw then the user implicitly creates a virtual-css-bridge. But if the user user the same binary to create a 'none' machine he does not create a virtual-css-bridge. Another interesting example is virtio-net. It is created implicity by he user with a s390-virtio-ccw if it is not created explicitly by the user and if the user did not explicitly disable implicit creation. For machine type none no virtio-net is created implicitly. So the user using a s390-virtio-ccw has 3 options: create it implicitly, create it explicitly, disable implicit creation. Of course if there has to be exactly one (or N) a certain device for a machine, and the device has not user adjustable properties, then there is not reason for the user for wanting to explicitly specify the device on the command line. I think, you misunderstood me. If not. Please tell me how do we set properties for non-user-createable non-abstract devices on the command line? > What _could_ make sense is having a way to add css images manually and > having specify whether they are default. (Obviously not when they are > hotplugged.) For compatibility, we could create css image 0xfe > automatically as default if none has been defined. Not sure how easy it > would be to get this right, though. >