Messages in this thread | | | Subject | Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest | From | Pierre Morel <> | Date | Tue, 5 Dec 2017 15:47:24 +0100 |
| |
On 05/12/2017 15:30, Cornelia Huck wrote: > On Tue, 5 Dec 2017 15:23:50 +0100 > Pierre Morel <pmorel@linux.vnet.ibm.com> wrote: > >> On 05/12/2017 15:04, Cornelia Huck wrote: >>> On Tue, 5 Dec 2017 08:52:57 +0100 >>> Harald Freudenberger <freude@linux.vnet.ibm.com> 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?
No idea which machine are supported or not, will ask.
What I can say is that I have here a Lpar which does not support QCI. It seems to be a zEC12.2. z13 support it.
> >> >> 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. >
-- Pierre Morel Linux/KVM/QEMU in Böblingen - Germany
| |