On Mon, 27 Nov 2017 16:09:09 +0100 Boris Fiuczynski <fiu...@linux.vnet.ibm.com> wrote:
> On 11/27/2017 03:13 PM, Halil Pasic 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. > >> > > > > @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 > > > I agree with Christian that we should not throw the "setting of a > default cssid" together with "unrestricted cssid" and than use read/only > and read/write to distinguish between the two! > OK, let's step back and summarize a bit. Current situation: - virtual devices must go into 0xfe, non-virtual devices must go into non-0xfe - 0xfe is the default cssid; non-mcss-e OSs see only devices in there - to expose non-virtual devices to today's guests, you need to use the squash-mcss parameter, which tries to put non-virtual devices into the same place in css 0xfe This is problematic in various ways (potential for incomprehensible errors, amongst others), so we agreed that the way to go is to drop the virtual-vs-non-virtual cssid restrictions and allow any device in any css image. Now, we need a way for libvirt to detect this, so that it knows that it can put e.g. vfio-ccw devices in the same css image as virtio devices. Proposal 1: Use a device attribute to show that the device can be put anywhere. This approach feels wrong to me (the non-restriction is not a property of the individual device, but of the whole css resp. the machine), so I would continue to veto this. 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. Proposal 3: Add a machine property that indicates cssids are not restricted. Later, optionally add a second property that exposes the default cssid and makes it configurable. Personally, I prefer 2 (especially as this also allows to find out where the best place to put devices for non-mcss-e enabled guests is), but I could live with 3 as well (if making this r/w later would be problematic for libvirt.) (In every case, we would deprecate and later remove the squash parameter.) [As an aside, how hard is it to make the default cssid configurable? At a glance, it does not seem too bad to me.]
