From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 192A1C4321D for ; Tue, 21 Aug 2018 18:55:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D73E72177F for ; Tue, 21 Aug 2018 18:55:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D73E72177F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.ibm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727608AbeHUWQU (ORCPT ); Tue, 21 Aug 2018 18:16:20 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:39684 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727549AbeHUWQU (ORCPT ); Tue, 21 Aug 2018 18:16:20 -0400 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w7LIsDNB094342 for ; Tue, 21 Aug 2018 14:54:59 -0400 Received: from e06smtp04.uk.ibm.com (e06smtp04.uk.ibm.com [195.75.94.100]) by mx0a-001b2d01.pphosted.com with ESMTP id 2m0ndtqmgn-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 21 Aug 2018 14:54:59 -0400 Received: from localhost by e06smtp04.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 21 Aug 2018 19:54:56 +0100 Received: from b06cxnps4076.portsmouth.uk.ibm.com (9.149.109.198) by e06smtp04.uk.ibm.com (192.168.101.134) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Tue, 21 Aug 2018 19:54:53 +0100 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w7LIspsk19857500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 21 Aug 2018 18:54:51 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C35AAA404D; Tue, 21 Aug 2018 21:54:51 +0100 (BST) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D928CA4051; Tue, 21 Aug 2018 21:54:49 +0100 (BST) Received: from oc0155643701.ibm.com (unknown [9.145.63.66]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTP; Tue, 21 Aug 2018 21:54:49 +0100 (BST) Subject: Re: [PATCH v9 22/22] s390: doc: detailed specifications for AP virtualization To: Tony Krowiak , Cornelia Huck , Tony Krowiak Cc: linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, freude@de.ibm.com, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, borntraeger@de.ibm.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, jjherne@linux.vnet.ibm.com, thuth@redhat.com, pasic@linux.vnet.ibm.com, berrange@redhat.com, fiuczy@linux.vnet.ibm.com, buendgen@de.ibm.com, frankja@linux.ibm.com References: <1534196899-16987-1-git-send-email-akrowiak@linux.vnet.ibm.com> <1534196899-16987-23-git-send-email-akrowiak@linux.vnet.ibm.com> <20180820180359.38cc4af3.cohuck@redhat.com> From: Halil Pasic Date: Tue, 21 Aug 2018 20:54:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 x-cbid: 18082118-0016-0000-0000-000001F9CC1B X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18082118-0017-0000-0000-000032501CE0 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-08-21_09:,, 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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808210193 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/20/2018 10:16 PM, Tony Krowiak wrote: >> Does the SIE complain if you specify a control >> domain that the host does not have access to (I'd guess so)? > > The SIE does not complain if you specify a domain to which the host - or a > lower level guest - does not have access. The firmware performs a logical > AND of the guest's and hosts's - or lower level guest's - APMs, AQMs and ADMs Rather a bit-wise AND, I guess (of the same type masks corresponding to Guest 1 and Guest 2). The result of a logical AND is a logical value (true or false) as far as I remember. > to create effective masks EAPM, EAQM and EADM. Only devices corresponding to > the bits set in the EAPM, EAQM and EADM will be accessible by the guest. I'm not sure what is the intended meaning of 'the SIE complains'. If it means getting out of (SIE when interpreting lets say an NQAP under the discussed circumstances) with some sort of error code, I think Tony's answer, ' SIE does not complain' makes a lot of sense. It's the guest that's is trying to stretch further than the blanket reaches, and it's the guest that needs to be educated on this fact. AFAIR SIE does the right thing (whatever the right thing is) and we don't have to worry about it. As a matter of fact I can't recall exactly what is supposed to happen when a guest tries to modify a domain such that the guest does not have privileges to modify (in terms of EADM, either because the guest or because the host does not have the corresponding bit set). I'm sure I did not try it out. Tony did you test this scenario? (BTW my best guess at the moment is, that the situation is handled via the command-reply.) Regards, Halil