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

[Christian Borntraeger <borntraeger@de.ibm.com>]

On 11/21/2017 02:44 PM, Cornelia Huck wrote:
> On Tue, 21 Nov 2017 12:18:25 +0100
> Halil Pasic <pasic@linux.vnet.ibm.com> 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:

I see no fundamental reason to not allow any device everywhere. And yes,
if we would start today, we would not use fe but 0. But we already have 
code outside (libvirt), we have exisiting guest xmls and we have documentation
outside and we have  communicated that via  a lot of channels. So if we want
to stay compatible we should really keep css 0xfe as the default css (that
is seen as css 0 anyway for non-mcss-e guests).

The nice thing with Halils approach is that it will continue to work
if future guests enable MCSS-E and it is the most minimal change by just
lifting a restriction in terms of flexibility. 

> 
> - 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.