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

[Dong Jia Shi]

* Cornelia Huck <address@hidden> [2017-11-27 17:56:07 +0100]:

> 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
When squashing, everything will be squashed to css 0 which is the
deafult css in this case.

[No effect to the conclusions below, but better to clarify.:-]

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

-- 
Dong Jia Shi