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

[Cornelia Huck]

On Tue, 5 Dec 2017 15:23:50 +0100
Pierre Morel <address@hidden> wrote:

> On 05/12/2017 15:04, Cornelia Huck wrote:
> > On Tue, 5 Dec 2017 08:52:57 +0100
> > Harald Freudenberger <address@hidden> 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 
> >>> the
> >>>    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

Dumb question: How old? Machines that are still supported?

> 
> So for my point of view, it make sense to separate the three facilities 
> to enable migration on older systems.

OK, if STFLE 12 might not be present (pending my question above), but
STFLE 15 is indeed a must-have, we should split this up.