Re: [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids

[Cornelia Huck <cohuck@redhat.com>]

On Thu, 23 Nov 2017 14:33:56 +0100
Halil Pasic <pasic@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.

> 
> 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.

> 
> 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.]

> 
> 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 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.

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.