From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933883AbdKBPxY (ORCPT ); Thu, 2 Nov 2017 11:53:24 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:41422 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932244AbdKBPxW (ORCPT ); Thu, 2 Nov 2017 11:53:22 -0400 Subject: Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest To: Tony Krowiak , Martin Schwidefsky , freude@de.ibm.com Cc: linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, heiko.carstens@de.ibm.com, cohuck@redhat.com, kwankhede@nvidia.com, bjsdjshi@linux.vnet.ibm.com, pbonzini@redhat.com, alex.williamson@redhat.com, pmorel@linux.vnet.ibm.com, alifm@linux.vnet.ibm.com, mjrosato@linux.vnet.ibm.com, qemu-s390x@nongnu.org, jjherne@linux.vnet.ibm.com, thuth@redhat.com, pasic@linux.vnet.ibm.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> From: Christian Borntraeger Date: Thu, 2 Nov 2017 16:53:16 +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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17110215-0040-0000-0000-00000409D26A X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17110215-0041-0000-0000-000020AC5F76 Message-Id: <6d9ae0c1-6f64-1562-bf10-864cf66e3a08@de.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-11-02_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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711020197 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/02/2017 04:36 PM, Tony Krowiak wrote: > On 11/02/2017 08:08 AM, Christian Borntraeger wrote: >> >> On 10/16/2017 11:25 AM, Martin Schwidefsky wrote: >>> On Fri, 13 Oct 2017 13:39:04 -0400 >>> Tony Krowiak wrote: >>> >>>> Sets up the following facilities bits to enable the specified AP >>>> facilities for the guest VM: >>>> * STFLE.12: Enables the AP Query Configuration Information >>>> facility. The AP bus running in the guest uses >>>> the information returned from this instruction >>>> to configure AP adapters and domains for the >>>> guest machine. >>>> * STFLE.15: Indicates the AP facilities test is available. >>>> The AP bus running in the guest uses the >>>> information. >>>> >>>> Signed-off-by: Tony Krowiak >>>> --- >>>> arch/s390/tools/gen_facilities.c | 2 ++ >>>> 1 files changed, 2 insertions(+), 0 deletions(-) >>>> >>>> diff --git a/arch/s390/tools/gen_facilities.c b/arch/s390/tools/gen_facilities.c >>>> index 70dd8f1..eeaa7db 100644 >>>> --- a/arch/s390/tools/gen_facilities.c >>>> +++ b/arch/s390/tools/gen_facilities.c >>>> @@ -74,8 +74,10 @@ struct facility_def { >>>> 8, /* enhanced-DAT 1 */ >>>> 9, /* sense-running-status */ >>>> 10, /* conditional sske */ >>>> + 12, /* AP query configuration */ >>>> 13, /* ipte-range */ >>>> 14, /* nonquiescing key-setting */ >>>> + 15, /* AP special-command facility */ >>>> 73, /* transactional execution */ >>>> 75, /* access-exception-fetch/store indication */ >>>> 76, /* msa extension 3 */ >>> With this all KVM guests will always have the AP instructions available, no? >>> In principles I like this approach, but it differs from the way z/VM does things, >>> there the guest will get an exception if it tries to execute an AP instruction >>> if there are no AP devices assigned to the guest. I wonder if there is a reason >>> why z/VM does it the way it does. >> A good question. For LPAR it seems that you have AP instructions even if you have >> no crypto cards. >> > I don't believe these facilities control whether or not AP instructions will be available > > to the guest. This is actually handled by your patch2 enabling the ECA bit. I think we must decide if we want to be able to disable these instructions via the cpu model. If yes we must then couple the facilities with the enablement.