From: Leonardo Bras <hidden> Date: 2020-09-11 17:14:42
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
##
This patchset is based on top of:
https://github.com/linuxppc/linux/tree/next
that already contains
http://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=194179&state=%2A&archive=both
##
So far it's assumed possible to map the guest RAM 1:1 to the bus, which
works with a small number of devices. SRIOV changes it as the user can
configure hundreds VFs and since phyp preallocates TCEs and does not
allow IOMMU pages bigger than 64K, it has to limit the number of TCEs
per a PE to limit waste of physical pages.
As of today, if the assumed direct mapping is not possible, DDW creation
is skipped and the default DMA window "ibm,dma-window" is used instead.
Using the DDW instead of the default DMA window may allow to expand the
amount of memory that can be DMA-mapped, given the number of pages (TCEs)
may stay the same and the default DMA window offers only 4k-pages
while DDW may offer larger pages (64k).
Patch #1 replaces hard-coded 4K page size with a variable containing the
correct page size for the window.
Patch #2 makes sure IOMMU_PAGE_SIZE() <= PAGE_SIZE, to avoid mapping
pages from other processess.
Patch #3 will save TCEs for small allocations when
IOMMU_PAGE_SIZE() < PAGE_SIZE.
Patch #4 let small allocations use largepool if there is no more space
left in the other pools, thus allowing the whole DMA window to be used by
smaller allocations.
Patch #5 introduces iommu_table_in_use(), and replace manual bit-field
checking where it's used. It will be used for aborting enable_ddw() if
there is any current iommu allocation and we are trying single window
indirect mapping.
Patch #6 introduces iommu_pseries_alloc_table() that will be helpful
when indirect mapping needs to replace the iommu_table.
Patch #7 adds helpers for adding DDWs in the list.
Patch #8 refactors enable_ddw() so it returns if direct mapping is
possible, instead of DMA offset. It helps for next patches on
indirect DMA mapping and also allows DMA windows starting at 0x00.
Patch #9 bring new helper to simplify enable_ddw(), allowing
some reorganization for introducing indirect mapping DDW.
Patch #10 adds new helper _iommu_table_setparms() and use it in other
*setparams*() to fill iommu_table. It will also be used for creating a
new iommu_table for indirect mapping.
Patch #11 updates remove_dma_window() to accept different property names,
so we can introduce a new property for indirect mapping.
Patch #12 extracts find_existing_ddw_windows() into
find_existing_ddw_windows_named(), and calls it by it's property name.
This will be useful when the property for indirect mapping is created,
so we can search the device-tree for both properties.
Patch #13:
Instead of destroying the created DDW if it doesn't map the whole
partition, make use of it instead of the default DMA window as it improves
performance. Also, update the iommu_table and re-generate the pools.
It introduces a new property name for DDW with indirect DMA mapping.
Patch #14:
Does some renaming of 'direct window' to 'dma window', given the DDW
created can now be also used in indirect mapping if direct mapping is not
available.
All patches were tested into an LPAR with an Ethernet VF:
4005:01:00.0 Ethernet controller: Mellanox Technologies MT27700 Family
[ConnectX-4 Virtual Function]
Patchset was tested with a 64GB DDW which did not map the whole
partition (128G).
Leonardo Bras (14):
powerpc/pseries/iommu: Replace hard-coded page shift
powerpc/pseries/iommu: Makes sure IOMMU_PAGE_SIZE <= PAGE_SIZE
powerpc/kernel/iommu: Align size for IOMMU_PAGE_SIZE() to save TCEs
powerpc/kernel/iommu: Use largepool as a last resort when !largealloc
powerpc/kernel/iommu: Add new iommu_table_in_use() helper
powerpc/pseries/iommu: Add iommu_pseries_alloc_table() helper
powerpc/pseries/iommu: Add ddw_list_new_entry() helper
powerpc/pseries/iommu: Allow DDW windows starting at 0x00
powerpc/pseries/iommu: Add ddw_property_create() and refactor
enable_ddw()
powerpc/pseries/iommu: Reorganize iommu_table_setparms*() with new
helper
powerpc/pseries/iommu: Update remove_dma_window() to accept property
name
powerpc/pseries/iommu: Find existing DDW with given property name
powerpc/pseries/iommu: Make use of DDW for indirect mapping
powerpc/pseries/iommu: Rename "direct window" to "dma window"
arch/powerpc/include/asm/iommu.h | 1 +
arch/powerpc/include/asm/tce.h | 8 -
arch/powerpc/kernel/iommu.c | 86 ++--
arch/powerpc/platforms/pseries/iommu.c | 648 ++++++++++++++-----------
4 files changed, 417 insertions(+), 326 deletions(-)
--
2.25.4
From: Leonardo Bras <hidden> Date: 2020-09-11 17:16:44
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Some functions assume IOMMU page size can only be 4K (pageshift == 12).
Update them to accept any page size passed, so we can use 64K pages.
In the process, some defines like TCE_SHIFT were made obsolete, and then
removed.
IODA3 Revision 3.0_prd1 (OpenPowerFoundation), Figures 3.4 and 3.5 show
a RPN of 52-bit, and considers a 12-bit pageshift, so there should be
no need of using TCE_RPN_MASK, which masks out any bit after 40 in rpn.
It's usage removed from tce_build_pSeries(), tce_build_pSeriesLP(), and
tce_buildmulti_pSeriesLP().
Most places had a tbl struct, so using tbl->it_page_shift was simple.
tce_free_pSeriesLP() was a special case, since callers not always have a
tbl struct, so adding a tceshift parameter seems the right thing to do.
Signed-off-by: Leonardo Bras <redacted>
---
arch/powerpc/include/asm/tce.h | 8 ------
arch/powerpc/platforms/pseries/iommu.c | 39 +++++++++++++++-----------
2 files changed, 23 insertions(+), 24 deletions(-)
@@ -107,6 +107,8 @@ static int tce_build_pSeries(struct iommu_table *tbl, long index,u64proto_tce;__be64*tcep;u64rpn;+constunsignedlongtceshift=tbl->it_page_shift;+constunsignedlongpagesize=IOMMU_PAGE_SIZE(tbl);proto_tce=TCE_PCI_READ;// Read allowed
@@ -117,10 +119,10 @@ static int tce_build_pSeries(struct iommu_table *tbl, long index,while(npages--){/* can't move this out since we might cross MEMBLOCK boundary */-rpn=__pa(uaddr)>>TCE_SHIFT;-*tcep=cpu_to_be64(proto_tce|(rpn&TCE_RPN_MASK)<<TCE_RPN_SHIFT);+rpn=__pa(uaddr)>>tceshift;+*tcep=cpu_to_be64(proto_tce|rpn<<tceshift);-uaddr+=TCE_PAGE_SIZE;+uaddr+=pagesize;tcep++;}return0;
@@ -146,7 +148,7 @@ static unsigned long tce_get_pseries(struct iommu_table *tbl, long index)returnbe64_to_cpu(*tcep);}-staticvoidtce_free_pSeriesLP(unsignedlongliobn,long,long);+staticvoidtce_free_pSeriesLP(unsignedlongliobn,long,long,long);staticvoidtce_freemulti_pSeriesLP(structiommu_table*,long,long);staticinttce_build_pSeriesLP(unsignedlongliobn,longtcenum,longtceshift,
@@ -166,12 +168,12 @@ static int tce_build_pSeriesLP(unsigned long liobn, long tcenum, long tceshift,proto_tce|=TCE_PCI_WRITE;while(npages--){-tce=proto_tce|(rpn&TCE_RPN_MASK)<<tceshift;+tce=proto_tce|rpn<<tceshift;rc=plpar_tce_put((u64)liobn,(u64)tcenum<<tceshift,tce);if(unlikely(rc==H_NOT_ENOUGH_RESOURCES)){ret=(int)rc;-tce_free_pSeriesLP(liobn,tcenum_start,+tce_free_pSeriesLP(liobn,tcenum_start,tceshift,(npages_start-(npages+1)));break;}
@@ -205,10 +207,11 @@ static int tce_buildmulti_pSeriesLP(struct iommu_table *tbl, long tcenum,longtcenum_start=tcenum,npages_start=npages;intret=0;unsignedlongflags;+constunsignedlongtceshift=tbl->it_page_shift;if((npages==1)||!firmware_has_feature(FW_FEATURE_PUT_TCE_IND)){returntce_build_pSeriesLP(tbl->it_index,tcenum,-tbl->it_page_shift,npages,uaddr,+tceshift,npages,uaddr,direction,attrs);}
@@ -225,13 +228,13 @@ static int tce_buildmulti_pSeriesLP(struct iommu_table *tbl, long tcenum,if(!tcep){local_irq_restore(flags);returntce_build_pSeriesLP(tbl->it_index,tcenum,-tbl->it_page_shift,+tceshift,npages,uaddr,direction,attrs);}__this_cpu_write(tce_page,tcep);}-rpn=__pa(uaddr)>>TCE_SHIFT;+rpn=__pa(uaddr)>>tceshift;proto_tce=TCE_PCI_READ;if(direction!=DMA_TO_DEVICE)proto_tce|=TCE_PCI_WRITE;
@@ -245,12 +248,12 @@ static int tce_buildmulti_pSeriesLP(struct iommu_table *tbl, long tcenum,limit=min_t(long,npages,4096/TCE_ENTRY_SIZE);for(l=0;l<limit;l++){-tcep[l]=cpu_to_be64(proto_tce|(rpn&TCE_RPN_MASK)<<TCE_RPN_SHIFT);+tcep[l]=cpu_to_be64(proto_tce|rpn<<tceshift);rpn++;}rc=plpar_tce_put_indirect((u64)tbl->it_index,-(u64)tcenum<<12,+(u64)tcenum<<tceshift,(u64)__pa(tcep),limit);
@@ -277,12 +280,13 @@ static int tce_buildmulti_pSeriesLP(struct iommu_table *tbl, long tcenum,returnret;}-staticvoidtce_free_pSeriesLP(unsignedlongliobn,longtcenum,longnpages)+staticvoidtce_free_pSeriesLP(unsignedlongliobn,longtcenum,longtceshift,+longnpages){u64rc;while(npages--){-rc=plpar_tce_put((u64)liobn,(u64)tcenum<<12,0);+rc=plpar_tce_put((u64)liobn,(u64)tcenum<<tceshift,0);if(rc&&printk_ratelimit()){printk("tce_free_pSeriesLP: plpar_tce_put failed. rc=%lld\n",rc);
@@ -301,9 +305,11 @@ static void tce_freemulti_pSeriesLP(struct iommu_table *tbl, long tcenum, long nu64rc;if(!firmware_has_feature(FW_FEATURE_STUFF_TCE))-returntce_free_pSeriesLP(tbl->it_index,tcenum,npages);+returntce_free_pSeriesLP(tbl->it_index,tcenum,+tbl->it_page_shift,npages);-rc=plpar_tce_stuff((u64)tbl->it_index,(u64)tcenum<<12,0,npages);+rc=plpar_tce_stuff((u64)tbl->it_index,+(u64)tcenum<<tbl->it_page_shift,0,npages);if(rc&&printk_ratelimit()){printk("tce_freemulti_pSeriesLP: plpar_tce_stuff failed\n");
@@ -319,7 +325,8 @@ static unsigned long tce_get_pSeriesLP(struct iommu_table *tbl, long tcenum)u64rc;unsignedlongtce_ret;-rc=plpar_tce_get((u64)tbl->it_index,(u64)tcenum<<12,&tce_ret);+rc=plpar_tce_get((u64)tbl->it_index,+(u64)tcenum<<tbl->it_page_shift,&tce_ret);if(rc&&printk_ratelimit()){printk("tce_get_pSeriesLP: plpar_tce_get failed. rc=%lld\n",rc);
From: Leonardo Bras <hidden> Date: 2020-09-11 17:19:02
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Having System pagesize < IOMMU pagesize may cause a page owned by another
process/VM to be written by a buggy driver / device.
As it's intended to use DDW for indirect mapping, it's possible to get
a configuration where (PAGE_SIZE = 4k) < (IOMMU_PAGE_SIZE() = 64k).
To avoid this, make sure create_ddw() can only use pagesize <= PAGE_SIZE.
Signed-off-by: Leonardo Bras <redacted>
---
arch/powerpc/platforms/pseries/iommu.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
From: Leonardo Bras <hidden> Date: 2020-09-11 17:21:57
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Currently both iommu_alloc_coherent() and iommu_free_coherent() align the
desired allocation size to PAGE_SIZE, and gets system pages and IOMMU
mappings (TCEs) for that value.
When IOMMU_PAGE_SIZE < PAGE_SIZE, this behavior may cause unnecessary
TCEs to be created for mapping the whole system page.
Example:
- PAGE_SIZE = 64k, IOMMU_PAGE_SIZE() = 4k
- iommu_alloc_coherent() is called for 128 bytes
- 1 system page (64k) is allocated
- 16 IOMMU pages (16 x 4k) are allocated (16 TCEs used)
It would be enough to use a single TCE for this, so 15 TCEs are
wasted in the process.
Update iommu_*_coherent() to make sure the size alignment happens only
for IOMMU_PAGE_SIZE() before calling iommu_alloc() and iommu_free().
Also, on iommu_range_alloc(), replace ALIGN(n, 1 << tbl->it_page_shift)
with IOMMU_PAGE_ALIGN(n, tbl), which is easier to read and does the
same.
Signed-off-by: Leonardo Bras <redacted>
---
arch/powerpc/kernel/iommu.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
@@ -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){
From: Leonardo Bras <hidden> Date: 2020-09-11 17:27:39
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
There are two functions creating direct_window_list entries in a
similar way, so create a ddw_list_new_entry() to avoid duplicity and
simplify those functions.
Signed-off-by: Leonardo Bras <redacted>
---
arch/powerpc/platforms/pseries/iommu.c | 32 +++++++++++++++++---------
1 file changed, 21 insertions(+), 11 deletions(-)
From: Leonardo Bras <hidden> Date: 2020-09-11 17:29:43
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
As of today, doing iommu_range_alloc() only for !largealloc (npages <= 15)
will only be able to use 3/4 of the available pages, given pages on
largepool not being available for !largealloc.
This could mean some drivers not being able to fully use all the available
pages for the DMA window.
Add pages on largepool as a last resort for !largealloc, making all pages
of the DMA window available.
Signed-off-by: Leonardo Bras <redacted>
Reviewed-by: Alexey Kardashevskiy <redacted>
---
arch/powerpc/kernel/iommu.c | 9 +++++++++
1 file changed, 9 insertions(+)
@@ -261,6 +261,15 @@ static unsigned long iommu_range_alloc(struct device *dev,pass++;gotoagain;+}elseif(pass==tbl->nr_pools+1){+/* Last resort: try largepool */+spin_unlock(&pool->lock);+pool=&tbl->large_pool;+spin_lock(&pool->lock);+pool->hint=pool->start;+pass++;+gotoagain;+}else{/* Give up */spin_unlock_irqrestore(&(pool->lock),flags);
From: Leonardo Bras <hidden> Date: 2020-09-11 17:31:52
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
enable_ddw() currently returns the address of the DMA window, which is
considered invalid if has the value 0x00.
Also, it only considers valid an address returned from find_existing_ddw
if it's not 0x00.
Changing this behavior makes sense, given the users of enable_ddw() only
need to know if direct mapping is possible. It can also allow a DMA window
starting at 0x00 to be used.
This will be helpful for using a DDW with indirect mapping, as the window
address will be different than 0x00, but it will not map the whole
partition.
Signed-off-by: Leonardo Bras <redacted>
Reviewed-by: Alexey Kardashevskiy <redacted>
---
arch/powerpc/platforms/pseries/iommu.c | 30 ++++++++++++--------------
1 file changed, 14 insertions(+), 16 deletions(-)
@@ -849,24 +849,25 @@ static void remove_ddw(struct device_node *np, bool remove_prop)np,ret);}-staticu64find_existing_ddw(structdevice_node*pdn)+staticboolfind_existing_ddw(structdevice_node*pdn,u64*dma_addr){structdirect_window*window;conststructdynamic_dma_window_prop*direct64;-u64dma_addr=0;+boolfound=false;spin_lock(&direct_window_list_lock);/* check if we already created a window and dupe that config if so */list_for_each_entry(window,&direct_window_list,list){if(window->device==pdn){direct64=window->prop;-dma_addr=be64_to_cpu(direct64->dma_base);+*dma_addr=be64_to_cpu(direct64->dma_base);+found=true;break;}}spin_unlock(&direct_window_list_lock);-returndma_addr;+returnfound;}staticstructdirect_window*ddw_list_new_entry(structdevice_node*pdn,
From: Leonardo Bras <hidden> Date: 2020-09-11 17:34:39
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Creates a helper to allow allocating a new iommu_table without the need
to reallocate the iommu_group.
This will be helpful for replacing the iommu_table for the new DMA window,
after we remove the old one with iommu_tce_table_put().
Signed-off-by: Leonardo Bras <redacted>
Reviewed-by: Alexey Kardashevskiy <redacted>
---
arch/powerpc/platforms/pseries/iommu.c | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
From: Leonardo Bras <hidden> Date: 2020-09-11 17:34:46
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Having a function to check if the iommu table has any allocation helps
deciding if a tbl can be reset for using a new DMA window.
It should be enough to replace all instances of !bitmap_empty(tbl...).
iommu_table_in_use() skips reserved memory, so we don't need to worry about
releasing it before testing. This causes iommu_table_release_pages() to
become unnecessary, given it is only used to remove reserved memory for
testing.
Also, only allow storing reserved memory values in tbl if they are valid
in the table, so there is no need to check it in the new helper.
Signed-off-by: Leonardo Bras <redacted>
---
arch/powerpc/include/asm/iommu.h | 1 +
arch/powerpc/kernel/iommu.c | 61 +++++++++++++++-----------------
2 files changed, 30 insertions(+), 32 deletions(-)
@@ -655,34 +655,21 @@ static void iommu_table_reserve_pages(struct iommu_table *tbl,if(tbl->it_offset==0)set_bit(0,tbl->it_map);+/* Check if res_start..res_end is a valid range in the table */+if(res_start>=res_end||res_start<tbl->it_offset||+res_end>(tbl->it_offset+tbl->it_size)){+tbl->it_reserved_start=tbl->it_offset;+tbl->it_reserved_end=tbl->it_offset;+return;+}+tbl->it_reserved_start=res_start;tbl->it_reserved_end=res_end;-/* Check if res_start..res_end isn't empty and overlaps the table */-if(res_start&&res_end&&-(tbl->it_offset+tbl->it_size<res_start||-res_end<tbl->it_offset))-return;-for(i=tbl->it_reserved_start;i<tbl->it_reserved_end;++i)set_bit(i-tbl->it_offset,tbl->it_map);}-staticvoidiommu_table_release_pages(structiommu_table*tbl)-{-inti;--/*-*Incasewehavereservedthefirstbit,weshouldnotemit-*thewarningbelow.-*/-if(tbl->it_offset==0)-clear_bit(0,tbl->it_map);--for(i=tbl->it_reserved_start;i<tbl->it_reserved_end;++i)-clear_bit(i-tbl->it_offset,tbl->it_map);-}-/**Buildaiommu_tablestructure.Thiscontainsabitmapwhich*isusedtomanageallocationofthetcespace.
@@ -759,10 +763,8 @@ static void iommu_table_free(struct kref *kref)return;}-iommu_table_release_pages(tbl);-/* verify that table contains no entries */-if(!bitmap_empty(tbl->it_map,tbl->it_size))+if(iommu_table_in_use(tbl))pr_warn("%s: Unexpected TCEs\n",__func__);/* calculate bitmap size in bytes */
@@ -1068,18 +1070,13 @@ int iommu_take_ownership(struct iommu_table *tbl)for(i=0;i<tbl->nr_pools;i++)spin_lock(&tbl->pools[i].lock);-iommu_table_release_pages(tbl);--if(!bitmap_empty(tbl->it_map,tbl->it_size)){+if(iommu_table_in_use(tbl)){pr_err("iommu_tce: it_map is not empty");ret=-EBUSY;-/* Undo iommu_table_release_pages, i.e. restore bit#0, etc */-iommu_table_reserve_pages(tbl,tbl->it_reserved_start,-tbl->it_reserved_end);-}else{-memset(tbl->it_map,0xff,sz);}+memset(tbl->it_map,0xff,sz);+for(i=0;i<tbl->nr_pools;i++)spin_unlock(&tbl->pools[i].lock);spin_unlock_irqrestore(&tbl->large_pool.lock,flags);
From: Leonardo Bras <hidden> Date: 2020-09-11 17:34:55
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Code used to create a ddw property that was previously scattered in
enable_ddw() is now gathered in ddw_property_create(), which deals with
allocation and filling the property, letting it ready for
of_property_add(), which now occurs in sequence.
This created an opportunity to reorganize the second part of enable_ddw():
Without this patch enable_ddw() does, in order:
kzalloc() property & members, create_ddw(), fill ddwprop inside property,
ddw_list_new_entry(), do tce_setrange_multi_pSeriesLP_walk in all memory,
of_add_property(), and list_add().
With this patch enable_ddw() does, in order:
create_ddw(), ddw_property_create(), of_add_property(),
ddw_list_new_entry(), do tce_setrange_multi_pSeriesLP_walk in all memory,
and list_add().
This change requires of_remove_property() in case anything fails after
of_add_property(), but we get to do tce_setrange_multi_pSeriesLP_walk
in all memory, which looks the most expensive operation, only if
everything else succeeds.
Signed-off-by: Leonardo Bras <redacted>
---
arch/powerpc/platforms/pseries/iommu.c | 106 +++++++++++++++----------
1 file changed, 63 insertions(+), 43 deletions(-)
@@ -177,7 +177,7 @@ static int tce_build_pSeriesLP(unsigned long liobn, long tcenum, long tceshift,if(unlikely(rc==H_NOT_ENOUGH_RESOURCES)){ret=(int)rc;tce_free_pSeriesLP(liobn,tcenum_start,tceshift,-(npages_start-(npages+1)));+(npages_start-(npages+1)));break;}
@@ -215,7 +215,7 @@ static int tce_buildmulti_pSeriesLP(struct iommu_table *tbl, long tcenum,if((npages==1)||!firmware_has_feature(FW_FEATURE_PUT_TCE_IND)){returntce_build_pSeriesLP(tbl->it_index,tcenum,tceshift,npages,uaddr,-direction,attrs);+direction,attrs);}local_irq_save(flags);/* to protect tcep and the page behind it */
@@ -269,7 +269,7 @@ static int tce_buildmulti_pSeriesLP(struct iommu_table *tbl, long tcenum,if(unlikely(rc==H_NOT_ENOUGH_RESOURCES)){ret=(int)rc;tce_freemulti_pSeriesLP(tbl,tcenum_start,-(npages_start-(npages+limit)));+(npages_start-(npages+limit)));returnret;}
@@ -1245,72 +1273,64 @@ static bool enable_ddw(struct pci_dev *dev, struct device_node *pdn)gotoout_failed;}len=order_base_2(max_addr);-win64=kzalloc(sizeof(structproperty),GFP_KERNEL);-if(!win64){-dev_info(&dev->dev,-"couldn't allocate property for 64bit dma window\n");-gotoout_failed;-}-win64->name=kstrdup(DIRECT64_PROPNAME,GFP_KERNEL);-win64->value=ddwprop=kmalloc(sizeof(*ddwprop),GFP_KERNEL);-win64->length=sizeof(*ddwprop);-if(!win64->name||!win64->value){-dev_info(&dev->dev,-"couldn't allocate property name and value\n");-gotoout_free_prop;-}ret=create_ddw(dev,ddw_avail,&create,page_shift,len);if(ret!=0)-gotoout_free_prop;--ddwprop->liobn=cpu_to_be32(create.liobn);-ddwprop->dma_base=cpu_to_be64(((u64)create.addr_hi<<32)|-create.addr_lo);-ddwprop->tce_shift=cpu_to_be32(page_shift);-ddwprop->window_shift=cpu_to_be32(len);+gotoout_failed;dev_dbg(&dev->dev,"created tce table LIOBN 0x%x for %pOF\n",-create.liobn,dn);+create.liobn,dn);-window=ddw_list_new_entry(pdn,ddwprop);+win_addr=((u64)create.addr_hi<<32)|create.addr_lo;+win64=ddw_property_create(DIRECT64_PROPNAME,create.liobn,win_addr,+page_shift,len);+if(!win64){+dev_info(&dev->dev,+"couldn't allocate property, property name, or value\n");+gotoout_win_del;+}++ret=of_add_property(pdn,win64);+if(ret){+dev_err(&dev->dev,"unable to add dma window property for %pOF: %d",+pdn,ret);+gotoout_prop_free;+}++window=ddw_list_new_entry(pdn,win64->value);if(!window)-gotoout_clear_window;+gotoout_prop_del;ret=walk_system_ram_range(0,memblock_end_of_DRAM()>>PAGE_SHIFT,win64->value,tce_setrange_multi_pSeriesLP_walk);if(ret){dev_info(&dev->dev,"failed to map direct window for %pOF: %d\n",dn,ret);-gotoout_free_window;-}--ret=of_add_property(pdn,win64);-if(ret){-dev_err(&dev->dev,"unable to add dma window property for %pOF: %d",-pdn,ret);-gotoout_free_window;+gotoout_list_del;}spin_lock(&direct_window_list_lock);list_add(&window->list,&direct_window_list);spin_unlock(&direct_window_list_lock);-dev->dev.archdata.dma_offset=be64_to_cpu(ddwprop->dma_base);+dev->dev.archdata.dma_offset=win_addr;gotoout_unlock;-out_free_window:+out_list_del:kfree(window);-out_clear_window:-remove_ddw(pdn,true);+out_prop_del:+of_remove_property(pdn,win64);-out_free_prop:+out_prop_free:kfree(win64->name);kfree(win64->value);kfree(win64);win64=NULL;+out_win_del:+remove_ddw(pdn,true);+out_failed:if(default_win_removed)reset_dma_window(dev,pdn);
From: Leonardo Bras <hidden> Date: 2020-09-11 17:38:19
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Add a new helper _iommu_table_setparms(), and use it in
iommu_table_setparms() and iommu_table_setparms_lpar() to avoid duplicated
code.
Also, setting tbl->it_ops was happening outsite iommu_table_setparms*(),
so move it to the new helper. Since we need the iommu_table_ops to be
declared before used, move iommu_table_lpar_multi_ops and
iommu_table_pseries_ops to before their respective iommu_table_setparms*().
The tce_exchange_pseries() also had to be moved up, since it's used in
iommu_table_lpar_multi_ops.xchg_no_kill.
Signed-off-by: Leonardo Bras <redacted>
---
arch/powerpc/platforms/pseries/iommu.c | 149 ++++++++++++-------------
1 file changed, 72 insertions(+), 77 deletions(-)
@@ -495,12 +495,62 @@ static int tce_setrange_multi_pSeriesLP(unsigned long start_pfn,returnrc;}+#ifdef CONFIG_IOMMU_API+staticinttce_exchange_pseries(structiommu_table*tbl,longindex,unsigned+long*tce,enumdma_data_direction*direction,+boolrealmode)+{+longrc;+unsignedlongioba=(unsignedlong)index<<tbl->it_page_shift;+unsignedlongflags,oldtce=0;+u64proto_tce=iommu_direction_to_tce_perm(*direction);+unsignedlongnewtce=*tce|proto_tce;++spin_lock_irqsave(&tbl->large_pool.lock,flags);++rc=plpar_tce_get((u64)tbl->it_index,ioba,&oldtce);+if(!rc)+rc=plpar_tce_put((u64)tbl->it_index,ioba,newtce);++if(!rc){+*direction=iommu_tce_direction(oldtce);+*tce=oldtce&~(TCE_PCI_READ|TCE_PCI_WRITE);+}++spin_unlock_irqrestore(&tbl->large_pool.lock,flags);++returnrc;+}+#endif+staticinttce_setrange_multi_pSeriesLP_walk(unsignedlongstart_pfn,unsignedlongnum_pfn,void*arg){returntce_setrange_multi_pSeriesLP(start_pfn,num_pfn,arg);}+staticinlinevoid_iommu_table_setparms(structiommu_table*tbl,unsignedlongbusno,+unsignedlongliobn,unsignedlongwin_addr,+unsignedlongwindow_size,unsignedlongpage_shift,+unsignedlongbase,structiommu_table_ops*table_ops)+{+tbl->it_busno=busno;+tbl->it_index=liobn;+tbl->it_offset=win_addr>>page_shift;+tbl->it_size=window_size>>page_shift;+tbl->it_page_shift=page_shift;+tbl->it_base=base;+tbl->it_blocksize=16;+tbl->it_type=TCE_PCI;+tbl->it_ops=table_ops;+}++structiommu_table_opsiommu_table_pseries_ops={+.set=tce_build_pSeries,+.clear=tce_free_pSeries,+.get=tce_get_pseries+};+staticvoidiommu_table_setparms(structpci_controller*phb,structdevice_node*dn,structiommu_table*tbl)
@@ -509,8 +559,13 @@ static void iommu_table_setparms(struct pci_controller *phb,constunsignedlong*basep;constu32*sizep;-node=phb->dn;+/* Test if we are going over 2GB of DMA space */+if(phb->dma_window_base_cur+phb->dma_window_size>0x80000000ul){+udbg_printf("PCI_DMA: Unexpected number of IOAs under this PHB.\n");+panic("PCI_DMA: Unexpected number of IOAs under this PHB.\n");+}+node=phb->dn;basep=of_get_property(node,"linux,tce-base",NULL);sizep=of_get_property(node,"linux,tce-size",NULL);if(basep==NULL||sizep==NULL){
@@ -519,33 +574,25 @@ static void iommu_table_setparms(struct pci_controller *phb,return;}-tbl->it_base=(unsignedlong)__va(*basep);+_iommu_table_setparms(tbl,phb->bus->number,0,phb->dma_window_base_cur,+phb->dma_window_size,IOMMU_PAGE_SHIFT_4K,+(unsignedlong)__va(*basep),&iommu_table_pseries_ops);if(!is_kdump_kernel())memset((void*)tbl->it_base,0,*sizep);-tbl->it_busno=phb->bus->number;-tbl->it_page_shift=IOMMU_PAGE_SHIFT_4K;--/* Units of tce entries */-tbl->it_offset=phb->dma_window_base_cur>>tbl->it_page_shift;--/* Test if we are going over 2GB of DMA space */-if(phb->dma_window_base_cur+phb->dma_window_size>0x80000000ul){-udbg_printf("PCI_DMA: Unexpected number of IOAs under this PHB.\n");-panic("PCI_DMA: Unexpected number of IOAs under this PHB.\n");-}-phb->dma_window_base_cur+=phb->dma_window_size;--/* Set the tce table size - measured in entries */-tbl->it_size=phb->dma_window_size>>tbl->it_page_shift;--tbl->it_index=0;-tbl->it_blocksize=16;-tbl->it_type=TCE_PCI;}+structiommu_table_opsiommu_table_lpar_multi_ops={+.set=tce_buildmulti_pSeriesLP,+#ifdef CONFIG_IOMMU_API+.xchg_no_kill=tce_exchange_pseries,+#endif+.clear=tce_freemulti_pSeriesLP,+.get=tce_get_pSeriesLP+};+/**iommu_table_setparms_lpar*
@@ -647,7 +683,6 @@ static void pci_dma_bus_setup_pSeries(struct pci_bus *bus)tbl=pci->table_group->tables[0];iommu_table_setparms(pci->phb,dn,tbl);-tbl->it_ops=&iommu_table_pseries_ops;iommu_init_table(tbl,pci->phb->node,0,0);/* Divide the rest (1.75GB) among the children */
From: Leonardo Bras <hidden> Date: 2020-09-11 17:40:35
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Update remove_dma_window() so it can be used to remove DDW with a given
property name.
This enables the creation of new property names for DDW, so we can
have different usage for it, like indirect mapping.
Signed-off-by: Leonardo Bras <redacted>
---
arch/powerpc/platforms/pseries/iommu.c | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
From: Leonardo Bras <hidden> Date: 2020-09-11 17:43:57
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Extract find_existing_ddw_windows() into find_existing_ddw_windows_named()
and calls it with current property name.
This will allow more property names to be checked in
find_existing_ddw_windows(), enabling the creation of new property names,
like the one that will be used for indirect mapping.
Signed-off-by: Leonardo Bras <redacted>
---
arch/powerpc/platforms/pseries/iommu.c | 25 +++++++++++++++----------
1 file changed, 15 insertions(+), 10 deletions(-)
From: Leonardo Bras <hidden> Date: 2020-09-11 17:46:51
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
So far it's assumed possible to map the guest RAM 1:1 to the bus, which
works with a small number of devices. SRIOV changes it as the user can
configure hundreds VFs and since phyp preallocates TCEs and does not
allow IOMMU pages bigger than 64K, it has to limit the number of TCEs
per a PE to limit waste of physical pages.
As of today, if the assumed direct mapping is not possible, DDW creation
is skipped and the default DMA window "ibm,dma-window" is used instead.
The default DMA window uses 4k pages instead of 64k pages, and since
the amount of pages (TCEs) may stay the same (on pHyp case), making
use of DDW instead of the default DMA window for indirect mapping will
expand in up to 16x the amount of memory that can be mapped on DMA.
Indirect mapping will only be used if direct mapping is not a
possibility.
For indirect mapping, it's necessary to re-create the iommu_table with
the new DMA window parameters, so iommu_alloc() can use it.
Removing the default DMA window for using DDW with indirect mapping
is only allowed if there is no current IOMMU memory allocated in
the iommu_table. enable_ddw() is aborted otherwise.
Even though there won't be both direct and indirect mappings at the
same time, we can't reuse the DIRECT64_PROPNAME property name, or else
an older kexec()ed kernel can assume direct mapping, and skip
iommu_alloc(), causing undesirable behavior.
So a new property name DMA64_PROPNAME "linux,dma64-ddr-window-info"
was created to represent a DDW that does not allow direct mapping.
Note: ddw_memory_hotplug_max() was moved up so it can be used in
find_existing_ddw().
Signed-off-by: Leonardo Bras <redacted>
---
arch/powerpc/platforms/pseries/iommu.c | 160 ++++++++++++++++---------
1 file changed, 103 insertions(+), 57 deletions(-)
@@ -1266,15 +1278,25 @@ static bool enable_ddw(struct pci_dev *dev, struct device_node *pdn)}/* verify the window * number of ptes will map the partition */-/* check largest block * page size > max memory hotplug addr */max_addr=ddw_memory_hotplug_max();if(query.largest_available_block<(max_addr>>page_shift)){-dev_dbg(&dev->dev,"can't map partition max 0x%llx with %llu "-"%llu-sized pages\n",max_addr,query.largest_available_block,-1ULL<<page_shift);+dev_dbg(&dev->dev,"can't map partition max 0x%llx with %llu %llu-sized pages\n",+max_addr,query.largest_available_block,+1ULL<<page_shift);++len=order_base_2(query.largest_available_block<<page_shift);+win_name=DMA64_PROPNAME;+}else{+direct_mapping=true;+len=order_base_2(max_addr);+win_name=DIRECT64_PROPNAME;+}++/* DDW + IOMMU on single window may fail if there is any allocation */+if(default_win_removed&&!direct_mapping&&iommu_table_in_use(tbl)){+dev_dbg(&dev->dev,"current IOMMU table in use, can't be replaced.\n");gotoout_failed;}-len=order_base_2(max_addr);ret=create_ddw(dev,ddw_avail,&create,page_shift,len);if(ret!=0)
@@ -1300,15 +1321,37 @@ static bool enable_ddw(struct pci_dev *dev, struct device_node *pdn)}window=ddw_list_new_entry(pdn,win64->value);-if(!window)+if(!window){+dev_dbg(&dev->dev,"couldn't create new list entry\n");gotoout_prop_del;+}-ret=walk_system_ram_range(0,memblock_end_of_DRAM()>>PAGE_SHIFT,-win64->value,tce_setrange_multi_pSeriesLP_walk);-if(ret){-dev_info(&dev->dev,"failed to map direct window for %pOF: %d\n",-dn,ret);-gotoout_list_del;+if(direct_mapping){+/* DDW maps the whole partition, so enable direct DMA mapping */+ret=walk_system_ram_range(0,memblock_end_of_DRAM()>>PAGE_SHIFT,+win64->value,tce_setrange_multi_pSeriesLP_walk);+if(ret){+dev_info(&dev->dev,"failed to map direct window for %pOF: %d\n",+dn,ret);+gotoout_list_del;+}+}else{+/* New table for using DDW instead of the default DMA window */+tbl=iommu_pseries_alloc_table(pci->phb->node);+if(!tbl){+dev_dbg(&dev->dev,"couldn't create new IOMMU table\n");+gotoout_list_del;+}++_iommu_table_setparms(tbl,pci->phb->bus->number,create.liobn,win_addr,+1UL<<len,page_shift,0,&iommu_table_lpar_multi_ops);+iommu_init_table(tbl,pci->phb->node,0,0);++/* Free old table and replace by the newer */+iommu_tce_table_put(pci->table_group->tables[0]);+pci->table_group->tables[0]=tbl;++set_iommu_table_base(&dev->dev,tbl);}spin_lock(&direct_window_list_lock);
From: Leonardo Bras <hidden> Date: 2020-09-11 17:48:49
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
A previous change introduced the usage of DDW as a bigger indirect DMA
mapping when the DDW available size does not map the whole partition.
As most of the code that manipulates direct mappings was reused for
indirect mappings, it's necessary to rename all names and debug/info
messages to reflect that it can be used for both kinds of mapping.
Also, defines DEFAULT_DMA_WIN as "ibm,dma-window" to document that
it's the name of the default DMA window.
Those changes are not supposed to change how the code works in any
way, just adjust naming.
Signed-off-by: Leonardo Bras <redacted>
---
arch/powerpc/platforms/pseries/iommu.c | 102 +++++++++++++------------
1 file changed, 53 insertions(+), 49 deletions(-)
@@ -369,13 +369,14 @@ struct ddw_create_response {u32addr_lo;};-staticLIST_HEAD(direct_window_list);+staticLIST_HEAD(dma_win_list);/* prevents races between memory on/offline and window creation */-staticDEFINE_SPINLOCK(direct_window_list_lock);+staticDEFINE_SPINLOCK(dma_win_list_lock);/* protects initializing window twice for same device */-staticDEFINE_MUTEX(direct_window_init_mutex);+staticDEFINE_MUTEX(dma_win_init_mutex);#define DIRECT64_PROPNAME "linux,direct64-ddr-window-info"#define DMA64_PROPNAME "linux,dma64-ddr-window-info"+#define DEFAULT_DMA_WIN "ibm,dma-window"staticinttce_clearrange_multi_pSeriesLP(unsignedlongstart_pfn,unsignedlongnum_pfn,constvoid*arg)
@@ -706,15 +707,18 @@ static void pci_dma_bus_setup_pSeriesLP(struct pci_bus *bus)pr_debug("pci_dma_bus_setup_pSeriesLP: setting up bus %pOF\n",dn);-/* Find nearest ibm,dma-window, walking up the device tree */+/*+*Findnearestibm,dma-window(defaultDMAwindow),walkingupthe+*devicetree+*/for(pdn=dn;pdn!=NULL;pdn=pdn->parent){-dma_window=of_get_property(pdn,"ibm,dma-window",NULL);+dma_window=of_get_property(pdn,DEFAULT_DMA_WIN,NULL);if(dma_window!=NULL)break;}if(dma_window==NULL){-pr_debug(" no ibm,dma-window property !\n");+pr_debug(" no %s property !\n",DEFAULT_DMA_WIN);return;}
@@ -810,11 +814,11 @@ static void remove_dma_window(struct device_node *np, u32 *ddw_avail,ret=rtas_call(ddw_avail[DDW_REMOVE_PE_DMA_WIN],1,1,NULL,liobn);if(ret)-pr_warn("%pOF: failed to remove direct window: rtas returned "+pr_warn("%pOF: failed to remove dma window: rtas returned ""%d to ibm,remove-pe-dma-window(%x) %llx\n",np,ret,ddw_avail[DDW_REMOVE_PE_DMA_WIN],liobn);else-pr_debug("%pOF: successfully removed direct window: rtas returned "+pr_debug("%pOF: successfully removed dma window: rtas returned ""%d to ibm,remove-pe-dma-window(%x) %llx\n",np,ret,ddw_avail[DDW_REMOVE_PE_DMA_WIN],liobn);}
@@ -842,7 +846,7 @@ static int remove_ddw(struct device_node *np, bool remove_prop, const char *win_ret=of_remove_property(np,win);if(ret)-pr_warn("%pOF: failed to remove direct window property: %d\n",+pr_warn("%pOF: failed to remove dma window property: %d\n",np,ret);return0;}
@@ -886,34 +890,34 @@ static phys_addr_t ddw_memory_hotplug_max(void)staticboolfind_existing_ddw(structdevice_node*pdn,u64*dma_addr,bool*direct_mapping){-structdirect_window*window;-conststructdynamic_dma_window_prop*direct64;+structdma_win*window;+conststructdynamic_dma_window_prop*dma64;unsignedlongwindow_size;boolfound=false;-spin_lock(&direct_window_list_lock);+spin_lock(&dma_win_list_lock);/* check if we already created a window and dupe that config if so */-list_for_each_entry(window,&direct_window_list,list){+list_for_each_entry(window,&dma_win_list,list){if(window->device==pdn){-direct64=window->prop;-*dma_addr=be64_to_cpu(direct64->dma_base);+dma64=window->prop;+*dma_addr=be64_to_cpu(dma64->dma_base);-window_size=(1UL<<be32_to_cpu(direct64->window_shift));+window_size=(1UL<<be32_to_cpu(dma64->window_shift));*direct_mapping=(window_size>=ddw_memory_hotplug_max());found=true;break;}}-spin_unlock(&direct_window_list_lock);+spin_unlock(&dma_win_list_lock);returnfound;}-staticstructdirect_window*ddw_list_new_entry(structdevice_node*pdn,-conststructdynamic_dma_window_prop*dma64)+staticstructdma_win*ddw_list_new_entry(structdevice_node*pdn,+conststructdynamic_dma_window_prop*dma64){-structdirect_window*window;+structdma_win*window;window=kzalloc(sizeof(*window),GFP_KERNEL);if(!window)
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
A previous change introduced the usage of DDW as a bigger indirect DMA
mapping when the DDW available size does not map the whole partition.
As most of the code that manipulates direct mappings was reused for
indirect mappings, it's necessary to rename all names and debug/info
messages to reflect that it can be used for both kinds of mapping.
Also, defines DEFAULT_DMA_WIN as "ibm,dma-window" to document that
it's the name of the default DMA window.
"ibm,dma-window" is so old so it does not need a macro (which btw would
be DMA_WIN_PROPNAME to match the other names) :)
Those changes are not supposed to change how the code works in any
way, just adjust naming.
I simply have this in my .vimrc for the cases like this one:
===
This should cause no behavioural change.
===
@@ -369,13 +369,14 @@ struct ddw_create_response {u32addr_lo;};-staticLIST_HEAD(direct_window_list);+staticLIST_HEAD(dma_win_list);/* prevents races between memory on/offline and window creation */-staticDEFINE_SPINLOCK(direct_window_list_lock);+staticDEFINE_SPINLOCK(dma_win_list_lock);/* protects initializing window twice for same device */-staticDEFINE_MUTEX(direct_window_init_mutex);+staticDEFINE_MUTEX(dma_win_init_mutex);#define DIRECT64_PROPNAME "linux,direct64-ddr-window-info"#define DMA64_PROPNAME "linux,dma64-ddr-window-info"+#define DEFAULT_DMA_WIN "ibm,dma-window"staticinttce_clearrange_multi_pSeriesLP(unsignedlongstart_pfn,unsignedlongnum_pfn,constvoid*arg)
@@ -706,15 +707,18 @@ static void pci_dma_bus_setup_pSeriesLP(struct pci_bus *bus)pr_debug("pci_dma_bus_setup_pSeriesLP: setting up bus %pOF\n",dn);-/* Find nearest ibm,dma-window, walking up the device tree */+/*+*Findnearestibm,dma-window(defaultDMAwindow),walkingupthe+*devicetree+*/for(pdn=dn;pdn!=NULL;pdn=pdn->parent){-dma_window=of_get_property(pdn,"ibm,dma-window",NULL);+dma_window=of_get_property(pdn,DEFAULT_DMA_WIN,NULL);if(dma_window!=NULL)break;}if(dma_window==NULL){-pr_debug(" no ibm,dma-window property !\n");+pr_debug(" no %s property !\n",DEFAULT_DMA_WIN);return;}
@@ -810,11 +814,11 @@ static void remove_dma_window(struct device_node *np, u32 *ddw_avail,ret=rtas_call(ddw_avail[DDW_REMOVE_PE_DMA_WIN],1,1,NULL,liobn);if(ret)-pr_warn("%pOF: failed to remove direct window: rtas returned "+pr_warn("%pOF: failed to remove dma window: rtas returned ""%d to ibm,remove-pe-dma-window(%x) %llx\n",np,ret,ddw_avail[DDW_REMOVE_PE_DMA_WIN],liobn);else-pr_debug("%pOF: successfully removed direct window: rtas returned "+pr_debug("%pOF: successfully removed dma window: rtas returned "
s/dma/DMA/ in all user visible strings.
quoted hunk
"%d to ibm,remove-pe-dma-window(%x) %llx\n",
np, ret, ddw_avail[DDW_REMOVE_PE_DMA_WIN], liobn);
}
@@ -842,7 +846,7 @@ static int remove_ddw(struct device_node *np, bool remove_prop, const char *win_ ret = of_remove_property(np, win); if (ret)- pr_warn("%pOF: failed to remove direct window property: %d\n",+ pr_warn("%pOF: failed to remove dma window property: %d\n", np, ret); return 0; }
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Update remove_dma_window() so it can be used to remove DDW with a given
property name.
Out of context this seems useless. How about?
===
At the moment pseries stores information about created directly mapped
DDW window in DIRECT64_PROPNAME. We are going to implement indirect DDW
window which we need to preserve during kexec so we need another
property for that.
===
Feel free to correct my english :)
quoted hunk
This enables the creation of new property names for DDW, so we can
have different usage for it, like indirect mapping.
Signed-off-by: Leonardo Bras <redacted>
---
arch/powerpc/platforms/pseries/iommu.c | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
@@ -818,31 +818,32 @@ static void remove_dma_window(struct device_node *np, u32 *ddw_avail,np,ret,ddw_avail[DDW_REMOVE_PE_DMA_WIN],liobn);}-staticvoidremove_ddw(structdevice_node*np,boolremove_prop)+staticintremove_ddw(structdevice_node*np,boolremove_prop,constchar*win_name){structproperty*win;u32ddw_avail[DDW_APPLICABLE_SIZE];intret=0;+win=of_find_property(np,win_name,NULL);+if(!win)+return-EINVAL;+ret=of_property_read_u32_array(np,"ibm,ddw-applicable",&ddw_avail[0],DDW_APPLICABLE_SIZE);if(ret)-return;--win=of_find_property(np,DIRECT64_PROPNAME,NULL);-if(!win)-return;+return0;if(win->length>=sizeof(structdynamic_dma_window_prop))remove_dma_window(np,ddw_avail,win);if(!remove_prop)-return;+return0;ret=of_remove_property(np,win);if(ret)pr_warn("%pOF: failed to remove direct window property: %d\n",np,ret);+return0;
You do not test the return code anywhere until 13/14 so I'd say merge
this one into 13/14, the same comment applies to 12/14. If you do not
move chunks in 13/14, it is going to be fairly small patch.
@@ -1480,7 +1481,7 @@ static int iommu_reconfig_notifier(struct notifier_block *nb, unsigned long acti * we have to remove the property when releasing * the device node. */- remove_ddw(np, false);+ remove_ddw(np, false, DIRECT64_PROPNAME); if (pci && pci->table_group) iommu_pseries_free_group(pci->table_group, np->full_name);
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
So far it's assumed possible to map the guest RAM 1:1 to the bus, which
works with a small number of devices. SRIOV changes it as the user can
configure hundreds VFs and since phyp preallocates TCEs and does not
allow IOMMU pages bigger than 64K, it has to limit the number of TCEs
per a PE to limit waste of physical pages.
As of today, if the assumed direct mapping is not possible, DDW creation
is skipped and the default DMA window "ibm,dma-window" is used instead.
The default DMA window uses 4k pages instead of 64k pages, and since
the amount of pages (TCEs) may stay the same (on pHyp case), making
use of DDW instead of the default DMA window for indirect mapping will
expand in up to 16x the amount of memory that can be mapped on DMA.
Indirect mapping will only be used if direct mapping is not a
possibility.
For indirect mapping, it's necessary to re-create the iommu_table with
the new DMA window parameters, so iommu_alloc() can use it.
Removing the default DMA window for using DDW with indirect mapping
is only allowed if there is no current IOMMU memory allocated in
the iommu_table. enable_ddw() is aborted otherwise.
Even though there won't be both direct and indirect mappings at the
same time, we can't reuse the DIRECT64_PROPNAME property name, or else
an older kexec()ed kernel can assume direct mapping, and skip
iommu_alloc(), causing undesirable behavior.
So a new property name DMA64_PROPNAME "linux,dma64-ddr-window-info"
was created to represent a DDW that does not allow direct mapping.
Note: ddw_memory_hotplug_max() was moved up so it can be used in
find_existing_ddw().
Signed-off-by: Leonardo Bras <redacted>
---
arch/powerpc/platforms/pseries/iommu.c | 160 ++++++++++++++++---------
1 file changed, 103 insertions(+), 57 deletions(-)
@@ -1486,7 +1529,10 @@ static int iommu_reconfig_notifier(struct notifier_block *nb, unsigned long acti * we have to remove the property when releasing * the device node. */- remove_ddw(np, false, DIRECT64_PROPNAME);++ if (remove_ddw(np, false, DIRECT64_PROPNAME))+ remove_ddw(np, false, DMA64_PROPNAME);+ if (pci && pci->table_group) iommu_pseries_free_group(pci->table_group, np->full_name);
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Add a new helper _iommu_table_setparms(), and use it in
iommu_table_setparms() and iommu_table_setparms_lpar() to avoid duplicated
code.
Also, setting tbl->it_ops was happening outsite iommu_table_setparms*(),
so move it to the new helper. Since we need the iommu_table_ops to be
declared before used, move iommu_table_lpar_multi_ops and
iommu_table_pseries_ops to before their respective iommu_table_setparms*().
The tce_exchange_pseries() also had to be moved up, since it's used in
iommu_table_lpar_multi_ops.xchg_no_kill.
Use forward declarations (preferred) or make a separate patch for moving
chunks (I do not see much point).
@@ -495,12 +495,62 @@ static int tce_setrange_multi_pSeriesLP(unsigned long start_pfn,returnrc;}+#ifdef CONFIG_IOMMU_API+staticinttce_exchange_pseries(structiommu_table*tbl,longindex,unsigned+long*tce,enumdma_data_direction*direction,+boolrealmode)+{+longrc;+unsignedlongioba=(unsignedlong)index<<tbl->it_page_shift;+unsignedlongflags,oldtce=0;+u64proto_tce=iommu_direction_to_tce_perm(*direction);+unsignedlongnewtce=*tce|proto_tce;++spin_lock_irqsave(&tbl->large_pool.lock,flags);++rc=plpar_tce_get((u64)tbl->it_index,ioba,&oldtce);+if(!rc)+rc=plpar_tce_put((u64)tbl->it_index,ioba,newtce);++if(!rc){+*direction=iommu_tce_direction(oldtce);+*tce=oldtce&~(TCE_PCI_READ|TCE_PCI_WRITE);+}++spin_unlock_irqrestore(&tbl->large_pool.lock,flags);++returnrc;+}+#endif+staticinttce_setrange_multi_pSeriesLP_walk(unsignedlongstart_pfn,unsignedlongnum_pfn,void*arg){returntce_setrange_multi_pSeriesLP(start_pfn,num_pfn,arg);}+staticinlinevoid_iommu_table_setparms(structiommu_table*tbl,unsignedlongbusno,+unsignedlongliobn,unsignedlongwin_addr,+unsignedlongwindow_size,unsignedlongpage_shift,+unsignedlongbase,structiommu_table_ops*table_ops)+{+tbl->it_busno=busno;+tbl->it_index=liobn;+tbl->it_offset=win_addr>>page_shift;+tbl->it_size=window_size>>page_shift;+tbl->it_page_shift=page_shift;+tbl->it_base=base;+tbl->it_blocksize=16;+tbl->it_type=TCE_PCI;+tbl->it_ops=table_ops;+}++structiommu_table_opsiommu_table_pseries_ops={+.set=tce_build_pSeries,+.clear=tce_free_pSeries,+.get=tce_get_pseries+};+staticvoidiommu_table_setparms(structpci_controller*phb,structdevice_node*dn,structiommu_table*tbl)
@@ -509,8 +559,13 @@ static void iommu_table_setparms(struct pci_controller *phb,constunsignedlong*basep;constu32*sizep;-node=phb->dn;+/* Test if we are going over 2GB of DMA space */+if(phb->dma_window_base_cur+phb->dma_window_size>0x80000000ul){+udbg_printf("PCI_DMA: Unexpected number of IOAs under this PHB.\n");+panic("PCI_DMA: Unexpected number of IOAs under this PHB.\n");+}
s/0x80000000ul/2*SZ_1G/
but more to the point - why this check? QEMU can create windows at 0 and
as big as the VM requested. And I am pretty sure I can construct QEMU
command line such as it won't have MMIO32 at all and a 4GB default DMA
window.
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Code used to create a ddw property that was previously scattered in
enable_ddw() is now gathered in ddw_property_create(), which deals with
allocation and filling the property, letting it ready for
of_property_add(), which now occurs in sequence.
This created an opportunity to reorganize the second part of enable_ddw():
Without this patch enable_ddw() does, in order:
kzalloc() property & members, create_ddw(), fill ddwprop inside property,
ddw_list_new_entry(), do tce_setrange_multi_pSeriesLP_walk in all memory,
of_add_property(), and list_add().
With this patch enable_ddw() does, in order:
create_ddw(), ddw_property_create(), of_add_property(),
ddw_list_new_entry(), do tce_setrange_multi_pSeriesLP_walk in all memory,
and list_add().
This change requires of_remove_property() in case anything fails after
of_add_property(), but we get to do tce_setrange_multi_pSeriesLP_walk
in all memory, which looks the most expensive operation, only if
everything else succeeds.
Signed-off-by: Leonardo Bras <redacted>
---
arch/powerpc/platforms/pseries/iommu.c | 106 +++++++++++++++----------
1 file changed, 63 insertions(+), 43 deletions(-)
@@ -177,7 +177,7 @@ static int tce_build_pSeriesLP(unsigned long liobn, long tcenum, long tceshift,if(unlikely(rc==H_NOT_ENOUGH_RESOURCES)){ret=(int)rc;tce_free_pSeriesLP(liobn,tcenum_start,tceshift,-(npages_start-(npages+1)));+(npages_start-(npages+1)));
Unrelated spaces change, the existing code does not seem incorrect (tabs
first, then spaces).
quoted hunk
break;
}
@@ -215,7 +215,7 @@ static int tce_buildmulti_pSeriesLP(struct iommu_table *tbl, long tcenum, if ((npages == 1) || !firmware_has_feature(FW_FEATURE_PUT_TCE_IND)) { return tce_build_pSeriesLP(tbl->it_index, tcenum, tceshift, npages, uaddr,- direction, attrs);+ direction, attrs);
And here.
quoted hunk
}
local_irq_save(flags); /* to protect tcep and the page behind it */
@@ -269,7 +269,7 @@ static int tce_buildmulti_pSeriesLP(struct iommu_table *tbl, long tcenum, if (unlikely(rc == H_NOT_ENOUGH_RESOURCES)) { ret = (int)rc; tce_freemulti_pSeriesLP(tbl, tcenum_start,- (npages_start - (npages + limit)));+ (npages_start - (npages + limit)));
And here.
quoted hunk
return ret;
}
@@ -1121,6 +1121,35 @@ static void reset_dma_window(struct pci_dev *dev, struct device_node *par_dn) ret); }+static struct property *ddw_property_create(const char *propname, u32 liobn, u64 dma_addr,+ u32 page_shift, u32 window_shift)+{+ struct dynamic_dma_window_prop *ddwprop;+ struct property *win64;++ win64 = kzalloc(sizeof(*win64), GFP_KERNEL);+ if (!win64)+ return NULL;++ win64->name = kstrdup(propname, GFP_KERNEL);+ ddwprop = kzalloc(sizeof(*ddwprop), GFP_KERNEL);+ win64->value = ddwprop;+ win64->length = sizeof(*ddwprop);+ if (!win64->name || !win64->value) {+ kfree(win64);+ kfree(win64->name);+ kfree(win64->value);+ return NULL;+ }++ ddwprop->liobn = cpu_to_be32(liobn);+ ddwprop->dma_base = cpu_to_be64(dma_addr);+ ddwprop->tce_shift = cpu_to_be32(page_shift);+ ddwprop->window_shift = cpu_to_be32(window_shift);++ return win64;+}+ /* * If the PE supports dynamic dma windows, and there is space for a table * that can map all pages in a linear offset, then setup such a table,
Some functions assume IOMMU page size can only be 4K (pageshift == 12).
Update them to accept any page size passed, so we can use 64K pages.
In the process, some defines like TCE_SHIFT were made obsolete, and then
removed.
IODA3 Revision 3.0_prd1 (OpenPowerFoundation), Figures 3.4 and 3.5 show
a RPN of 52-bit, and considers a 12-bit pageshift, so there should be
no need of using TCE_RPN_MASK, which masks out any bit after 40 in rpn.
It's usage removed from tce_build_pSeries(), tce_build_pSeriesLP(), and
tce_buildmulti_pSeriesLP().
Most places had a tbl struct, so using tbl->it_page_shift was simple.
tce_free_pSeriesLP() was a special case, since callers not always have a
tbl struct, so adding a tceshift parameter seems the right thing to do.
Signed-off-by: Leonardo Bras <redacted>
@@ -107,6 +107,8 @@ static int tce_build_pSeries(struct iommu_table *tbl, long index,u64proto_tce;__be64*tcep;u64rpn;+constunsignedlongtceshift=tbl->it_page_shift;+constunsignedlongpagesize=IOMMU_PAGE_SIZE(tbl);proto_tce=TCE_PCI_READ;// Read allowed
@@ -117,10 +119,10 @@ static int tce_build_pSeries(struct iommu_table *tbl, long index,while(npages--){/* can't move this out since we might cross MEMBLOCK boundary */-rpn=__pa(uaddr)>>TCE_SHIFT;-*tcep=cpu_to_be64(proto_tce|(rpn&TCE_RPN_MASK)<<TCE_RPN_SHIFT);+rpn=__pa(uaddr)>>tceshift;+*tcep=cpu_to_be64(proto_tce|rpn<<tceshift);-uaddr+=TCE_PAGE_SIZE;+uaddr+=pagesize;tcep++;}return0;
@@ -146,7 +148,7 @@ static unsigned long tce_get_pseries(struct iommu_table *tbl, long index)returnbe64_to_cpu(*tcep);}-staticvoidtce_free_pSeriesLP(unsignedlongliobn,long,long);+staticvoidtce_free_pSeriesLP(unsignedlongliobn,long,long,long);staticvoidtce_freemulti_pSeriesLP(structiommu_table*,long,long);staticinttce_build_pSeriesLP(unsignedlongliobn,longtcenum,longtceshift,
@@ -166,12 +168,12 @@ static int tce_build_pSeriesLP(unsigned long liobn, long tcenum, long tceshift,proto_tce|=TCE_PCI_WRITE;while(npages--){-tce=proto_tce|(rpn&TCE_RPN_MASK)<<tceshift;+tce=proto_tce|rpn<<tceshift;rc=plpar_tce_put((u64)liobn,(u64)tcenum<<tceshift,tce);if(unlikely(rc==H_NOT_ENOUGH_RESOURCES)){ret=(int)rc;-tce_free_pSeriesLP(liobn,tcenum_start,+tce_free_pSeriesLP(liobn,tcenum_start,tceshift,(npages_start-(npages+1)));break;}
@@ -205,10 +207,11 @@ static int tce_buildmulti_pSeriesLP(struct iommu_table *tbl, long tcenum,longtcenum_start=tcenum,npages_start=npages;intret=0;unsignedlongflags;+constunsignedlongtceshift=tbl->it_page_shift;if((npages==1)||!firmware_has_feature(FW_FEATURE_PUT_TCE_IND)){returntce_build_pSeriesLP(tbl->it_index,tcenum,-tbl->it_page_shift,npages,uaddr,+tceshift,npages,uaddr,direction,attrs);}
@@ -225,13 +228,13 @@ static int tce_buildmulti_pSeriesLP(struct iommu_table *tbl, long tcenum,if(!tcep){local_irq_restore(flags);returntce_build_pSeriesLP(tbl->it_index,tcenum,-tbl->it_page_shift,+tceshift,npages,uaddr,direction,attrs);}__this_cpu_write(tce_page,tcep);}-rpn=__pa(uaddr)>>TCE_SHIFT;+rpn=__pa(uaddr)>>tceshift;proto_tce=TCE_PCI_READ;if(direction!=DMA_TO_DEVICE)proto_tce|=TCE_PCI_WRITE;
@@ -245,12 +248,12 @@ static int tce_buildmulti_pSeriesLP(struct iommu_table *tbl, long tcenum,limit=min_t(long,npages,4096/TCE_ENTRY_SIZE);for(l=0;l<limit;l++){-tcep[l]=cpu_to_be64(proto_tce|(rpn&TCE_RPN_MASK)<<TCE_RPN_SHIFT);+tcep[l]=cpu_to_be64(proto_tce|rpn<<tceshift);rpn++;}rc=plpar_tce_put_indirect((u64)tbl->it_index,-(u64)tcenum<<12,+(u64)tcenum<<tceshift,(u64)__pa(tcep),limit);
@@ -277,12 +280,13 @@ static int tce_buildmulti_pSeriesLP(struct iommu_table *tbl, long tcenum,returnret;}-staticvoidtce_free_pSeriesLP(unsignedlongliobn,longtcenum,longnpages)+staticvoidtce_free_pSeriesLP(unsignedlongliobn,longtcenum,longtceshift,+longnpages){u64rc;while(npages--){-rc=plpar_tce_put((u64)liobn,(u64)tcenum<<12,0);+rc=plpar_tce_put((u64)liobn,(u64)tcenum<<tceshift,0);if(rc&&printk_ratelimit()){printk("tce_free_pSeriesLP: plpar_tce_put failed. rc=%lld\n",rc);
@@ -301,9 +305,11 @@ static void tce_freemulti_pSeriesLP(struct iommu_table *tbl, long tcenum, long nu64rc;if(!firmware_has_feature(FW_FEATURE_STUFF_TCE))-returntce_free_pSeriesLP(tbl->it_index,tcenum,npages);+returntce_free_pSeriesLP(tbl->it_index,tcenum,+tbl->it_page_shift,npages);-rc=plpar_tce_stuff((u64)tbl->it_index,(u64)tcenum<<12,0,npages);+rc=plpar_tce_stuff((u64)tbl->it_index,+(u64)tcenum<<tbl->it_page_shift,0,npages);if(rc&&printk_ratelimit()){printk("tce_freemulti_pSeriesLP: plpar_tce_stuff failed\n");
@@ -319,7 +325,8 @@ static unsigned long tce_get_pSeriesLP(struct iommu_table *tbl, long tcenum)u64rc;unsignedlongtce_ret;-rc=plpar_tce_get((u64)tbl->it_index,(u64)tcenum<<12,&tce_ret);+rc=plpar_tce_get((u64)tbl->it_index,+(u64)tcenum<<tbl->it_page_shift,&tce_ret);if(rc&&printk_ratelimit()){printk("tce_get_pSeriesLP: plpar_tce_get failed. rc=%lld\n",rc);
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Having a function to check if the iommu table has any allocation helps
deciding if a tbl can be reset for using a new DMA window.
It should be enough to replace all instances of !bitmap_empty(tbl...).
iommu_table_in_use() skips reserved memory, so we don't need to worry about
releasing it before testing. This causes iommu_table_release_pages() to
become unnecessary, given it is only used to remove reserved memory for
testing.
Also, only allow storing reserved memory values in tbl if they are valid
in the table, so there is no need to check it in the new helper.
Signed-off-by: Leonardo Bras <redacted>
---
arch/powerpc/include/asm/iommu.h | 1 +
arch/powerpc/kernel/iommu.c | 61 +++++++++++++++-----------------
2 files changed, 30 insertions(+), 32 deletions(-)
@@ -655,34 +655,21 @@ static void iommu_table_reserve_pages(struct iommu_table *tbl,if(tbl->it_offset==0)set_bit(0,tbl->it_map);+/* Check if res_start..res_end is a valid range in the table */+if(res_start>=res_end||res_start<tbl->it_offset||+res_end>(tbl->it_offset+tbl->it_size)){+tbl->it_reserved_start=tbl->it_offset;+tbl->it_reserved_end=tbl->it_offset;
This silently ignores overlapped range of the reserved area and the
window which does not seem right.
quoted hunk
+ return;
+ }
+
tbl->it_reserved_start = res_start;
tbl->it_reserved_end = res_end;
- /* Check if res_start..res_end isn't empty and overlaps the table */
- if (res_start && res_end &&
- (tbl->it_offset + tbl->it_size < res_start ||
- res_end < tbl->it_offset))
- return;
-
for (i = tbl->it_reserved_start; i < tbl->it_reserved_end; ++i)
set_bit(i - tbl->it_offset, tbl->it_map);
}
-static void iommu_table_release_pages(struct iommu_table *tbl)
-{
- int i;
-
- /*
- * In case we have reserved the first bit, we should not emit
- * the warning below.
- */
- if (tbl->it_offset == 0)
- clear_bit(0, tbl->it_map);
-
- for (i = tbl->it_reserved_start; i < tbl->it_reserved_end; ++i)
- clear_bit(i - tbl->it_offset, tbl->it_map);
-}
-
/*
* Build a iommu_table structure. This contains a bit map which
* is used to manage allocation of the tce space.
@@ -759,10 +763,8 @@ static void iommu_table_free(struct kref *kref) return; }- iommu_table_release_pages(tbl);- /* verify that table contains no entries */- if (!bitmap_empty(tbl->it_map, tbl->it_size))+ if (iommu_table_in_use(tbl)) pr_warn("%s: Unexpected TCEs\n", __func__); /* calculate bitmap size in bytes */
@@ -1068,18 +1070,13 @@ int iommu_take_ownership(struct iommu_table *tbl) for (i = 0; i < tbl->nr_pools; i++) spin_lock(&tbl->pools[i].lock);- iommu_table_release_pages(tbl);-- if (!bitmap_empty(tbl->it_map, tbl->it_size)) {+ if (iommu_table_in_use(tbl)) { pr_err("iommu_tce: it_map is not empty"); ret = -EBUSY;- /* Undo iommu_table_release_pages, i.e. restore bit#0, etc */- iommu_table_reserve_pages(tbl, tbl->it_reserved_start,- tbl->it_reserved_end);- } else {- memset(tbl->it_map, 0xff, sz); }+ memset(tbl->it_map, 0xff, sz);+ for (i = 0; i < tbl->nr_pools; i++) spin_unlock(&tbl->pools[i].lock); spin_unlock_irqrestore(&tbl->large_pool.lock, flags);
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Having System pagesize < IOMMU pagesize may cause a page owned by another
process/VM to be written by a buggy driver / device.
As it's intended to use DDW for indirect mapping, it's possible to get
a configuration where (PAGE_SIZE = 4k) < (IOMMU_PAGE_SIZE() = 64k).
Have you tried 4K VM kernel under phyp with 64K iommu pages? phyp may
assume it is still correct as it knows that it allocates memory in 256MB
contiguous chunks and for DMA purposes phyp may assume that there just a
VM kernel which owns all the VM physical memory and can align size in
iommu_range_alloc() to the IOMMU page size. Not sure.
quoted hunk
To avoid this, make sure create_ddw() can only use pagesize <= PAGE_SIZE.
Signed-off-by: Leonardo Bras <redacted>
---
arch/powerpc/platforms/pseries/iommu.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
Kind of useless check, if it is not 64K, it is 4K.
I understand you are trying to be safe here but this give a new reader
an idea of more flexibility that there is :) BUILD_BUG_ON() would do
here imho.
page_shift = 12; /* 4kB */
} else {
dev_dbg(&dev->dev, "no supported direct page size in mask %x",
query.page_size);
goto out_failed;
}
+
Unrelated.
/* verify the window * number of ptes will map the partition */
/* check largest block * page size > max memory hotplug addr */
max_addr = ddw_memory_hotplug_max();
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Currently both iommu_alloc_coherent() and iommu_free_coherent() align the
desired allocation size to PAGE_SIZE, and gets system pages and IOMMU
mappings (TCEs) for that value.
When IOMMU_PAGE_SIZE < PAGE_SIZE, this behavior may cause unnecessary
TCEs to be created for mapping the whole system page.
Example:
- PAGE_SIZE = 64k, IOMMU_PAGE_SIZE() = 4k
- iommu_alloc_coherent() is called for 128 bytes
- 1 system page (64k) is allocated
- 16 IOMMU pages (16 x 4k) are allocated (16 TCEs used)
It would be enough to use a single TCE for this, so 15 TCEs are
wasted in the process.
Update iommu_*_coherent() to make sure the size alignment happens only
for IOMMU_PAGE_SIZE() before calling iommu_alloc() and iommu_free().
Also, on iommu_range_alloc(), replace ALIGN(n, 1 << tbl->it_page_shift)
with IOMMU_PAGE_ALIGN(n, tbl), which is easier to read and does the
same.
This seems alright but rather unrelated to the series, probably makes
sense to post it separately.
Reviewed-by: Alexey Kardashevskiy <redacted>
@@ -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){
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
There are two functions creating direct_window_list entries in a
similar way, so create a ddw_list_new_entry() to avoid duplicity and
simplify those functions.
Signed-off-by: Leonardo Bras <redacted>
Yeah, it looks like something went wrong between git format-patch and
git send-email. I will look for in in the next series.
quoted
Some functions assume IOMMU page size can only be 4K (pageshift == 12).
Update them to accept any page size passed, so we can use 64K pages.
In the process, some defines like TCE_SHIFT were made obsolete, and then
removed.
IODA3 Revision 3.0_prd1 (OpenPowerFoundation), Figures 3.4 and 3.5 show
a RPN of 52-bit, and considers a 12-bit pageshift, so there should be
no need of using TCE_RPN_MASK, which masks out any bit after 40 in rpn.
It's usage removed from tce_build_pSeries(), tce_build_pSeriesLP(), and
tce_buildmulti_pSeriesLP().
Most places had a tbl struct, so using tbl->it_page_shift was simple.
tce_free_pSeriesLP() was a special case, since callers not always have a
tbl struct, so adding a tceshift parameter seems the right thing to do.
Signed-off-by: Leonardo Bras <redacted>
@@ -107,6 +107,8 @@ static int tce_build_pSeries(struct iommu_table *tbl, long index,u64proto_tce;__be64*tcep;u64rpn;+constunsignedlongtceshift=tbl->it_page_shift;+constunsignedlongpagesize=IOMMU_PAGE_SIZE(tbl);proto_tce=TCE_PCI_READ;// Read allowed
@@ -117,10 +119,10 @@ static int tce_build_pSeries(struct iommu_table *tbl, long index,while(npages--){/* can't move this out since we might cross MEMBLOCK boundary */-rpn=__pa(uaddr)>>TCE_SHIFT;-*tcep=cpu_to_be64(proto_tce|(rpn&TCE_RPN_MASK)<<TCE_RPN_SHIFT);+rpn=__pa(uaddr)>>tceshift;+*tcep=cpu_to_be64(proto_tce|rpn<<tceshift);-uaddr+=TCE_PAGE_SIZE;+uaddr+=pagesize;tcep++;}return0;
@@ -146,7 +148,7 @@ static unsigned long tce_get_pseries(struct iommu_table *tbl, long index)returnbe64_to_cpu(*tcep);}-staticvoidtce_free_pSeriesLP(unsignedlongliobn,long,long);+staticvoidtce_free_pSeriesLP(unsignedlongliobn,long,long,long);staticvoidtce_freemulti_pSeriesLP(structiommu_table*,long,long);staticinttce_build_pSeriesLP(unsignedlongliobn,longtcenum,longtceshift,
@@ -166,12 +168,12 @@ static int tce_build_pSeriesLP(unsigned long liobn, long tcenum, long tceshift,proto_tce|=TCE_PCI_WRITE;while(npages--){-tce=proto_tce|(rpn&TCE_RPN_MASK)<<tceshift;+tce=proto_tce|rpn<<tceshift;rc=plpar_tce_put((u64)liobn,(u64)tcenum<<tceshift,tce);if(unlikely(rc==H_NOT_ENOUGH_RESOURCES)){ret=(int)rc;-tce_free_pSeriesLP(liobn,tcenum_start,+tce_free_pSeriesLP(liobn,tcenum_start,tceshift,(npages_start-(npages+1)));break;}
@@ -205,10 +207,11 @@ static int tce_buildmulti_pSeriesLP(struct iommu_table *tbl, long tcenum,longtcenum_start=tcenum,npages_start=npages;intret=0;unsignedlongflags;+constunsignedlongtceshift=tbl->it_page_shift;if((npages==1)||!firmware_has_feature(FW_FEATURE_PUT_TCE_IND)){returntce_build_pSeriesLP(tbl->it_index,tcenum,-tbl->it_page_shift,npages,uaddr,+tceshift,npages,uaddr,direction,attrs);}
@@ -225,13 +228,13 @@ static int tce_buildmulti_pSeriesLP(struct iommu_table *tbl, long tcenum,if(!tcep){local_irq_restore(flags);returntce_build_pSeriesLP(tbl->it_index,tcenum,-tbl->it_page_shift,+tceshift,npages,uaddr,direction,attrs);}__this_cpu_write(tce_page,tcep);}-rpn=__pa(uaddr)>>TCE_SHIFT;+rpn=__pa(uaddr)>>tceshift;proto_tce=TCE_PCI_READ;if(direction!=DMA_TO_DEVICE)proto_tce|=TCE_PCI_WRITE;
@@ -245,12 +248,12 @@ static int tce_buildmulti_pSeriesLP(struct iommu_table *tbl, long tcenum,limit=min_t(long,npages,4096/TCE_ENTRY_SIZE);for(l=0;l<limit;l++){-tcep[l]=cpu_to_be64(proto_tce|(rpn&TCE_RPN_MASK)<<TCE_RPN_SHIFT);+tcep[l]=cpu_to_be64(proto_tce|rpn<<tceshift);rpn++;}rc=plpar_tce_put_indirect((u64)tbl->it_index,-(u64)tcenum<<12,+(u64)tcenum<<tceshift,(u64)__pa(tcep),limit);
@@ -277,12 +280,13 @@ static int tce_buildmulti_pSeriesLP(struct iommu_table *tbl, long tcenum,returnret;}-staticvoidtce_free_pSeriesLP(unsignedlongliobn,longtcenum,longnpages)+staticvoidtce_free_pSeriesLP(unsignedlongliobn,longtcenum,longtceshift,+longnpages){u64rc;while(npages--){-rc=plpar_tce_put((u64)liobn,(u64)tcenum<<12,0);+rc=plpar_tce_put((u64)liobn,(u64)tcenum<<tceshift,0);if(rc&&printk_ratelimit()){printk("tce_free_pSeriesLP: plpar_tce_put failed. rc=%lld\n",rc);
@@ -301,9 +305,11 @@ static void tce_freemulti_pSeriesLP(struct iommu_table *tbl, long tcenum, long nu64rc;if(!firmware_has_feature(FW_FEATURE_STUFF_TCE))-returntce_free_pSeriesLP(tbl->it_index,tcenum,npages);+returntce_free_pSeriesLP(tbl->it_index,tcenum,+tbl->it_page_shift,npages);-rc=plpar_tce_stuff((u64)tbl->it_index,(u64)tcenum<<12,0,npages);+rc=plpar_tce_stuff((u64)tbl->it_index,+(u64)tcenum<<tbl->it_page_shift,0,npages);if(rc&&printk_ratelimit()){printk("tce_freemulti_pSeriesLP: plpar_tce_stuff failed\n");
@@ -319,7 +325,8 @@ static unsigned long tce_get_pSeriesLP(struct iommu_table *tbl, long tcenum)u64rc;unsignedlongtce_ret;-rc=plpar_tce_get((u64)tbl->it_index,(u64)tcenum<<12,&tce_ret);+rc=plpar_tce_get((u64)tbl->it_index,+(u64)tcenum<<tbl->it_page_shift,&tce_ret);if(rc&&printk_ratelimit()){printk("tce_get_pSeriesLP: plpar_tce_get failed. rc=%lld\n",rc);
From: Leonardo Bras <hidden> Date: 2020-09-29 20:57:03
On Tue, 2020-09-29 at 13:55 +1000, Alexey Kardashevskiy wrote:
On 12/09/2020 03:07, Leonardo Bras wrote:
quoted
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
A previous change introduced the usage of DDW as a bigger indirect DMA
mapping when the DDW available size does not map the whole partition.
As most of the code that manipulates direct mappings was reused for
indirect mappings, it's necessary to rename all names and debug/info
messages to reflect that it can be used for both kinds of mapping.
Also, defines DEFAULT_DMA_WIN as "ibm,dma-window" to document that
it's the name of the default DMA window.
"ibm,dma-window" is so old so it does not need a macro (which btw would
be DMA_WIN_PROPNAME to match the other names) :)
Thanks for bringing that to my attention!
In fact, DMA_WIN_PROPNAME makes more sense, but it's still generic and
doesn't look to point to a generic one.
Would that be ok to call it DEFAULT_WIN_PROPNAME ?
quoted
Those changes are not supposed to change how the code works in any
way, just adjust naming.
I simply have this in my .vimrc for the cases like this one:
===
This should cause no behavioural change.
===
Great tip! I will make sure to have this saved here :)
Thank you!
On Tue, 2020-09-29 at 13:55 +1000, Alexey Kardashevskiy wrote:
quoted
On 12/09/2020 03:07, Leonardo Bras wrote:
quoted
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
A previous change introduced the usage of DDW as a bigger indirect DMA
mapping when the DDW available size does not map the whole partition.
As most of the code that manipulates direct mappings was reused for
indirect mappings, it's necessary to rename all names and debug/info
messages to reflect that it can be used for both kinds of mapping.
Also, defines DEFAULT_DMA_WIN as "ibm,dma-window" to document that
it's the name of the default DMA window.
"ibm,dma-window" is so old so it does not need a macro (which btw would
be DMA_WIN_PROPNAME to match the other names) :)
Thanks for bringing that to my attention!
In fact, DMA_WIN_PROPNAME makes more sense, but it's still generic and
doesn't look to point to a generic one.
Would that be ok to call it DEFAULT_WIN_PROPNAME ?
I would not touch it at all, the property name is painfully known and
not going to change ever. Does anyone else define it as a macro? I do
not see any:
[fstn1-p1 kernel-dma-bypass]$ git grep "ibm,dma-window" | wc -l
8
[fstn1-p1 kernel-dma-bypass]$ git grep "define.*ibm,dma-window" | wc -l
0
quoted
quoted
Those changes are not supposed to change how the code works in any
way, just adjust naming.
I simply have this in my .vimrc for the cases like this one:
===
This should cause no behavioural change.
===
Great tip! I will make sure to have this saved here :)
Thank you!
if (tbl->it_offset == 0)
set_bit(0, tbl->it_map);
+ /* Check if res_start..res_end is a valid range in the table */
+ if (res_start >= res_end || res_start < tbl->it_offset ||
+ res_end > (tbl->it_offset + tbl->it_size)) {
+ tbl->it_reserved_start = tbl->it_offset;
+ tbl->it_reserved_end = tbl->it_offset;
This silently ignores overlapped range of the reserved area and the
window which does not seem right.
Humm, that makes sense.
Would it be better to do something like this?
if (res_start < tbl->it_offset)
res_start = tbl->it_offset;
if (res_end > (tbl->it_offset + tbl->it_size))
res_end = tbl->it_offset + tbl->it_size;
if (res_start >= res_end) {
tbl->it_reserved_start = tbl->it_offset;
tbl->it_reserved_end = tbl->it_offset;
return;
}
Unrelated. If you think the spaces/tabs thing needs to be fixed, make it
a separate patch and do all these changes there at once.
Sorry, it was some issue with my editor / diff.
I removed those changes for next version.
quoted
-out_free_prop:
+out_prop_free:
Really? :) s/out_prop_del/out_del_prop/ may be? The less unrelated
changes the better.
I changed all labels I added to have out_<action>_<target>, I think
that will allow it to stay like existing labels.
Thanks for reviewing!
Leonardo Bras
From: Leonardo Bras <hidden> Date: 2021-04-11 08:17:18
On Tue, 2020-09-29 at 13:56 +1000, Alexey Kardashevskiy wrote:
On 12/09/2020 03:07, Leonardo Bras wrote:
quoted
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Add a new helper _iommu_table_setparms(), and use it in
iommu_table_setparms() and iommu_table_setparms_lpar() to avoid duplicated
code.
Also, setting tbl->it_ops was happening outsite iommu_table_setparms*(),
so move it to the new helper. Since we need the iommu_table_ops to be
declared before used, move iommu_table_lpar_multi_ops and
iommu_table_pseries_ops to before their respective iommu_table_setparms*().
The tce_exchange_pseries() also had to be moved up, since it's used in
iommu_table_lpar_multi_ops.xchg_no_kill.
Use forward declarations (preferred) or make a separate patch for moving
chunks (I do not see much point).
- node = phb->dn;
+ /* Test if we are going over 2GB of DMA space */
+ if (phb->dma_window_base_cur + phb->dma_window_size > 0x80000000ul) {
+ udbg_printf("PCI_DMA: Unexpected number of IOAs under this PHB.\n");
+ panic("PCI_DMA: Unexpected number of IOAs under this PHB.\n");
+ }
s/0x80000000ul/2*SZ_1G/
Done!
but more to the point - why this check? QEMU can create windows at 0 and
as big as the VM requested. And I am pretty sure I can construct QEMU
command line such as it won't have MMIO32 at all and a 4GB default DMA
window.
Oh, the diff was a little strange here. I did not add this snippet, it
was already in that function, but since I created the helper, the diff
made it look like I introduced this piece of code.
Please take a look in the diff snippet bellow. (This same lines were
there.)
From: Leonardo Bras <hidden> Date: 2021-04-13 05:44:59
On Tue, 2020-09-29 at 13:56 +1000, Alexey Kardashevskiy wrote:
On 12/09/2020 03:07, Leonardo Bras wrote:
quoted
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Update remove_dma_window() so it can be used to remove DDW with a given
property name.
Out of context this seems useless. How about?
===
At the moment pseries stores information about created directly mapped
DDW window in DIRECT64_PROPNAME. We are going to implement indirect DDW
window which we need to preserve during kexec so we need another
property for that.
===
Feel free to correct my english :)
Thanks Alexey! It helped a lot me better describing the reasoning
before the change!
quoted
ret = of_remove_property(np, win);
if (ret)
pr_warn("%pOF: failed to remove direct window property: %d\n",
np, ret);
+ return 0;
You do not test the return code anywhere until 13/14 so I'd say merge
this one into 13/14, the same comment applies to 12/14. If you do not
move chunks in 13/14, it is going to be fairly small patch.
I have applied most suggested changes for patches 11,12,13, but on a
single diff it still amounts to 275 lines.
To be honest, after 7 months of sending this patchset (and working on
other stuff), patch 13 looks a lot like to read alone, and merging with
11 & 12 seems to be too much.
Would it be ok to apply the changes and leave them all separated, or as
a mid ground just merging 11 & 12 together?
Adding your suggested text above should be enough to get enough context
for them. I could also say why the return code is left unused for now.
Best regards,
Leonardo Bras
It is 0,0 only if win_addr>0 which is not the QEMU case.
Oh, ok.
I previously though it was ok to use 0,0 here as any other usage in
this file was also 0,0.
What should I use to get the correct parameters? Use the previous tbl
it_reserved_start and tbl->it_reserved_end is enough?
Best regards,
Leonardo Bras
From: Leonardo Bras <hidden> Date: 2021-04-13 06:04:22
On Wed, 2020-09-30 at 17:29 +1000, Alexey Kardashevskiy wrote:
On 30/09/2020 06:54, Leonardo Bras wrote:
quoted
On Tue, 2020-09-29 at 13:55 +1000, Alexey Kardashevskiy wrote:
quoted
On 12/09/2020 03:07, Leonardo Bras wrote:
quoted
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
A previous change introduced the usage of DDW as a bigger indirect DMA
mapping when the DDW available size does not map the whole partition.
As most of the code that manipulates direct mappings was reused for
indirect mappings, it's necessary to rename all names and debug/info
messages to reflect that it can be used for both kinds of mapping.
Also, defines DEFAULT_DMA_WIN as "ibm,dma-window" to document that
it's the name of the default DMA window.
"ibm,dma-window" is so old so it does not need a macro (which btw would
be DMA_WIN_PROPNAME to match the other names) :)
Thanks for bringing that to my attention!
In fact, DMA_WIN_PROPNAME makes more sense, but it's still generic and
doesn't look to point to a generic one.
Would that be ok to call it DEFAULT_WIN_PROPNAME ?
I would not touch it at all, the property name is painfully known and
not going to change ever. Does anyone else define it as a macro? I do
not see any:
It is 0,0 only if win_addr>0 which is not the QEMU case.
Oh, ok.
I previously though it was ok to use 0,0 here as any other usage in
this file was also 0,0.
What should I use to get the correct parameters? Use the previous tbl
it_reserved_start and tbl->it_reserved_end is enough?
depends on whether you carry reserved start/end even if they are outside
of the dma window.
--
Alexey
It is 0,0 only if win_addr>0 which is not the QEMU case.
Oh, ok.
I previously though it was ok to use 0,0 here as any other usage in
this file was also 0,0.
What should I use to get the correct parameters? Use the previous tbl
it_reserved_start and tbl->it_reserved_end is enough?
depends on whether you carry reserved start/end even if they are outside
of the dma window.
Oh, that makes sense.
On a previous patch (5/14 IIRC), I changed the behavior to only store
the valid range on tbl, but now I understand why it's important to
store the raw value.
Ok, I will change it back so the reserved range stays in tbl even if it
does not intersect with the DMA window. This way I can reuse the values
in case of indirect mapping with DDW.
Is that ok? Are the reserved values are supposed to stay the same after
changing from Default DMA window to DDW?
Best regards,
Leonardo Bras
It is 0,0 only if win_addr>0 which is not the QEMU case.
Oh, ok.
I previously though it was ok to use 0,0 here as any other usage in
this file was also 0,0.
What should I use to get the correct parameters? Use the previous tbl
it_reserved_start and tbl->it_reserved_end is enough?
depends on whether you carry reserved start/end even if they are outside
of the dma window.
Oh, that makes sense.
On a previous patch (5/14 IIRC), I changed the behavior to only store
the valid range on tbl, but now I understand why it's important to
store the raw value.
Ok, I will change it back so the reserved range stays in tbl even if it
does not intersect with the DMA window. This way I can reuse the values
in case of indirect mapping with DDW.
Is that ok? Are the reserved values are supposed to stay the same after
changing from Default DMA window to DDW?
I added them to know what bits in it_map to ignore when checking if
there is any active user of the table. If you have non zero reserved
start/end but they do not affect it_map, then it is rather weird way to
carry reserved start/end from DDW to no-DDW. May be do not set these at
all for DDW with window start at 1<<59 and when going back to no-DDW (or
if DDW starts at 0) - just set them from MMIO32, just as they are
initialized in the first place.
--
Alexey
It is 0,0 only if win_addr>0 which is not the QEMU case.
Oh, ok.
I previously though it was ok to use 0,0 here as any other usage in
this file was also 0,0.
What should I use to get the correct parameters? Use the previous tbl
it_reserved_start and tbl->it_reserved_end is enough?
depends on whether you carry reserved start/end even if they are outside
of the dma window.
Oh, that makes sense.
On a previous patch (5/14 IIRC), I changed the behavior to only store
the valid range on tbl, but now I understand why it's important to
store the raw value.
Ok, I will change it back so the reserved range stays in tbl even if it
does not intersect with the DMA window. This way I can reuse the values
in case of indirect mapping with DDW.
Is that ok? Are the reserved values are supposed to stay the same after
changing from Default DMA window to DDW?
I added them to know what bits in it_map to ignore when checking if
there is any active user of the table. If you have non zero reserved
start/end but they do not affect it_map, then it is rather weird way to
carry reserved start/end from DDW to no-DDW.
Ok, agreed.
May be do not set these at
all for DDW with window start at 1<<59 and when going back to no-DDW (or
if DDW starts at 0) - just set them from MMIO32, just as they are
initialized in the first place.
If I get it correctly from pci_of_scan.c, MMIO32 = {0, 32MB}, is that
correct?
So, if DDW starts at any value in this range (most probably at zero),
we should remove the rest, is that correct?
Could it always use iommu_init_table(..., 0, 32MB) here, so it always
reserve any part of the DMA window that's in this range? Ot there may
be other reserved values range?
and when going back to no-DDW
After iommu_init_table() there should be no failure, so it looks like
there is no 'going back to no-DDW'. Am I missing something?
Thanks for helping!
Best regards,
Leonardo Bras
It is 0,0 only if win_addr>0 which is not the QEMU case.
Oh, ok.
I previously though it was ok to use 0,0 here as any other usage in
this file was also 0,0.
What should I use to get the correct parameters? Use the previous tbl
it_reserved_start and tbl->it_reserved_end is enough?
depends on whether you carry reserved start/end even if they are outside
of the dma window.
Oh, that makes sense.
On a previous patch (5/14 IIRC), I changed the behavior to only store
the valid range on tbl, but now I understand why it's important to
store the raw value.
Ok, I will change it back so the reserved range stays in tbl even if it
does not intersect with the DMA window. This way I can reuse the values
in case of indirect mapping with DDW.
Is that ok? Are the reserved values are supposed to stay the same after
changing from Default DMA window to DDW?
I added them to know what bits in it_map to ignore when checking if
there is any active user of the table. If you have non zero reserved
start/end but they do not affect it_map, then it is rather weird way to
carry reserved start/end from DDW to no-DDW.
Ok, agreed.
quoted
May be do not set these at
all for DDW with window start at 1<<59 and when going back to no-DDW (or
if DDW starts at 0) - just set them from MMIO32, just as they are
initialized in the first place.
If I get it correctly from pci_of_scan.c, MMIO32 = {0, 32MB}, is that
correct?
No, under QEMU it is 0x8000.0000-0x1.0000.0000:
/proc/device-tree/pci@800000020000000/ranges
7 cells for each resource, the second one is MMIO32 (the first is IO
ports, the last is 64bit MMIO).
So, if DDW starts at any value in this range (most probably at zero),
we should remove the rest, is that correct?
Could it always use iommu_init_table(..., 0, 32MB) here, so it always
reserve any part of the DMA window that's in this range? Ot there may
be other reserved values range?
quoted
and when going back to no-DDW
After iommu_init_table() there should be no failure, so it looks like
there is no 'going back to no-DDW'. Am I missing something?
Well, a random driver could request 32bit DMA and if the new window is
1:1, then it would break but this does not seem to happen and we do not
support it anyway so no loss here.
--
Alexey
It is 0,0 only if win_addr>0 which is not the QEMU case.
Oh, ok.
I previously though it was ok to use 0,0 here as any other usage in
this file was also 0,0.
What should I use to get the correct parameters? Use the previous tbl
it_reserved_start and tbl->it_reserved_end is enough?
depends on whether you carry reserved start/end even if they are outside
of the dma window.
Oh, that makes sense.
On a previous patch (5/14 IIRC), I changed the behavior to only store
the valid range on tbl, but now I understand why it's important to
store the raw value.
Ok, I will change it back so the reserved range stays in tbl even if it
does not intersect with the DMA window. This way I can reuse the values
in case of indirect mapping with DDW.
Is that ok? Are the reserved values are supposed to stay the same after
changing from Default DMA window to DDW?
I added them to know what bits in it_map to ignore when checking if
there is any active user of the table. If you have non zero reserved
start/end but they do not affect it_map, then it is rather weird way to
carry reserved start/end from DDW to no-DDW.
Ok, agreed.
quoted
May be do not set these at
all for DDW with window start at 1<<59 and when going back to no-DDW (or
if DDW starts at 0) - just set them from MMIO32, just as they are
initialized in the first place.
If I get it correctly from pci_of_scan.c, MMIO32 = {0, 32MB}, is that
correct?
No, under QEMU it is 0x8000.0000-0x1.0000.0000:
/proc/device-tree/pci@800000020000000/ranges
7 cells for each resource, the second one is MMIO32 (the first is IO
ports, the last is 64bit MMIO).
quoted
So, if DDW starts at any value in this range (most probably at zero),
we should remove the rest, is that correct?
Could it always use iommu_init_table(..., 0, 32MB) here, so it always
reserve any part of the DMA window that's in this range? Ot there may
be other reserved values range?
quoted
and when going back to no-DDW
After iommu_init_table() there should be no failure, so it looks like
there is no 'going back to no-DDW'. Am I missing something?
Well, a random driver could request 32bit DMA and if the new window is
1:1, then it would break but this does not seem to happen and we do not
support it anyway so no loss here.
So you would recommend reading "ranges" with of_get_property() and
using the second entry (cells 7 - 13) in this point, get base & size to
make sure it does not map anything here? (should have no effect if the
value does not intersect with the DMA window)
Thank you for reviewing!
Leonardo Bras