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=-4.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,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 EF1E8C04AB3 for ; Mon, 27 May 2019 10:38:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CA6C920883 for ; Mon, 27 May 2019 10:38:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726538AbfE0KiN (ORCPT ); Mon, 27 May 2019 06:38:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48758 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725996AbfE0KiN (ORCPT ); Mon, 27 May 2019 06:38:13 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 066B8821D8; Mon, 27 May 2019 10:38:13 +0000 (UTC) Received: from gondolin (ovpn-204-109.brq.redhat.com [10.40.204.109]) by smtp.corp.redhat.com (Postfix) with ESMTP id 58E2C60C64; Mon, 27 May 2019 10:38:06 +0000 (UTC) Date: Mon, 27 May 2019 12:38:02 +0200 From: Cornelia Huck To: Michael Mueller Cc: KVM Mailing List , Linux-S390 Mailing List , Sebastian Ott , Heiko Carstens , Halil Pasic , virtualization@lists.linux-foundation.org, "Michael S . Tsirkin" , Christoph Hellwig , Thomas Huth , Christian Borntraeger , Viktor Mihajlovski , Vasily Gorbik , Janosch Frank , Claudio Imbrenda , Farhan Ali , Eric Farman , Pierre Morel Subject: Re: [PATCH v2 3/8] s390/cio: add basic protected virtualization support Message-ID: <20190527123802.54cd3589.cohuck@redhat.com> In-Reply-To: <20190523162209.9543-4-mimu@linux.ibm.com> References: <20190523162209.9543-1-mimu@linux.ibm.com> <20190523162209.9543-4-mimu@linux.ibm.com> Organization: Red Hat GmbH MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Mon, 27 May 2019 10:38:13 +0000 (UTC) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Thu, 23 May 2019 18:22:04 +0200 Michael Mueller wrote: > From: Halil Pasic > > As virtio-ccw devices are channel devices, we need to use the dma area > for any communication with the hypervisor. > > It handles neither QDIO in the common code, nor any device type specific > stuff (like channel programs constructed by the DASD driver). > > An interesting side effect is that virtio structures are now going to > get allocated in 31 bit addressable storage. > > Signed-off-by: Halil Pasic [Side note: you really should add your s-o-b if you send someone else's patches... if Halil ends up committing them, it's fine, though.] > --- > arch/s390/include/asm/ccwdev.h | 4 +++ > drivers/s390/cio/ccwreq.c | 9 +++--- > drivers/s390/cio/device.c | 64 +++++++++++++++++++++++++++++++++------- > drivers/s390/cio/device_fsm.c | 53 ++++++++++++++++++++------------- > drivers/s390/cio/device_id.c | 20 +++++++------ > drivers/s390/cio/device_ops.c | 21 +++++++++++-- > drivers/s390/cio/device_pgid.c | 22 +++++++------- > drivers/s390/cio/device_status.c | 24 +++++++-------- > drivers/s390/cio/io_sch.h | 20 +++++++++---- > drivers/s390/virtio/virtio_ccw.c | 10 ------- > 10 files changed, 164 insertions(+), 83 deletions(-) > (...) > @@ -1593,20 +1622,31 @@ struct ccw_device * __init ccw_device_create_console(struct ccw_driver *drv) > return ERR_CAST(sch); > > io_priv = kzalloc(sizeof(*io_priv), GFP_KERNEL | GFP_DMA); > - if (!io_priv) { > - put_device(&sch->dev); > - return ERR_PTR(-ENOMEM); > - } > + if (!io_priv) > + goto err_priv; > + io_priv->dma_area = dma_alloc_coherent(&sch->dev, > + sizeof(*io_priv->dma_area), > + &io_priv->dma_area_dma, GFP_KERNEL); Even though we'll only end up here for 3215 or 3270 consoles, this sent me looking. This code is invoked via console_init(). A few lines down in start_kernel(), we have /* * This needs to be called before any devices perform DMA * operations that might use the SWIOTLB bounce buffers. It will * mark the bounce buffers as decrypted so that their usage will * not cause "plain-text" data to be decrypted when accessed. */ mem_encrypt_init(); So, I'm wondering if creating the console device interacts in any way with the memory encryption interface? [Does basic recognition work if you start a protected virt guest with a 3270 console? I realize that the console is unlikely to work, but that should at least exercise this code path.] > + if (!io_priv->dma_area) > + goto err_dma_area; > set_io_private(sch, io_priv); > cdev = io_subchannel_create_ccwdev(sch); > if (IS_ERR(cdev)) { > put_device(&sch->dev); > + dma_free_coherent(&sch->dev, sizeof(*io_priv->dma_area), > + io_priv->dma_area, io_priv->dma_area_dma); > kfree(io_priv); > return cdev; > } > cdev->drv = drv; > ccw_device_set_int_class(cdev); > return cdev; > + > +err_dma_area: > + kfree(io_priv); > +err_priv: > + put_device(&sch->dev); > + return ERR_PTR(-ENOMEM); > } > > void __init ccw_device_destroy_console(struct ccw_device *cdev)