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

[Cornelia Huck]

On Mon, 27 Nov 2017 16:09:09 +0100
Boris Fiuczynski <address@hidden> wrote:

> On 11/27/2017 03:13 PM, Halil Pasic wrote:
> > 
> > 
> > On 11/27/2017 02:19 PM, Cornelia Huck wrote:  
> >> On Mon, 27 Nov 2017 14:11:57 +0100
> >> Halil Pasic <address@hidden> wrote:
> >>  
> >>> On 11/27/2017 01:56 PM, Cornelia Huck wrote:  
> >>>> On Fri, 24 Nov 2017 17:39:04 +0100
> >>>> Halil Pasic <address@hidden> wrote:
> >>>>      
> >>>>> On 11/24/2017 05:15 PM, Cornelia Huck wrote:  
> >>  
> >>>>>> (Unless we simply make this a "default cssid" prop after all - then it
> >>>>>> would be more than just a simple indication for libvirt...)
> >>>>>>        
> >>>>>
> >>>>> We are now talking about the "cssid-unrestricted" property. The default
> >>>>> cssid is not something I would like to do any time soon.  
> >>>>
> >>>> What's so bad about this? As said above, I think it would be much more
> >>>> useful. If libvirt can detect r/o vs. r/w for properties, we can simply
> >>>> start out with a r/o variant now...
> >>>>      
> >>>
> >>> I'm not sure I understand you. Are you proposing the following:
> >>> Drop the restriction, but don't indicate this via a read only
> >>> "cssid-unrestricted" device property but via a "default-css"
> >>> read only machine property.
> >>>
> >>> Libvirt then should know that if "default-css" is present then
> >>> we don't have this virtual into 0xfe and non virtual into 0xfd
> >>> restriction any more.  
> >>
> >> Yes.
> >>  
> > 
> > @Boris:
> > Does this work for you? Technically it's equivalent to having
> > "cssid-unrestricted" at machine level.
> > 
> > I don't really like the idea of indicating unrestricted via
> > something mostly unrelated (at least for me it ain't obvious that
> > having the id of the default css exposed means we got rid of the
> > limitation.). But I'm tied of discussing this, so I'm willing to
> > compromise.
> > 
> > Halil
> >   
> I agree with Christian that we should not throw the "setting of a 
> default cssid" together with "unrestricted cssid" and than use read/only 
> and read/write to distinguish between the two!
> 

OK, let's step back and summarize a bit.

Current situation:
- virtual devices must go into 0xfe, non-virtual devices must go into
  non-0xfe
- 0xfe is the default cssid; non-mcss-e OSs see only devices in there
- to expose non-virtual devices to today's guests, you need to use the
  squash-mcss parameter, which tries to put non-virtual devices into
  the same place in css 0xfe

This is problematic in various ways (potential for incomprehensible
errors, amongst others), so we agreed that the way to go is to drop the
virtual-vs-non-virtual cssid restrictions and allow any device in any
css image.

Now, we need a way for libvirt to detect this, so that it knows that it
can put e.g. vfio-ccw devices in the same css image as virtio devices.

Proposal 1: Use a device attribute to show that the device can be put
anywhere. This approach feels wrong to me (the non-restriction is not a
property of the individual device, but of the whole css resp. the
machine), so I would continue to veto this.

Proposal 2: Export the default cssid as a machine property. If this
property exists, it also implies that devices can be put into any css
image (although it makes the most sense to put them into the default
css image as indicated by the property). Can be made r/w later if it is
too much for 2.12.

Proposal 3: Add a machine property that indicates cssids are not
restricted. Later, optionally add a second property that exposes the
default cssid and makes it configurable.

Personally, I prefer 2 (especially as this also allows to find out
where the best place to put devices for non-mcss-e enabled guests is),
but I could live with 3 as well (if making this r/w later would be
problematic for libvirt.)

(In every case, we would deprecate and later remove the squash
parameter.)

[As an aside, how hard is it to make the default cssid configurable? At
a glance, it does not seem too bad to me.]