[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Halil Pasic
Subject: Re: [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids
Date: Tue, 28 Nov 2017 15:11:15 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

On 11/24/2017 01:46 PM, Cornelia Huck wrote:
> On Thu, 23 Nov 2017 14:33:56 +0100
> Halil Pasic <address@hidden> 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:

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]