Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1783417imm; Wed, 6 Jun 2018 23:50:37 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLV9q5azoG41HfObmBZDw6iCOyf4UCGUCNT77wE9pak3Gple2HyywKJDMKDSk0Rpz2B8qVS X-Received: by 2002:a17:902:1e2:: with SMTP id b89-v6mr711638plb.279.1528354237352; Wed, 06 Jun 2018 23:50:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528354237; cv=none; d=google.com; s=arc-20160816; b=bDEh0yE2mF7QBhoCb+BIdO+o6dNZGEUTcinIj/AQtZtyFSTuOy57Yaj6sJbOPd11cd Zgi9h10AkC4UVA9QE+v30FnilCMPUgAI0oUTLyM8YYS95G9RYGKGsHsKaxeKSaxAqdQF jXPG2hP5N9APKxg4FdZ3O9ITiYbIDzxEckbENMea059ftc7kCEeM6W/vljK2EYqBzWon iuRPs/nTIRm6AjcIDJZ2tLqipo/FiCiSizdo19ogrMTrNuDM7j9KDfkPZhQPG1nSuojr vDP3gsWN0kgn7cTjHB2ODUlHh41EGtYhpYVvL7x0AW6zTDJdldU89t48BeC7jrWv+Yc8 6Zpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=nXAL4w9H6UhQcrZPO66VGXXAB5GJvdtFhSK1Lx6koJ4=; b=Rh+EryX9pXtycTyVuwoPo+alEo0qRqGhnALBUJYBbP4NDKEl2y5zn2hi1tGzApmd1a q+NhZxzInS7lsCt0JDQ6OwW4KrnaIs00XA9Aa7FiH4b+9m1QWykdJ1co81XuHi8Z1RCU ImSCCTzYOtjOQMpCHleFEPxmFOqWSI10OjC5EF574TpHVain5YHaN/vloKrDb6tZ4CCH gdxihK4CMSWUK14+ea9+DdX6SXccr/E1fryndOmOyFtxJDewX/fE/yCkQsyr2mYnJ/iN 1+d0P1nEAGqKu7uCKBXZ7ELN6FRMCg4adVrER8Lzhb6VBK9KrKvLZDSuYdwBYkIh+lPZ EHCA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=FLbZXZ19; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f127-v6si39490410pgc.503.2018.06.06.23.50.11; Wed, 06 Jun 2018 23:50:37 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=FLbZXZ19; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752577AbeFGGjI (ORCPT + 99 others); Thu, 7 Jun 2018 02:39:08 -0400 Received: from mail-lf0-f67.google.com ([209.85.215.67]:43334 "EHLO mail-lf0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751372AbeFGGjH (ORCPT ); Thu, 7 Jun 2018 02:39:07 -0400 Received: by mail-lf0-f67.google.com with SMTP id n15-v6so12833022lfn.10; Wed, 06 Jun 2018 23:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=nXAL4w9H6UhQcrZPO66VGXXAB5GJvdtFhSK1Lx6koJ4=; b=FLbZXZ19OSTwZr5X/CNIi+f8JhaigWq0TDc4LDwoNmmfuQPdKfsBsannHaIbUXSo/c gOpkDneCrBKXnMhdhu30TLozMJagB19+WtK+gALSuW5JnUtg/FhWCLuS1r/rZV4fkuWq 8gjS9R9VqENBTT/fsJ2l/WzTfUij9dv1MihdeLntY7FxWSzoIr6Sn+k3nRlFdpFJzupf xZgV++4NQDYluO34ps1YwhPmrZ+l3hah7lHZUFkarCTTdlIDyQAxfwRYhjUVXjNoP61e xXiS9emQDXnJW9NKKD67q0lLJ63qldPUYfhc9CpW/qepbmqfaVHPVoHxN8VKC2NUUnAH F/RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=nXAL4w9H6UhQcrZPO66VGXXAB5GJvdtFhSK1Lx6koJ4=; b=gxMHPt2jyKpydFL7zoEes35QRgJAdveHFq6liBd7uvRsXe8PFopLiFmTVsjyw3q+6I ajJB+nubMrHa4u8NQ7aXbRtvb9lI3L56tdLvJ7YSeLxmqAkJ9AdFJbk1qxW6faYwsIdr +n5OSbbet8arCKfsBHQjvAtNvuGvHBver9BbjdwwdFq9YW3vhYJFDHufVRHnJtHthnD7 xcloiGKUNLsckncwcG22z+3pW2JkmXHrFsAxhWZvVeQFvMlO2nkFEVfgKnHMNyNM/eVc MdUjk3jO5hM4ieJuQxvRph1bCuKXe875B3+hLJXDEeq0FHywVbCkJ0Mw+yAQ6d6OozBo A54g== X-Gm-Message-State: APt69E0xlNP2epM+4HYhI/LJiRh63S7D2jyBXZgSR9vL1MrRFXlf78yt F3wPJJwBtS8uK/s4Ga/yz4o= X-Received: by 2002:a2e:1710:: with SMTP id l16-v6mr509966lje.74.1528353545403; Wed, 06 Jun 2018 23:39:05 -0700 (PDT) Received: from [10.17.182.9] (ll-55.209.223.85.sovam.net.ua. [85.223.209.55]) by smtp.gmail.com with ESMTPSA id q2-v6sm4832226ljg.90.2018.06.06.23.39.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jun 2018 23:39:04 -0700 (PDT) Subject: Re: [Xen-devel] [PATCH v2 5/9] xen/gntdev: Allow mappings for DMA buffers To: Boris Ostrovsky , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org, jgross@suse.com, konrad.wilk@oracle.com Cc: daniel.vetter@intel.com, matthew.d.roper@intel.com, dongwon.kim@intel.com, Oleksandr Andrushchenko References: <20180601114132.22596-1-andr2000@gmail.com> <20180601114132.22596-6-andr2000@gmail.com> <64facf05-0a51-c3d9-9d3b-780893248628@oracle.com> <84217eac-b83b-710f-39ab-c93cad65bf9a@gmail.com> From: Oleksandr Andrushchenko Message-ID: <30fa03c0-1b75-c0b1-b14f-8b52ea584e20@gmail.com> Date: Thu, 7 Jun 2018 09:39:03 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/07/2018 12:19 AM, Boris Ostrovsky wrote: > On 06/06/2018 04:14 AM, Oleksandr Andrushchenko wrote: >> On 06/04/2018 11:12 PM, Boris Ostrovsky wrote: >>> On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: >>> @@ -121,8 +146,27 @@ static void gntdev_free_map(struct grant_map *map) >>>       if (map == NULL) >>>           return; >>>   +#ifdef CONFIG_XEN_GRANT_DMA_ALLOC *Option 1: kfree(map->frames);* >>> +    if (map->dma_vaddr) { >>> +        struct gnttab_dma_alloc_args args; >>> + >>> +        args.dev = map->dma_dev; >>> +        args.coherent = map->dma_flags & GNTDEV_DMA_FLAG_COHERENT; >>> +        args.nr_pages = map->count; >>> +        args.pages = map->pages; >>> +        args.frames = map->frames; >>> +        args.vaddr = map->dma_vaddr; >>> +        args.dev_bus_addr = map->dma_bus_addr; >>> + >>> +        gnttab_dma_free_pages(&args); *Option 2: kfree(map->frames);* >>> +    } else >>> +#endif >>>       if (map->pages) >>>           gnttab_free_pages(map->count, map->pages); >>> + >>> +#ifdef CONFIG_XEN_GRANT_DMA_ALLOC >>> +    kfree(map->frames); >>> +#endif >>> >>> Can this be done under if (map->dma_vaddr) ? >>>   In other words, is it >>> possible for dma_vaddr to be NULL and still have unallocated frames >>> pointer? >> It is possible to have vaddr == NULL and frames != NULL as we >> allocate frames outside of gnttab_dma_alloc_pages which >> may fail. Calling kfree on NULL pointer is safe, > > I am not questioning safety of the code, I would like avoid another ifdef. Ah, I now understand, so you are asking if we can have that kfree(map->frames); in the place *Option 2* I marked above. Unfortunately no: map->frames is allocated before we try to allocate DMA memory, e.g. before dma_vaddr is set: [...]         add->frames = kcalloc(count, sizeof(add->frames[0]),                       GFP_KERNEL);         if (!add->frames)             goto err; [...]         if (gnttab_dma_alloc_pages(&args))             goto err;         add->dma_vaddr = args.vaddr; [...] err:     gntdev_free_map(add); So, it is possible to enter gntdev_free_map with frames != NULL and dma_vaddr == NULL. Option 1 above cannot be used as map->frames is needed for gnttab_dma_free_pages(&args); and Option 2 cannot be used as frames != NULL and dma_vaddr == NULL. Thus, I think that unfortunately we need that #ifdef. Option 3 below can also be considered, but that seems to be not good as we free resources in different places which looks inconsistent. Sorry if I'm still missing your point. > >> so >> I see no reason to change this code. >>>>       kfree(map->pages); >>>>       kfree(map->grants); >>>>       kfree(map->map_ops); >>>> @@ -132,7 +176,8 @@ static void gntdev_free_map(struct grant_map *map) >>>>       kfree(map); >>>>   } >>>>   -static struct grant_map *gntdev_alloc_map(struct gntdev_priv >>>> *priv, int count) >>>> +static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, >>>> int count, >>>> +                      int dma_flags) >>>>   { >>>>       struct grant_map *add; >>>>       int i; >>>> @@ -155,6 +200,37 @@ static struct grant_map >>>> *gntdev_alloc_map(struct gntdev_priv *priv, int count) >>>>           NULL == add->pages) >>>>           goto err; >>>>   +#ifdef CONFIG_XEN_GRANT_DMA_ALLOC >>>> +    add->dma_flags = dma_flags; >>>> + >>>> +    /* >>>> +     * Check if this mapping is requested to be backed >>>> +     * by a DMA buffer. >>>> +     */ >>>> +    if (dma_flags & (GNTDEV_DMA_FLAG_WC | GNTDEV_DMA_FLAG_COHERENT)) { >>>> +        struct gnttab_dma_alloc_args args; >>>> + >>>> +        add->frames = kcalloc(count, sizeof(add->frames[0]), >>>> +                      GFP_KERNEL); >>>> +        if (!add->frames) >>>> +            goto err; >>>> + >>>> +        /* Remember the device, so we can free DMA memory. */ >>>> +        add->dma_dev = priv->dma_dev; >>>> + >>>> +        args.dev = priv->dma_dev; >>>> +        args.coherent = dma_flags & GNTDEV_DMA_FLAG_COHERENT; >>>> +        args.nr_pages = count; >>>> +        args.pages = add->pages; >>>> +        args.frames = add->frames; >>>> + >>>> +        if (gnttab_dma_alloc_pages(&args)) *Option 3: kfree(map->frames);* >>>> +            goto err; >>>> + >>>> +        add->dma_vaddr = args.vaddr; >>>> +        add->dma_bus_addr = args.dev_bus_addr; >>>> +    } else >>>> +#endif >>>>       if (gnttab_alloc_pages(count, add->pages)) >>>>           goto err; >>>>   @@ -325,6 +401,14 @@ static int map_grant_pages(struct grant_map >>>> *map) >>>>           map->unmap_ops[i].handle = map->map_ops[i].handle; >>>>           if (use_ptemod) >>>>               map->kunmap_ops[i].handle = map->kmap_ops[i].handle; >>>> +#ifdef CONFIG_XEN_GRANT_DMA_ALLOC >>>> +        else if (map->dma_vaddr) { >>>> +            unsigned long mfn; >>>> + >>>> +            mfn = __pfn_to_mfn(page_to_pfn(map->pages[i])); >>> Not pfn_to_mfn()? >> I'd love to, but pfn_to_mfn is only defined for x86, not ARM: [1] and [2] >> Thus, >> >> drivers/xen/gntdev.c:408:10: error: implicit declaration of function >> ‘pfn_to_mfn’ [-Werror=implicit-function-declaration] >>     mfn = pfn_to_mfn(page_to_pfn(map->pages[i])); >> >> So, I'll keep __pfn_to_mfn > > How will this work on non-PV x86? So, you mean I need: #ifdef CONFIG_X86 mfn = pfn_to_mfn(page_to_pfn(map->pages[i])); #else mfn = __pfn_to_mfn(page_to_pfn(map->pages[i])); #endif > -boris > > Thank you, Oleksandr