* [PATCH v4 2/6] iommu: keep dma mode build options consistent with cmdline options
From: Zhen Lei @ 2019-04-07 12:41 UTC (permalink / raw)
To: Jean-Philippe Brucker, John Garry, Robin Murphy, Will Deacon,
Joerg Roedel, Jonathan Corbet, linux-doc, Sebastian Ott,
Gerald Schaefer, Martin Schwidefsky, Heiko Carstens,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Tony Luck, Fenghua Yu, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, David Woodhouse, iommu,
linux-kernel, linux-s390, linuxppc-dev, x86, linux-ia64
Cc: Hanjun Guo, Zhen Lei
In-Reply-To: <20190407124147.13576-1-thunder.leizhen@huawei.com>
First, add build option IOMMU_DMA_MODE_LAZY, so that we have the
opportunity to set lazy mode as default at build time. Then put the
three config options in an choice, make people can only choose one of the
three at a time, the same to the boot options iommu.dma_mode.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
drivers/iommu/Kconfig | 30 +++++++++++++++++++++++++++---
drivers/iommu/iommu.c | 4 +++-
2 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index b67fcabd668f7b6..19118cfdea1c335 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -74,16 +74,40 @@ config IOMMU_DEBUGFS
debug/iommu directory, and then populate a subdirectory with
entries as required.
-config IOMMU_DEFAULT_PASSTHROUGH
- bool "IOMMU passthrough by default"
+choice
+ prompt "IOMMU dma mode"
depends on IOMMU_API
+ default IOMMU_DMA_MODE_STRICT
+ help
+ IOMMU dma mode, such as: passthrough, lazy, strict.
+
+config IOMMU_DMA_MODE_PASSTHROUGH
+ bool "Configure DMA to bypass the IOMMU"
help
Enable passthrough by default, removing the need to pass in
iommu.dma_mode=passthrough or iommu=pt through command line. If this
is enabled, you can still disable with iommu.dma_mode={lazy|strict}
or iommu=nopt depending on the architecture.
- If unsure, say N here.
+config IOMMU_DMA_MODE_LAZY
+ bool "IOMMU DMA use lazy mode to flush IOTLB and free IOVA"
+ help
+ Support lazy mode, where for every IOMMU DMA unmap operation, the
+ flush operation of IOTLB and the free operation of IOVA are deferred.
+ They are only guaranteed to be done before the related IOVA will be
+ reused. Removing the need to pass in kernel parameters through
+ command line. For example, iommu.dma_mode=lazy on ARM64. If this is
+ enabled, you can still disable with kernel parameters, such as
+ iommu.dma_mode=strict depending on the architecture.
+
+config IOMMU_DMA_MODE_STRICT
+ bool "IOMMU DMA use strict mode to flush IOTLB and free IOVA"
+ help
+ For every IOMMU DMA unmap operation, the flush operation of IOTLB and
+ the free operation of IOVA are guaranteed to be done in the unmap
+ function.
+
+endchoice
config OF_IOMMU
def_bool y
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index e4d581e6cb8d210..b75e23a2ea08da8 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -39,8 +39,10 @@
static struct kset *iommu_group_kset;
static DEFINE_IDA(iommu_group_ida);
-#ifdef CONFIG_IOMMU_DEFAULT_PASSTHROUGH
+#if defined(CONFIG_IOMMU_DMA_MODE_PASSTHROUGH)
#define IOMMU_DEFAULT_DMA_MODE IOMMU_DMA_MODE_PASSTHROUGH
+#elif defined(CONFIG_IOMMU_DMA_MODE_LAZY)
+#define IOMMU_DEFAULT_DMA_MODE IOMMU_DMA_MODE_LAZY
#else
#define IOMMU_DEFAULT_DMA_MODE IOMMU_DMA_MODE_STRICT
#endif
--
1.8.3
^ permalink raw reply related
* Re: [PATCH] powerpc/configs: Enable CONFIG_USB_XHCI_HCD by default
From: Thomas Huth @ 2019-04-07 12:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: Laurent Vivier, David Gibson, linuxppc-dev
In-Reply-To: <20190212103129.19de0cfc@umbus.fritz.box>
[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]
On 12/02/2019 00.31, David Gibson wrote:
> On Mon, 11 Feb 2019 12:37:12 +0100
> Thomas Huth <thuth@redhat.com> wrote:
>
>> Recent versions of QEMU provide a XHCI device by default these
>> days instead of an old-fashioned OHCI device:
>>
>> https://git.qemu.org/?p=qemu.git;a=commitdiff;h=57040d451315320b7d27
>>
>> So to get the keyboard working in the graphical console there again,
>> we should now include XHCI support in the kernel by default, too.
>>
>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>
> Wow, we didn't before? That's bonkers.
>
> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
>
>> ---
>> arch/powerpc/configs/pseries_defconfig | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/powerpc/configs/pseries_defconfig b/arch/powerpc/configs/pseries_defconfig
>> index ea79c51..62e12f6 100644
>> --- a/arch/powerpc/configs/pseries_defconfig
>> +++ b/arch/powerpc/configs/pseries_defconfig
>> @@ -217,6 +217,7 @@ CONFIG_USB_MON=m
>> CONFIG_USB_EHCI_HCD=y
>> # CONFIG_USB_EHCI_HCD_PPC_OF is not set
>> CONFIG_USB_OHCI_HCD=y
>> +CONFIG_USB_XHCI_HCD=y
>> CONFIG_USB_STORAGE=m
>> CONFIG_NEW_LEDS=y
>> CONFIG_LEDS_CLASS=m
>> --
>> 1.8.3.1
Ping?
Thomas
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/pseries/iommu: fix set but not used values
From: Mukesh Ojha @ 2019-04-07 6:34 UTC (permalink / raw)
To: Qian Cai, mpe, benh, paulus; +Cc: aik, linuxppc-dev, linux-kernel
In-Reply-To: <20190407024808.39821-1-cai@lca.pw>
On 4/7/2019 8:18 AM, Qian Cai wrote:
> The commit b7d6bf4fdd47 ("powerpc/pseries/pci: Remove obsolete SW
> invalidate") left 2 variables unused.
>
> arch/powerpc/platforms/pseries/iommu.c: In function 'tce_build_pSeries':
> arch/powerpc/platforms/pseries/iommu.c:108:17: warning: variable 'tces'
> set but not used [-Wunused-but-set-variable]
> __be64 *tcep, *tces;
> ^~~~
> arch/powerpc/platforms/pseries/iommu.c: In function 'tce_free_pSeries':
> arch/powerpc/platforms/pseries/iommu.c:132:17: warning: variable 'tces'
> set but not used [-Wunused-but-set-variable]
> __be64 *tcep, *tces;
> ^~~~
>
> Also, the commit 68c0449ea16d ("powerpc/pseries/iommu: Use memory@ nodes
> in max RAM address calculation") set "ranges" in
> ddw_memory_hotplug_max() but never use it.
>
> arch/powerpc/platforms/pseries/iommu.c: In function
> 'ddw_memory_hotplug_max':
> arch/powerpc/platforms/pseries/iommu.c:948:7: warning: variable 'ranges'
> set but not used [-Wunused-but-set-variable]
> int ranges, n_mem_addr_cells, n_mem_size_cells, len;
> ^~~~~~
>
> Signed-off-by: Qian Cai <cai@lca.pw>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Cheers,
-Mukesh
> ---
> arch/powerpc/platforms/pseries/iommu.c | 13 +++++--------
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
> index 36eb1ddbac69..03bbb299320e 100644
> --- a/arch/powerpc/platforms/pseries/iommu.c
> +++ b/arch/powerpc/platforms/pseries/iommu.c
> @@ -105,7 +105,7 @@ static int tce_build_pSeries(struct iommu_table *tbl, long index,
> unsigned long attrs)
> {
> u64 proto_tce;
> - __be64 *tcep, *tces;
> + __be64 *tcep;
> u64 rpn;
>
> proto_tce = TCE_PCI_READ; // Read allowed
> @@ -113,7 +113,7 @@ static int tce_build_pSeries(struct iommu_table *tbl, long index,
> if (direction != DMA_TO_DEVICE)
> proto_tce |= TCE_PCI_WRITE;
>
> - tces = tcep = ((__be64 *)tbl->it_base) + index;
> + tcep = ((__be64 *)tbl->it_base) + index;
>
> while (npages--) {
> /* can't move this out since we might cross MEMBLOCK boundary */
> @@ -129,9 +129,9 @@ static int tce_build_pSeries(struct iommu_table *tbl, long index,
>
> static void tce_free_pSeries(struct iommu_table *tbl, long index, long npages)
> {
> - __be64 *tcep, *tces;
> + __be64 *tcep;
>
> - tces = tcep = ((__be64 *)tbl->it_base) + index;
> + tcep = ((__be64 *)tbl->it_base) + index;
>
> while (npages--)
> *(tcep++) = 0;
> @@ -945,7 +945,7 @@ static phys_addr_t ddw_memory_hotplug_max(void)
>
> for_each_node_by_type(memory, "memory") {
> unsigned long start, size;
> - int ranges, n_mem_addr_cells, n_mem_size_cells, len;
> + int n_mem_addr_cells, n_mem_size_cells, len;
> const __be32 *memcell_buf;
>
> memcell_buf = of_get_property(memory, "reg", &len);
> @@ -955,9 +955,6 @@ static phys_addr_t ddw_memory_hotplug_max(void)
> n_mem_addr_cells = of_n_addr_cells(memory);
> n_mem_size_cells = of_n_size_cells(memory);
>
> - /* ranges in cell */
> - ranges = (len >> 2) / (n_mem_addr_cells + n_mem_size_cells);
> -
> start = of_read_number(memcell_buf, n_mem_addr_cells);
> memcell_buf += n_mem_addr_cells;
> size = of_read_number(memcell_buf, n_mem_size_cells);
^ permalink raw reply
* Re: [PATCH] powerpc/pseries/pmem: fix a set but not used value
From: Mukesh Ojha @ 2019-04-07 6:17 UTC (permalink / raw)
To: Qian Cai, mpe, benh, paulus; +Cc: linuxppc-dev, oohall, linux-kernel
In-Reply-To: <20190407015447.39292-1-cai@lca.pw>
On 4/7/2019 7:24 AM, Qian Cai wrote:
> The commit 4c5d87db4978 ("powerpc/pseries: PAPR persistent memory
> support") set a local variable "count" in dlpar_hp_pmem() but never
> use it.
>
> arch/powerpc/platforms/pseries/pmem.c: In function 'dlpar_hp_pmem':
> arch/powerpc/platforms/pseries/pmem.c:109:6: warning: variable 'count'
> set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: Qian Cai <cai@lca.pw>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Cheers,
-Mukesh
> ---
> arch/powerpc/platforms/pseries/pmem.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/pmem.c b/arch/powerpc/platforms/pseries/pmem.c
> index 27f0a915c8a9..f860a897a9e0 100644
> --- a/arch/powerpc/platforms/pseries/pmem.c
> +++ b/arch/powerpc/platforms/pseries/pmem.c
> @@ -106,7 +106,7 @@ static ssize_t pmem_drc_remove_node(u32 drc_index)
>
> int dlpar_hp_pmem(struct pseries_hp_errorlog *hp_elog)
> {
> - u32 count, drc_index;
> + u32 drc_index;
> int rc;
>
> /* slim chance, but we might get a hotplug event while booting */
> @@ -123,7 +123,6 @@ int dlpar_hp_pmem(struct pseries_hp_errorlog *hp_elog)
> return -EINVAL;
> }
>
> - count = hp_elog->_drc_u.drc_count;
> drc_index = hp_elog->_drc_u.drc_index;
>
> lock_device_hotplug();
^ permalink raw reply
* [PATCH] powerpc/pseries/iommu: fix set but not used values
From: Qian Cai @ 2019-04-07 2:48 UTC (permalink / raw)
To: mpe, benh, paulus; +Cc: aik, Qian Cai, linuxppc-dev, linux-kernel
The commit b7d6bf4fdd47 ("powerpc/pseries/pci: Remove obsolete SW
invalidate") left 2 variables unused.
arch/powerpc/platforms/pseries/iommu.c: In function 'tce_build_pSeries':
arch/powerpc/platforms/pseries/iommu.c:108:17: warning: variable 'tces'
set but not used [-Wunused-but-set-variable]
__be64 *tcep, *tces;
^~~~
arch/powerpc/platforms/pseries/iommu.c: In function 'tce_free_pSeries':
arch/powerpc/platforms/pseries/iommu.c:132:17: warning: variable 'tces'
set but not used [-Wunused-but-set-variable]
__be64 *tcep, *tces;
^~~~
Also, the commit 68c0449ea16d ("powerpc/pseries/iommu: Use memory@ nodes
in max RAM address calculation") set "ranges" in
ddw_memory_hotplug_max() but never use it.
arch/powerpc/platforms/pseries/iommu.c: In function
'ddw_memory_hotplug_max':
arch/powerpc/platforms/pseries/iommu.c:948:7: warning: variable 'ranges'
set but not used [-Wunused-but-set-variable]
int ranges, n_mem_addr_cells, n_mem_size_cells, len;
^~~~~~
Signed-off-by: Qian Cai <cai@lca.pw>
---
arch/powerpc/platforms/pseries/iommu.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
index 36eb1ddbac69..03bbb299320e 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -105,7 +105,7 @@ static int tce_build_pSeries(struct iommu_table *tbl, long index,
unsigned long attrs)
{
u64 proto_tce;
- __be64 *tcep, *tces;
+ __be64 *tcep;
u64 rpn;
proto_tce = TCE_PCI_READ; // Read allowed
@@ -113,7 +113,7 @@ static int tce_build_pSeries(struct iommu_table *tbl, long index,
if (direction != DMA_TO_DEVICE)
proto_tce |= TCE_PCI_WRITE;
- tces = tcep = ((__be64 *)tbl->it_base) + index;
+ tcep = ((__be64 *)tbl->it_base) + index;
while (npages--) {
/* can't move this out since we might cross MEMBLOCK boundary */
@@ -129,9 +129,9 @@ static int tce_build_pSeries(struct iommu_table *tbl, long index,
static void tce_free_pSeries(struct iommu_table *tbl, long index, long npages)
{
- __be64 *tcep, *tces;
+ __be64 *tcep;
- tces = tcep = ((__be64 *)tbl->it_base) + index;
+ tcep = ((__be64 *)tbl->it_base) + index;
while (npages--)
*(tcep++) = 0;
@@ -945,7 +945,7 @@ static phys_addr_t ddw_memory_hotplug_max(void)
for_each_node_by_type(memory, "memory") {
unsigned long start, size;
- int ranges, n_mem_addr_cells, n_mem_size_cells, len;
+ int n_mem_addr_cells, n_mem_size_cells, len;
const __be32 *memcell_buf;
memcell_buf = of_get_property(memory, "reg", &len);
@@ -955,9 +955,6 @@ static phys_addr_t ddw_memory_hotplug_max(void)
n_mem_addr_cells = of_n_addr_cells(memory);
n_mem_size_cells = of_n_size_cells(memory);
- /* ranges in cell */
- ranges = (len >> 2) / (n_mem_addr_cells + n_mem_size_cells);
-
start = of_read_number(memcell_buf, n_mem_addr_cells);
memcell_buf += n_mem_addr_cells;
size = of_read_number(memcell_buf, n_mem_size_cells);
--
2.17.2 (Apple Git-113)
^ permalink raw reply related
* [PATCH] powerpc/pseries/pmem: fix a set but not used value
From: Qian Cai @ 2019-04-07 1:54 UTC (permalink / raw)
To: mpe, benh, paulus; +Cc: Qian Cai, linuxppc-dev, oohall, linux-kernel
The commit 4c5d87db4978 ("powerpc/pseries: PAPR persistent memory
support") set a local variable "count" in dlpar_hp_pmem() but never
use it.
arch/powerpc/platforms/pseries/pmem.c: In function 'dlpar_hp_pmem':
arch/powerpc/platforms/pseries/pmem.c:109:6: warning: variable 'count'
set but not used [-Wunused-but-set-variable]
Signed-off-by: Qian Cai <cai@lca.pw>
---
arch/powerpc/platforms/pseries/pmem.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/pmem.c b/arch/powerpc/platforms/pseries/pmem.c
index 27f0a915c8a9..f860a897a9e0 100644
--- a/arch/powerpc/platforms/pseries/pmem.c
+++ b/arch/powerpc/platforms/pseries/pmem.c
@@ -106,7 +106,7 @@ static ssize_t pmem_drc_remove_node(u32 drc_index)
int dlpar_hp_pmem(struct pseries_hp_errorlog *hp_elog)
{
- u32 count, drc_index;
+ u32 drc_index;
int rc;
/* slim chance, but we might get a hotplug event while booting */
@@ -123,7 +123,6 @@ int dlpar_hp_pmem(struct pseries_hp_errorlog *hp_elog)
return -EINVAL;
}
- count = hp_elog->_drc_u.drc_count;
drc_index = hp_elog->_drc_u.drc_index;
lock_device_hotplug();
--
2.17.2 (Apple Git-113)
^ permalink raw reply related
* Re: [PATCH v2] powerpc: silence unused-but-set-variable warnings
From: Qian Cai @ 2019-04-07 1:33 UTC (permalink / raw)
To: benh, paulus, mpe; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20190307144031.52494-1-cai@lca.pw>
Ping. The patchwork status is still New after a month.
On 3/7/19 9:40 AM, Qian Cai wrote:
> pte_unmap() compiles away on some powerpc platforms, so silence the
> warnings below by making it a static inline function.
>
> mm/memory.c: In function 'copy_pte_range':
> mm/memory.c:820:24: warning: variable 'orig_dst_pte' set but not used
> [-Wunused-but-set-variable]
> mm/memory.c:820:9: warning: variable 'orig_src_pte' set but not used
> [-Wunused-but-set-variable]
> mm/madvise.c: In function 'madvise_free_pte_range':
> mm/madvise.c:318:9: warning: variable 'orig_pte' set but not used
> [-Wunused-but-set-variable]
> mm/swap_state.c: In function 'swap_ra_info':
> mm/swap_state.c:634:15: warning: variable 'orig_pte' set but not used
> [-Wunused-but-set-variable]
>
> Suggested-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Signed-off-by: Qian Cai <cai@lca.pw>
> ---
>
> v2: make it a static inline function.
>
> arch/powerpc/include/asm/book3s/64/pgtable.h | 3 ++-
> arch/powerpc/include/asm/nohash/64/pgtable.h | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h b/arch/powerpc/include/asm/book3s/64/pgtable.h
> index 868fcaf56f6b..d798e33a0c86 100644
> --- a/arch/powerpc/include/asm/book3s/64/pgtable.h
> +++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
> @@ -1006,7 +1006,8 @@ extern struct page *pgd_page(pgd_t pgd);
> (((pte_t *) pmd_page_vaddr(*(dir))) + pte_index(addr))
>
> #define pte_offset_map(dir,addr) pte_offset_kernel((dir), (addr))
> -#define pte_unmap(pte) do { } while(0)
> +
> +static inline void pte_unmap(pte_t *pte) { }
>
> /* to find an entry in a kernel page-table-directory */
> /* This now only contains the vmalloc pages */
> diff --git a/arch/powerpc/include/asm/nohash/64/pgtable.h b/arch/powerpc/include/asm/nohash/64/pgtable.h
> index e77ed9761632..0384a3302fb6 100644
> --- a/arch/powerpc/include/asm/nohash/64/pgtable.h
> +++ b/arch/powerpc/include/asm/nohash/64/pgtable.h
> @@ -205,7 +205,8 @@ static inline void pgd_set(pgd_t *pgdp, unsigned long val)
> (((pte_t *) pmd_page_vaddr(*(dir))) + (((addr) >> PAGE_SHIFT) & (PTRS_PER_PTE - 1)))
>
> #define pte_offset_map(dir,addr) pte_offset_kernel((dir), (addr))
> -#define pte_unmap(pte) do { } while(0)
> +
> +static inline void pte_unmap(pte_t *pte) { }
>
> /* to find an entry in a kernel page-table-directory */
> /* This now only contains the vmalloc pages */
>
^ permalink raw reply
* Re: [Qemu-ppc] pseries on qemu-system-ppc64le crashes in doorbell_core_ipi()
From: Frederic Weisbecker @ 2019-04-06 0:06 UTC (permalink / raw)
To: Peter Zijlstra, Nicholas Piggin
Cc: Sebastian Andrzej Siewior, Steven Rostedt, Paul Mackerras,
Cédric Le Goater, Suraj Jitindar Singh, Frederic Weisbecker,
qemu-ppc, tglx, linuxppc-dev, David? Gibson
In-Reply-To: <20190401083827.GE11158@hirez.programming.kicks-ass.net>
On Mon, Apr 01, 2019 at 10:38:27AM +0200, Peter Zijlstra wrote:
>
> + fweisbec, who did the remote bits
>
> On Sat, Mar 30, 2019 at 01:10:28PM +1000, Nicholas Piggin wrote:
> > diff --git a/kernel/irq_work.c b/kernel/irq_work.c
> > index 6b7cdf17ccf8..f0e539d0f879 100644
> > --- a/kernel/irq_work.c
> > +++ b/kernel/irq_work.c
> > -/* Enqueue the irq work @work on the current CPU */
> > -bool irq_work_queue(struct irq_work *work)
> > +/*
> > + * Enqueue the irq_work @work on @cpu unless it's already pending
> > + * somewhere.
> > + *
> > + * Can be re-enqueued while the callback is still in progress.
> > + */
> > +bool irq_work_queue_on(struct irq_work *work, int cpu)
> > {
> > +#ifndef CONFIG_SMP
> > + return irq_work_queue(work);
> > +
I'd suggest to use "if (!IS_ENABLED(CONFIG_SMP))" here to avoid the large
ifdeffery.
> > +#else /* #ifndef CONFIG_SMP */
> > + /* All work should have been flushed before going offline */
> > + WARN_ON_ONCE(cpu_is_offline(cpu));
> > +
> > /* Only queue if not already pending */
> > if (!irq_work_claim(work))
> > return false;
> >
> > - /* Queue the entry and raise the IPI if needed. */
> > preempt_disable();
> > -
> > - /* If the work is "lazy", handle it from next tick if any */
> > - if (work->flags & IRQ_WORK_LAZY) {
> > - if (llist_add(&work->llnode, this_cpu_ptr(&lazy_list)) &&
> > - tick_nohz_tick_stopped())
> > - arch_irq_work_raise();
> > - } else {
> > - if (llist_add(&work->llnode, this_cpu_ptr(&raised_list)))
> > - arch_irq_work_raise();
> > - }
> > -
> > + if (cpu != smp_processor_id()) {
> > + /* Arch remote IPI send/receive backend aren't NMI safe */
> > + WARN_ON_ONCE(in_nmi());
> > + if (llist_add(&work->llnode, &per_cpu(raised_list, cpu)))
> > + arch_send_call_function_single_ipi(cpu);
> > + } else
> > + __irq_work_queue(work);
Also perhaps rename __irq_work_queue() to irq_work_queue_local() to make it
instantly clearer to reviewers.
Other than those cosmetic changes,
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
Thanks.
^ permalink raw reply
* Re: [PATCH 1/2] pci: rpadlpar: fix leaked device_node references in add/remove paths
From: Bjorn Helgaas @ 2019-04-05 23:04 UTC (permalink / raw)
To: Tyrel Datwyler; +Cc: linux-pci, linuxppc-dev, linux-kernel
In-Reply-To: <20190322182722.8255-1-tyreld@linux.vnet.ibm.com>
On Fri, Mar 22, 2019 at 01:27:21PM -0500, Tyrel Datwyler wrote:
> The find_dlpar_node() helper returns a device node with its reference
> incremented. Both the add and remove paths use this helper for find the
> appropriate node, but fail to release the reference when done.
>
> Annotate the find_dlpar_node() helper with a comment about the incremented
> reference count, and call of_node_put() on the obtained device_node in the
> add and remove paths. Also, fixup a reference leak in the find_vio_slot()
> helper where we fail to call of_node_put() on the vdevice node after we
> iterate over its children.
>
> Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Both applied to pci/hotplug for v5.2, thanks!
> ---
> drivers/pci/hotplug/rpadlpar_core.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/pci/hotplug/rpadlpar_core.c b/drivers/pci/hotplug/rpadlpar_core.c
> index e2356a9c7088..182f9e3443ee 100644
> --- a/drivers/pci/hotplug/rpadlpar_core.c
> +++ b/drivers/pci/hotplug/rpadlpar_core.c
> @@ -51,6 +51,7 @@ static struct device_node *find_vio_slot_node(char *drc_name)
> if (rc == 0)
> break;
> }
> + of_node_put(parent);
>
> return dn;
> }
> @@ -71,6 +72,7 @@ static struct device_node *find_php_slot_pci_node(char *drc_name,
> return np;
> }
>
> +/* Returns a device_node with its reference count incremented */
> static struct device_node *find_dlpar_node(char *drc_name, int *node_type)
> {
> struct device_node *dn;
> @@ -306,6 +308,7 @@ int dlpar_add_slot(char *drc_name)
> rc = dlpar_add_phb(drc_name, dn);
> break;
> }
> + of_node_put(dn);
>
> printk(KERN_INFO "%s: slot %s added\n", DLPAR_MODULE_NAME, drc_name);
> exit:
> @@ -439,6 +442,7 @@ int dlpar_remove_slot(char *drc_name)
> rc = dlpar_remove_pci_slot(drc_name, dn);
> break;
> }
> + of_node_put(dn);
> vm_unmap_aliases();
>
> printk(KERN_INFO "%s: slot %s removed\n", DLPAR_MODULE_NAME, drc_name);
> --
> 2.12.3
>
^ permalink raw reply
* Re: [PATCH 0/4] Enabling secure boot on PowerNV systems
From: Matthew Garrett @ 2019-04-05 22:19 UTC (permalink / raw)
To: Claudio Carvalho
Cc: linux-efi, Ard Biesheuvel, Nayna Jain, Linux Kernel Mailing List,
Matthew Garret, linuxppc-dev, Paul Mackerras, Jeremy Kerr,
linux-integrity
In-Reply-To: <d79f47f8-9006-3a47-2bdc-58012cef5c7e@linux.ibm.com>
On Fri, Apr 5, 2019 at 2:11 PM Claudio Carvalho <cclaudio@linux.ibm.com> wrote:
>
>
> On 4/3/19 7:27 PM, Matthew Garrett wrote:
> > Not supporting dbx seems like a pretty significant shortcoming. How
> > are signatures meant to be revoked?
>
>
> We began by focusing on certificates for keys that can be added at
> runtime. Before adding support for revocation, we plan to gather
> additional use cases. In the meantime, unwanted certificates can be
> removed by the administrator.
Based on our experience doing this in UEFI, that's insufficient - you
want to be able to block individual binaries or leaf certificates
without dropping trust in an intermediate certificate entirely.
>
> >
> >> PK, KEK and db updates will be signed the same way, that is, using
> >> userspace tooling like efitools in PowerNV. As for the authentication
> >> descriptors, only the EFI_VARIABLE_AUTHENTICATION_2 descriptor will be
> >> supported.
> > Is this API documented?
>
>
> The API is still a work in progress. We are planning to publish a document
> describing the current API and overall design shortly.
Ok. How are the attributes interpreted by the API?
> Perhaps the biggest departure is that the secure variables are stored in
> flash memory that is not lockable. In order to protect the secure
> variables, hashes of the flash regions where they're stored are written to
> TPM NVRAM indices. The TPM NVRAM indices we use are write locked at
> runtime. The sysadmin enqueues update commands in flash. During the next
> boot, the firmware verifies and processes the commands to update the
> certificate store and accompanying integrity hashes in the TPM NVRAM
> indices and write locks them. Before certificates read from flash are
> used, the certificate store is hashed and compared against the hashes
> stored from the TPM. The one exception is the PK. We store it in a TPM
> NVRAM index by itself rather than flash because updates to it must be
> guaranteed to be atomic.
What's the behaviour if multiple updates are enqueued? Does reading
back show a mocked up updated variable or the original state?
> > I think that depends on exactly what problem you're trying to solve.
> > Some aspects of the EFI secure boot design end up mirroring the
> > economics of the PC ecosystem rather than being inherently good design
> > goals, so it'd be helpful to know whether you're taking this solution
> > because you want the same three-level key infrastructure or because
> > that just leaves you compatible with the tooling.
>
>
> In our use case, the three-level key hierarchy conveniently supports the
> concept of (1) an administrator authority, who authorizes (2) other
> organizations, e.g., distros, to provide (3) certificates for their code
> signing keys. By using efivars, we leverage pre-existing userspace EFI
> tools to generate authenticated updates and certificates. Additionally,
> pre-existing kernel infrastructure simplifies efivars processing.
I'm not really clear on the workflow here. Who's the administrator
authority? When would they be updating the second level of keys? If
there's no support for revocation, why would distributions need two
levels of key in the system database rather than just distributing a
single intermediate and signing their actual signing certs with that?
^ permalink raw reply
* Re: [PATCH 2/3] ASoC: fsl_utils: fix a leaked reference by adding missing of_node_put
From: Markus Elfring @ 2019-04-05 12:30 UTC (permalink / raw)
To: Wen Yang, alsa-devel, linuxppc-dev
Cc: Yi Wang, Timur Tabi, Xiubo Li, Takashi Iwai, Liam Girdwood,
linux-kernel, Nicolin Chen, Mark Brown, Jaroslav Kysela,
Fabio Estevam
In-Reply-To: <1551169071-11639-2-git-send-email-wen.yang99@zte.com.cn>
> @@ -71,6 +71,7 @@ int fsl_asoc_get_dma_channel(struct device_node *ssi_np,
> iprop = of_get_property(dma_np, "cell-index", NULL);
> if (!iprop) {
> of_node_put(dma_np);
> + of_node_put(dma_channel_np);
> return -EINVAL;
> }
> *dma_id = be32_to_cpup(iprop);
How do you think about to adjust the exception handling in this function
implementation a bit more according to the Linux coding style?
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/sound/soc/fsl/fsl_utils.c?id=c705247136a523488eac806bd357c3e5d79a7acd#n16
Regards,
Markus
^ permalink raw reply
* Re: [PATCH 0/4] Enabling secure boot on PowerNV systems
From: Claudio Carvalho @ 2019-04-05 21:11 UTC (permalink / raw)
To: Matthew Garrett
Cc: linux-efi, Ard Biesheuvel, Nayna Jain, Linux Kernel Mailing List,
Matthew Garret, linuxppc-dev, Paul Mackerras, Jeremy Kerr,
linux-integrity
In-Reply-To: <CACdnJuu8OqMrSs0esOmf=ro9n00aYEQ-nikAh6v6sk+YAQw4cQ@mail.gmail.com>
On 4/3/19 7:27 PM, Matthew Garrett wrote:
> On Tue, Apr 2, 2019 at 4:31 PM Claudio Carvalho <cclaudio@linux.ibm.com> wrote:
>>
>> On 4/2/19 6:51 PM, Matthew Garrett wrote:
>>> So you implement the full PK/KEK/db/dbx/dbt infrastructure, and
>>> updates are signed in the same way?
>> For the first version, our firmware will implement a simplistic PK, KEK and
>> db infrastructure (without dbx and dbt) where only the Setup and User modes
>> will be supported.
> Not supporting dbx seems like a pretty significant shortcoming. How
> are signatures meant to be revoked?
We began by focusing on certificates for keys that can be added at
runtime. Before adding support for revocation, we plan to gather
additional use cases. In the meantime, unwanted certificates can be
removed by the administrator.
>
>> PK, KEK and db updates will be signed the same way, that is, using
>> userspace tooling like efitools in PowerNV. As for the authentication
>> descriptors, only the EFI_VARIABLE_AUTHENTICATION_2 descriptor will be
>> supported.
> Is this API documented?
The API is still a work in progress. We are planning to publish a document
describing the current API and overall design shortly.
Perhaps the biggest departure is that the secure variables are stored in
flash memory that is not lockable. In order to protect the secure
variables, hashes of the flash regions where they're stored are written to
TPM NVRAM indices. The TPM NVRAM indices we use are write locked at
runtime. The sysadmin enqueues update commands in flash. During the next
boot, the firmware verifies and processes the commands to update the
certificate store and accompanying integrity hashes in the TPM NVRAM
indices and write locks them. Before certificates read from flash are
used, the certificate store is hashed and compared against the hashes
stored from the TPM. The one exception is the PK. We store it in a TPM
NVRAM index by itself rather than flash because updates to it must be
guaranteed to be atomic.
>>> In that case we might be better off with a generic interface for this
>>> purpose that we can expose on all platforms that implement a secure
>>> boot key hierarchy. Having an efivarfs that doesn't allow the creation
>>> of arbitrary attributes may break other existing userland
>>> expectations.
>>>
>> For what it's worth, gsmi uses the efivars infrastructure for EFI-like
>> variables.
> My recollection is that at the time the Chromebook firmware still had
> EFI underpinnings and the gsmi code was largely just an alternate
> mechanism for calling into something that was fundamentally the EFI
> variable store. With hindsight I don't think layering this was the
> right move - we've adjusted the semantics of efivarfs on more than one
> occasion to deal with the behaviour of real-world EFI platforms, and I
> don't think it's helpful to end up in a situation where we're trying
> to keep behaviour consistent among entirely different firmware
> interfaces.
>
>> What might a generic interface look like? It would have to work for
>> existing secure boot solutions - including EFI - which would seem to imply
>> changes to userspace tools.
> I think that depends on exactly what problem you're trying to solve.
> Some aspects of the EFI secure boot design end up mirroring the
> economics of the PC ecosystem rather than being inherently good design
> goals, so it'd be helpful to know whether you're taking this solution
> because you want the same three-level key infrastructure or because
> that just leaves you compatible with the tooling.
In our use case, the three-level key hierarchy conveniently supports the
concept of (1) an administrator authority, who authorizes (2) other
organizations, e.g., distros, to provide (3) certificates for their code
signing keys. By using efivars, we leverage pre-existing userspace EFI
tools to generate authenticated updates and certificates. Additionally,
pre-existing kernel infrastructure simplifies efivars processing.
Thanks,
Claudio
^ permalink raw reply
* Re: [PATCH RFC 1/5] cpu/speculation: Add 'cpu_spec_mitigations=' cmdline options
From: Josh Poimboeuf @ 2019-04-05 16:18 UTC (permalink / raw)
To: Borislav Petkov
Cc: Peter Zijlstra, Heiko Carstens, Paul Mackerras, H . Peter Anvin,
Ingo Molnar, Andrea Arcangeli, linux-s390, x86, Will Deacon,
Linus Torvalds, Catalin Marinas, Waiman Long, linux-arch,
Jon Masters, Jiri Kosina, Andy Lutomirski, Thomas Gleixner,
linux-arm-kernel, Greg Kroah-Hartman, linux-kernel, Tyler Hicks,
Martin Schwidefsky, linuxppc-dev
In-Reply-To: <20190405160136.GI23348@zn.tnic>
On Fri, Apr 05, 2019 at 06:01:36PM +0200, Borislav Petkov wrote:
> Thinking about this more, we can shave off the first 4 chars and have it
> be:
>
> spec_mitigations=
>
> I think it is painfully clear which speculation mitigations we mean. And
> the other switches don't have "cpu_" prefixes too so...
Sure, I'm ok with renaming it to that, if there are no objections.
--
Josh
^ permalink raw reply
* Re: [PATCH RFC 2/5] x86/speculation: Add support for 'cpu_spec_mitigations=' cmdline options
From: Josh Poimboeuf @ 2019-04-05 16:05 UTC (permalink / raw)
To: Borislav Petkov
Cc: Peter Zijlstra, Heiko Carstens, Paul Mackerras, H . Peter Anvin,
Ingo Molnar, Andrea Arcangeli, linux-s390, x86, Will Deacon,
Linus Torvalds, Catalin Marinas, Waiman Long, linux-arch,
Jon Masters, Jiri Kosina, Andy Lutomirski, Thomas Gleixner,
linux-arm-kernel, Greg Kroah-Hartman, linux-kernel, Tyler Hicks,
Martin Schwidefsky, linuxppc-dev
In-Reply-To: <20190405152650.GH23348@zn.tnic>
On Fri, Apr 05, 2019 at 05:26:50PM +0200, Borislav Petkov wrote:
> On Fri, Apr 05, 2019 at 09:31:01AM -0500, Josh Poimboeuf wrote:
> > My thinking was that the individual options could be used to override
> > the global option. But maybe that's overkill? I dunno.
>
> You mean if the user deliberately types:
>
> "cpu_spec_mitigations=off spectre_v2=auto"
>
> on the cmdline to turn off all and then enable only one?
>
> Hmm, yap, sounds like an overkill to me. Then I'd probably do:
>
> pr_err("Make up your mind already!\n");
> return;
>
> :-))
>
> I'd say let's do the simpler and cleaner thing now and think about
> supporting this overkill when it really turns out that it is needed.
Fair enough.
> > I assume you mean just the part where L1TF_MITIGATION_DEFAULT is added?
>
> Yap.
Ok.
--
Josh
^ permalink raw reply
* Re: [PATCH RFC 5/5] arm64/speculation: Add support for 'cpu_spec_mitigations=' cmdline options
From: Josh Poimboeuf @ 2019-04-05 16:03 UTC (permalink / raw)
To: Will Deacon
Cc: Peter Zijlstra, Heiko Carstens, Paul Mackerras, H . Peter Anvin,
Ingo Molnar, Andrea Arcangeli, linux-s390, x86, Linus Torvalds,
Catalin Marinas, Waiman Long, linux-arch, Jon Masters,
Jiri Kosina, Borislav Petkov, Andy Lutomirski, Thomas Gleixner,
linux-arm-kernel, Greg Kroah-Hartman, linux-kernel, Tyler Hicks,
Martin Schwidefsky, linuxppc-dev
In-Reply-To: <20190405144414.GB7662@fuggles.cambridge.arm.com>
On Fri, Apr 05, 2019 at 03:44:14PM +0100, Will Deacon wrote:
> Hi Josh,
>
> On Thu, Apr 04, 2019 at 11:44:15AM -0500, Josh Poimboeuf wrote:
> > Configure arm64 runtime CPU speculation bug mitigations in accordance
> > with the 'cpu_spec_mitigations=' cmdline options. This affects
> > Meltdown and Speculative Store Bypass.
> >
> > The default behavior is unchanged.
> >
> > Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
> > ---
> > Documentation/admin-guide/kernel-parameters.txt | 2 ++
> > arch/arm64/kernel/cpu_errata.c | 4 ++++
> > arch/arm64/kernel/cpufeature.c | 6 ++++++
> > 3 files changed, 12 insertions(+)
>
> Just wanted to make you aware that this is probably going to conflict badly
> with some patches we have pending to hook up the sysfs entries:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2019-March/640326.html
>
> That patch series isn't quite there yet, so I'm expecting a v7, but I think
> it will change the shape of this patch quite a lot.
Thanks for the heads up Will. I will drop the arm64 patch for now then.
--
Josh
^ permalink raw reply
* Re: [PATCH RFC 1/5] cpu/speculation: Add 'cpu_spec_mitigations=' cmdline options
From: Borislav Petkov @ 2019-04-05 16:01 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Peter Zijlstra, Heiko Carstens, Paul Mackerras, H . Peter Anvin,
Ingo Molnar, Andrea Arcangeli, linux-s390, x86, Will Deacon,
Linus Torvalds, Catalin Marinas, Waiman Long, linux-arch,
Jon Masters, Jiri Kosina, Andy Lutomirski, Thomas Gleixner,
linux-arm-kernel, Greg Kroah-Hartman, linux-kernel, Tyler Hicks,
Martin Schwidefsky, linuxppc-dev
In-Reply-To: <20190405152059.GG23348@zn.tnic>
Thinking about this more, we can shave off the first 4 chars and have it
be:
spec_mitigations=
I think it is painfully clear which speculation mitigations we mean. And
the other switches don't have "cpu_" prefixes too so...
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* Re: [PATCH RFC 2/5] x86/speculation: Add support for 'cpu_spec_mitigations=' cmdline options
From: Josh Poimboeuf @ 2019-04-05 15:30 UTC (permalink / raw)
To: Randy Dunlap
Cc: Peter Zijlstra, Heiko Carstens, Paul Mackerras, H . Peter Anvin,
Ingo Molnar, Andrea Arcangeli, linux-s390, x86, Will Deacon,
Linus Torvalds, Catalin Marinas, Waiman Long, linux-arch,
Jon Masters, Jiri Kosina, Borislav Petkov, Andy Lutomirski,
Thomas Gleixner, linux-arm-kernel, Greg Kroah-Hartman,
linux-kernel, Tyler Hicks, Martin Schwidefsky, linuxppc-dev
In-Reply-To: <5ccc7515-33e6-b726-833e-9553ab0f4c6a@infradead.org>
On Fri, Apr 05, 2019 at 08:18:09AM -0700, Randy Dunlap wrote:
> On 4/5/19 6:57 AM, Borislav Petkov wrote:
> > On Thu, Apr 04, 2019 at 11:44:12AM -0500, Josh Poimboeuf wrote:
> >> Configure x86 runtime CPU speculation bug mitigations in accordance with
> >> the 'cpu_spec_mitigations=' cmdline options. This affects Meltdown,
> >> Spectre v2, Speculative Store Bypass, and L1TF.
> >>
> >> The default behavior is unchanged.
> >>
> >> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
> >> ---
> >> .../admin-guide/kernel-parameters.txt | 15 +++++++++
> >> arch/x86/include/asm/processor.h | 1 +
> >> arch/x86/kernel/cpu/bugs.c | 32 ++++++++++++++++---
> >> arch/x86/kvm/vmx/vmx.c | 2 ++
> >> arch/x86/mm/pti.c | 4 ++-
> >> 5 files changed, 49 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> >> index ac42e510bd6e..29dc03971630 100644
> >> --- a/Documentation/admin-guide/kernel-parameters.txt
> >> +++ b/Documentation/admin-guide/kernel-parameters.txt
> >> @@ -2552,6 +2552,11 @@
> >>
> >> off
> >> Disable all speculative CPU mitigations.
> >> + Equivalent to: nopti [x86]
> >> + nospectre_v2 [x86]
> >> + spectre_v2_user=off [x86]
> >> + spec_store_bypass_disable=off [x86]
> >> + l1tf=off [x86]
> >>
> >> auto (default)
> >> Mitigate all speculative CPU vulnerabilities,
> >> @@ -2560,12 +2565,22 @@
> >> surprised by SMT getting disabled across kernel
> >> upgrades, or who have other ways of avoiding
> >> SMT-based attacks.
> >> + Equivalent to: pti=auto [x86]
> >> + spectre_v2=auto [x86]
> >> + spectre_v2_user=auto [x86]
> >> + spec_store_bypass_disable=auto [x86]
> >> + l1tf=flush [x86]
> >>
> >> auto,nosmt
> >> Mitigate all speculative CPU vulnerabilities,
> >> disabling SMT if needed. This is for users who
> >> always want to be fully mitigated, even if it
> >> means losing SMT.
> >> + Equivalent to: pti=auto [x86]
> >> + spectre_v2=auto [x86]
> >> + spectre_v2_user=auto [x86]
> >> + spec_store_bypass_disable=auto [x86]
> >> + l1tf=flush,nosmt [x86]
> >>
> >> mminit_loglevel=
> >> [KNL] When CONFIG_DEBUG_MEMORY_INIT is set, this
> >
> > Yap, those sets look ok.
>
> nit: s/x86/X86/g
> according to Documentation/admin-guide/kernel-parameters.rst
Ah, I didn't realize I was conforming to a standard. I will update the
other arch strings as well. Thanks.
--
Josh
^ permalink raw reply
* Re: [PATCH RFC 2/5] x86/speculation: Add support for 'cpu_spec_mitigations=' cmdline options
From: Borislav Petkov @ 2019-04-05 15:26 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Peter Zijlstra, Heiko Carstens, Paul Mackerras, H . Peter Anvin,
Ingo Molnar, Andrea Arcangeli, linux-s390, x86, Will Deacon,
Linus Torvalds, Catalin Marinas, Waiman Long, linux-arch,
Jon Masters, Jiri Kosina, Andy Lutomirski, Thomas Gleixner,
linux-arm-kernel, Greg Kroah-Hartman, linux-kernel, Tyler Hicks,
Martin Schwidefsky, linuxppc-dev
In-Reply-To: <20190405143101.ksj7ayjis4p52dgt@treble>
On Fri, Apr 05, 2019 at 09:31:01AM -0500, Josh Poimboeuf wrote:
> My thinking was that the individual options could be used to override
> the global option. But maybe that's overkill? I dunno.
You mean if the user deliberately types:
"cpu_spec_mitigations=off spectre_v2=auto"
on the cmdline to turn off all and then enable only one?
Hmm, yap, sounds like an overkill to me. Then I'd probably do:
pr_err("Make up your mind already!\n");
return;
:-))
I'd say let's do the simpler and cleaner thing now and think about
supporting this overkill when it really turns out that it is needed.
> I assume you mean just the part where L1TF_MITIGATION_DEFAULT is added?
Yap.
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* Re: [PATCH RFC 1/5] cpu/speculation: Add 'cpu_spec_mitigations=' cmdline options
From: Borislav Petkov @ 2019-04-05 15:20 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Peter Zijlstra, Heiko Carstens, Paul Mackerras, H . Peter Anvin,
Ingo Molnar, Andrea Arcangeli, linux-s390, x86, Will Deacon,
Linus Torvalds, Catalin Marinas, Waiman Long, linux-arch,
Jon Masters, Jiri Kosina, Andy Lutomirski, Thomas Gleixner,
linux-arm-kernel, Greg Kroah-Hartman, linux-kernel, Tyler Hicks,
Martin Schwidefsky, linuxppc-dev
In-Reply-To: <20190405142048.burthk2jnpcvi2om@treble>
On Fri, Apr 05, 2019 at 09:20:48AM -0500, Josh Poimboeuf wrote:
> In your scenario, the fact that it's so easy to remember would save the
> day, since you wouldn't have to go look up some obscure shortened option
> name in the documentation :-)
No no, the idea is for the short option to be memorable.
> Suggestions are welcome but I couldn't come up with a reasonable shorter
> option.
Same here.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* Re: [PATCH RFC 2/5] x86/speculation: Add support for 'cpu_spec_mitigations=' cmdline options
From: Randy Dunlap @ 2019-04-05 15:18 UTC (permalink / raw)
To: Borislav Petkov, Josh Poimboeuf
Cc: Peter Zijlstra, Heiko Carstens, Paul Mackerras, H . Peter Anvin,
Ingo Molnar, Andrea Arcangeli, linux-s390, x86, Will Deacon,
Linus Torvalds, Catalin Marinas, Waiman Long, linux-arch,
Jon Masters, Jiri Kosina, Andy Lutomirski, Thomas Gleixner,
linux-arm-kernel, Greg Kroah-Hartman, linux-kernel, Tyler Hicks,
Martin Schwidefsky, linuxppc-dev
In-Reply-To: <20190405135712.GF23348@zn.tnic>
On 4/5/19 6:57 AM, Borislav Petkov wrote:
> On Thu, Apr 04, 2019 at 11:44:12AM -0500, Josh Poimboeuf wrote:
>> Configure x86 runtime CPU speculation bug mitigations in accordance with
>> the 'cpu_spec_mitigations=' cmdline options. This affects Meltdown,
>> Spectre v2, Speculative Store Bypass, and L1TF.
>>
>> The default behavior is unchanged.
>>
>> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
>> ---
>> .../admin-guide/kernel-parameters.txt | 15 +++++++++
>> arch/x86/include/asm/processor.h | 1 +
>> arch/x86/kernel/cpu/bugs.c | 32 ++++++++++++++++---
>> arch/x86/kvm/vmx/vmx.c | 2 ++
>> arch/x86/mm/pti.c | 4 ++-
>> 5 files changed, 49 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index ac42e510bd6e..29dc03971630 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -2552,6 +2552,11 @@
>>
>> off
>> Disable all speculative CPU mitigations.
>> + Equivalent to: nopti [x86]
>> + nospectre_v2 [x86]
>> + spectre_v2_user=off [x86]
>> + spec_store_bypass_disable=off [x86]
>> + l1tf=off [x86]
>>
>> auto (default)
>> Mitigate all speculative CPU vulnerabilities,
>> @@ -2560,12 +2565,22 @@
>> surprised by SMT getting disabled across kernel
>> upgrades, or who have other ways of avoiding
>> SMT-based attacks.
>> + Equivalent to: pti=auto [x86]
>> + spectre_v2=auto [x86]
>> + spectre_v2_user=auto [x86]
>> + spec_store_bypass_disable=auto [x86]
>> + l1tf=flush [x86]
>>
>> auto,nosmt
>> Mitigate all speculative CPU vulnerabilities,
>> disabling SMT if needed. This is for users who
>> always want to be fully mitigated, even if it
>> means losing SMT.
>> + Equivalent to: pti=auto [x86]
>> + spectre_v2=auto [x86]
>> + spectre_v2_user=auto [x86]
>> + spec_store_bypass_disable=auto [x86]
>> + l1tf=flush,nosmt [x86]
>>
>> mminit_loglevel=
>> [KNL] When CONFIG_DEBUG_MEMORY_INIT is set, this
>
> Yap, those sets look ok.
nit: s/x86/X86/g
according to Documentation/admin-guide/kernel-parameters.rst
--
~Randy
^ permalink raw reply
* Re: [Qemu-ppc] pseries on qemu-system-ppc64le crashes in doorbell_core_ipi()
From: Sebastian Andrzej Siewior @ 2019-04-05 14:47 UTC (permalink / raw)
To: Nicholas Piggin
Cc: Peter Zijlstra, Frederic Weisbecker, Steven Rostedt,
Paul Mackerras, Cédric Le Goater, Suraj Jitindar Singh,
qemu-ppc, tglx, linuxppc-dev, David? Gibson
In-Reply-To: <1554395089.85h590cqg5.astroid@bobo.none>
On 2019-04-05 02:25:44 [+1000], Nicholas Piggin wrote:
> Sebastian, are you able to test if this patch solves your problem?
yes, it does.
Tested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Thanks,
> Nick
Sebastian
^ permalink raw reply
* Re: [PATCH RFC 5/5] arm64/speculation: Add support for 'cpu_spec_mitigations=' cmdline options
From: Will Deacon @ 2019-04-05 14:44 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Peter Zijlstra, Heiko Carstens, Paul Mackerras, H . Peter Anvin,
Ingo Molnar, Andrea Arcangeli, linux-s390, x86, Linus Torvalds,
Catalin Marinas, Waiman Long, linux-arch, Jon Masters,
Jiri Kosina, Borislav Petkov, Andy Lutomirski, Thomas Gleixner,
linux-arm-kernel, Greg Kroah-Hartman, linux-kernel, Tyler Hicks,
Martin Schwidefsky, linuxppc-dev
In-Reply-To: <5f70df57b19bbccc4a0d5d76134b4681c9a50b0b.1554396090.git.jpoimboe@redhat.com>
Hi Josh,
On Thu, Apr 04, 2019 at 11:44:15AM -0500, Josh Poimboeuf wrote:
> Configure arm64 runtime CPU speculation bug mitigations in accordance
> with the 'cpu_spec_mitigations=' cmdline options. This affects
> Meltdown and Speculative Store Bypass.
>
> The default behavior is unchanged.
>
> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 2 ++
> arch/arm64/kernel/cpu_errata.c | 4 ++++
> arch/arm64/kernel/cpufeature.c | 6 ++++++
> 3 files changed, 12 insertions(+)
Just wanted to make you aware that this is probably going to conflict badly
with some patches we have pending to hook up the sysfs entries:
http://lists.infradead.org/pipermail/linux-arm-kernel/2019-March/640326.html
That patch series isn't quite there yet, so I'm expecting a v7, but I think
it will change the shape of this patch quite a lot.
Will
^ permalink raw reply
* Re: [PATCH RFC 5/5] arm64/speculation: Add support for 'cpu_spec_mitigations=' cmdline options
From: Josh Poimboeuf @ 2019-04-05 14:43 UTC (permalink / raw)
To: Steven Price
Cc: Peter Zijlstra, Catalin Marinas, Heiko Carstens, Paul Mackerras,
H . Peter Anvin, Ingo Molnar, Andrea Arcangeli, linux-s390, x86,
linux-arm-kernel, Waiman Long, linux-arch, Will Deacon,
Jiri Kosina, linuxppc-dev, Borislav Petkov, Andy Lutomirski,
Thomas Gleixner, Jon Masters, Greg Kroah-Hartman, linux-kernel,
Tyler Hicks, Martin Schwidefsky, Linus Torvalds
In-Reply-To: <be6ba8fe-b261-668a-05b9-7fa937ae650a@arm.com>
On Fri, Apr 05, 2019 at 03:39:58PM +0100, Steven Price wrote:
> On 04/04/2019 17:44, Josh Poimboeuf wrote:
> > Configure arm64 runtime CPU speculation bug mitigations in accordance
> > with the 'cpu_spec_mitigations=' cmdline options. This affects
> > Meltdown and Speculative Store Bypass.
> >
> > The default behavior is unchanged.
> >
> > Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
> > ---
> > Documentation/admin-guide/kernel-parameters.txt | 2 ++
> > arch/arm64/kernel/cpu_errata.c | 4 ++++
> > arch/arm64/kernel/cpufeature.c | 6 ++++++
> > 3 files changed, 12 insertions(+)
> >
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > index e838af96daa4..0b54385ee7a8 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > @@ -2553,11 +2553,13 @@
> > off
> > Disable all speculative CPU mitigations.
> > Equivalent to: nopti [x86, powerpc]
> > + kpti=0 [arm64]
> > nospectre_v1 [powerpc]
> > nospectre_v2 [x86, powerpc, s390]
> > spectre_v2_user=off [x86]
> > nobp=0 [s390]
> > spec_store_bypass_disable=off [x86, powerpc]
> > + ssbd=force-off [arm64]
> > l1tf=off [x86]
> >
> > auto (default)
> > diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
> > index 9950bb0cbd52..db8d27e3fb1c 100644
> > --- a/arch/arm64/kernel/cpu_errata.c
> > +++ b/arch/arm64/kernel/cpu_errata.c
> > @@ -19,6 +19,7 @@
> > #include <linux/arm-smccc.h>
> > #include <linux/psci.h>
> > #include <linux/types.h>
> > +#include <linux/cpu.h>
> > #include <asm/cpu.h>
> > #include <asm/cputype.h>
> > #include <asm/cpufeature.h>
> > @@ -385,6 +386,9 @@ static bool has_ssbd_mitigation(const struct arm64_cpu_capabilities *entry,
> > return false;
> > }
> >
> > + if (cpu_spec_mitigations == CPU_SPEC_MITIGATIONS_OFF)
> > + ssbd_state = ARM64_SSBD_FORCE_DISABLE;
> > +
> > switch (psci_ops.conduit) {
> > case PSCI_CONDUIT_HVC:
> > arm_smccc_1_1_hvc(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index 4061de10cea6..4512b582d50f 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -25,6 +25,7 @@
> > #include <linux/stop_machine.h>
> > #include <linux/types.h>
> > #include <linux/mm.h>
> > +#include <linux/cpu.h>
> > #include <asm/cpu.h>
> > #include <asm/cpufeature.h>
> > #include <asm/cpu_ops.h>
> > @@ -978,6 +979,11 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
> > __kpti_forced = -1;
> > }
> >
> > + if (cpu_spec_mitigations == CPU_SPEC_MITIGATIONS_OFF) {
> > + str = "cpu_spec_mitigations=off";
>
> Might also be worth changing the initialisation of str, currently it is:
>
> > char const *str = "command line option";
>
> But now we have two command line options, perhaps "kpti command line
> option".
Yes, agreed, thanks.
--
Josh
^ permalink raw reply
* [PATCH v2 1/2] bus: mc-bus: Add support for mapping shareable portals
From: Roy Pledge @ 2019-04-05 14:41 UTC (permalink / raw)
To: stuyoder@gmail.com, Laurentiu Tudor, Leo Li
Cc: Roy Pledge, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1554475256-4805-1-git-send-email-roy.pledge@nxp.com>
Starting with v5 of NXP QBMan devices the hardware supports using
regular cacheable/shareable memory as the backing store for the
portals.
This patch adds support for the new portal mode by switching to
use the DPRC get object region v2 command which returns both
a base address and offset for the portal memory. The new portal
region is identified as shareable through the addition of a new
flag.
Signed-off-by: Roy Pledge <roy.pledge@nxp.com>
---
drivers/bus/fsl-mc/dprc.c | 30 +++++++++++++++++++++++++++---
drivers/bus/fsl-mc/fsl-mc-bus.c | 15 +++++++++++++--
drivers/bus/fsl-mc/fsl-mc-private.h | 17 +++++++++++++++--
3 files changed, 55 insertions(+), 7 deletions(-)
diff --git a/drivers/bus/fsl-mc/dprc.c b/drivers/bus/fsl-mc/dprc.c
index 1c3f621..0fe3f52 100644
--- a/drivers/bus/fsl-mc/dprc.c
+++ b/drivers/bus/fsl-mc/dprc.c
@@ -443,11 +443,31 @@ int dprc_get_obj_region(struct fsl_mc_io *mc_io,
struct fsl_mc_command cmd = { 0 };
struct dprc_cmd_get_obj_region *cmd_params;
struct dprc_rsp_get_obj_region *rsp_params;
+ u16 major_ver, minor_ver;
int err;
/* prepare command */
- cmd.header = mc_encode_cmd_header(DPRC_CMDID_GET_OBJ_REG,
- cmd_flags, token);
+ err = dprc_get_api_version(mc_io, 0,
+ &major_ver,
+ &minor_ver);
+ if (err)
+ return err;
+
+ /**
+ * MC API version 6.3 introduced a new field to the region
+ * descriptor: base_address. If the older API is in use then the base
+ * address is set to zero to indicate it needs to be obtained elsewhere
+ * (typically the device tree).
+ */
+ if (major_ver > 6 || (major_ver == 6 && minor_ver >= 3))
+ cmd.header =
+ mc_encode_cmd_header(DPRC_CMDID_GET_OBJ_REG_V2,
+ cmd_flags, token);
+ else
+ cmd.header =
+ mc_encode_cmd_header(DPRC_CMDID_GET_OBJ_REG,
+ cmd_flags, token);
+
cmd_params = (struct dprc_cmd_get_obj_region *)cmd.params;
cmd_params->obj_id = cpu_to_le32(obj_id);
cmd_params->region_index = region_index;
@@ -461,8 +481,12 @@ int dprc_get_obj_region(struct fsl_mc_io *mc_io,
/* retrieve response parameters */
rsp_params = (struct dprc_rsp_get_obj_region *)cmd.params;
- region_desc->base_offset = le64_to_cpu(rsp_params->base_addr);
+ region_desc->base_offset = le64_to_cpu(rsp_params->base_offset);
region_desc->size = le32_to_cpu(rsp_params->size);
+ if (major_ver > 6 || (major_ver == 6 && minor_ver >= 3))
+ region_desc->base_address = le64_to_cpu(rsp_params->base_addr);
+ else
+ region_desc->base_address = 0;
return 0;
}
diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index f0404c6..5c9bf2e 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -487,10 +487,19 @@ static int fsl_mc_device_get_mmio_regions(struct fsl_mc_device *mc_dev,
"dprc_get_obj_region() failed: %d\n", error);
goto error_cleanup_regions;
}
-
- error = translate_mc_addr(mc_dev, mc_region_type,
+ /*
+ * Older MC only returned region offset and no base address
+ * If base address is in the region_desc use it otherwise
+ * revert to old mechanism
+ */
+ if (region_desc.base_address)
+ regions[i].start = region_desc.base_address +
+ region_desc.base_offset;
+ else
+ error = translate_mc_addr(mc_dev, mc_region_type,
region_desc.base_offset,
®ions[i].start);
+
if (error < 0) {
dev_err(parent_dev,
"Invalid MC offset: %#x (for %s.%d\'s region %d)\n",
@@ -504,6 +513,8 @@ static int fsl_mc_device_get_mmio_regions(struct fsl_mc_device *mc_dev,
regions[i].flags = IORESOURCE_IO;
if (region_desc.flags & DPRC_REGION_CACHEABLE)
regions[i].flags |= IORESOURCE_CACHEABLE;
+ if (region_desc.flags & DPRC_REGION_SHAREABLE)
+ regions[i].flags |= IORESOURCE_MEM;
}
mc_dev->regions = regions;
diff --git a/drivers/bus/fsl-mc/fsl-mc-private.h b/drivers/bus/fsl-mc/fsl-mc-private.h
index ea11b4f..020fcc0 100644
--- a/drivers/bus/fsl-mc/fsl-mc-private.h
+++ b/drivers/bus/fsl-mc/fsl-mc-private.h
@@ -79,9 +79,11 @@ int dpmcp_reset(struct fsl_mc_io *mc_io,
/* DPRC command versioning */
#define DPRC_CMD_BASE_VERSION 1
+#define DPRC_CMD_2ND_VERSION 2
#define DPRC_CMD_ID_OFFSET 4
#define DPRC_CMD(id) (((id) << DPRC_CMD_ID_OFFSET) | DPRC_CMD_BASE_VERSION)
+#define DPRC_CMD_V2(id) (((id) << DPRC_CMD_ID_OFFSET) | DPRC_CMD_2ND_VERSION)
/* DPRC command IDs */
#define DPRC_CMDID_CLOSE DPRC_CMD(0x800)
@@ -100,6 +102,7 @@ int dpmcp_reset(struct fsl_mc_io *mc_io,
#define DPRC_CMDID_GET_OBJ_COUNT DPRC_CMD(0x159)
#define DPRC_CMDID_GET_OBJ DPRC_CMD(0x15A)
#define DPRC_CMDID_GET_OBJ_REG DPRC_CMD(0x15E)
+#define DPRC_CMDID_GET_OBJ_REG_V2 DPRC_CMD_V2(0x15E)
#define DPRC_CMDID_SET_OBJ_IRQ DPRC_CMD(0x15F)
struct dprc_cmd_open {
@@ -199,9 +202,16 @@ struct dprc_rsp_get_obj_region {
/* response word 0 */
__le64 pad;
/* response word 1 */
- __le64 base_addr;
+ __le64 base_offset;
/* response word 2 */
__le32 size;
+ __le32 pad2;
+ /* response word 3 */
+ __le32 flags;
+ __le32 pad3;
+ /* response word 4 */
+ /* base_addr may be zero if older MC firmware is used */
+ __le64 base_addr;
};
struct dprc_cmd_set_obj_irq {
@@ -334,6 +344,7 @@ int dprc_set_obj_irq(struct fsl_mc_io *mc_io,
/* Region flags */
/* Cacheable - Indicates that region should be mapped as cacheable */
#define DPRC_REGION_CACHEABLE 0x00000001
+#define DPRC_REGION_SHAREABLE 0x00000002
/**
* enum dprc_region_type - Region type
@@ -342,7 +353,8 @@ int dprc_set_obj_irq(struct fsl_mc_io *mc_io,
*/
enum dprc_region_type {
DPRC_REGION_TYPE_MC_PORTAL,
- DPRC_REGION_TYPE_QBMAN_PORTAL
+ DPRC_REGION_TYPE_QBMAN_PORTAL,
+ DPRC_REGION_TYPE_QBMAN_MEM_BACKED_PORTAL
};
/**
@@ -360,6 +372,7 @@ struct dprc_region_desc {
u32 size;
u32 flags;
enum dprc_region_type type;
+ u64 base_address;
};
int dprc_get_obj_region(struct fsl_mc_io *mc_io,
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/2] soc: fsl: dpio: Add support for memory backed QBMan portals
From: Roy Pledge @ 2019-04-05 14:41 UTC (permalink / raw)
To: stuyoder@gmail.com, Laurentiu Tudor, Leo Li
Cc: Roy Pledge, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Youri Querry
In-Reply-To: <1554475256-4805-1-git-send-email-roy.pledge@nxp.com>
NXP devices with QBMan version 5 and above can enable software
portals that are memory backed. This allows the portal to be
mapped as cacheable/sharable (same as all normal memory) so
that portals can freely migrate between cores and clusters
in the SoC. The driver will enable this mode by default when
appropriate HW support is detected.
Signed-off-by: Youri Querry <youri.querry_1@nxp.com>
Signed-off-by: Roy Pledge <roy.pledge@nxp.com>
---
drivers/soc/fsl/dpio/dpio-driver.c | 23 ++++--
drivers/soc/fsl/dpio/qbman-portal.c | 148 ++++++++++++++++++++++++++++++------
drivers/soc/fsl/dpio/qbman-portal.h | 5 ++
3 files changed, 144 insertions(+), 32 deletions(-)
diff --git a/drivers/soc/fsl/dpio/dpio-driver.c b/drivers/soc/fsl/dpio/dpio-driver.c
index c0cdc89..70014ec 100644
--- a/drivers/soc/fsl/dpio/dpio-driver.c
+++ b/drivers/soc/fsl/dpio/dpio-driver.c
@@ -197,13 +197,22 @@ static int dpaa2_dpio_probe(struct fsl_mc_device *dpio_dev)
desc.cpu);
}
- /*
- * Set the CENA regs to be the cache inhibited area of the portal to
- * avoid coherency issues if a user migrates to another core.
- */
- desc.regs_cena = devm_memremap(dev, dpio_dev->regions[1].start,
- resource_size(&dpio_dev->regions[1]),
- MEMREMAP_WC);
+ if (dpio_dev->obj_desc.region_count < 3) {
+ /* No support for DDR backed portals, use classic mapping */
+ /*
+ * Set the CENA regs to be the cache inhibited area of the
+ * portal to avoid coherency issues if a user migrates to
+ * another core.
+ */
+ desc.regs_cena = devm_memremap(dev, dpio_dev->regions[1].start,
+ resource_size(&dpio_dev->regions[1]),
+ MEMREMAP_WC);
+ } else {
+ desc.regs_cena = devm_memremap(dev, dpio_dev->regions[2].start,
+ resource_size(&dpio_dev->regions[2]),
+ MEMREMAP_WB);
+ }
+
if (IS_ERR(desc.regs_cena)) {
dev_err(dev, "devm_memremap failed\n");
err = PTR_ERR(desc.regs_cena);
diff --git a/drivers/soc/fsl/dpio/qbman-portal.c b/drivers/soc/fsl/dpio/qbman-portal.c
index d020135..c66f5b7 100644
--- a/drivers/soc/fsl/dpio/qbman-portal.c
+++ b/drivers/soc/fsl/dpio/qbman-portal.c
@@ -15,6 +15,8 @@
#define QMAN_REV_4000 0x04000000
#define QMAN_REV_4100 0x04010000
#define QMAN_REV_4101 0x04010001
+#define QMAN_REV_5000 0x05000000
+
#define QMAN_REV_MASK 0xffff0000
/* All QBMan command and result structures use this "valid bit" encoding */
@@ -25,10 +27,17 @@
#define QBMAN_WQCHAN_CONFIGURE 0x46
/* CINH register offsets */
+#define QBMAN_CINH_SWP_EQCR_PI 0x800
#define QBMAN_CINH_SWP_EQAR 0x8c0
+#define QBMAN_CINH_SWP_CR_RT 0x900
+#define QBMAN_CINH_SWP_VDQCR_RT 0x940
+#define QBMAN_CINH_SWP_EQCR_AM_RT 0x980
+#define QBMAN_CINH_SWP_RCR_AM_RT 0x9c0
#define QBMAN_CINH_SWP_DQPI 0xa00
#define QBMAN_CINH_SWP_DCAP 0xac0
#define QBMAN_CINH_SWP_SDQCR 0xb00
+#define QBMAN_CINH_SWP_EQCR_AM_RT2 0xb40
+#define QBMAN_CINH_SWP_RCR_PI 0xc00
#define QBMAN_CINH_SWP_RAR 0xcc0
#define QBMAN_CINH_SWP_ISR 0xe00
#define QBMAN_CINH_SWP_IER 0xe40
@@ -43,6 +52,13 @@
#define QBMAN_CENA_SWP_RR(vb) (0x700 + ((u32)(vb) >> 1))
#define QBMAN_CENA_SWP_VDQCR 0x780
+/* CENA register offsets in memory-backed mode */
+#define QBMAN_CENA_SWP_DQRR_MEM(n) (0x800 + ((u32)(n) << 6))
+#define QBMAN_CENA_SWP_RCR_MEM(n) (0x1400 + ((u32)(n) << 6))
+#define QBMAN_CENA_SWP_CR_MEM 0x1600
+#define QBMAN_CENA_SWP_RR_MEM 0x1680
+#define QBMAN_CENA_SWP_VDQCR_MEM 0x1780
+
/* Reverse mapping of QBMAN_CENA_SWP_DQRR() */
#define QBMAN_IDX_FROM_DQRR(p) (((unsigned long)(p) & 0x1ff) >> 6)
@@ -96,10 +112,13 @@ static inline void *qbman_get_cmd(struct qbman_swp *p, u32 offset)
#define SWP_CFG_DQRR_MF_SHIFT 20
#define SWP_CFG_EST_SHIFT 16
+#define SWP_CFG_CPBS_SHIFT 15
#define SWP_CFG_WN_SHIFT 14
#define SWP_CFG_RPM_SHIFT 12
#define SWP_CFG_DCM_SHIFT 10
#define SWP_CFG_EPM_SHIFT 8
+#define SWP_CFG_VPM_SHIFT 7
+#define SWP_CFG_CPM_SHIFT 6
#define SWP_CFG_SD_SHIFT 5
#define SWP_CFG_SP_SHIFT 4
#define SWP_CFG_SE_SHIFT 3
@@ -125,6 +144,8 @@ static inline u32 qbman_set_swp_cfg(u8 max_fill, u8 wn, u8 est, u8 rpm, u8 dcm,
ep << SWP_CFG_EP_SHIFT);
}
+#define QMAN_RT_MODE 0x00000100
+
/**
* qbman_swp_init() - Create a functional object representing the given
* QBMan portal descriptor.
@@ -146,6 +167,8 @@ struct qbman_swp *qbman_swp_init(const struct qbman_swp_desc *d)
p->sdq |= qbman_sdqcr_dct_prio_ics << QB_SDQCR_DCT_SHIFT;
p->sdq |= qbman_sdqcr_fc_up_to_3 << QB_SDQCR_FC_SHIFT;
p->sdq |= QMAN_SDQCR_TOKEN << QB_SDQCR_TOK_SHIFT;
+ if ((p->desc->qman_version & QMAN_REV_MASK) >= QMAN_REV_5000)
+ p->mr.valid_bit = QB_VALID_BIT;
atomic_set(&p->vdq.available, 1);
p->vdq.valid_bit = QB_VALID_BIT;
@@ -163,6 +186,9 @@ struct qbman_swp *qbman_swp_init(const struct qbman_swp_desc *d)
p->addr_cena = d->cena_bar;
p->addr_cinh = d->cinh_bar;
+ if ((p->desc->qman_version & QMAN_REV_MASK) >= QMAN_REV_5000)
+ memset(p->addr_cena, 0, 64 * 1024);
+
reg = qbman_set_swp_cfg(p->dqrr.dqrr_size,
1, /* Writes Non-cacheable */
0, /* EQCR_CI stashing threshold */
@@ -175,6 +201,10 @@ struct qbman_swp *qbman_swp_init(const struct qbman_swp_desc *d)
1, /* dequeue stashing priority == TRUE */
0, /* dequeue stashing enable == FALSE */
0); /* EQCR_CI stashing priority == FALSE */
+ if ((p->desc->qman_version & QMAN_REV_MASK) >= QMAN_REV_5000)
+ reg |= 1 << SWP_CFG_CPBS_SHIFT | /* memory-backed mode */
+ 1 << SWP_CFG_VPM_SHIFT | /* VDQCR read triggered mode */
+ 1 << SWP_CFG_CPM_SHIFT; /* CR read triggered mode */
qbman_write_register(p, QBMAN_CINH_SWP_CFG, reg);
reg = qbman_read_register(p, QBMAN_CINH_SWP_CFG);
@@ -184,6 +214,10 @@ struct qbman_swp *qbman_swp_init(const struct qbman_swp_desc *d)
return NULL;
}
+ if ((p->desc->qman_version & QMAN_REV_MASK) >= QMAN_REV_5000) {
+ qbman_write_register(p, QBMAN_CINH_SWP_EQCR_PI, QMAN_RT_MODE);
+ qbman_write_register(p, QBMAN_CINH_SWP_RCR_PI, QMAN_RT_MODE);
+ }
/*
* SDQCR needs to be initialized to 0 when no channels are
* being dequeued from or else the QMan HW will indicate an
@@ -278,7 +312,10 @@ void qbman_swp_interrupt_set_inhibit(struct qbman_swp *p, int inhibit)
*/
void *qbman_swp_mc_start(struct qbman_swp *p)
{
- return qbman_get_cmd(p, QBMAN_CENA_SWP_CR);
+ if ((p->desc->qman_version & QMAN_REV_MASK) < QMAN_REV_5000)
+ return qbman_get_cmd(p, QBMAN_CENA_SWP_CR);
+ else
+ return qbman_get_cmd(p, QBMAN_CENA_SWP_CR_MEM);
}
/*
@@ -289,8 +326,14 @@ void qbman_swp_mc_submit(struct qbman_swp *p, void *cmd, u8 cmd_verb)
{
u8 *v = cmd;
- dma_wmb();
- *v = cmd_verb | p->mc.valid_bit;
+ if ((p->desc->qman_version & QMAN_REV_MASK) < QMAN_REV_5000) {
+ dma_wmb();
+ *v = cmd_verb | p->mc.valid_bit;
+ } else {
+ *v = cmd_verb | p->mc.valid_bit;
+ dma_wmb();
+ qbman_write_register(p, QBMAN_CINH_SWP_CR_RT, QMAN_RT_MODE);
+ }
}
/*
@@ -301,13 +344,27 @@ void *qbman_swp_mc_result(struct qbman_swp *p)
{
u32 *ret, verb;
- ret = qbman_get_cmd(p, QBMAN_CENA_SWP_RR(p->mc.valid_bit));
+ if ((p->desc->qman_version & QMAN_REV_MASK) < QMAN_REV_5000) {
+ ret = qbman_get_cmd(p, QBMAN_CENA_SWP_RR(p->mc.valid_bit));
+ /* Remove the valid-bit - command completed if the rest
+ * is non-zero.
+ */
+ verb = ret[0] & ~QB_VALID_BIT;
+ if (!verb)
+ return NULL;
+ p->mc.valid_bit ^= QB_VALID_BIT;
+ } else {
+ ret = qbman_get_cmd(p, QBMAN_CENA_SWP_RR_MEM);
+ /* Command completed if the valid bit is toggled */
+ if (p->mr.valid_bit != (ret[0] & QB_VALID_BIT))
+ return NULL;
+ /* Command completed if the rest is non-zero */
+ verb = ret[0] & ~QB_VALID_BIT;
+ if (!verb)
+ return NULL;
+ p->mr.valid_bit ^= QB_VALID_BIT;
+ }
- /* Remove the valid-bit - command completed if the rest is non-zero */
- verb = ret[0] & ~QB_VALID_BIT;
- if (!verb)
- return NULL;
- p->mc.valid_bit ^= QB_VALID_BIT;
return ret;
}
@@ -384,6 +441,18 @@ void qbman_eq_desc_set_qd(struct qbman_eq_desc *d, u32 qdid,
#define EQAR_VB(eqar) ((eqar) & 0x80)
#define EQAR_SUCCESS(eqar) ((eqar) & 0x100)
+static inline void qbman_write_eqcr_am_rt_register(struct qbman_swp *p,
+ u8 idx)
+{
+ if (idx < 16)
+ qbman_write_register(p, QBMAN_CINH_SWP_EQCR_AM_RT + idx * 4,
+ QMAN_RT_MODE);
+ else
+ qbman_write_register(p, QBMAN_CINH_SWP_EQCR_AM_RT2 +
+ (idx - 16) * 4,
+ QMAN_RT_MODE);
+}
+
/**
* qbman_swp_enqueue() - Issue an enqueue command
* @s: the software portal used for enqueue
@@ -408,9 +477,15 @@ int qbman_swp_enqueue(struct qbman_swp *s, const struct qbman_eq_desc *d,
memcpy(&p->dca, &d->dca, 31);
memcpy(&p->fd, fd, sizeof(*fd));
- /* Set the verb byte, have to substitute in the valid-bit */
- dma_wmb();
- p->verb = d->verb | EQAR_VB(eqar);
+ if ((s->desc->qman_version & QMAN_REV_MASK) < QMAN_REV_5000) {
+ /* Set the verb byte, have to substitute in the valid-bit */
+ dma_wmb();
+ p->verb = d->verb | EQAR_VB(eqar);
+ } else {
+ p->verb = d->verb | EQAR_VB(eqar);
+ dma_wmb();
+ qbman_write_eqcr_am_rt_register(s, EQAR_IDX(eqar));
+ }
return 0;
}
@@ -587,17 +662,27 @@ int qbman_swp_pull(struct qbman_swp *s, struct qbman_pull_desc *d)
return -EBUSY;
}
s->vdq.storage = (void *)(uintptr_t)d->rsp_addr_virt;
- p = qbman_get_cmd(s, QBMAN_CENA_SWP_VDQCR);
+ if ((s->desc->qman_version & QMAN_REV_MASK) < QMAN_REV_5000)
+ p = qbman_get_cmd(s, QBMAN_CENA_SWP_VDQCR);
+ else
+ p = qbman_get_cmd(s, QBMAN_CENA_SWP_VDQCR_MEM);
p->numf = d->numf;
p->tok = QMAN_DQ_TOKEN_VALID;
p->dq_src = d->dq_src;
p->rsp_addr = d->rsp_addr;
p->rsp_addr_virt = d->rsp_addr_virt;
- dma_wmb();
- /* Set the verb byte, have to substitute in the valid-bit */
- p->verb = d->verb | s->vdq.valid_bit;
- s->vdq.valid_bit ^= QB_VALID_BIT;
+ if ((s->desc->qman_version & QMAN_REV_MASK) < QMAN_REV_5000) {
+ dma_wmb();
+ /* Set the verb byte, have to substitute in the valid-bit */
+ p->verb = d->verb | s->vdq.valid_bit;
+ s->vdq.valid_bit ^= QB_VALID_BIT;
+ } else {
+ p->verb = d->verb | s->vdq.valid_bit;
+ s->vdq.valid_bit ^= QB_VALID_BIT;
+ dma_wmb();
+ qbman_write_register(s, QBMAN_CINH_SWP_VDQCR_RT, QMAN_RT_MODE);
+ }
return 0;
}
@@ -655,7 +740,10 @@ const struct dpaa2_dq *qbman_swp_dqrr_next(struct qbman_swp *s)
QBMAN_CENA_SWP_DQRR(s->dqrr.next_idx)));
}
- p = qbman_get_cmd(s, QBMAN_CENA_SWP_DQRR(s->dqrr.next_idx));
+ if ((s->desc->qman_version & QMAN_REV_MASK) < QMAN_REV_5000)
+ p = qbman_get_cmd(s, QBMAN_CENA_SWP_DQRR(s->dqrr.next_idx));
+ else
+ p = qbman_get_cmd(s, QBMAN_CENA_SWP_DQRR_MEM(s->dqrr.next_idx));
verb = p->dq.verb;
/*
@@ -807,18 +895,28 @@ int qbman_swp_release(struct qbman_swp *s, const struct qbman_release_desc *d,
return -EBUSY;
/* Start the release command */
- p = qbman_get_cmd(s, QBMAN_CENA_SWP_RCR(RAR_IDX(rar)));
+ if ((s->desc->qman_version & QMAN_REV_MASK) < QMAN_REV_5000)
+ p = qbman_get_cmd(s, QBMAN_CENA_SWP_RCR(RAR_IDX(rar)));
+ else
+ p = qbman_get_cmd(s, QBMAN_CENA_SWP_RCR_MEM(RAR_IDX(rar)));
/* Copy the caller's buffer pointers to the command */
for (i = 0; i < num_buffers; i++)
p->buf[i] = cpu_to_le64(buffers[i]);
p->bpid = d->bpid;
- /*
- * Set the verb byte, have to substitute in the valid-bit and the number
- * of buffers.
- */
- dma_wmb();
- p->verb = d->verb | RAR_VB(rar) | num_buffers;
+ if ((s->desc->qman_version & QMAN_REV_MASK) < QMAN_REV_5000) {
+ /*
+ * Set the verb byte, have to substitute in the valid-bit
+ * and the number of buffers.
+ */
+ dma_wmb();
+ p->verb = d->verb | RAR_VB(rar) | num_buffers;
+ } else {
+ p->verb = d->verb | RAR_VB(rar) | num_buffers;
+ dma_wmb();
+ qbman_write_register(s, QBMAN_CINH_SWP_RCR_AM_RT +
+ RAR_IDX(rar) * 4, QMAN_RT_MODE);
+ }
return 0;
}
diff --git a/drivers/soc/fsl/dpio/qbman-portal.h b/drivers/soc/fsl/dpio/qbman-portal.h
index fa35fc1..78c700e 100644
--- a/drivers/soc/fsl/dpio/qbman-portal.h
+++ b/drivers/soc/fsl/dpio/qbman-portal.h
@@ -110,6 +110,11 @@ struct qbman_swp {
u32 valid_bit; /* 0x00 or 0x80 */
} mc;
+ /* Management response */
+ struct {
+ u32 valid_bit; /* 0x00 or 0x80 */
+ } mr;
+
/* Push dequeues */
u32 sdq;
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox