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 CFCBEC10F0E for ; Wed, 10 Apr 2019 00:10:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A2B6C21741 for ; Wed, 10 Apr 2019 00:10:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726953AbfDJAK4 (ORCPT ); Tue, 9 Apr 2019 20:10:56 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:49522 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726607AbfDJAK4 (ORCPT ); Tue, 9 Apr 2019 20:10:56 -0400 Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x3A04jwd049066 for ; Tue, 9 Apr 2019 20:10:55 -0400 Received: from e06smtp07.uk.ibm.com (e06smtp07.uk.ibm.com [195.75.94.103]) by mx0a-001b2d01.pphosted.com with ESMTP id 2rs4v2hmd8-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 09 Apr 2019 20:10:54 -0400 Received: from localhost by e06smtp07.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 10 Apr 2019 01:10:52 +0100 Received: from b06cxnps4076.portsmouth.uk.ibm.com (9.149.109.198) by e06smtp07.uk.ibm.com (192.168.101.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Wed, 10 Apr 2019 01:10:50 +0100 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x3A0AmNv52297878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 10 Apr 2019 00:10:48 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4391C52052; Wed, 10 Apr 2019 00:10:48 +0000 (GMT) Received: from oc2783563651 (unknown [9.145.25.61]) by d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTP id 9323E5204F; Wed, 10 Apr 2019 00:10:47 +0000 (GMT) Date: Wed, 10 Apr 2019 02:10:44 +0200 From: Halil Pasic To: Cornelia Huck Cc: kvm@vger.kernel.org, linux-s390@vger.kernel.org, Martin Schwidefsky , Sebastian Ott , virtualization@lists.linux-foundation.org, Christian Borntraeger , Viktor Mihajlovski , Vasily Gorbik , Janosch Frank , Claudio Imbrenda , Farhan Ali , Eric Farman Subject: Re: [RFC PATCH 05/12] s390/cio: add protected virtualization support to cio In-Reply-To: <20190409195548.6dea6e40.cohuck@redhat.com> References: <20190404231622.52531-1-pasic@linux.ibm.com> <20190404231622.52531-6-pasic@linux.ibm.com> <20190409195548.6dea6e40.cohuck@redhat.com> Organization: IBM X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 19041000-0028-0000-0000-0000035F16B0 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19041000-0029-0000-0000-0000241E3697 Message-Id: <20190410021044.4da3e847@oc2783563651> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-04-09_14:,, 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-1810050000 definitions=main-1904090153 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Tue, 9 Apr 2019 19:55:48 +0200 Cornelia Huck wrote: > On Fri, 5 Apr 2019 01:16:15 +0200 > Halil Pasic wrote: > > > Virtio-ccw relies on cio mechanisms for bootstrapping the ccw device. > > Well, a ccw device is, by definition, using cio mechanisms ;) Right, this was supposed to explain to the non-virtio guys why do I have to deal with this stuff in cio in a series that is about virtio. I was chiefly alluding to the SENSE stuff. > > Better say: "As virtio-ccw devices are channel devices, we need to use > the dma area for any communication with the hypervisor." > Or something like that. Sure we can come up with a better commit message. Your sentence is already better than mine ;). > > > Thus we need to make sure any memory that is used for communication with > > the hypervisor is shared. > > In this context, does 'hypervisor' always mean 'QEMU/KVM'? If Other > Hypervisors implement protected virtualization, we probably need to > make sure that all common I/O layer control blocks are in the dma area > (including e.g. QDIO), not just what virtio-ccw devices use. > Hypervisor could theoretically be something different than QEMU/KVM. Yet, as stated before, this series is about getting virtio-ccw working (modulo the TODOs). [..] > > > > So, this leaves some things I'm not sure about, especially as I do not > know the architecture of this new feature. > > - This applies only to asynchronously handled things, it seems? So > things like control blocks modified by stsch/msch/etc does not need > special treatment? I had a feeble attempt at explaining this in the cover letter: * make sure that virtio-ccw specific stuff uses shared memory when talking to the hypervisor (except communication blocks like ORB, these are handled by the hypervisor) Unfortunately the last 'hypervisor' was supposed to be 'ultravisor'. I.e. the ultravisor will take care of exposing the control blocks to the hypervisor (and of changes as well). > - What about channel measurements? Or are they not supported? For virtio-ccw channel measurements are not very relevant. I think it should work as it used to, but I will give it another look later. > - What about CHSCs? Or would only asynchronous commands (which we > currently don't implement in QEMU) need special treatment? > CHSC is special. AFAIR the code of Vasily and Janosch is handling what needs to be handled. But I will double-check this as well. Regards, Halil