On 11/27/2017 03:03 PM, Christian Borntraeger wrote: > > > On 11/27/2017 02:19 PM, Cornelia Huck wrote: >> On Mon, 27 Nov 2017 14:11:57 +0100 >> Halil Pasic <pa...@linux.vnet.ibm.com> wrote: >> >>> On 11/27/2017 01:56 PM, Cornelia Huck wrote: >>>> On Fri, 24 Nov 2017 17:39:04 +0100 >>>> Halil Pasic <pa...@linux.vnet.ibm.com> wrote: >>>> >>>>> On 11/24/2017 05:15 PM, Cornelia Huck wrote: >> >>>>>> (Unless we simply make this a "default cssid" prop after all - then it >>>>>> would be more than just a simple indication for libvirt...) >>>>>> >>>>> >>>>> We are now talking about the "cssid-unrestricted" property. The default >>>>> cssid is not something I would like to do any time soon. >>>> >>>> What's so bad about this? As said above, I think it would be much more >>>> useful. If libvirt can detect r/o vs. r/w for properties, we can simply >>>> start out with a r/o variant now... >>>> >>> >>> I'm not sure I understand you. Are you proposing the following: >>> Drop the restriction, but don't indicate this via a read only >>> "cssid-unrestricted" device property but via a "default-css" >>> read only machine property. >>> >>> Libvirt then should know that if "default-css" is present then >>> we don't have this virtual into 0xfe and non virtual into 0xfd >>> restriction any more. >> >> Yes. > > Unless we implement the ability to set the default css _NOW_, I would > prefer to not couple different things (ability to change default-css > and abiltity to move devices around). Otherwise we might need to change > things again if we find out that our plan does not work out. > > So what about having > - a cssid-unrestricted machine property that shows that devices can move > around > - later a default-css machine property when we actually implement that > > ? >
I can -- compromise and -- live with that. I'm still not convinced that having the property at the machines is better. But I don't think, I can convince Connie that having it at the devices is better. I would like to get this done. > Christian > >