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 <fiu...@linux.vnet.ibm.com> wrote: >>> >>>> On 11/28/2017 11:22 AM, Cornelia Huck wrote: >>>>> On Tue, 28 Nov 2017 09:53:15 +0100 >>>>> Boris Fiuczynski <fiu...@linux.vnet.ibm.com> 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?