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 B7DADC10F11 for ; Wed, 10 Apr 2019 16:21:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 912332082E for ; Wed, 10 Apr 2019 16:21:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387784AbfDJQV2 (ORCPT ); Wed, 10 Apr 2019 12:21:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40212 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727892AbfDJQV2 (ORCPT ); Wed, 10 Apr 2019 12:21:28 -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 0ABBCC049E37; Wed, 10 Apr 2019 16:21:28 +0000 (UTC) Received: from gondolin (ovpn-204-33.brq.redhat.com [10.40.204.33]) by smtp.corp.redhat.com (Postfix) with ESMTP id B58DF619AA; Wed, 10 Apr 2019 16:21:24 +0000 (UTC) Date: Wed, 10 Apr 2019 18:21:21 +0200 From: Cornelia Huck To: Halil Pasic 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 07/12] virtio/s390: use DMA memory for ccw I/O Message-ID: <20190410182121.61fb89b6.cohuck@redhat.com> In-Reply-To: <20190410164245.53f8b26d@oc2783563651> References: <20190404231622.52531-1-pasic@linux.ibm.com> <20190404231622.52531-8-pasic@linux.ibm.com> <20190410104251.38fe7405.cohuck@redhat.com> <20190410164245.53f8b26d@oc2783563651> 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.31]); Wed, 10 Apr 2019 16:21:28 +0000 (UTC) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Wed, 10 Apr 2019 16:42:45 +0200 Halil Pasic wrote: > On Wed, 10 Apr 2019 10:42:51 +0200 > Cornelia Huck wrote: > > > On Fri, 5 Apr 2019 01:16:17 +0200 > > Halil Pasic wrote: > > > @@ -167,6 +170,28 @@ static struct virtio_ccw_device *to_vc_device(struct virtio_device *vdev) > > > return container_of(vdev, struct virtio_ccw_device, vdev); > > > } > > > > > > +#define vc_dma_decl_struct(type, field) \ > > > + dma_addr_t field ## _dma_addr; \ > > > + struct type *field > > > + > > > +static inline void *__vc_dma_alloc(struct virtio_device *vdev, size_t size, > > > + dma_addr_t *dma_handle) > > > +{ > > > + return dma_alloc_coherent(vdev->dev.parent, size, dma_handle, > > > + GFP_DMA | GFP_KERNEL | __GFP_ZERO); > > > +} > > > + > > > +static inline void __vc_dma_free(struct virtio_device *vdev, size_t size, > > > + void *cpu_addr, dma_addr_t dma_handle) > > > +{ > > > + dma_free_coherent(vdev->dev.parent, size, cpu_addr, dma_handle); > > > +} > > > + > > > +#define vc_dma_alloc_struct(vdev, ptr) \ > > > + ({ ptr = __vc_dma_alloc(vdev, (sizeof(*(ptr))), &(ptr ## _dma_addr)); }) > > > +#define vc_dma_free_struct(vdev, ptr) \ > > > + __vc_dma_free(vdev, sizeof(*(ptr)), (ptr), (ptr ## _dma_addr)) > > > > Not sure I'm a fan of those wrappers... I think they actually hurt > > readability of the code. > > > > By wrappers you mean just the macros or also the inline functions? In particular, I dislike the macros. > > If we agree to go with the cio DMA pool instead of using DMA API > facilities for allocation (dma_alloc_coherent or maybe a per ccw-device > dma_pool) I think I could just use cio_dma_zalloc() directly if you like. If we go with the pool (I'm not familiar enough with the dma stuff to be able to make a good judgment there), nice and obvious calls sound good to me :) > > I was quite insecure about how this gen_pool idea is going to be received > here. That's why I decided to keep the dma_alloc_coherent() version in > for the RFC. > > If you prefer I can squash patches #7 #9 #10 and #11 together and > pull #8 forward. Would you prefer that? If that avoids multiple switches of the approach used, that sounds like a good idea. (Still would like to see some feedback from others.)