Received: by 2002:a05:6a10:6006:0:0:0:0 with SMTP id w6csp577143pxa; Thu, 27 Aug 2020 09:53:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxetEbChJdz8Nj9mJR8SmiH0yMSnXGO3XABzK7wv+U1g2jxGl1jzbYon6GyhXyNcMOpvGWZ X-Received: by 2002:a17:906:68cd:: with SMTP id y13mr3377084ejr.132.1598547214323; Thu, 27 Aug 2020 09:53:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598547214; cv=none; d=google.com; s=arc-20160816; b=dK2Mvw7hgSBaDFVb3o+NIWNR6eADbMN5Atlt0eus67LQdTT+hYTHi84qfLuJRYFzpS ngZvkVhBZC6XYGPaBCyG6F0kycvLqQW+5A1Ce0+oxHM4gMdCyZ6A9osxfWA4D0ZCms1V 01IQk/EtxLUGdYG3qNIwyWWbFeM9y6VOhuD2RnMMf5qBTI9moEbF86hd5RS85oA2K/rj SpgV+4iWFBNL43OpPRRWERGER7L7Dw6PDkqFHH/UF0P9DVKgmZ82NXW/WtPJ0njcduXW Ga3Gm044EXN8kCX6hwVtBZoUr00vlDRX7oyP8w+ZwSEE3vm8gSZgwNFYcNMupiZXCpxl 7dMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:organization:references:in-reply-to:date:cc:to:from :subject:message-id:dkim-signature; bh=pMOP7GvtalnvE1bAalLKdMDTFVojjFa/CIZrykJhyA0=; b=yF3CWGJUFCDKUqqM3tAOLEoHsm3rp2rcX7s8PD5shnMlgYeA8AO1RunRJ7Ove1h60T YkuL1rXLBtOOBMSSfGMQYac4y7E+KYp3kahVdoWsbwSdwp5Nu3hVFXIeHca0Ntux/Cwy GPeBhl84/u7jYJDK40DpfDyWeXWgY9iEJZOCiBv7cGW5i8zRcOuErmjxPJiI16EqwqW1 GfYmtkcvCQgpf0mtgSPOXch9m9RxAbauSOaeamIUh/zw5zk9snawkoSBBp9AEe/2Laeu vLeKu6MR9qMpYPwceGmHKjINF6xNVgbqsp7GxJXvv92PUWByYqIc/WjMgmsU9GvW51ZI kSUQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=h0P8ksLv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id a8si1727749ejx.387.2020.08.27.09.53.11; Thu, 27 Aug 2020 09:53:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=h0P8ksLv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1726804AbgH0QwJ (ORCPT + 99 others); Thu, 27 Aug 2020 12:52:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52308 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726009AbgH0QwE (ORCPT ); Thu, 27 Aug 2020 12:52:04 -0400 Received: from mail-qv1-xf44.google.com (mail-qv1-xf44.google.com [IPv6:2607:f8b0:4864:20::f44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 33492C061264 for ; Thu, 27 Aug 2020 09:52:04 -0700 (PDT) Received: by mail-qv1-xf44.google.com with SMTP id cs12so2923144qvb.2 for ; Thu, 27 Aug 2020 09:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:cc:date:in-reply-to:references :organization:user-agent:mime-version:content-transfer-encoding; bh=pMOP7GvtalnvE1bAalLKdMDTFVojjFa/CIZrykJhyA0=; b=h0P8ksLv0SkYmJK3zzvDr/R7THSzA72QP3N2IwSzwKpJ3iiNMHxFi/mQ5kzKYteTfz fQyLTnyLdIHB3Gaa1yTROhP6k90swdorDE4WYoa6fySeP32+qdkuNRsu06JLnpLRR7u0 g8PhQElen69O4YP4hvfTiIkqWRYB8+3JLN8aTIHWcjAo0NmCwJAk1BWOPkVGyACdgvGQ BMRiELtJhmECatPKpRBEQVtmOLOrAjywEKaK03Yvwujqgd4uT+UDH0xI9AaijUSfprMv //0ZILqH1SsviV/dU8hcaAB6fycLMW70fjo1LRHld16XoyvT99lWozl+qEiS6PSYaeOs EKlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:organization:user-agent:mime-version :content-transfer-encoding; bh=pMOP7GvtalnvE1bAalLKdMDTFVojjFa/CIZrykJhyA0=; b=a92KI65nc5qAevB+1oY16sliY7BsodmK3jME7A/jGIdcGKqJ9O3E6egGesTYzTU5WE WwihCYsOPCHIWJQr4/gjYwuQ0vJGija25I1gn13eY8fj60XZmUICRKIo6gl+XRTc8Yyo ZNrewZ4CNeR55WYKcUIqQ8Mkv9IUloRwLdYuBabtkHZHgEM62DuG38RLcpSF77As/Jly U7e0QCI1y5ClxLgL2d6IFQFJLgB7mWJeiR52Nlu/8KrxdsU6q/3dNd+q4eSIgg2bVlFZ f9imhmVB0dvI9ahX5u9ZYIG9Hzm9gHrf0R3u6EFjqC+53agjkASG72oqip0PkLtMlDJH uMYg== X-Gm-Message-State: AOAM532D15X2Hn75Fg8aOaVzvXJM/S9G0VIJxl0/sQ5fgzIFwvkNZWb0 J/GZoE0edEBHIZlY/CmTxR4= X-Received: by 2002:ad4:5764:: with SMTP id r4mr2903921qvx.73.1598547123085; Thu, 27 Aug 2020 09:52:03 -0700 (PDT) Received: from LeoBras ([2804:14d:8084:8e41:9b0d:571e:a65:b5d8]) by smtp.gmail.com with ESMTPSA id e13sm2139022qkg.124.2020.08.27.09.51.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2020 09:52:02 -0700 (PDT) Message-ID: Subject: Re: [PATCH v1 02/10] powerpc/kernel/iommu: Align size for IOMMU_PAGE_SIZE on iommu_*_coherent() From: Leonardo Bras To: Alexey Kardashevskiy , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , Christophe Leroy , Joel Stanley , Thiago Jung Bauermann , Ram Pai , Brian King , Murilo Fossa Vicentini , David Dai Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Date: Thu, 27 Aug 2020 13:51:54 -0300 In-Reply-To: <7b9640e0-568f-1470-40f4-a3ccec8abcf2@ozlabs.ru> References: <20200817234033.442511-1-leobras.c@gmail.com> <20200817234033.442511-3-leobras.c@gmail.com> <7b9640e0-568f-1470-40f4-a3ccec8abcf2@ozlabs.ru> Organization: IBM Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.4 (3.34.4-1.fc31) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 2020-08-22 at 20:07 +1000, Alexey Kardashevskiy wrote: > > On 18/08/2020 09:40, Leonardo Bras wrote: > > Both iommu_alloc_coherent() and iommu_free_coherent() assume that once > > size is aligned to PAGE_SIZE it will be aligned to IOMMU_PAGE_SIZE. > > The only case when it is not aligned is when IOMMU_PAGE_SIZE > PAGE_SIZE > which is unlikely but not impossible, we could configure the kernel for > 4K system pages and 64K IOMMU pages I suppose. Do we really want to do > this here, or simply put WARN_ON(tbl->it_page_shift > PAGE_SHIFT)? I think it would be better to keep the code as much generic as possible regarding page sizes. > Because if we want the former (==support), then we'll have to align the > size up to the bigger page size when allocating/zeroing system pages, > etc. This part I don't understand. Why do we need to align everything to the bigger pagesize? I mean, is not that enough that the range [ret, ret + size[ is both allocated by mm and mapped on a iommu range? Suppose a iommu_alloc_coherent() of 16kB on PAGESIZE = 4k and IOMMU_PAGE_SIZE() == 64k. Why 4 * cpu_pages mapped by a 64k IOMMU page is not enough? All the space the user asked for is allocated and mapped for DMA. > Bigger pages are not the case here as I understand it. I did not get this part, what do you mean? > > Update those functions to guarantee alignment with requested size > > using IOMMU_PAGE_ALIGN() before doing iommu_alloc() / iommu_free(). > > > > Also, on iommu_range_alloc(), replace ALIGN(n, 1 << tbl->it_page_shift) > > with IOMMU_PAGE_ALIGN(n, tbl), which seems easier to read. > > > > Signed-off-by: Leonardo Bras > > --- > > arch/powerpc/kernel/iommu.c | 17 +++++++++-------- > > 1 file changed, 9 insertions(+), 8 deletions(-) > > > > diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c > > index 9704f3f76e63..d7086087830f 100644 > > --- a/arch/powerpc/kernel/iommu.c > > +++ b/arch/powerpc/kernel/iommu.c > > @@ -237,10 +237,9 @@ static unsigned long iommu_range_alloc(struct device *dev, > > } > > > > if (dev) > > - boundary_size = ALIGN(dma_get_seg_boundary(dev) + 1, > > - 1 << tbl->it_page_shift); > > + boundary_size = IOMMU_PAGE_ALIGN(dma_get_seg_boundary(dev) + 1, tbl); > > Run checkpatch.pl, should complain about a long line. It's 86 columns long, which is less than the new limit of 100 columns Linus announced a few weeks ago. checkpatch.pl was updated too: https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Deprecates-80-Col > > > > else > > - boundary_size = ALIGN(1UL << 32, 1 << tbl->it_page_shift); > > + boundary_size = IOMMU_PAGE_ALIGN(1UL << 32, tbl); > > /* 4GB boundary for iseries_hv_alloc and iseries_hv_map */ > > > > n = iommu_area_alloc(tbl->it_map, limit, start, npages, tbl->it_offset, > > @@ -858,6 +857,7 @@ void *iommu_alloc_coherent(struct device *dev, struct iommu_table *tbl, > > unsigned int order; > > unsigned int nio_pages, io_order; > > struct page *page; > > + size_t size_io = size; > > > > size = PAGE_ALIGN(size); > > order = get_order(size); > > @@ -884,8 +884,9 @@ void *iommu_alloc_coherent(struct device *dev, struct iommu_table *tbl, > > memset(ret, 0, size); > > > > /* Set up tces to cover the allocated range */ > > - nio_pages = size >> tbl->it_page_shift; > > - io_order = get_iommu_order(size, tbl); > > + size_io = IOMMU_PAGE_ALIGN(size_io, tbl); > > + nio_pages = size_io >> tbl->it_page_shift; > > + io_order = get_iommu_order(size_io, tbl); > > mapping = iommu_alloc(dev, tbl, ret, nio_pages, DMA_BIDIRECTIONAL, > > mask >> tbl->it_page_shift, io_order, 0); > > if (mapping == DMA_MAPPING_ERROR) { > > @@ -900,11 +901,11 @@ void iommu_free_coherent(struct iommu_table *tbl, size_t size, > > void *vaddr, dma_addr_t dma_handle) > > { > > if (tbl) { > > - unsigned int nio_pages; > > + size_t size_io = IOMMU_PAGE_ALIGN(size, tbl); > > + unsigned int nio_pages = size_io >> tbl->it_page_shift; > > > > - size = PAGE_ALIGN(size); > > - nio_pages = size >> tbl->it_page_shift; > > iommu_free(tbl, dma_handle, nio_pages); > > + > > Unrelated new line. Will be removed. Thanks! > > > > size = PAGE_ALIGN(size); > > free_pages((unsigned long)vaddr, get_order(size)); > > } > >