On Tue, 28 Nov 2017 14:25:08 +0100 Christian Borntraeger <borntrae...@de.ibm.com> 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?