Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp663397pxv; Wed, 14 Jul 2021 12:26:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzDD5ZiRZqC6LO17ifoE/yg2Z9Tso6vELLfuz2q9yybPVyzP71ULBEboUNvHnk0dNCyp7kY X-Received: by 2002:a17:906:3699:: with SMTP id a25mr13828936ejc.452.1626290805531; Wed, 14 Jul 2021 12:26:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626290805; cv=none; d=google.com; s=arc-20160816; b=0iyQqPzxr1tApcS6AHPM2Hh0pVFbHzxUgxfYtqT26fwgfjy1+pWjwPn8nD3bdS6yPR y4sG4y5fMINhIwq/xAvoxgKy0EFHA67zq9PM5p/Y+EoRVDeyixk2LA/1im6T57xbEbU8 pdKpJg0JpmpQSERqHRI10FCxTEA90BJ1ttaKrceTiX4UIHuq7uoDuDsozLwkyqEzNDBy Yc8PHInMk7J+VhV7mG0lhMuLGpaCV+5QUoNj77yTtuuz5Wpr5WLZwdxMeZjaJKoY6bOo 78Frmq4XH9Q6qA9686nHQp27Hz/n/INa6IUi5bAqFpR0B4gSn5B8qfq7K7aPwQan0mUX FWkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=N+JKQJqwCl0d6bUKiCh0PgpItsPMqUhVfYdVbCoV6oQ=; b=aY3cdILM41FMnn6CCupyneLN3sb85dLhYYOJSDtAd4qZpwTe6L5M1pxE5Y24Q7f8Ur Q7lHQReYqjr2iY2NGqadE1FFv1vB2zJ/zF11hRwexpL3Q/3/J/1pZ+6SYmv1QbARU4vz vdHyO0T7EE3fcYrS3LzBvqqdXjFwmI4pcDkz9uZL0NJmLhexyLA/XKg0O9DUjlqx8Qu6 AkW9wc8VRzfDNHfkllTtx5woCbmvNr3E/abKrDtEox/ZSqKwApV9ep8C9mUtvTAMtztw mYzqilo2mqmWCb+UKdJgY7ENoO8nLQJJydoWurskwfj+kq3DcI8QBcKhAiuGmjMSfN6f aAnw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=MINw0efa; 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 r4si3422315edp.476.2021.07.14.12.26.22; Wed, 14 Jul 2021 12:26:45 -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=MINw0efa; 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 S240170AbhGNT1s (ORCPT + 99 others); Wed, 14 Jul 2021 15:27:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44820 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230209AbhGNT1s (ORCPT ); Wed, 14 Jul 2021 15:27:48 -0400 Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7325AC06175F for ; Wed, 14 Jul 2021 12:24:56 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id a2so3540480pgi.6 for ; Wed, 14 Jul 2021 12:24:56 -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 :user-agent:mime-version:content-transfer-encoding; bh=N+JKQJqwCl0d6bUKiCh0PgpItsPMqUhVfYdVbCoV6oQ=; b=MINw0efaLc4wJ0CtFKxIpr9crzGyoIWHvKyAgHMOHiEaLA38w6/psshHzlCRXKKiIV ENLi5dHSoAqVy8qEbg887PK4YQlUD35rqAyvuEbwWK5mJ+ZMRIyGPODT0I8eFhfAkv9F /V+bPuffgS6OgQiryLJBN/b5WMr1dWwLV1IKPd5Jj9/bdXAMUqQcPong+g9yxwgWdnDK 7MIpswHhqVOCiXYvOsz/dLaD0npb/WiTgWNUm0Dp5vYVgwq59i/dt7j/h51JlvmO78K+ xdHm012kB8M3gYgTIEBl+KS3/8ErGG4iQ0auG96vmR6MYo6pBE/Ikyv9iTkLTNwF3YX+ 0C6A== 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:user-agent:mime-version:content-transfer-encoding; bh=N+JKQJqwCl0d6bUKiCh0PgpItsPMqUhVfYdVbCoV6oQ=; b=Ug3lwBR0CAGzYXk/rFC7CelmohE8xtY90zJflBqZMQLiwu90CCryglTN61l5bcLO1Y ZQiKiHUnGA146FMuwrU5sALrIiFBq7pmsIo/m8X/wNsxS/wooPGfSeQ8SZPdI/G1QGFk wtrFAc4irpEq4TmfT+7+J0qRud+ATpYxKDrnN1fkalw+tixufEenJYvQuh9Jlv+rr8g7 NLCD56XwFxiHyDkcFnyoO9fFxtsWPNSY6QpNxborZwFWgB/T5d0BC9bAtRuGbv6BvxRh I+zy+1DY379zmyGB08rQ1IBLrKKb670DbVwyA/JcGTV9gcqr4lyR/MfPQe2ey5/o4YHe iFkA== X-Gm-Message-State: AOAM531gGS9Ec7iGXFW8GDf+JQDOwtP3PdFO+5GcbV7ql723qp+qpgTY pjL1xY/bXH/nnlgtzyAAVak= X-Received: by 2002:a63:5d52:: with SMTP id o18mr11120911pgm.440.1626290695918; Wed, 14 Jul 2021 12:24:55 -0700 (PDT) Received: from ?IPv6:2804:14c:482:92eb:ffdf:6b35:b94d:258? ([2804:14c:482:92eb:ffdf:6b35:b94d:258]) by smtp.gmail.com with ESMTPSA id o3sm6548755pjp.27.2021.07.14.12.24.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Jul 2021 12:24:55 -0700 (PDT) Message-ID: <3951d2c425daa7b05e209a6fc8a550c2fca1645f.camel@gmail.com> Subject: Re: [PATCH v4 10/11] powerpc/pseries/iommu: Make use of DDW for indirect mapping From: Leonardo =?ISO-8859-1?Q?Br=E1s?= To: Alexey Kardashevskiy , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , Joel Stanley , Christophe Leroy , Nicolin Chen , Niklas Schnelle Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Date: Wed, 14 Jul 2021 16:25:08 -0300 In-Reply-To: <2e88a275-3379-6f14-3c93-d2919bee2142@ozlabs.ru> References: <20210430163145.146984-1-leobras.c@gmail.com> <20210430163145.146984-11-leobras.c@gmail.com> <95ac11e9-a709-e0a2-9690-ef13c4a2cd43@ozlabs.ru> <5b8676140f495dbbe3e28ce261e449b885dbae66.camel@gmail.com> <2e88a275-3379-6f14-3c93-d2919bee2142@ozlabs.ru> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2021-07-14 at 18:38 +1000, Alexey Kardashevskiy wrote: > >           for (i = 0; i < > > > > ARRAY_SIZE(pci->phb->mem_resources); > > > > i++) { > > > > +                       const unsigned long mask = > > > > IORESOURCE_MEM_64 > > > > > IORESOURCE_MEM; > > > > + > > > > +                       /* Look for MMIO32 */ > > > > +                       if ((pci->phb->mem_resources[i].flags & > > > > mask) > > > > == IORESOURCE_MEM) > > > > +                               break; > > > > > > What if there is no IORESOURCE_MEM? pci->phb- > > > >mem_resources[i].start > > > below will have garbage. > > > > > > > > Yeah, that makes sense. I will add this lines after 'for': > > > > if (i == ARRAY_SIZE(pci->phb->mem_resources)) { > >   iommu_tce_table_put(newtbl); > >   goto out_del_list; > > } > > > > What do you think? > > > Move this and that "for" before iommu_pseries_alloc_table() so you > won't > need to free if there is no IORESOURCE_MEM. Done! > > > > > > > > > > > > > > > > +               } > > > > + > > > > +               _iommu_table_setparms(newtbl, pci->phb->bus- > > > > >number, > > > > create.liobn, win_addr, > > > > +                                     1UL << len, page_shift, > > > > 0, > > > > &iommu_table_lpar_multi_ops); > > > > +               iommu_init_table(newtbl, pci->phb->node, pci- > > > > >phb- > > > > > mem_resources[i].start, > > > > +                                pci->phb- > > > > >mem_resources[i].end); > > > > + > > > > +               if (default_win_removed) > > > > +                       iommu_tce_table_put(tbl); > > > > > > > > > iommu_tce_table_put() should have been called when the window was > > > removed. > > > > > > Also after some thinking - what happens if there were 2 devices > > > in the > > > PE and one requested 64bit DMA? This will only update > > > set_iommu_table_base() for the 64bit one but not for the other. > > > > > > I think the right thing to do is: > > > > > > 1. check if table[0] is in use, if yes => fail (which this does > > > already) > > > > > > 2. remove default dma window but keep the iommu_table struct with > > > one > > > change - set it_size to 0 (and free it_map) so the 32bit device > > > won't > > > look at a stale structure and think there is some window > > > (imaginery > > > situation for phyp but easy to recreate in qemu). > > > > > > 3. use table[1] for newly created indirect DDW window. > > > > > > 4. change get_iommu_table_base() to return a usable table (or may > > > be > > > not > > > needed?). > > > > > > If this sounds reasonable (does it?), > > > > Looks ok, I will try your suggestion. > > I was not aware of how pci->table_group->tables[] worked, so I > > replaced > > pci->table_group->tables[0] with the new tbl, while moving the > > older in > > pci->table_group->tables[1]. > > > pci->table_group->tables[0] is window#0 at @0. > pci->table_group->tables[1] is window#1 at 0x0800.0000.0000.0000. > That > is all :) > > pseries does not use tables[1] but powernv does (by VFIO only > though). Thanks! This helped a lot! > > > > (4) get_iommu_table_base() does not seem to need update, as it > > returns > > the tlb set by set_iommu_table_base() which is already called in > > the > > !direct_mapping path in current patch. > > Sounds right. > > > > > >   the question is now if you have > > > time to do that and the hardware to test that, or I'll have to > > > finish > > > the work :) > > > > Sorry, for some reason part of this got lost in Evolution mail > > client. > > > > If possible, I do want to finish this work, and I am talking to IBM > > Virt people in order to get testing HW. > > > Even I struggle to find a powervm machine :) > > > > > > > > > > > +               else > > > > +                       pci->table_group->tables[1] = tbl; > > > > > > > > > What is this for? > > > > I was thinking of adding the older table to pci->table_group- > > >tables[1] > > while keeping the newer table on pci->table_group->tables[0]. > > This did work, but I think your suggestion may work better. > > > > Best regards, > > Leonardo Bras > > > > > Thanks a lot for reviewing Alexey! I will send a v5 soon. Best regards, Leonardo Bras