Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752616AbdLEOYL (ORCPT ); Tue, 5 Dec 2017 09:24:11 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:49956 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752176AbdLEOYG (ORCPT ); Tue, 5 Dec 2017 09:24:06 -0500 Subject: Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest To: Cornelia Huck , Harald Freudenberger Cc: Tony Krowiak , Christian Borntraeger , Martin Schwidefsky , freude@de.ibm.com, mjrosato@linux.vnet.ibm.com, pasic@linux.vnet.ibm.com, Boris Fiuczynski , linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, heiko.carstens@de.ibm.com, kwankhede@nvidia.com, bjsdjshi@linux.vnet.ibm.com, pbonzini@redhat.com, alex.williamson@redhat.com, alifm@linux.vnet.ibm.com, qemu-s390x@nongnu.org, jjherne@linux.vnet.ibm.com, thuth@redhat.com References: <1507916344-3896-1-git-send-email-akrowiak@linux.vnet.ibm.com> <1507916344-3896-20-git-send-email-akrowiak@linux.vnet.ibm.com> <20171016112510.39e9c330@mschwideX1> <3e836f59-3ef1-57d8-d6df-b66011c173c4@de.ibm.com> <6d9ae0c1-6f64-1562-bf10-864cf66e3a08@de.ibm.com> <40cdab64-9eeb-02bd-f260-80e9da8c9034@linux.vnet.ibm.com> <35f17b01-49e0-eafb-ad05-c642c579dd3a@de.ibm.com> <8c8c7a0e-2ae4-443b-9444-e2022436c3ee@linux.vnet.ibm.com> <20171205150421.01ec1ed8.cohuck@redhat.com> From: Pierre Morel Date: Tue, 5 Dec 2017 15:23:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171205150421.01ec1ed8.cohuck@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 x-cbid: 17120514-0012-0000-0000-0000059594CD X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17120514-0013-0000-0000-000019109295 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-12-05_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1712050208 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2725 Lines: 57 On 05/12/2017 15:04, Cornelia Huck wrote: > On Tue, 5 Dec 2017 08:52:57 +0100 > Harald Freudenberger 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 So for my point of view, it make sense to separate the three facilities to enable migration on older systems. Pierre -- Pierre Morel Linux/KVM/QEMU in Böblingen - Germany