Re: [qemu-s390x] [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids

[Cornelia Huck]

On Tue, 28 Nov 2017 14:25:08 +0100
Christian Borntraeger <address@hidden> wrote:

> On 11/28/2017 02:17 PM, Halil Pasic wrote:

> > In the meanwhile I strongly prefer option 1 (at the ccw devices). I've just
> > sent a v2, and IMHO it shows the limitations of machine properties very 
> > well.  
> 
> option 1 is still fine with me.

I still dislike it a lot. Machine properties have their own set of
problems, but I think devices are really the wrong place for a global
property.

> 
> >   
> >>>
> >>> Halil, do you see any chance to do this for 2.12? There's plenty of
> >>> time left, and I don't think it's too hard. If not, we don't have any
> >>> other option than proposal 3, even though I don't like it a lot.
> >>>  
> > 
> > I do think we have enough time to do this right. And of course I'm willing
> > to do it right. IMHO the 3 options summarized by Connie are not the only
> > options. But if we go for reworking our QOM composition tree, it will take
> > a lot of discussion. I'm not sure all the required people have enough spare
> > time for that.
> > 
> > Halil  
> 
> I am actually not sure if we really want to have a "user-definable default 
> css" anytime
> soon. I think it might really open a can of worms in regard to management 
> tooling.

Fair enough, there's really no short-term use case.

> What I want now is to enable vfio-ccw for libvirt and Linux guests and for 
> that
> we need to lift the restriction of having vfio not in FE.

This, however, worries me. I don't really consider vfio-ccw ready for
prime time yet. We still need to figure out path handling at the very
least. And I'm still not sure that our non-handling of halt/clear won't
cause major issues with e.g. a storage server error recovery.

Can we flag vfio-ccw as experimental or such in libvirt?