Re: [qemu-s390x] [Qemu-devel] [PATCH 1/3] s390x/css: unrestrict cssids

[Cornelia Huck]

On Mon, 4 Dec 2017 16:02:14 +0100
Halil Pasic <address@hidden> wrote:

> On 12/04/2017 12:10 PM, Cornelia Huck wrote:
> > On Fri,  1 Dec 2017 15:31:34 +0100
> > Halil Pasic <address@hidden> wrote:
> >   
> >> 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 guests can exploit multiple
> >> channel subsystems. Since current guests don't do that, the pain of the
> >> partitioned (cssid) namespace outweighs the gain.
> >>
> >> 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.  
> > 
> > Doubled paragraph?
> >   
> 
> Yep. Copy paste mistake.
> 
> >>
> >> Let us remove the corresponding restrictions (virtual devices
> >> can be put only in 0xfe and non-virtual devices in any css except
> >> the 0xfe -- while s390-squash-mcss then remaps everything to cssid 0).
> >>
> >> At the same time, change our schema for generating css bus ids to put
> >> both virtual and non-virtual devices into the default css (spilling over
> >> into other css images, if needed). The intention is to deprecate
> >> s390-squash-mcss. Whit this change devices without a specified devno  
> > 
> > s/Whit/With/  
> 
> Nod
> 
> >   
> >> won't end up hidden to guests not supporting multiple channel subsystems,
> >> unless this can not be avoided (default css full).
> >>
> >> Deprecaton of s390-squash-mcss and indicating the changes via QMP is  
> 
> s/Deprecaton/Deprecation/
> 
> >> expected to follow soon (as separate commits).  
> > 
> > Let's drop this paragraph (the qmp interface should be squashed in, and
> > you mention the deprecation right above.)
> >   
> >>
> >> The adverse effect of getting rid of the restriction on migration should
> >> not be too severe.  Vfio-ccw devices are not live-migratable yet, and for
> >> virtual devices using the extra freedom would only make sense with the
> >> aforementioned guest support in place.
> >>
> >> The auto-generated bus ids are affected by both changes. We hope to not
> >> encounter any auto-generated bus ids in production as Libvirt is always
> >> explicit about the bus id.  Since 8ed179c937 ("s390x/css: catch section
> >> mismatch on load", 2017-05-18) the worst that can happen because the same
> >> device ended up having a different bus id is a cleanly failed migration.
> >> I find it hard to reason about the impact of changed auto-generated bus
> >> ids on migration for command line users as I don't know which rules is
> >> such an user supposed to follow.  
> > 
> > Should we document somewhere that guests supposed to be migrated should
> > make sure that they use explicit devnos?
> >   
> 
> I think having a document collecting such migration rules and best practices
> for command line users (and implicitly also for implementers of management
> software) would be a good idea. Maybe there is such a documentation, but
> I don't know where. The devnos should be a part of it for sure. But I'm
> not volunteering for creating this kind of documentation. Natural languages
> aren't my forte.

I would not mind someone else doing this.

> 
> >>
> >> Another pain-point is down- or upgrade of QEMU for command line users.
> >> The old way and the new way of doing vfio-ccw are mutually incompatible.
> >> Libvirt is only going to support the new way, so for libvirt users, the
> >> possible problems at QEMU downgrade are the following. If a domain
> >> contains virtual devices placed into a css different than 0xfe the domain
> >> will refuse to start with a QEMU not having this patch. Putting devices
> >> into a css different that 0xfe however won't make much sense in the near
> >> future (guest support). Libvirt will refuse to do vfio-ccw with a QEMU
> >> not having this patch. This is business as usual.  
> > 
> > My writing style would be to have this as a shorter, bulleted list -
> > but no need to rewrite this if this is understandable to the others on
> > cc:
> >   
> 
> If you want, we can iterate on the description. My primary concern was
> to agree on how to advertise this change.

Let's skip that.

> 
> >>
> >> Signed-off-by: Halil Pasic <address@hidden>