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

[Halil Pasic]

On 11/28/2017 01:24 PM, Christian Borntraeger wrote:
> 
> 
> On 11/28/2017 01:14 PM, Cornelia Huck wrote:
>> On Tue, 28 Nov 2017 12:49:04 +0100
>> Boris Fiuczynski <address@hidden> wrote:
>>
>>> On 11/28/2017 11:22 AM, Cornelia Huck wrote:
>>>> On Tue, 28 Nov 2017 09:53:15 +0100
>>>> Boris Fiuczynski <address@hidden> wrote:
>>>>   
>>>>> On 11/27/2017 05:56 PM, Cornelia Huck wrote:  
>>>>>> Proposal 2: Export the default cssid as a machine property. If this
>>>>>> property exists, it also implies that devices can be put into any css
>>>>>> image (although it makes the most sense to put them into the default
>>>>>> css image as indicated by the property). Can be made r/w later if it is
>>>>>> too much for 2.12.  
>>>>> Just as a side discussion:
>>>>> I know of qom command query-machines but that does not seem to provide
>>>>> the information you suggest to use with proposal 2.  
>>> Sorry, I meant query-command-line-options.
>>>
>>>>> What qom command do you suggest to use for the introspection of the
>>>>> machine options access mode?
>>>>>  
>>>>
>>>> Is qom-get what you are looking for?
>>>>
>>>> virsh # qemu-monitor-command vm1 --pretty '{ "execute": "qom-get", 
>>>> "arguments": { "path": "/machine/", "property": "accel"} }'
>>>> {
>>>>    "return": "kvm",
>>>>    "id": "libvirt-18"
>>>> }
>>>>   
>>> How do you find out from returned values that accel is r/o or r/w?
>>>
>>
>> I read some code and it turns out that we aren't really prepared for
>> any r/o opts... sigh.
>>
>> So, proposal 2 is only viable if we make it configurable from the start.
> 
> I really really dislike option 2.
> Binding the capability to "assign freely" to a property that is named default 
> css is
> just wrong. Both capabilities are really independent.
> 

I fully agree with Christian.

> I strongly prefer option 3.
> 

In the meanwhile I strongly prefer option 1 (at the ccw devices). I've just
sent a v2, and IMHO it shows the limitations of machine properties very well.

>>
>> Halil, do you see any chance to do this for 2.12? There's plenty of
>> time left, and I don't think it's too hard. If not, we don't have any
>> other option than proposal 3, even though I don't like it a lot.
>>

I do think we have enough time to do this right. And of course I'm willing
to do it right. IMHO the 3 options summarized by Connie are not the only
options. But if we go for reworking our QOM composition tree, it will take
a lot of discussion. I'm not sure all the required people have enough spare
time for that.

Halil