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 68F0FC10F11 for ; Wed, 10 Apr 2019 13:02:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3EF702083E for ; Wed, 10 Apr 2019 13:02:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732251AbfDJNCg (ORCPT ); Wed, 10 Apr 2019 09:02:36 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:34046 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727178AbfDJNCf (ORCPT ); Wed, 10 Apr 2019 09:02:35 -0400 Received: from pps.filterd (m0098414.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x3ACsTct099059 for ; Wed, 10 Apr 2019 09:02:34 -0400 Received: from e06smtp01.uk.ibm.com (e06smtp01.uk.ibm.com [195.75.94.97]) by mx0b-001b2d01.pphosted.com with ESMTP id 2rsf22x4mw-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 10 Apr 2019 09:02:34 -0400 Received: from localhost by e06smtp01.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 10 Apr 2019 14:02:31 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195) by e06smtp01.uk.ibm.com (192.168.101.131) 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 14:02:29 +0100 Received: from b06wcsmtp001.portsmouth.uk.ibm.com (b06wcsmtp001.portsmouth.uk.ibm.com [9.149.105.160]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x3AD2Rl856492136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 10 Apr 2019 13:02:27 GMT Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5B15BA4060; Wed, 10 Apr 2019 13:02:27 +0000 (GMT) Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DE3E7A4054; Wed, 10 Apr 2019 13:02:26 +0000 (GMT) Received: from oc2783563651 (unknown [9.152.224.40]) by b06wcsmtp001.portsmouth.uk.ibm.com (Postfix) with ESMTP; Wed, 10 Apr 2019 13:02:26 +0000 (GMT) Date: Wed, 10 Apr 2019 15:02:25 +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: <20190410102557.1ba89d96.cohuck@redhat.com> References: <20190404231622.52531-1-pasic@linux.ibm.com> <20190404231622.52531-6-pasic@linux.ibm.com> <20190409195548.6dea6e40.cohuck@redhat.com> <20190410021044.4da3e847@oc2783563651> <20190410102557.1ba89d96.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: 19041013-4275-0000-0000-0000032655FB X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19041013-4276-0000-0000-0000383572AD Message-Id: <20190410150225.61b86cd9@oc2783563651> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-04-10_06:,, 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-1904100092 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Wed, 10 Apr 2019 10:25:57 +0200 Cornelia Huck wrote: > On Wed, 10 Apr 2019 02:10:44 +0200 > Halil Pasic wrote: > > > On Tue, 9 Apr 2019 19:55:48 +0200 > > Cornelia Huck wrote: > > > > > On Fri, 5 Apr 2019 01:16:15 +0200 > > > Halil Pasic wrote: > > > > > 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). > > Sure, just wanted to point it out. If this is "enable the common I/O > layer, except for QDIO" or so, that would sound fine to me :) > Right except QDIO. Series cares only about the bits relevant for virtio-ccw. I guess I should make that clearer in the commit message. > > > > [..] > > > > > > > > > > > > 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). > > Yeah, that "control blocks" or "communication blocks" leaves me a bit > fuzzy :) Yeah. I don't know if there is an official name for the stuff. For the ORB of SSCH control block seems quite fitting. For the SCHIB of STSCH communication seems a better fit. > > So, what is a high-level summary of areas that need the treatment? > What I get from looking at the patches so far, it's: > - stuff that is written by the hypervisor's interrupt injection code: > IRB, indicators, etc. In interrupt context IRB behaves like a control block. We don't have to make it shared. I moved IRB because of snse: @@ -329,9 +329,9 @@ ccw_device_do_sense(struct ccw_device *cdev, struct irb *irb) /* * We have ending status but no sense information. Do a basic sense. */ - sense_ccw = &to_io_private(sch)->sense_ccw; + sense_ccw = &to_io_private(sch)->dma_area->sense_ccw; sense_ccw->cmd_code = CCW_CMD_BASIC_SENSE; - sense_ccw->cda = (__u32) __pa(cdev->private->irb.ecw); + sense_ccw->cda = (__u32) __pa(cdev->private->dma_area->irb.ecw); as the irb.ecw is used as channel program data. And that needs to be shared. > - buffers that are filled by a channel program: sense, sense id, etc. > - ccws themselves (because of translation?) > Right. The idea is: smallish, basically fixed size a readily available control blocks (specified as a ) are copied back and forth by the ultravisor (via SIE SD). Regards, Halil