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. >
@Boris: Does this work for you? Technically it's equivalent to having "cssid-unrestricted" at machine level. I don't really like the idea of indicating unrestricted via something mostly unrelated (at least for me it ain't obvious that having the id of the default css exposed means we got rid of the limitation.). But I'm tied of discussing this, so I'm willing to compromise. Halil
