From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753006AbdK1Ajo (ORCPT ); Mon, 27 Nov 2017 19:39:44 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:51894 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752421AbdK1Ajm (ORCPT ); Mon, 27 Nov 2017 19:39:42 -0500 Subject: Re: [RFC 00/19] KVM: s390/crypto/vfio: guest dedicated crypto adapters To: Cornelia Huck Cc: Pierre Morel , 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, 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> <5baf5f90-6cac-3c09-7b66-1bc8b30b8093@linux.vnet.ibm.com> <20171114145722.4ab850a5.cohuck@redhat.com> <8a492b07-3d3b-f4cf-e139-7de345ea8188@linux.vnet.ibm.com> <20171116180308.289e5eed.cohuck@redhat.com> <1476b0a4-a2a3-2c48-107a-ab7b39b0e93e@linux.vnet.ibm.com> <0b40cee7-78d3-f96b-ab46-1f40b31251cb@linux.vnet.ibm.com> <20171117110742.1d416435.cohuck@redhat.com> <20171120181345.3fbda311.cohuck@redhat.com> <20171122144750.1ceffe41.cohuck@redhat.com> From: Tony Krowiak Date: Mon, 27 Nov 2017 19:39:32 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <20171122144750.1ceffe41.cohuck@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-TM-AS-GCONF: 00 x-cbid: 17112800-0004-0000-0000-0000134A4748 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008121; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000241; SDB=6.00952175; UDB=6.00480991; IPR=6.00732256; BA=6.00005715; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00018215; XFM=3.00000015; UTC=2017-11-28 00:39:40 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17112800-0005-0000-0000-0000850BF64E Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-11-27_12:,, 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-1711280005 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/22/2017 08:47 AM, Cornelia Huck wrote: > On Tue, 21 Nov 2017 11:08:01 -0500 > Tony Krowiak wrote: > > >> I am not quite sure what you are asking, but I'll attempt to answer >> what I think you're asking. A new type of mediated matrix device >> will be introduced to configure a virtual matrix for a guest that >> provides the interfaces to map a virtual adapter/domain ID to one >> or more real adapter/domain IDs. If by virtualization facility, >> you are talking about the VFIO AP matrix driver, then yes, >> the driver will handle ioctl requests based on the type of the >> mediated matrix device through which the request was submitted: >> >> If the request is to configure the KVM guest's matrix: >> >> * If the mediated matrix device type is passthrough: >> * Do validation of matrix >> * Configure the APM, AQM and ADM in the KVM guest's CRYCB >> according to the configuration specified via the mediated >> device's sysfs attribute files. >> * If the mediated matrix device type is virtual: >> * Do validation of matrix >> * No need to configure CRYCB since all instructions will be >> intercepted > Ok, so we would have two distinct paths here... It depends upon what you mean by two distinct paths. Configuring the mediated device would require a new mediated device type for virtualized AP matrices. The ioctl for configuring the KVM guest's CRYCB would require an additional check to determine whether the CRYCB need be configured or not. > >> If the request is to execute an intercepted AP instruction: >> >> * If the mediated matrix device type is passthrough: >> * Forward the instruction to the AP device and return the >> result to QEMU. >> >> * If the mediated matrix device type is virtual: >> >> * Retrieve all of the real APQNs mapped to the virtual >> adapter and domain IDs configured in the mediated matrix >> device's sysfs attribute files >> * If there is more than one APQN mapping, then determine >> which would be best to use - algorithm TBD >> * Forward the instruction to the AP device and return the >> result. > ...and two distinct paths for most instructions here as well. The driver would require additional ioctls to handle interception of all AP instructions for virtual matrices and additional code to remap virtual APQNs to real APQNs and determine which real APQN to which intercepted instructions should be forwarded. > >> Of course, these are just preliminary ideas at this time. >> I've only prototyped the sysfs configuration interfaces. No >> back end prototyping has been undertaken yet. If the ideas do >> not pan out, however; I think virtualization can be introduced >> as an independent design. > Yes, let's cross that bridge when we get to it. That is the plan. Given Pierre's objections, I thought it might help to touch on this. >