qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Christian Borntraeger
Subject: Re: [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids
Date: Tue, 28 Nov 2017 15:17:49 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

On 11/28/2017 03:01 PM, Cornelia Huck wrote:
> 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?

We should have flagged vfio-ccw experimental in QEMU then.
e.g. by using x-vfio-ccw or whatever.I dont think we can do that
after the facts.

I am not that deep into vfio-ccw, but I was under the impression that
the missing features should not affect the vfio interface that is
created by libvirt. After all this should just be a "-device vfio-ccw,....."
statement and some setup steps beforehand (unbind + setup of vfio-ccw)

If your concern is the serviceability I think it would be valid for a RHEL
KVM to disable vfio-ccw in the kernel. Maybe we could even provide a config
for QEMU?


PS: I learned from the PCI and CCW experience that I do not want
to upstream kernel/qemu code unless I have a working libvirt code that
shows that the thing will work.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]