Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest

[Tony Krowiak]

On 12/05/2017 09:23 AM, Pierre Morel wrote:
> On 05/12/2017 15:04, Cornelia Huck wrote:
> > On Tue, 5 Dec 2017 08:52:57 +0100
> > Harald Freudenberger <freude@xxxxxxxxxxxxxxxxxx> wrote:
> >
> > > On 12/02/2017 02:30 AM, Tony Krowiak wrote:
> >
> > > > I agree with your suggestion that defining a new CPU model feature 
> > > > is probably
> > > > the best way to resolve this issue. The question is, should we 
> > > > define a single
> > > > feature indicating whether AP instructions are installed and set 
> > > > features bits
> > > > for the guest based on whether or not they are set in the linux 
> > > > host, or should
> > > > we define additional CPU model features for turning features bits 
> > > > on and off?
> > > > I guess it boils down to what behavior is expected for the AP bus 
> > > > running on
> > > > the linux guest. Here is a rundown of the facilities bits 
> > > > associated with AP
> > > > and how they affect the behavior of the AP bus:
> > > >
> > > > * STFLE.12 indicates whether the AP query function is available. If 
> > > > this bit
> > > >    is not set, then the AP bus scan will only test domains 0-15. 
> > > > For example,
> > > >    if adapters 4, 5, and 6 and domains 12 and 71 (0x47) are 
> > > > installed, then AP
> > > >    queues 04.0047, 05.0047 and 06.0047 will not be made available.
> > > STFLE 12 is the indication for Query AP Configuration Information 
> > > (QCI) available.
> > > > * STFLE.15 indicates whether the AP facilities test function is 
> > > > available. If
> > > >    this bit is not set, then the CEX4, CEX5 and CEX6 device drivers 
> > > > discovered
> > > >    by the AP bus scan will not get bound to any AP device drivers. 
> > > > Since theI think
> > > > STFLE.12
> > > >    AP matrix model supports only CEX4 and greater, no devices will 
> > > > be bound
> > > >    to any driver for a guest.
> > > This T-Bit extension to the TAPQ subfunction is a must have. When 
> > > kvm only
> > > supports CEX4 and upper then this bit could also act as the 
> > > indicator for
> > > AP instructions available. Of course if you want to implement pure 
> > > virtual
> > > full simulated AP without any real AP hardware on the host this bit 
> > > can't
> > > be the indicator.
> >
> > It would probably make sense to group these two together. Or is there
> > any advantage in supporting only a part of it?
> >
> > > > * STFLE.65 indicates whether AP interrupts are available. If this 
> > > > bit is not
> > > >    set, then the AP bus will use polling instead of using interrupt 
> > > > handlers
> > > >    to process AP events.
> >
> > So, does this indicate "adapter interrupts for AP" only? If so, we
> > should keep this separate and only enable it when we have the gisa etc.
> > ready.
>
> Yes, STFLE 65, it is for AP only.
>
> QCI, STFLE 12, is no present on older systems, in this case AP uses 
> TAPQ to retrieve information for each AP
>
> So for my point of view, it make sense to separate the three 
> facilities to enable migration on older syste
In the interest of keeping things simple, this makes sense.
> Pierre