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