* Cornelia Huck <coh...@redhat.com> [2017-11-27 17:56:07 +0100]: > 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 When squashing, everything will be squashed to css 0 which is the deafult css in this case.
[No effect to the conclusions below, but better to clarify.:-] > > 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.] > -- Dong Jia Shi
