[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids
From: |
Cornelia Huck |
Subject: |
Re: [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids |
Date: |
Wed, 22 Nov 2017 13:18:12 +0100 |
On Tue, 21 Nov 2017 19:10:15 +0100
Christian Borntraeger <address@hidden> wrote:
> On 11/21/2017 05:06 PM, Cornelia Huck wrote:
> > On Tue, 21 Nov 2017 15:45:17 +0100
> > Christian Borntraeger <address@hidden> wrote:
> >
> >> On 11/21/2017 02:44 PM, Cornelia Huck wrote:
> >>> On Tue, 21 Nov 2017 12:18:25 +0100
> >>> Halil Pasic <address@hidden> 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
> >>
> >> address@hidden 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.
- [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids, Halil Pasic, 2017/11/21
- Re: [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids, Halil Pasic, 2017/11/21
- Re: [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids, Cornelia Huck, 2017/11/21
- Re: [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids, Halil Pasic, 2017/11/21
- Re: [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids, Cornelia Huck, 2017/11/22
- Re: [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids, Boris Fiuczynski, 2017/11/22
- Re: [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids, Cornelia Huck, 2017/11/22
- Re: [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids, Halil Pasic, 2017/11/23
- Re: [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids, Cornelia Huck, 2017/11/24
- Re: [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids, Christian Borntraeger, 2017/11/24
- Re: [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids, Cornelia Huck, 2017/11/24