On Mon, Dec 25, 2023 at 07:58:41AM -0500, guo...@kernel.org wrote:
> From: Guo Ren
>
> Force to enable virt_spin_lock when KVM guest, because fair locks
> have horrible lock 'holder' preemption issues.
>
> Suggested-by: Leonardo Bras
> Link: https://lkml.kernel.
ic_branch_disable(_spin_lock_key);
> + else
> + pr_info("Enable virt_spin_lock\n");
> +}
> +#endif
> +
> static void __init riscv_spinlock_init(void)
> {
> if (!enable_qspinlock) {
> @@ -274,6 +296,10 @@ static void __init riscv_spinlock_init(void)
> } else {
> pr_info("Queued spinlock: enabled\n");
> }
> +
> +#ifdef CONFIG_QUEUED_SPINLOCKS
> + virt_spin_lock_init();
> +#endif
> }
> #endif
>
> --
> 2.40.1
>
LGTM:
Reviewed-by: Leonardo Bras
On Mon, Dec 25, 2023 at 07:58:39AM -0500, guo...@kernel.org wrote:
> From: Guo Ren
>
> Combo spinlock could support queued and ticket in one Linux Image and
> select them during boot time via command line. Here is the func
> size (Bytes) comparison table below:
>
> TYPE : COMBO
On Mon, Dec 25, 2023 at 07:58:36AM -0500, guo...@kernel.org wrote:
> From: Guo Ren
>
> Move errata vendor func-id definitions from errata_list into
> vendorid_list.h. Unifying these definitions is also for following
> rwonce errata implementation.
>
> Suggested-by: Leonard
On Tue, 2021-04-20 at 15:18 +1000, Alexey Kardashevskiy wrote:
>
> On 20/04/2021 14:54, Leonardo Bras wrote:
> > As of today, if the DDW is big enough to fit (1 << MAX_PHYSMEM_BITS) it's
> > possible to use direct DMA mapping even with pmem region.
> >
> > B
reated, being insufficient for correct
usage.
Fix this so the correct window size is used in this case.
Fixes: bf6e2d562bbc4("powerpc/dma: Fallback to dma_ops when persistent memory
present")
Signed-off-by: Leonardo Bras
---
arch/powerpc/platforms/pseries/iommu.c | 2 +-
1 file chan
On Mon, 2021-04-19 at 20:39 -0500, Rob Herring wrote:
> On Mon, Apr 19, 2021 at 7:35 PM Leonardo Bras wrote:
> >
> > On Mon, 2021-04-19 at 10:44 -0500, Rob Herring wrote:
> > > On Fri, Apr 16, 2021 at 3:58 PM Leonardo Bras wrote:
> > > >
> &g
On Mon, 2021-04-19 at 10:44 -0500, Rob Herring wrote:
> On Fri, Apr 16, 2021 at 3:58 PM Leonardo Bras wrote:
> >
> > Hello Rob, thanks for this feedback!
> >
> > On Thu, 2021-04-15 at 13:59 -0500, Rob Herring wrote:
> > > +PPC and PCI lists
> > >
&
Hello Rob, thanks for this feedback!
On Thu, 2021-04-15 at 13:59 -0500, Rob Herring wrote:
> +PPC and PCI lists
>
> On Thu, Apr 15, 2021 at 1:01 PM Leonardo Bras wrote:
> >
> > Many other resource flag parsers already add this flag when the input
> > has bits 24 &
Hello Rob, thanks for this feedback!
On Thu, 2021-04-15 at 13:59 -0500, Rob Herring wrote:
> +PPC and PCI lists
>
> On Thu, Apr 15, 2021 at 1:01 PM Leonardo Bras wrote:
> >
> > Many other resource flag parsers already add this flag when the input
> > has bits 24 &
know which one is which.
Signed-off-by: Leonardo Bras
---
drivers/of/address.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 73ddf2540f3f..dc7147843783 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -1
e mental load a lot. You can add
> a comment at the single spot you use them, explaining what this is, in a
> much better way!
>
> Comments are *good*.
>
>
> Segher
Thanks for the feedback Alexey, Michael and Segher!
I have sent a v3 for this patch.
http://patchwork.ozlabs.org/project/linuxppc-dev/patch/20210408201915.174217-1-leobra...@gmail.com/
Please let me know of your feedback in it.
Best regards,
Leonardo Bras
ath is far from clear.
>
On hotplug, HPT is resized-up before adding LMBs.
On hotunplug, HPT is resized-down after removing LMBs.
And each one has it's own mechanism to batch HPT resizes...
I can't understand exactly how using it on hotplug fail path can be any
different than using it on hotunplug.
>
Can you please help me understanding this?
Best regards,
Leonardo Bras
resize to the right size for the full add,
> then resize several times again as we perform the add? Or.. I guess
> that will be suppressed by patch 1/3.
Correct.
> That's seems kinda fragile, though.
What do you mean by fragile here?
What would you suggest doing different?
Best regards,
Leonardo Bras
e
> resize attempts first.
This batching is something I had thought a lot about.
Problem is that there are a lot of generic interfaces between memory
hotplug and actually resizing HPT. I tried a simpler approach in
patches 2 & 3, so I don't touch much stuff there.
Best regards,
Leonardo Bras
r 32M, 64M,
128M, 256M and 16G.
Enabling bigger pages would be interesting for direct mapping systems
with a lot of RAM, while using less TCE entries.
Signed-off-by: Leonardo Bras
---
Changes since v2:
- Restore 'int array & shift' strategy
- Remove defines for RTAS "IO Page Size"
On Thu, 2021-04-08 at 03:20 -0300, Leonardo Bras wrote:
> > > +#define QUERY_DDW_PGSIZE_4K 0x01
> > > +#define QUERY_DDW_PGSIZE_64K 0x02
> > > +#define QUERY_DDW_PGSIZE_16M 0x04
> > > +#define QUERY_DDW_PGSIZE_32M 0x08
> > > +#define
Hello Michael, thank you for this feedback!
Comments inline:
On Thu, 2021-04-08 at 15:37 +1000, Michael Ellerman wrote:
> Leonardo Bras writes:
> > According to LoPAR, ibm,query-pe-dma-window output named "IO Page Sizes"
> > will let the OS know all possible p
) and so on.
>
> OTOH the PAPR page sizes need macros as they are the ones which are
> weird and screaming for macros.
>
> I'd steal/rework spapr_page_mask_to_query_mask() from QEMU. Thanks,
>
Thanks for this feedback!
I just sent a v2 applying your suggestions.
Best regards,
Leonardo Bras
r 32M, 64M,
128M, 256M and 16G.
Enabling bigger pages would be interesting for direct mapping systems
with a lot of RAM, while using less TCE entries.
Signed-off-by: Leonardo Bras
---
arch/powerpc/platforms/pseries/iommu.c | 49 ++
1 file changed, 42 insertions(+), 7
r 32M, 64M,
128M, 256M and 16G.
Enabling bigger pages would be interesting for direct mapping systems
with a lot of RAM, while using less TCE entries.
Signed-off-by: Leonardo Bras
---
arch/powerpc/include/asm/iommu.h | 8
arch/powerpc/platforms/pseries/io
Add pages on largepool as a last resort for !largealloc, making all pages
of the DMA window available.
Signed-off-by: Leonardo Bras
Reviewed-by: Alexey Kardashevskiy
---
arch/powerpc/kernel/iommu.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/powerpc/kernel/iommu.c b/a
mu_*_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: L
to temporarily disable all HPT
resize-downs before hotunplug, re-enable them after hotunplug ends,
and then resize-down HPT to the current memory size.
As an example, hotunplugging 256GB from a 385GB guest took 621s without
this patch, and 100s after applied.
Signed-off-by: Leonardo Bras
---
arch
memory:
Adding 256G to a 2GB guest, for example will require 8 HPT resizes.
Perform an HPT resize before memory hotplug, updating HPT to its
final size (considering a successful hotplug), taking the number of
HPT resizes to at most one per memory hotplug action.
Signed-off-by: Leonardo Bras
---
arch
, hotunplug = 100s.
Any feedback will be appreciated!
I believe the code may not be very well placed in available files,
so please give some feedback on that.
Best regards,
Leonardo Bras (3):
powerpc/mm/hash: Avoid resizing-down HPT on first memory hotplug
powerpc/mm/hash: Avoid multiple HPT
memory
hotplug times.
As an example, hotplugging 256GB on a 129GB guest took 710s without this
patch, and 21s after applied.
Signed-off-by: Leonardo Bras
---
arch/powerpc/mm/book3s64/hash_utils.c | 36 ---
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/arch
Hello Sebastian,
Thanks for the feedback!
On Thu, 2021-01-28 at 11:33 +0100, Sebastian Andrzej Siewior wrote:
> On 2021-01-28 03:55:06 [-0300], Leonardo Bras wrote:
> > Currently, during flush_smp_call_function_queue():
> > - All items are transversed once, for inverting.
>
mp; CONFIG_PPC_BOOK3S_64
> >
> > Or something the user need to select himself in menuconfig?
>
> Yeah I meant a default n thing under powerpc kernel debugging somewhere.
So, IIUC all we can do is split this in 2 changes:
1 - Adding notrace to those functions
2 - Introducing a kernel debug config that reverts (1) and 'fixes' mftb
If that's correct, I have some ideas we can use.
For debug option, should we add the offset on get_tb() or mftb()?
Another option would be to adding this tb_offset only in the routines
used by tracing. But this could probably mean having to add a function
in arch-generic code, but still an option.
What do you think?
>
> Thanks,
> Nick
Thank you!
Leonardo Bras
Hello Fabiano,
Thanks for reviewing!
(answers inline)
On Fri, 2021-02-05 at 10:09 -0300, Fabiano Rosas wrote:
> Leonardo Bras writes:
>
> > Before guest entry, TBU40 register is changed to reflect guest timebase.
> > After exitting guest, the register is reverted to i
upstream
> could you put it under a debug config option?
You mean something that is automatically selected whenever those
configs are enabled?
CONFIG_TRACEPOINT && CONFIG_KVM_BOOK3S_HANDLER && CONFIG_PPC_BOOK3S_64
Or something the user need to select himself in menuconfig?
in
kvmppc_guest_entry_inject_int(), which depending on last tracepoint
acquired could actually cause the host to crash.
Save the Timebase Offset to PACA and use it on sched_clock() to always
get the correct timestamp.
Signed-off-by: Leonardo Bras
Suggested-by: Paul Mackerras
---
Changes since v1
in
kvmppc_guest_entry_inject_int(), which depending on last tracepoint
acquired could actually cause the host to crash.
Save the Timebase Offset to PACA and use it on sched_clock() to always
get the correct timestamp.
Signed-off-by: Leonardo Bras
---
arch/powerpc/include/asm/kvm_book3s_asm.h | 1
ores the cpu-offlining case, in
which all items would be transversed again, in both cases.)
Signed-off-by: Leonardo Bras
---
kernel/smp.c | 173 ++-
1 file changed, 87 insertions(+), 86 deletions(-)
diff --git a/kernel/smp.c b/kernel/smp.c
i
(arg &= 0x3f) : Gets (RB) 58:63, missing bit 57
Fixes this by applying the correct mask.
Signed-off-by: Leonardo Bras
---
Changes since v1:
- Commit message 's/LSB/MSB/', because ISA ordering is big-endian.
arch/powerpc/kvm/book3s_hv.c | 6 +++---
1 file changed, 3 insertions(+
(arg &= 0x3f) : Gets (RB) 58:63, missing bit 57
Fixes this by applying the correct mask.
Signed-off-by: Leonardo Bras
---
arch/powerpc/kvm/book3s_hv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_
On Wed, 2020-09-16 at 12:22 +, Peter Geis wrote:
> Good Day,
>
> This series introduces upstream kernel support for the Ouya game console
> device. Please review and apply. Thank you in advance.
>
> Peter Geis (3):
> ARM: tegra: Add device-tree for Ouya
> dt-bindings: Add vendor prefix
On Thu, 2020-09-03 at 14:41 +1000, Alexey Kardashevskiy wrote:
> I am new to this, so I am trying to understand how a memory page mapped
> > as DMA, and used for something else could be a problem.
>
> From the device prospective, there is PCI space and everything from 0
> till 1<<64 is
On Mon, 2020-08-31 at 14:35 +1000, Alexey Kardashevskiy wrote:
>
> On 29/08/2020 04:36, Leonardo Bras wrote:
> > On Mon, 2020-08-24 at 15:17 +1000, Alexey Kardashevskiy wrote:
> > > On 18/08/2020 09:40, Leonardo Bras wrote:
> > > > As of today, if the biggest
On Mon, 2020-08-31 at 14:34 +1000, Alexey Kardashevskiy wrote:
>
> On 29/08/2020 01:25, Leonardo Bras wrote:
> > On Mon, 2020-08-24 at 15:07 +1000, Alexey Kardashevskiy wrote:
> > > On 18/08/2020 09:40, Leonardo Bras wrote:
> > > > Code used to create a ddw prope
the
> > > supported set of sizes is different for P8/P9 and type of IO (PHB,
> > > NVLink/CAPI).
> > >
> > >
> > > > > > Update those functions to guarantee alignment with requested size
> > > > > > using IOMMU_PAGE_ALIGN()
On Mon, 2020-08-31 at 13:48 +1000, Alexey Kardashevskiy wrote:
> > > > Well, I created this TCE_RPN_BITS = 52 because the previous mask was a
> > > > hardcoded 40-bit mask (0xfful), for hard-coded 12-bit (4k)
> > > > pagesize, and on PAPR+/LoPAR also defines TCE as having bits 0-51
> > > >
DMA_TO_DEVICE DMA_TO_DEVICE, DMA_NONE
DMA_FROM_DEVICE DMA_FROM_DEVICE, DMA_NONE
DMA_NONEDMA_NONE
This macro is useful for checking if a DMA mapping can be reused.
Signed-off-by: Leonardo Bras
---
include/linux/dma-direction.h | 3 +++
1 file changed, 3 insertions(+)
diff
for the FIFO is just for testing purposes.
It's also very possible that it will not be a good idea in platforms
other than pseries, (i have not tested them).
I can plan I bypass for those cases without much work.
Thank you!
Leonardo Bras (2):
dma-direction: Add DMA_DIR_COMPAT() macro to test
have:
- Both XArrays,
- 2 llist for entry/removal point on FIFO,
- 1 Atomic Cachesize, to manage the FIFO.
Signed-off-by: Leonardo Bras
---
arch/powerpc/include/asm/iommu-cache.h | 31
arch/powerpc/include/asm/iommu.h | 4 +
arch/powerpc/kernel/Makefile | 2 +-
On Fri, 2020-08-28 at 11:58 +1000, Alexey Kardashevskiy wrote:
>
> On 28/08/2020 08:11, Leonardo Bras wrote:
> > On Mon, 2020-08-24 at 13:46 +1000, Alexey Kardashevskiy wrote:
> > > > static int find_existing_ddw_windows(void)
> > > > {
> > >
>
> > > > Update those functions to guarantee alignment with requested size
> > > > using IOMMU_PAGE_ALIGN() before doing iommu_alloc() / iommu_free().
> > > >
> > > > Also, on iommu_range_alloc(), replace ALIGN(n, 1 << tbl->it_page_shift)
>
On Fri, 2020-08-28 at 12:27 +1000, Alexey Kardashevskiy wrote:
>
> On 28/08/2020 01:32, Leonardo Bras wrote:
> > Hello Alexey, thank you for this feedback!
> >
> > On Sat, 2020-08-22 at 19:33 +1000, Alexey Kardashevskiy wrote:
> > > > +#define TCE_RPN_BITS
On Mon, 2020-08-24 at 15:17 +1000, Alexey Kardashevskiy wrote:
>
> On 18/08/2020 09:40, Leonardo Bras wrote:
> > As of today, if the biggest DDW that can be created can't map the whole
> > partition, it's creation is skipped and the default DMA window
> > "ib
On Mon, 2020-08-24 at 15:07 +1000, Alexey Kardashevskiy wrote:
>
> On 18/08/2020 09:40, Leonardo Bras wrote:
> > 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
On Mon, 2020-08-24 at 13:44 +1000, Alexey Kardashevskiy wrote:
>
> > On 18/08/2020 09:40, Leonardo Bras wrote:
> > enable_ddw() currently returns the address of the DMA window, which is
> > considered invalid if has the value 0x00.
> >
> > Also, it only conside
On Mon, 2020-08-24 at 13:46 +1000, Alexey Kardashevskiy wrote:
> > static int find_existing_ddw_windows(void)
> > {
> > int len;
> > @@ -887,18 +905,11 @@ static int find_existing_ddw_windows(void)
> > if (!direct64)
> > continue;
> >
> > - window
On Mon, 2020-08-24 at 10:38 +1000, Alexey Kardashevskiy wrote:
>
> On 18/08/2020 09:40, Leonardo Bras wrote:
> > Creates a helper to allow allocating a new iommu_table without the need
> > to reallocate the iommu_group.
> >
> > This will be helpful for replacing t
gned would cause it to become a big value and run
over memory outside the bitmap.
But I think you are right. That is not the place to check if the
reserved values are valid. It should just trust them here.
I intent to change iommu_table_reserve_pages() to only store the
parameters in it_reserved_{start,end} if they are in the range, and or
it_offset in both of them if they are not.
What do you think?
Thanks for the feedback!
Leonardo Bras
On Sat, 2020-08-22 at 20:09 +1000, Alexey Kardashevskiy wrote:
> > + goto again;
> > +
>
> A nit: unnecessary new line.
I was following the pattern used above. There is a newline after every
"goto again" in this 'if'.
> Reviewed-by: Alexey Kardashevskiy
Thank you!
On Sat, 2020-08-22 at 20:07 +1000, Alexey Kardashevskiy wrote:
>
> On 18/08/2020 09:40, Leonardo Bras wrote:
> > Both iommu_alloc_coherent() and iommu_free_coherent() assume that once
> > size is aligned to PAGE_SIZE it will be aligned to IOMMU_PAGE_SIZE.
>
> The only cas
Hello Alexey, thank you for this feedback!
On Sat, 2020-08-22 at 19:33 +1000, Alexey Kardashevskiy wrote:
> > +#define TCE_RPN_BITS 52 /* Bits 0-51 represent
> > RPN on TCE */
>
> Ditch this one and use MAX_PHYSMEM_BITS instead? I am pretty sure this
> is the actual
sive operation, only if
everything else succeeds.
Signed-off-by: Leonardo Bras
---
arch/powerpc/platforms/pseries/iommu.c | 97 +++---
1 file changed, 57 insertions(+), 40 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc/platforms/pseries/iommu.c
i
t;
looks the right thing to do.
To make sure the property differentiates both cases, a new u32 for flags
was added at the end of the property, where BIT(0) set means direct
mapping.
Signed-off-by: Leonardo Bras
---
arch/powerpc/platforms/pseries/iommu.c | 108 +++--
1 file
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
---
arch/powerpc/platforms
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
---
ar
There are two functions adding DDW to the direct_window_list in a
similar way, so create a ddw_list_add() to avoid duplicity and
simplify those functions.
Also, on enable_ddw(), add list_del() on out_free_window to allow
removing the window from list if any error occurs.
Signed-off-by: Leonardo
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
---
arch/powerpc/platforms
, on iommu_range_alloc(), replace ALIGN(n, 1 << tbl->it_page_shift)
with IOMMU_PAGE_ALIGN(n, tbl), which seems easier to read.
Signed-off-by: Leonardo Bras
---
arch/powerpc/kernel/iommu.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kernel/iommu.c b/arc
Add pages on largepool as a last resort for !largealloc, making all pages
of the DMA window available.
Signed-off-by: Leonardo Bras
---
arch/powerpc/kernel/iommu.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index d70860878
: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 (10):
powerpc/pseries/iommu: Replace hard-coded page shift
powerpc/kernel/iommu: Align size for IOMMU_PAGE
testing. This causes iommu_table_release_pages() to
become unnecessary, given it is only used to remove reserved memory for
testing.
Signed-off-by: Leonardo Bras
---
arch/powerpc/include/asm/iommu.h | 1 +
arch/powerpc/kernel/iommu.c | 62 ++--
2 files changed
used.
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
---
arch/powerpc/include/asm/tce.h |
Hello Michael,
Do you suggest any change for this patchset?
Any chance it can get in this merge window?
Best regards,
Leonardo Bras
On Wed, 2020-08-05 at 00:04 -0300, Leonardo Bras wrote:
> There are some devices in which a hypervisor may only allow 1 DMA window
> to exist at
Travis reported successful compilation with mpe/merge:
https://travis-ci.org/github/LeoBras/linux-ppc/builds/715028857
suggested by LoPAR: First reading the size of the extension array from
index 0, checking if the property exists, and then returning it's value.
Signed-off-by: Leonardo Bras
Tested-by: David Dai
---
arch/powerpc/platforms/pseries/iommu.c | 91 +++---
1 file changed, 81 i
;.
Signed-off-by: Leonardo Bras
Tested-by: David Dai
---
arch/powerpc/platforms/pseries/iommu.c | 45 +++---
1 file changed, 27 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc/platforms/pseries/iommu.c
index 1a933c4e8bba..4e
Create defines to help handling ibm,ddw-applicable values, avoiding
confusion about the index of given operations.
Signed-off-by: Leonardo Bras
Tested-by: David Dai
---
arch/powerpc/platforms/pseries/iommu.c | 43 --
1 file changed, 26 insertions(+), 17 deletions
time value, available in "ibm,dma-window" device tree node.
Signed-off-by: Leonardo Bras
Tested-by: David Dai
---
arch/powerpc/platforms/pseries/iommu.c | 73 +++---
1 file changed, 66 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iom
O'Halloran for the feedback provided!
Leonardo Bras (4):
powerpc/pseries/iommu: Create defines for operations in
ibm,ddw-applicable
powerpc/pseries/iommu: Update call to ibm,query-pe-dma-windows
powerpc/pseries/iommu: Move window-removing part of remove_ddw into
remove_dma_window
power
On Tue, 2020-07-21 at 19:52 -0500, Brian King wrote:
> >
> > As of today, there seems to be nothing like that happening in the
> > driver I am testing.
> > I spoke to Brian King on slack, and he mentioned that at the point DDW
> > is created there should be no allocations in place.
>
> I think
On Wed, 2020-07-22 at 11:28 +1000, Alexey Kardashevskiy wrote:
>
> On 22/07/2020 08:13, Leonardo Bras wrote:
> > On Tue, 2020-07-21 at 14:59 +1000, Alexey Kardashevskiy wrote:
> > > On 16/07/2020 17:16, Leonardo Bras wrote:
> > > > Move the part of iommu_table_fr
On Tue, 2020-07-21 at 14:59 +1000, Alexey Kardashevskiy wrote:
>
> On 16/07/2020 17:16, Leonardo Bras wrote:
> > Move the part of iommu_table_free() that does struct iommu_table cleaning
> > into iommu_table_clean, so we can invoke it separately.
> >
> > This new f
On Thu, 2020-07-16 at 04:16 -0300, Leonardo Bras wrote:
> +static void iommu_pseries_table_update(struct pci_dev *dev,
> + struct device_node *pdn)
> +{
> + const struct dynamic_dma_window_prop *ddw;
> + struct pci_dn *pci;
&g
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
---
ar
t;
looks the right thing to do.
Signed-off-by: Leonardo Bras
---
arch/powerpc/include/asm/iommu.h | 3 ++
arch/powerpc/kernel/iommu.c| 15 +
arch/powerpc/platforms/pseries/iommu.c | 46 +++---
3 files changed, 52 insertions(+), 12 deletions(-)
diff --
-off-by: Leonardo Bras
---
arch/powerpc/kernel/iommu.c | 30 ++
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 9704f3f76e63..c3242253a4e7 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch
;.
Signed-off-by: Leonardo Bras
---
arch/powerpc/platforms/pseries/iommu.c | 45 +++---
1 file changed, 27 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc/platforms/pseries/iommu.c
index 1a933c4e8bba..4e33147825cc 100644
time value, available in "ibm,dma-window" device tree node.
Signed-off-by: Leonardo Bras
---
arch/powerpc/platforms/pseries/iommu.c | 73 +++---
1 file changed, 66 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/power
://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=184420=%2A=both
Special thanks for Alexey Kardashevskiy, Brian King and
Oliver O'Halloran for the feedback provided!
Leonardo Bras (7):
powerpc/pseries/iommu: Create defines for operations in
ibm,ddw-applicable
powerpc/pseries/iommu: Update call
Create defines to help handling ibm,ddw-applicable values, avoiding
confusion about the index of given operations.
Signed-off-by: Leonardo Bras
---
arch/powerpc/platforms/pseries/iommu.c | 43 --
1 file changed, 26 insertions(+), 17 deletions(-)
diff --git a/arch
suggested by LoPAR: First reading the size of the extension array from
index 0, checking if the property exists, and then returning it's value.
Signed-off-by: Leonardo Bras
---
arch/powerpc/platforms/pseries/iommu.c | 91 +++---
1 file changed, 81 insertions(+), 10 delet
In fact, the changes over the last patch are more complex than the
current patch.
Just for reference, that's how enable_ddw() currently patches:
@@ -1087,7 +1119,7 @@ static u64 enable_ddw(struct pci_dev *dev, struct
device_node *pdn)
struct device_node *dn;
u32
On Tue, 2020-07-14 at 14:52 +1000, Alexey Kardashevskiy wrote:
>
> On 14/07/2020 12:40, Leonardo Bras wrote:
> > Thank you for this feedback Alexey!
> >
> > On Mon, 2020-07-13 at 17:33 +1000, Alexey Kardashevskiy wrote:
> > > [...]
> > > > -
Thank you for this feedback Alexey!
On Mon, 2020-07-13 at 17:33 +1000, Alexey Kardashevskiy wrote:
> [...]
> > - int len, ret;
> > + int len, ret, reset_win_ext;
>
> Make it "reset_token".
Oh, it's not a token here, it just checks if the reset_win extension
exists. The token would be
Signed-off-by: Leonardo Bras
---
arch/powerpc/include/asm/hvcall.h| 2 +-
arch/powerpc/kvm/trace_hv.h | 2 +-
tools/perf/arch/powerpc/util/book3s_hcalls.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/hvcall.h
b/arch/powerpc/i
On Thu, 2020-07-02 at 10:31 +1000, Alexey Kardashevskiy wrote:
>
> On 02/07/2020 09:48, Leonardo Bras wrote:
> > On Wed, 2020-07-01 at 16:57 -0300, Leonardo Bras wrote:
> > > > It is not necessarily "direct" anymore as the name suggests, you may
> > >
time value, available in "ibm,dma-window" device tree node.
Signed-off-by: Leonardo Bras
---
arch/powerpc/platforms/pseries/iommu.c | 83 +-
1 file changed, 69 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/power
ddr-window-info"
to
define DMA64_PROPNAME "linux,dma64-ddr-window-info"
looks the right thing to do.
Signed-off-by: Leonardo Bras
---
arch/powerpc/platforms/pseries/iommu.c | 38 --
1 file changed, 24 insertions(+), 14 deletions(-)
diff --git a/arch/powerp
;.
Signed-off-by: Leonardo Bras
---
arch/powerpc/platforms/pseries/iommu.c | 45 +++---
1 file changed, 27 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc/platforms/pseries/iommu.c
index 1a933c4e8bba..4e33147825cc 100644
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
---
ar
suggested by LoPAR: First reading the size of the extension array from
index 0, checking if the property exists, and then returning it's value.
Signed-off-by: Leonardo Bras
---
arch/powerpc/platforms/pseries/iommu.c | 91 +++---
1 file changed, 81 insertions(+), 10 delet
- v1 link:
http://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=184420=%2A=both
Special thanks for Alexey Kardashevskiy and Oliver O'Halloran for
the feedback provided!
Leonardo Bras (6):
powerpc/pseries/iommu: Create defines for operations in
ibm,ddw-applicable
powerpc/pseries
Create defines to help handling ibm,ddw-applicable values, avoiding
confusion about the index of given operations.
Signed-off-by: Leonardo Bras
---
arch/powerpc/platforms/pseries/iommu.c | 43 --
1 file changed, 26 insertions(+), 17 deletions(-)
diff --git a/arch
On Thu, 2020-07-02 at 10:31 +1000, Alexey Kardashevskiy wrote:
> > In fact, there is a lot of places in this file where it's called direct
> > window. Should I replace everything?
> > Should it be in a separated patch?
>
> If it looks simple and you write a nice commit log explaining all that
>
1 - 100 of 334 matches
Mail list logo