qemu-s390x
[Top][All Lists]
Advanced

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

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


From: Christian Borntraeger
Subject: Re: [qemu-s390x] [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids
Date: Fri, 24 Nov 2017 14:01:20 +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.
> 
>>
>> 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.

I first liked the idea to have it as a property of the css, but 
this is all pretty unclear how to do right. I start to think that going with
Halils first patch (a property per virtio device) is going to be the most
simple solution without causing any harm. After all as of today we only want 
to have a way to tell libvirt that devices can be everywhere. Specifying the
default css might be something that we want to have in the future, but here
future might even mean never.




reply via email to

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