On Tue, 21 Nov 2017 19:10:15 +0100 Christian Borntraeger <borntrae...@de.ibm.com> wrote:
> On 11/21/2017 05:06 PM, Cornelia Huck wrote: > > On Tue, 21 Nov 2017 15:45:17 +0100 > > Christian Borntraeger <borntrae...@de.ibm.com> wrote: > > > >> On 11/21/2017 02:44 PM, Cornelia Huck wrote: > >>> On Tue, 21 Nov 2017 12:18:25 +0100 > >>> Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >>> > >>> Subject: s/unresrict/unrestrict/ > >>> > >>>> The default css 0xFE is currently restricted to virtual subchannel > >>>> devices. The hope when the decision was made was, that non-virtual > >>>> subchannel devices will come around when guest can exploit multiple > >>>> channel subsystems. Since the guests generally don't do, the pain > >>>> of the partitioned (cssid) namespace outweighs the gain. > >>>> > >>>> Let us remove the corresponding restrictions (virtual devices > >>>> can be put only in 0xFE and non-virtual devices in any css except > >>>> the 0xFE), and inform management software property on all ccw > >>>> devices. > >>> > >>> I do not really like dropping the restrictions while still keeping the > >>> default cssid as 0xfe. Putting virtual devices into css 0 seems > >>> completely fine, but putting non-virtual devices into css 0xfe still > >>> feels a bit wrong. What about: > >>> > >>> - Add a property to specify the default cssid. Compat machines use a > >>> default cssid of 0xfe. > >>> - Default to a cssid of 0. > >>> - (optional) Warn when putting a non-virtual device into css 0xfe, > >>> unless it is the default css. > >> > >> To make it more clear, I think the most compatible solution would be to > >> allow > >> vfio-ccw also in FE. (But continue to force virtual devices in FE as well). > >> This was more or less the first proposal that we had. Then we asked > >> ourselves > >> why not also allow virtual devices in 0? > >> > >> I think your proposal of specifying a default css (and then allowing > >> all devices in that) is actually pretty close to Halils proposal. The only > >> difference is that Halils variant keeps fe as default css. > >> So I think we could even combine both approaches. Use Halils patch as a > >> base > >> and in addition provide a way to change the default css away from fe. Have > >> to > >> think about that. > > > > If keeping the default of 0xfe makes the life of management software > > easier, sure. As it is, we seem to be far more entrenched with > > paravirtual devices than I had expected when I first wrote this, so > > 0xfe might be the sensible choice even if mcss-e is available in the > > future. In this case, I think we should lift all cssid restrictions. > > So basically agree with the restriction lifting, but you want to have a > different method of telling libvirt about it? Yes. > [...] > >>> This allows building a commandline in a compat machine that will not > >>> work with old qemus, no? > >> > >> I think this is pretty common to have new devices and things that will not > >> work on old QEMUs but are allowed on compat machines, e.g. virtio-gpu was > >> added in 2.4 but > >> > >> [cborntra@oc7330422307 qemu]$ build/i386-softmmu/qemu-system-i386 -device > >> virtio-gpu-pci -M pc-i440fx-2.2 > >> VNC server running on ::1:5900 > >> > >> works fine > > > > It seems a bit more unexpected, though. > > What I understood from the CPU model discussion is, that the machine version > basically sets the migration > stream format and any "invisible" setting that the user cannot influence. But > it is not there to the fence > the user from specifying new devices or new CPU types (that the old QEMU does > not know) or different > command lines. You get a compatible machine if you specify an identical > command line that will work for > both. So we really need a good changelog entry for that one. Mind you, I'm not really opposed; but if a trap is there, it would be good to have at least some signage. > > > > (And I'm still not quite sure how all of this interacts with the squash > > option.) > > I think we should deprecate the squash option and not use it to simplify > things. I certainly want the squash option to go out when we do this. I just was a bit unsure about any interactions, but it seems it is not really problematic.
