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 D1BF9C10F11 for ; Wed, 10 Apr 2019 15:58:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9D2432133D for ; Wed, 10 Apr 2019 15:58:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731522AbfDJP6B convert rfc822-to-8bit (ORCPT ); Wed, 10 Apr 2019 11:58:01 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:47984 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730608AbfDJP6A (ORCPT ); Wed, 10 Apr 2019 11:58:00 -0400 Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x3AFpFiG075359 for ; Wed, 10 Apr 2019 11:57:59 -0400 Received: from e06smtp07.uk.ibm.com (e06smtp07.uk.ibm.com [195.75.94.103]) by mx0a-001b2d01.pphosted.com with ESMTP id 2rsjf8bmpp-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 10 Apr 2019 11:57:59 -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 16:57:57 +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 16:57:54 +0100 Received: from d06av22.portsmouth.uk.ibm.com (d06av22.portsmouth.uk.ibm.com [9.149.105.58]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x3AFvq5A26345578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 10 Apr 2019 15:57:53 GMT Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CC5364C050; Wed, 10 Apr 2019 15:57:52 +0000 (GMT) Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 60BAB4C044; Wed, 10 Apr 2019 15:57:52 +0000 (GMT) Received: from oc2783563651 (unknown [9.152.224.40]) by d06av22.portsmouth.uk.ibm.com (Postfix) with ESMTP; Wed, 10 Apr 2019 15:57:52 +0000 (GMT) Date: Wed, 10 Apr 2019 17:57:50 +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 00/12] s390: virtio: support protected virtualization In-Reply-To: <20190410112048.154c96fc.cohuck@redhat.com> References: <20190404231622.52531-1-pasic@linux.ibm.com> <20190410112048.154c96fc.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: 8BIT X-TM-AS-GCONF: 00 x-cbid: 19041015-0028-0000-0000-0000035F64F0 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19041015-0029-0000-0000-0000241E882B Message-Id: <20190410175750.0ed0a454@oc2783563651> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-04-10_07:,, 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-1904100110 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Wed, 10 Apr 2019 11:20:48 +0200 Cornelia Huck wrote: > On Fri, 5 Apr 2019 01:16:10 +0200 > Halil Pasic wrote: > > > Enhanced virtualization protection technology may require the use of > > bounce buffers for I/O. While support for this was built into the > > virtio core, virtio-ccw wasn't changed accordingly. > > > > Thus what needs to be done to bring virtio-ccw up to speed with > > respect to this is: > > * use some 'new' common virtio stuff > > * 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) > > * make sure the DMA API does what is necessary to talk through shared > > memory if we are a protected virtualization guest. > > * make sure the common IO layer plays along as well (airqs, sense). > > It would be good to have a summary somewhere in the code (or > Documentation/) as to what needs the dma treatment and what doesn't, > for later reference. We don't want people to accidentally break things > (especially if they cannot refer to architecture documentation - or > will at least some of that be published?) > I can put documentation on my TODO list. This cover letter was also supposed to provide a bird's-eye view on what needs to be done. > > > > The series is structured in incremental fashion: some of the changes > > are overridden by following patches. The main reason why is that > > this is how I developed. But I think it ain't bad for the didactic > > and we are a bit more flexible with regards to throwing out some of > > the stuff in the end. > > FWIW, I think reshuffling the patches in the next iteration would ease > review. > Can you please tell me more about what is desired here? I mean, I made some tentative proposals on squashing some patches together. I don't remember any requests to reorder patches or split. > > > > Important notes: > > > > * This is an early (WIP) RFC that does not add any function to the > > kernel at his stage, as the ultravisor interactions are left out. > > The purpose is getting some early feedback ASAP. > > I would like some comments from people who have experience with the dma > api. > I can only second that! >From the Linux on Z folks Sebastian seems to be the most likely suspect. I've briefly shown this series to him before posting here, and I asked him to have another look today. Unfortunately he seems quite busy at the moment, but he promised me that he will make some time for this (soonish). Getting some more feedback from Christoph Hellwig would be nice as well. > > > > * In future these patches will depend on some code interacting with > > the ultravisor (WIP by Vasily and Janosch). > > > > * The s390 names are by no means final, and are not properly > > explained. Should not hamper understanding too much. If it does > > please ask. > > > > * The existing naming in the common infrastructure (kernel internal > > interfaces) is pretty much based on the AMD SEV terminology. Thus > > the names aren't always perfect. There might be merit to changing > > these names to more abstract ones. I did not put much thought into > > that at the current stage. > > If we can find some generic names that work well for everyone, > converting seems like a good idea. But following SEV is not that bad, > either (you'll probably find more people who have heard about SEV than > folks familiar with s390 ;) > I agree. We should not swap out the names for worse ones for sure. :) I think the names discussion can be postponed. I would like to get the code right first. > > > > > > Testing: > > > > Please use iommu_platform=on for any virtio devices you are going > > to test this code with (so virtio actually uses the DMA API). > > > > Looking forward to your review or any other type of input. > > I have now read through the whole series and commented in some places. > But I'd really like to see comments from others as well. > Thank you so much for the quick review. Thanks to your quality review I will have a bunch of things to change (for the better) for v1. I intend to wait a bit for more feedback and also for the my dependencies to get published. I hope to send out a functional v1 mid next week. Thank you again! Regards, Halil