Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753177AbdLEOEg convert rfc822-to-8bit (ORCPT ); Tue, 5 Dec 2017 09:04:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49682 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753026AbdLEOEa (ORCPT ); Tue, 5 Dec 2017 09:04:30 -0500 Date: Tue, 5 Dec 2017 15:04:21 +0100 From: Cornelia Huck To: Harald Freudenberger Cc: Tony Krowiak , Christian Borntraeger , Martin Schwidefsky , freude@de.ibm.com, pmorel@linux.vnet.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 Subject: Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest Message-ID: <20171205150421.01ec1ed8.cohuck@redhat.com> In-Reply-To: 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> Organization: Red Hat GmbH MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 05 Dec 2017 14:04:30 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2320 Lines: 40 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.