qemu-devel
[Top][All Lists]
Advanced

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

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


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


On 11/28/2017 02:17 PM, Halil Pasic wrote:
> 
> 
> 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.

option 1 is still fine with me.

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

I am actually not sure if we really want to have a "user-definable default css" 
anytime
soon. I think it might really open a can of worms in regard to management 
tooling.

What I want now is to enable vfio-ccw for libvirt and Linux guests and for that
we need to lift the restriction of having vfio not in FE.

What is the use case for allowing to specify a different default CSS today? 
Unless
we have any usecase this will make things just more complicated for the benefit 
of what?




reply via email to

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