From: Wei Yang <weiyang@linux.vnet.ibm.com> To: Alexey Kardashevskiy <aik@ozlabs.ru> Cc: Wei Yang <weiyang@linux.vnet.ibm.com>, benh@au1.ibm.com, linuxppc-dev@lists.ozlabs.org, bhelgaas@google.com, linux-pci@vger.kernel.org, gwshan@linux.vnet.ibm.com, yan@linux.vnet.ibm.com, qiudayu@linux.vnet.ibm.com Subject: Re: [RFC PATCH V3 06/17] ppc/pnv: allocate pe->iommu_table dynamically Date: Wed, 25 Jun 2014 13:27:58 +0800 [thread overview] Message-ID: <20140625052758.GA8873@richard> (raw) In-Reply-To: <53AA4C32.7060004@ozlabs.ru> On Wed, Jun 25, 2014 at 02:12:34PM +1000, Alexey Kardashevskiy wrote: >On 06/25/2014 11:12 AM, Wei Yang wrote: >> On Tue, Jun 24, 2014 at 08:06:32PM +1000, Alexey Kardashevskiy wrote: >>> On 06/10/2014 11:56 AM, Wei Yang wrote: >>>> Current iommu_table of a PE is a static field. This will have a problem when >>>> iommu_free_table is called. >>> >>> What kind of problem? This table is per PE and PE is not going anywhere. >>> >> >> Yes, for Bus PE, they will always sit in the system. When VF PE introduced, >> they could be released on the fly. When they are released, so do the iommu >> table for the PE. > >iommu_table is a part of PE struct. When PE is released, iommu_table will >go with it as well. Why to make is a pointer? I would understand it if you >added reference counting there but no - iommu_table's lifetime is equal to >PE lifetime. > Yes, iommu_talbe's life time equals to PE lifetime, so when releasing a PE we need to release the iommu table. Currently, there is one function to release the iommu table, iommu_free_table() which takes a pointer of the iommu_table and release it. If the iommu table in PE is just a part of PE, it will have some problem to release it with iommu_free_table(). That's why I make it a pointer in PE structure. > > >-- >Alexey -- Richard Yang Help you, Help me
WARNING: multiple messages have this Message-ID (diff)
From: Wei Yang <weiyang@linux.vnet.ibm.com> To: Alexey Kardashevskiy <aik@ozlabs.ru> Cc: Wei Yang <weiyang@linux.vnet.ibm.com>, benh@au1.ibm.com, linux-pci@vger.kernel.org, gwshan@linux.vnet.ibm.com, yan@linux.vnet.ibm.com, bhelgaas@google.com, qiudayu@linux.vnet.ibm.com, linuxppc-dev@lists.ozlabs.org Subject: Re: [RFC PATCH V3 06/17] ppc/pnv: allocate pe->iommu_table dynamically Date: Wed, 25 Jun 2014 13:27:58 +0800 [thread overview] Message-ID: <20140625052758.GA8873@richard> (raw) In-Reply-To: <53AA4C32.7060004@ozlabs.ru> On Wed, Jun 25, 2014 at 02:12:34PM +1000, Alexey Kardashevskiy wrote: >On 06/25/2014 11:12 AM, Wei Yang wrote: >> On Tue, Jun 24, 2014 at 08:06:32PM +1000, Alexey Kardashevskiy wrote: >>> On 06/10/2014 11:56 AM, Wei Yang wrote: >>>> Current iommu_table of a PE is a static field. This will have a problem when >>>> iommu_free_table is called. >>> >>> What kind of problem? This table is per PE and PE is not going anywhere. >>> >> >> Yes, for Bus PE, they will always sit in the system. When VF PE introduced, >> they could be released on the fly. When they are released, so do the iommu >> table for the PE. > >iommu_table is a part of PE struct. When PE is released, iommu_table will >go with it as well. Why to make is a pointer? I would understand it if you >added reference counting there but no - iommu_table's lifetime is equal to >PE lifetime. > Yes, iommu_talbe's life time equals to PE lifetime, so when releasing a PE we need to release the iommu table. Currently, there is one function to release the iommu table, iommu_free_table() which takes a pointer of the iommu_table and release it. If the iommu table in PE is just a part of PE, it will have some problem to release it with iommu_free_table(). That's why I make it a pointer in PE structure. > > >-- >Alexey -- Richard Yang Help you, Help me
next prev parent reply other threads:[~2014-06-25 5:28 UTC|newest] Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-06-10 1:56 [RFC PATCH V3 00/17] Enable SRIOV on POWER8 Wei Yang 2014-06-10 1:56 ` Wei Yang 2014-06-10 1:56 ` [RFC PATCH V3 01/17] pci/iov: Export interface for retrieve VF's BDF Wei Yang 2014-06-10 1:56 ` Wei Yang 2014-06-10 1:56 ` [RFC PATCH V3 02/17] pci/of: Match PCI VFs to dev-tree nodes dynamically Wei Yang 2014-06-10 1:56 ` Wei Yang 2014-06-23 5:07 ` Gavin Shan 2014-06-23 5:07 ` Gavin Shan 2014-06-23 6:29 ` Wei Yang 2014-06-23 6:29 ` Wei Yang 2014-06-10 1:56 ` [RFC PATCH V3 03/17] ppc/pci: don't unset pci resources for VFs Wei Yang 2014-06-10 1:56 ` Wei Yang 2014-06-10 1:56 ` [RFC PATCH V3 04/17] PCI: SRIOV: add VF enable/disable hook Wei Yang 2014-06-10 1:56 ` Wei Yang 2014-06-23 5:03 ` Gavin Shan 2014-06-23 5:03 ` Gavin Shan 2014-06-23 6:29 ` Wei Yang 2014-06-23 6:29 ` Wei Yang 2014-06-10 1:56 ` [RFC PATCH V3 05/17] ppc/pnv: user macro to define the TCE size Wei Yang 2014-06-10 1:56 ` Wei Yang 2014-06-23 5:12 ` Gavin Shan 2014-06-23 5:12 ` Gavin Shan 2014-06-23 6:31 ` Wei Yang 2014-06-23 6:31 ` Wei Yang 2014-06-10 1:56 ` [RFC PATCH V3 06/17] ppc/pnv: allocate pe->iommu_table dynamically Wei Yang 2014-06-10 1:56 ` Wei Yang 2014-06-24 10:06 ` Alexey Kardashevskiy 2014-06-24 10:06 ` Alexey Kardashevskiy 2014-06-25 1:12 ` Wei Yang 2014-06-25 1:12 ` Wei Yang 2014-06-25 4:12 ` Alexey Kardashevskiy 2014-06-25 4:12 ` Alexey Kardashevskiy 2014-06-25 5:27 ` Wei Yang [this message] 2014-06-25 5:27 ` Wei Yang 2014-06-25 7:50 ` Alexey Kardashevskiy 2014-06-25 7:50 ` Alexey Kardashevskiy 2014-06-25 7:56 ` Benjamin Herrenschmidt 2014-06-25 7:56 ` Benjamin Herrenschmidt 2014-06-25 9:18 ` Wei Yang 2014-06-25 9:18 ` Wei Yang 2014-06-25 9:13 ` Wei Yang 2014-06-25 9:13 ` Wei Yang 2014-06-25 9:20 ` David Laight 2014-06-25 9:20 ` David Laight 2014-06-25 9:31 ` Wei Yang 2014-06-25 9:31 ` Wei Yang 2014-06-25 10:30 ` Alexey Kardashevskiy 2014-06-25 10:30 ` Alexey Kardashevskiy 2014-07-14 3:12 ` Benjamin Herrenschmidt 2014-06-10 1:56 ` [RFC PATCH V3 07/17] ppc/pnv: Add function to deconfig a PE Wei Yang 2014-06-10 1:56 ` Wei Yang 2014-06-23 5:27 ` Gavin Shan 2014-06-23 5:27 ` Gavin Shan 2014-06-23 9:07 ` Wei Yang 2014-06-23 9:07 ` Wei Yang 2014-06-10 1:56 ` [RFC PATCH V3 08/17] PCI: Add weak pcibios_sriov_resource_size() interface Wei Yang 2014-06-10 1:56 ` Wei Yang 2014-06-23 5:41 ` Gavin Shan 2014-06-23 5:41 ` Gavin Shan 2014-06-23 7:56 ` Wei Yang 2014-06-23 7:56 ` Wei Yang 2014-06-10 1:56 ` [RFC PATCH V3 09/17] PCI: Add weak pcibios_sriov_resource_alignment() interface Wei Yang 2014-06-10 1:56 ` Wei Yang 2014-06-10 1:56 ` [RFC PATCH V3 10/17] PCI: take additional IOV BAR alignment in sizing and assigning Wei Yang 2014-06-10 1:56 ` Wei Yang 2014-06-10 1:56 ` [RFC PATCH V3 11/17] ppc/pnv: Expand VF resources according to the number of total_pe Wei Yang 2014-06-10 1:56 ` Wei Yang 2014-06-23 6:07 ` Gavin Shan 2014-06-23 6:07 ` Gavin Shan 2014-06-23 6:56 ` Wei Yang 2014-06-23 6:56 ` Wei Yang 2014-06-23 7:08 ` Gavin Shan 2014-06-23 7:08 ` Gavin Shan 2014-06-10 1:56 ` [RFC PATCH V3 12/17] powerpc/powernv: implement pcibios_sriov_resource_alignment on powernv Wei Yang 2014-06-10 1:56 ` Wei Yang 2014-06-23 6:09 ` Gavin Shan 2014-06-23 6:09 ` Gavin Shan 2014-06-23 8:21 ` Wei Yang 2014-06-23 8:21 ` Wei Yang 2014-06-23 23:29 ` Gavin Shan 2014-06-23 23:29 ` Gavin Shan 2014-06-24 1:24 ` Wei Yang 2014-06-24 1:24 ` Wei Yang 2014-06-10 1:56 ` [RFC PATCH V3 13/17] powerpc/powernv: shift VF resource with an offset Wei Yang 2014-06-10 1:56 ` Wei Yang 2014-06-10 1:56 ` [RFC PATCH V3 14/17] ppc/pci: create/release dev-tree node for VFs Wei Yang 2014-06-10 1:56 ` Wei Yang 2014-06-18 18:26 ` Grant Likely 2014-06-18 20:51 ` Benjamin Herrenschmidt 2014-06-18 20:51 ` Benjamin Herrenschmidt 2014-06-19 2:46 ` Wei Yang 2014-06-19 8:30 ` Grant Likely 2014-06-19 9:42 ` Wei Yang 2014-06-20 3:46 ` Wei Yang 2014-06-10 1:56 ` [RFC PATCH V3 15/17] powerpc/powernv: allocate VF PE Wei Yang 2014-06-10 1:56 ` Wei Yang 2014-06-10 1:56 ` [RFC PATCH V3 16/17] ppc/pci: Expanding IOV BAR, with m64_per_iov supported Wei Yang 2014-06-10 1:56 ` Wei Yang 2014-06-10 1:56 ` [RFC PATCH V3 17/17] ppc/pnv: Group VF PE when IOV BAR is big on PHB3 Wei Yang 2014-06-10 1:56 ` Wei Yang
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20140625052758.GA8873@richard \ --to=weiyang@linux.vnet.ibm.com \ --cc=aik@ozlabs.ru \ --cc=benh@au1.ibm.com \ --cc=bhelgaas@google.com \ --cc=gwshan@linux.vnet.ibm.com \ --cc=linux-pci@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=qiudayu@linux.vnet.ibm.com \ --cc=yan@linux.vnet.ibm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.