LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH 09/13] powerpc/xive: Remove P9 DD1 flag XIVE_IRQ_FLAG_SHIFT_BUG
From: Cédric Le Goater @ 2020-12-10 13:18 UTC (permalink / raw)
  To: Greg Kurz; +Cc: linuxppc-dev
In-Reply-To: <20201208183906.1740c594@bahia.lan>

On 12/8/20 6:39 PM, Greg Kurz wrote:
> On Tue, 8 Dec 2020 16:11:20 +0100
> Cédric Le Goater <clg@kaod.org> wrote:
> 
>> This flag was used to support the PHB4 LSIs on P9 DD1 and we have
>> stopped supporting this CPU when DD2 came out. See skiboot commit:
>>
>>   https://github.com/open-power/skiboot/commit/0b0d15e3c170
>>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>> ---
> 
> Reviewed-by: Greg Kurz <groug@kaod.org>
> 
> Just a minor suggestion in case you need to post a v2. See below.
> 
>>  arch/powerpc/include/asm/opal-api.h     | 2 +-
>>  arch/powerpc/include/asm/xive.h         | 2 +-
>>  arch/powerpc/kvm/book3s_xive_native.c   | 3 ---
>>  arch/powerpc/kvm/book3s_xive_template.c | 3 ---
>>  arch/powerpc/sysdev/xive/common.c       | 8 --------
>>  arch/powerpc/sysdev/xive/native.c       | 2 --
>>  6 files changed, 2 insertions(+), 18 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/opal-api.h b/arch/powerpc/include/asm/opal-api.h
>> index 1dffa3cb16ba..48ee604ca39a 100644
>> --- a/arch/powerpc/include/asm/opal-api.h
>> +++ b/arch/powerpc/include/asm/opal-api.h
>> @@ -1091,7 +1091,7 @@ enum {
>>  	OPAL_XIVE_IRQ_TRIGGER_PAGE	= 0x00000001,
>>  	OPAL_XIVE_IRQ_STORE_EOI		= 0x00000002,
>>  	OPAL_XIVE_IRQ_LSI		= 0x00000004,
>> -	OPAL_XIVE_IRQ_SHIFT_BUG		= 0x00000008,
>> +	OPAL_XIVE_IRQ_SHIFT_BUG		= 0x00000008, /* P9 DD1.0 workaround */
> 
> Maybe you can even comment the entire line so that any future
> tentative to use that flag breaks build ?

This file is "copied" from OPAL. I think it is best to keep them
in sync.

> 
>>  	OPAL_XIVE_IRQ_MASK_VIA_FW	= 0x00000010,
>>  	OPAL_XIVE_IRQ_EOI_VIA_FW	= 0x00000020,
>>  };
>> diff --git a/arch/powerpc/include/asm/xive.h b/arch/powerpc/include/asm/xive.h
>> index d332dd9a18de..ff805885a028 100644
>> --- a/arch/powerpc/include/asm/xive.h
>> +++ b/arch/powerpc/include/asm/xive.h
>> @@ -60,7 +60,7 @@ struct xive_irq_data {
>>  };
>>  #define XIVE_IRQ_FLAG_STORE_EOI	0x01
>>  #define XIVE_IRQ_FLAG_LSI	0x02
>> -#define XIVE_IRQ_FLAG_SHIFT_BUG	0x04
>> +#define XIVE_IRQ_FLAG_SHIFT_BUG	0x04 /* P9 DD1.0 workaround */
> 
> Same here, with an extra cleanup to stop using it when initializing 
> xive_irq_flags[] in common.c.

Yes. Since this is an internal flag, we can simply remove it.

Thanks,

C. 

> 
>>  #define XIVE_IRQ_FLAG_MASK_FW	0x08
>>  #define XIVE_IRQ_FLAG_EOI_FW	0x10
>>  #define XIVE_IRQ_FLAG_H_INT_ESB	0x20
>> diff --git a/arch/powerpc/kvm/book3s_xive_native.c b/arch/powerpc/kvm/book3s_xive_native.c
>> index 9b395381179d..170d1d04e1d1 100644
>> --- a/arch/powerpc/kvm/book3s_xive_native.c
>> +++ b/arch/powerpc/kvm/book3s_xive_native.c
>> @@ -37,9 +37,6 @@ static u8 xive_vm_esb_load(struct xive_irq_data *xd, u32 offset)
>>  	 * ordering.
>>  	 */
>>  
>> -	if (xd->flags & XIVE_IRQ_FLAG_SHIFT_BUG)
>> -		offset |= offset << 4;
>> -
>>  	val = in_be64(xd->eoi_mmio + offset);
>>  	return (u8)val;
>>  }
>> diff --git a/arch/powerpc/kvm/book3s_xive_template.c b/arch/powerpc/kvm/book3s_xive_template.c
>> index 4ad3c0279458..ece36e024a8f 100644
>> --- a/arch/powerpc/kvm/book3s_xive_template.c
>> +++ b/arch/powerpc/kvm/book3s_xive_template.c
>> @@ -61,9 +61,6 @@ static u8 GLUE(X_PFX,esb_load)(struct xive_irq_data *xd, u32 offset)
>>  	if (offset == XIVE_ESB_SET_PQ_10 && xd->flags & XIVE_IRQ_FLAG_STORE_EOI)
>>  		offset |= XIVE_ESB_LD_ST_MO;
>>  
>> -	if (xd->flags & XIVE_IRQ_FLAG_SHIFT_BUG)
>> -		offset |= offset << 4;
>> -
>>  	val =__x_readq(__x_eoi_page(xd) + offset);
>>  #ifdef __LITTLE_ENDIAN__
>>  	val >>= 64-8;
>> diff --git a/arch/powerpc/sysdev/xive/common.c b/arch/powerpc/sysdev/xive/common.c
>> index 411cba12d73b..a9259470bf9f 100644
>> --- a/arch/powerpc/sysdev/xive/common.c
>> +++ b/arch/powerpc/sysdev/xive/common.c
>> @@ -200,10 +200,6 @@ static notrace u8 xive_esb_read(struct xive_irq_data *xd, u32 offset)
>>  	if (offset == XIVE_ESB_SET_PQ_10 && xd->flags & XIVE_IRQ_FLAG_STORE_EOI)
>>  		offset |= XIVE_ESB_LD_ST_MO;
>>  
>> -	/* Handle HW errata */
>> -	if (xd->flags & XIVE_IRQ_FLAG_SHIFT_BUG)
>> -		offset |= offset << 4;
>> -
>>  	if ((xd->flags & XIVE_IRQ_FLAG_H_INT_ESB) && xive_ops->esb_rw)
>>  		val = xive_ops->esb_rw(xd->hw_irq, offset, 0, 0);
>>  	else
>> @@ -214,10 +210,6 @@ static notrace u8 xive_esb_read(struct xive_irq_data *xd, u32 offset)
>>  
>>  static void xive_esb_write(struct xive_irq_data *xd, u32 offset, u64 data)
>>  {
>> -	/* Handle HW errata */
>> -	if (xd->flags & XIVE_IRQ_FLAG_SHIFT_BUG)
>> -		offset |= offset << 4;
>> -
>>  	if ((xd->flags & XIVE_IRQ_FLAG_H_INT_ESB) && xive_ops->esb_rw)
>>  		xive_ops->esb_rw(xd->hw_irq, offset, data, 1);
>>  	else
>> diff --git a/arch/powerpc/sysdev/xive/native.c b/arch/powerpc/sysdev/xive/native.c
>> index 5f1e5aed8ab4..0310783241b5 100644
>> --- a/arch/powerpc/sysdev/xive/native.c
>> +++ b/arch/powerpc/sysdev/xive/native.c
>> @@ -64,8 +64,6 @@ int xive_native_populate_irq_data(u32 hw_irq, struct xive_irq_data *data)
>>  		data->flags |= XIVE_IRQ_FLAG_STORE_EOI;
>>  	if (opal_flags & OPAL_XIVE_IRQ_LSI)
>>  		data->flags |= XIVE_IRQ_FLAG_LSI;
>> -	if (opal_flags & OPAL_XIVE_IRQ_SHIFT_BUG)
>> -		data->flags |= XIVE_IRQ_FLAG_SHIFT_BUG;
>>  	if (opal_flags & OPAL_XIVE_IRQ_MASK_VIA_FW)
>>  		data->flags |= XIVE_IRQ_FLAG_MASK_FW;
>>  	if (opal_flags & OPAL_XIVE_IRQ_EOI_VIA_FW)
> 


^ permalink raw reply

* Re: [PATCH] powerpc/rtas: fix typo of ibm,open-errinjct in rtas filter
From: Andrew Donnellan @ 2020-12-10 12:47 UTC (permalink / raw)
  To: Tyrel Datwyler, mpe; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20201208195434.8289-1-tyreld@linux.ibm.com>

On 9/12/20 6:54 am, Tyrel Datwyler wrote:
> Commit bd59380c5ba4 ("powerpc/rtas: Restrict RTAS requests from userspace")
> introduced the following error when invoking the errinjct userspace
> tool.
> 
> [root@ltcalpine2-lp5 librtas]# errinjct open
> [327884.071171] sys_rtas: RTAS call blocked - exploit attempt?
> [327884.071186] sys_rtas: token=0x26, nargs=0 (called by errinjct)
> errinjct: Could not open RTAS error injection facility
> errinjct: librtas: open: Unexpected I/O error
> 
> The entry for ibm,open-errinjct in rtas_filter array has a typo where
> the "j" is omitted in the rtas call name. After fixing this typo the
> errinjct tool functions again as expected.
> 
> [root@ltcalpine2-lp5 linux]# errinjct open
> RTAS error injection facility open, token = 1
> 
> fixes: bd59380c5ba4 ("powerpc/rtas: Restrict RTAS requests from userspace")
> Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>

Thanks for catching this!

Acked-by: Andrew Donnellan <ajd@linux.ibm.com>


-- 
Andrew Donnellan              OzLabs, ADL Canberra
ajd@linux.ibm.com             IBM Australia Limited

^ permalink raw reply

* Re: Linux kernel: powerpc: RTAS calls can be used to compromise kernel integrity
From: Andrew Donnellan @ 2020-12-10 12:47 UTC (permalink / raw)
  To: oss-security, linuxppc-dev; +Cc: Tyrel Datwyler
In-Reply-To: <a2fd9901-d8fc-3ba7-4422-2616bbf23220@linux.ibm.com>

On 24/11/20 1:41 am, Andrew Donnellan wrote:
> On 9/10/20 12:20 pm, Andrew Donnellan wrote:
>> The Linux kernel for powerpc has an issue with the Run-Time 
>> Abstraction Services (RTAS) interface, allowing root (or CAP_SYS_ADMIN 
>> users) in a VM to overwrite some parts of memory, including kernel 
>> memory.
>>
>> This issue impacts guests running on top of PowerVM or KVM hypervisors 
>> (pseries platform), and does *not* impact bare-metal machines (powernv 
>> platform).
> CVE-2020-27777 has been assigned.

A minor regression has been identified, affecting the ibm,open-errinjct 
RTAS call.

A patch is available at 
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20201208195434.8289-1-tyreld@linux.ibm.com/

Thanks to Tyrel Datwyler for identifying and fixing this issue.

-- 
Andrew Donnellan              OzLabs, ADL Canberra
ajd@linux.ibm.com             IBM Australia Limited

^ permalink raw reply

* Re: [PATCH 1/2] ALSA: ppc: drop if block with always false condition
From: Michael Ellerman @ 2020-12-10 11:30 UTC (permalink / raw)
  To: Bartlomiej Zolnierkiewicz, Arnd Bergmann, James E.J. Bottomley,
	Jaroslav Kysela, Michael Ellerman, Geoff Levand, Jakub Kicinski,
	Martin K. Petersen, Jens Axboe, Jim Paris, Takashi Iwai,
	Uwe Kleine-König, David S. Miller, Alan Stern,
	Greg Kroah-Hartman
  Cc: linux-fbdev, linux-scsi, linux-usb, alsa-devel, dri-devel,
	linux-block, Paul Mackerras, netdev, linuxppc-dev
In-Reply-To: <20201126165950.2554997-1-u.kleine-koenig@pengutronix.de>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 622 bytes --]

On Thu, 26 Nov 2020 17:59:49 +0100, Uwe Kleine-König wrote:
> The remove callback is only called for devices that were probed
> successfully before. As the matching probe function cannot complete
> without error if dev->match_id != PS3_MATCH_ID_SOUND, we don't have to
> check this here.

Applied to powerpc/next.

[1/2] ALSA: ppc: drop if block with always false condition
      https://git.kernel.org/powerpc/c/7ff94669e7d8e50756cd57947283381ae9665759
[2/2] powerpc/ps3: make system bus's remove and shutdown callbacks return void
      https://git.kernel.org/powerpc/c/6d247e4d264961aa3b871290f9b11a48d5a567f2

cheers

^ permalink raw reply

* Re: [PATCH] powerpc: Use common STABS_DEBUG and DWARF_DEBUG and ELF_DETAILS macro
From: Michael Ellerman @ 2020-12-10 11:30 UTC (permalink / raw)
  To: Youling Tang, Paul Mackerras, Benjamin Herrenschmidt,
	Michael Ellerman
  Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1606460857-2723-1-git-send-email-tangyouling@loongson.cn>

On Fri, 27 Nov 2020 15:07:37 +0800, Youling Tang wrote:
> Use the common STABS_DEBUG and DWARF_DEBUG and ELF_DETAILS macro rule for
> the linker script in an effort.

Applied to powerpc/next.

[1/1] powerpc: Use common STABS_DEBUG and DWARF_DEBUG and ELF_DETAILS macro
      https://git.kernel.org/powerpc/c/a21df7a1d6ca9bd387a17841863a99431c4aa730

cheers

^ permalink raw reply

* Re: [PATCH v2 0/4] Powerpc: Better preemption for shared processor
From: Michael Ellerman @ 2020-12-10 11:30 UTC (permalink / raw)
  To: Srikar Dronamraju, Michael Ellerman
  Cc: Nathan Lynch, Gautham R Shenoy, Phil Auld, Juri Lelli,
	Peter Zijlstra, LKML, Nicholas Piggin, Waiman Long, linuxppc-dev,
	Valentin Schneider
In-Reply-To: <20201202050456.164005-1-srikar@linux.vnet.ibm.com>

On Wed, 2 Dec 2020 10:34:52 +0530, Srikar Dronamraju wrote:
> Currently, vcpu_is_preempted will return the yield_count for
> shared_processor. On a PowerVM LPAR, Phyp schedules at SMT8 core boundary
> i.e all CPUs belonging to a core are either group scheduled in or group
> scheduled out. This can be used to better predict non-preempted CPUs on
> PowerVM shared LPARs.
> 
> perf stat -r 5 -a perf bench sched pipe -l 10000000 (lesser time is better)
> 
> [...]

Applied to powerpc/next.

[1/4] powerpc: Refactor is_kvm_guest() declaration to new header
      https://git.kernel.org/powerpc/c/92cc6bf01c7f4c5cfefd1963985c0064687ebeda
[2/4] powerpc: Rename is_kvm_guest() to check_kvm_guest()
      https://git.kernel.org/powerpc/c/16520a858a995742c2d2248e86a6026bd0316562
[3/4] powerpc: Reintroduce is_kvm_guest() as a fast-path check
      https://git.kernel.org/powerpc/c/a21d1becaa3f17a97b933ffa677b526afc514ec5
[4/4] powerpc/paravirt: Use is_kvm_guest() in vcpu_is_preempted()
      https://git.kernel.org/powerpc/c/ca3f969dcb111d35674b66bdcb72beb2c426b9b5

cheers

^ permalink raw reply

* Re: [PATCH] powerpc/xmon: Fix build failure for 8xx
From: Michael Ellerman @ 2020-12-10 11:30 UTC (permalink / raw)
  To: mpe, Ravi Bangoria; +Cc: christophe.leroy, mikey, linuxppc-dev
In-Reply-To: <20201130034406.288047-1-ravi.bangoria@linux.ibm.com>

On Mon, 30 Nov 2020 09:14:06 +0530, Ravi Bangoria wrote:
> With CONFIG_PPC_8xx and CONFIG_XMON set, kernel build fails with
> 
>   arch/powerpc/xmon/xmon.c:1379:12: error: 'find_free_data_bpt' defined
>   but not used [-Werror=unused-function]
> 
> Fix it by enclosing find_free_data_bpt() inside #ifndef CONFIG_PPC_8xx.

Applied to powerpc/next.

[1/1] powerpc/xmon: Fix build failure for 8xx
      https://git.kernel.org/powerpc/c/f3e90408019b353fd1fcd338091fb8d3c4a1c1a5

cheers

^ permalink raw reply

* Re: [PATCH] powernv/pci: Print an error when device enable is blocked
From: Michael Ellerman @ 2020-12-10 11:30 UTC (permalink / raw)
  To: Oliver O'Halloran, linuxppc-dev
In-Reply-To: <20200409061337.9187-1-oohall@gmail.com>

On Thu, 9 Apr 2020 16:13:37 +1000, Oliver O'Halloran wrote:
> If the platform decides to block enabling the device nothing is printed
> currently. This can lead to some confusion since the dmesg output will
> usually print an error with no context e.g.
> 
> 	e1000e: probe of 0022:01:00.0 failed with error -22
> 
> This shouldn't be spammy since pci_enable_device() already prints a
> messages when it succeeds.

Applied to powerpc/next.

[1/1] powernv/pci: Print an error when device enable is blocked
      https://git.kernel.org/powerpc/c/6c58b1b41b19c00099e4771ee55e21eb9aa245c1

cheers

^ permalink raw reply

* Re: [PATCH v3 0/2] powerpc/ptrace: Hard wire PT_SOFTE value to 1 in gpr_get() too
From: Michael Ellerman @ 2020-12-10 11:30 UTC (permalink / raw)
  To: Benjamin Herrenschmidt, Oleg Nesterov, Madhavan Srinivasan,
	Michael Ellerman, Paul Mackerras
  Cc: Christophe Leroy, linuxppc-dev, linux-kernel, Nicholas Piggin,
	Al Viro, Aneesh Kumar K.V, Jan Kratochvil
In-Reply-To: <20201119160154.GA5183@redhat.com>

On Thu, 19 Nov 2020 17:01:54 +0100, Oleg Nesterov wrote:
> Can we finally fix this problem? ;)
> 
> My previous attempt was ignored, see
> 
> 	https://lore.kernel.org/lkml/20190917121256.GA8659@redhat.com/
> 
> Now that gpr_get() was changed to use membuf API we can make a simpler fix.
> 
> [...]

Applied to powerpc/next.

[1/2] powerpc/ptrace: Simplify gpr_get()/tm_cgpr_get()
      https://git.kernel.org/powerpc/c/640586f8af356096e084d69a9909d217852bde48
[2/2] powerpc/ptrace: Hard wire PT_SOFTE value to 1 in gpr_get() too
      https://git.kernel.org/powerpc/c/324a69467f12652b21b17f9644faa967d3d8bbdf

cheers

^ permalink raw reply

* Re: [RFC PATCH] powerpc: show registers when unwinding interrupt frames
From: Michael Ellerman @ 2020-12-10 11:30 UTC (permalink / raw)
  To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <20201107023305.2384874-1-npiggin@gmail.com>

On Sat, 7 Nov 2020 12:33:05 +1000, Nicholas Piggin wrote:
> It's often useful to know the register state for interrupts in
> the stack frame. In the below example (with this patch applied),
> the important information is the state of the page fault.
> 
> A blatant case like this probably rather should have the page
> fault regs passed down to the warning, but quite often there are
> less obvious cases where an interrupt shows up that might give
> some more clues.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc: show registers when unwinding interrupt frames
      https://git.kernel.org/powerpc/c/bf13718bc57ada25016d9fe80323238d0b94506e

cheers

^ permalink raw reply

* Re: [PATCH 0/8] powerpc/64s: fix and improve machine check handling
From: Michael Ellerman @ 2020-12-10 11:30 UTC (permalink / raw)
  To: Nicholas Piggin, linuxppc-dev; +Cc: Mahesh Salgaonkar, kvm-ppc
In-Reply-To: <20201128070728.825934-1-npiggin@gmail.com>

On Sat, 28 Nov 2020 17:07:20 +1000, Nicholas Piggin wrote:
> First patch is a nasty memory scribble introduced by me :( That
> should go into fixes.
> 
> The next ones could wait for next merge window. They get things to the
> point where misbehaving or buggy guest isn't so painful for the host,
> and also get the guest SLB dumping code working (because the host no
> longer clears them before delivering the MCE to the guest).
> 
> [...]

Patches 2-8 applied to powerpc/next.

[2/8] powerpc/64s/powernv: Allow KVM to handle guest machine check details
      https://git.kernel.org/powerpc/c/0ce2382657f39ced2adbb927355360c3aaeb05f8
[3/8] KVM: PPC: Book3S HV: Don't attempt to recover machine checks for FWNMI enabled guests
      https://git.kernel.org/powerpc/c/067c9f9c98c8804b07751994c51d8557e440821e
[4/8] KVM: PPC: Book3S HV: Ratelimit machine check messages coming from guests
      https://git.kernel.org/powerpc/c/1d15ffdfc94127d75e04a88344ee1ce8c79f05fd
[5/8] powerpc/64s/powernv: Ratelimit harmless HMI error printing
      https://git.kernel.org/powerpc/c/f4b239e4c6bddf63d00cd460eabb933232dbc326
[6/8] powerpc/64s/pseries: Add ERAT specific machine check handler
      https://git.kernel.org/powerpc/c/82f70a05108c98aea4f140067c44a606262d2af7
[7/8] powerpc/64s: Remove "Host" from MCE logging
      https://git.kernel.org/powerpc/c/4a869531ddbf5939c45eab6ff389e4e58c8ed19c
[8/8] powerpc/64s: Tidy machine check SLB logging
      https://git.kernel.org/powerpc/c/865ae6f27789dcc3f92341d935f4439e8730a9fe

cheers

^ permalink raw reply

* Re: [PATCH v14 1/9] powerpc/feature: Use CONFIG_PPC64 instead of __powerpc64__ to define possible features
From: Michael Ellerman @ 2020-12-10 11:30 UTC (permalink / raw)
  To: linuxppc-dev, Michael Ellerman
In-Reply-To: <20201126131006.2431205-1-mpe@ellerman.id.au>

On Fri, 27 Nov 2020 00:09:58 +1100, Michael Ellerman wrote:
> In order to build VDSO32 for PPC64, we need to have CPU_FTRS_POSSIBLE
> and CPU_FTRS_ALWAYS independant of whether we are building the
> 32 bits VDSO or the 64 bits VDSO.
> 
> Use #ifdef CONFIG_PPC64 instead of #ifdef __powerpc64__

Applied to powerpc/next.

[1/9] powerpc/feature: Use CONFIG_PPC64 instead of __powerpc64__ to define possible features
      https://git.kernel.org/powerpc/c/8d1eeabf253657ae3e76970514f30b7e53a6898f
[2/9] powerpc/processor: Move cpu_relax() into asm/vdso/processor.h
      https://git.kernel.org/powerpc/c/8f8cffd9df81612b5b06d2c57ebf74f8961b41be
[3/9] powerpc/time: Move timebase functions into new asm/vdso/timebase.h
      https://git.kernel.org/powerpc/c/d26b3817d9eefae6b777739c1ea5daba5e72624e
[4/9] powerpc/time: Fix mftb()/get_tb() for use with the compat VDSO
      https://git.kernel.org/powerpc/c/5c189c523e78d4a70e874477e4b0628fd74207e4
[5/9] powerpc/barrier: Use CONFIG_PPC64 for barrier selection
      https://git.kernel.org/powerpc/c/1f1676bb2dd52c1054db8476d6387e6dcf62a1ba
[6/9] powerpc/vdso: Prepare for switching VDSO to generic C implementation.
      https://git.kernel.org/powerpc/c/ce7d8056e38b770f070fc4499c577322b6ccb9c7
[7/9] powerpc/vdso: Save and restore TOC pointer on PPC64
      https://git.kernel.org/powerpc/c/7fec9f5d41979dbe273ec337327d5939449562e7
[8/9] powerpc/vdso: Switch VDSO to generic C implementation.
      https://git.kernel.org/powerpc/c/ab037dd87a2f946556850e204c06cbd7a2a19390
[9/9] powerpc/vdso: Provide __kernel_clock_gettime64() on vdso32
      https://git.kernel.org/powerpc/c/d0e3fc69d00d1f50d22d6b6acfc555ccda80ad1e

cheers

^ permalink raw reply

* Re: [PATCH 1/3] powerpc: Make NUMA depend on SMP
From: Michael Ellerman @ 2020-12-10 11:30 UTC (permalink / raw)
  To: linuxppc-dev, Michael Ellerman; +Cc: rdunlap, srikar
In-Reply-To: <20201124120547.1940635-1-mpe@ellerman.id.au>

On Tue, 24 Nov 2020 23:05:45 +1100, Michael Ellerman wrote:
> Our Kconfig allows NUMA to be enabled without SMP, but none of
> our defconfigs use that combination. This means it can easily be
> broken inadvertently by code changes, which has happened recently.
> 
> Although it's theoretically possible to have a machine with a single
> CPU and multiple memory nodes, I can't think of any real systems where
> that's the case. Even so if such a system exists, it can just run an
> SMP kernel anyway.
> 
> [...]

Applied to powerpc/next.

[1/3] powerpc: Make NUMA depend on SMP
      https://git.kernel.org/powerpc/c/25395cd2f8cb24ce6a5ce073c898acfb091e06cf
[2/3] powerpc: Make NUMA default y for powernv
      https://git.kernel.org/powerpc/c/4c28b32b886f1489c5f510ed8e3f0c4e3dcb59f5
[3/3] powerpc: Update NUMA Kconfig description & help text
      https://git.kernel.org/powerpc/c/bae80c27fc2195b9e5723d7b05c592e0874f4ba9

cheers

^ permalink raw reply

* Re: [PATCH] powerpc/wrapper: add "-z rodynamic" when using LLD
From: Michael Ellerman @ 2020-12-10 11:30 UTC (permalink / raw)
  To: Bill Wendling, linuxppc-dev, Michael Ellerman
  Cc: Nick Desaulniers, Fangrui Song, Alan Modra
In-Reply-To: <20201118223910.2711337-1-morbo@google.com>

On Wed, 18 Nov 2020 14:39:10 -0800, Bill Wendling wrote:
> Normally all read-only sections precede SHF_WRITE sections. .dynamic and
> .got have the SHF_WRITE flag; .dynamic probably because of DT_DEBUG. LLD
> emits an error when this happens, so use "-z rodynamic" to mark .dynamic
> as read-only.

Applied to powerpc/next.

[1/1] powerpc/boot/wrapper: Add "-z rodynamic" when using LLD
      https://git.kernel.org/powerpc/c/26ba9f9651d802ba38583138f43fea5dc7eb0fd6

cheers

^ permalink raw reply

* Re: [PATCH] powerpc/boot: move the .got section to after the .dynamic section
From: Michael Ellerman @ 2020-12-10 11:30 UTC (permalink / raw)
  To: Bill Wendling, linuxppc-dev; +Cc: Paul Mackerras, Fangrui Song, Alan Modra
In-Reply-To: <20201017000151.150788-1-morbo@google.com>

On Fri, 16 Oct 2020 17:01:51 -0700, Bill Wendling wrote:
> Both .dynamic and .got are RELRO sections and should be placed together,
> and LLD emits an error:
> 
>   ld.lld: error: section: .got is not contiguous with other relro sections
> 
> Place them together to avoid this.

Applied to powerpc/next.

[1/1] powerpc/boot: Move the .got section to after the .dynamic section
      https://git.kernel.org/powerpc/c/a538d184e3f0e3b5f800c5ab148e83bb5cdd0133

cheers

^ permalink raw reply

* Re: [PATCH] powerpc/64: Fix an EMIT_BUG_ENTRY in head_64.S
From: Michael Ellerman @ 2020-12-10 11:30 UTC (permalink / raw)
  To: Jordan Niethe, linuxppc-dev
In-Reply-To: <20201130004404.30953-1-jniethe5@gmail.com>

On Mon, 30 Nov 2020 11:44:04 +1100, Jordan Niethe wrote:
> Commit 63ce271b5e37 ("powerpc/prom: convert PROM_BUG() to standard
> trap") added an EMIT_BUG_ENTRY for the trap after the branch to
> start_kernel(). The EMIT_BUG_ENTRY was for the address "0b", however the
> trap was not labeled with "0". Hence the address used for bug is in
> relative_toc() where the previous "0" label is. Label the trap as "0" so
> the correct address is used.

Applied to powerpc/next.

[1/1] powerpc/64: Fix an EMIT_BUG_ENTRY in head_64.S
      https://git.kernel.org/powerpc/c/fe18a35e685c9bdabc8b11b3e19deb85a068b75d

cheers

^ permalink raw reply

* Re: [PATCH v2] powerpc: Allow relative pointers in bug table entries
From: Michael Ellerman @ 2020-12-10 11:30 UTC (permalink / raw)
  To: Jordan Niethe, linuxppc-dev
In-Reply-To: <20201201005203.15210-1-jniethe5@gmail.com>

On Tue, 1 Dec 2020 11:52:03 +1100, Jordan Niethe wrote:
> This enables GENERIC_BUG_RELATIVE_POINTERS on Power so that 32-bit
> offsets are stored in the bug entries rather than 64-bit pointers.
> While this doesn't save space for 32-bit machines, use it anyway so
> there is only one code path.

Applied to powerpc/next.

[1/1] powerpc: Allow relative pointers in bug table entries
      https://git.kernel.org/powerpc/c/1baa1f70ef77c4447628992ad50ab83213e2eb6c

cheers

^ permalink raw reply

* Re: [PATCH 1/2] powerpc/book3s64/kexec: Clear CIABR on kexec
From: Michael Ellerman @ 2020-12-10 11:30 UTC (permalink / raw)
  To: Jordan Niethe, linuxppc-dev
In-Reply-To: <20201207010519.15597-1-jniethe5@gmail.com>

On Mon, 7 Dec 2020 12:05:18 +1100, Jordan Niethe wrote:
> The value in CIABR persists across kexec which can lead to unintended
> results when the new kernel hits the old kernel's breakpoint. For
> example:
> 
> 0:mon> bi $loadavg_proc_show
> 0:mon> b
>    type            address
> 1 inst   c000000000519060  loadavg_proc_show+0x0/0x130
> 0:mon> x
> 
> [...]

Applied to powerpc/next.

[1/2] powerpc/book3s64/kexec: Clear CIABR on kexec
      https://git.kernel.org/powerpc/c/4bb3219837a3dcf58bce96c27db6e0cd48f3d9b2
[2/2] powerpc/powernv/idle: Restore CIABR after idle for Power9
      https://git.kernel.org/powerpc/c/250ad7a45b1e58d580decfb935fc063c4cf56f91

cheers

^ permalink raw reply

* Re: [PATCH] selftests/powerpc: Fix uninitialized variable warning
From: Michael Ellerman @ 2020-12-10 11:30 UTC (permalink / raw)
  To: Harish, mpe; +Cc: linuxppc-dev
In-Reply-To: <20201201092403.238182-1-harish@linux.ibm.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 615 bytes --]

On Tue, 1 Dec 2020 14:54:03 +0530, Harish wrote:
> Patch fixes uninitialized variable warning in bad_accesses test
> which causes the selftests build to fail in older distibutions
> 
> bad_accesses.c: In function ‘bad_access’:
> bad_accesses.c:52:9: error: ‘x’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
>    printf("Bad - no SEGV! (%c)\n", x);
>          ^
> cc1: all warnings being treated as errors

Applied to powerpc/next.

[1/1] selftests/powerpc: Fix uninitialized variable warning
      https://git.kernel.org/powerpc/c/c9344769e2b46ba28b947bec7a8a8f0a091ecd57

cheers

^ permalink raw reply

* Re: [PATCH v5] lkdtm/powerpc: Add SLB multihit test
From: Michael Ellerman @ 2020-12-10 11:30 UTC (permalink / raw)
  To: mpe, linuxppc-dev, Ganesh Goudar; +Cc: msuchanek, mahesh, npiggin, keescook
In-Reply-To: <20201130083057.135610-1-ganeshgr@linux.ibm.com>

On Mon, 30 Nov 2020 14:00:57 +0530, Ganesh Goudar wrote:
> To check machine check handling, add support to inject slb
> multihit errors.

Applied to powerpc/next.

[1/1] lkdtm/powerpc: Add SLB multihit test
      https://git.kernel.org/powerpc/c/3ba150fb21207e4a7f4b600eb2dbbe83f94571fe

cheers

^ permalink raw reply

* Re: [PATCH] powerpc/pseries: Define PCI bus speed for Gen4 and Gen5
From: Michael Ellerman @ 2020-12-10 11:30 UTC (permalink / raw)
  To: Frederic Barrat, linuxppc-dev
In-Reply-To: <20201130152949.26467-1-fbarrat@linux.ibm.com>

On Mon, 30 Nov 2020 16:29:49 +0100, Frederic Barrat wrote:
> Update bus speed definition for PCI Gen4 and 5.

Applied to powerpc/next.

[1/1] powerpc/pseries: Define PCI bus speed for Gen4 and Gen5
      https://git.kernel.org/powerpc/c/c8754c517e37270a01b0561ad46ee647a721a09b

cheers

^ permalink raw reply

* Re: [PATCH] selftests/powerpc: update .gitignore
From: Michael Ellerman @ 2020-12-10 11:30 UTC (permalink / raw)
  To: Daniel Axtens, linuxppc-dev
In-Reply-To: <20201201144427.1228745-1-dja@axtens.net>

On Wed, 2 Dec 2020 01:44:27 +1100, Daniel Axtens wrote:
> I did an in-place build of the self-tests and found that it left
> the tree dirty.
> 
> Add missed test binaries to .gitignore

Applied to powerpc/next.

[1/1] selftests/powerpc: update .gitignore
      https://git.kernel.org/powerpc/c/f0812f6ca8299e864fe0f41bd7ffdaae3ce7630e

cheers

^ permalink raw reply

* Re: [PATCH] powerpc/feature-fixups: use a semicolon rather than a comma
From: Michael Ellerman @ 2020-12-10 11:30 UTC (permalink / raw)
  To: Daniel Axtens, linuxppc-dev; +Cc: Nick Piggin
In-Reply-To: <20201201144344.1228421-1-dja@axtens.net>

On Wed, 2 Dec 2020 01:43:44 +1100, Daniel Axtens wrote:
> In a bunch of our security flushes, we use a comma rather than
> a semicolon to 'terminate' an assignment. Nothing breaks, but
> checkpatch picks it up if you copy it into another flush.
> 
> Switch to semicolons for ending statements.

Applied to powerpc/next.

[1/1] powerpc/feature-fixups: use a semicolon rather than a comma
      https://git.kernel.org/powerpc/c/1fc0c27b14b93b2506953ef59e965d98ccc78122

cheers

^ permalink raw reply

* Re: [PATCH] powerpc: add security.config, enforcing lockdown=integrity
From: Michael Ellerman @ 2020-12-10 11:30 UTC (permalink / raw)
  To: Daniel Axtens, linuxppc-dev
In-Reply-To: <20201203042807.1293655-1-dja@axtens.net>

On Thu, 3 Dec 2020 15:28:07 +1100, Daniel Axtens wrote:
> It's sometimes handy to have a config that boots a bit like a system
> under secure boot (forcing lockdown=integrity, without needing any
> extra stuff like a command line option).
> 
> This config file allows that, and also turns on a few assorted security
> and hardening options for good measure.

Applied to powerpc/next.

[1/1] powerpc: add security.config, enforcing lockdown=integrity
      https://git.kernel.org/powerpc/c/ed2bbd2b8581313ca18a7c586a947f6cdd93a52a

cheers

^ permalink raw reply

* Re: [PATCH V4 0/5] ocxl: Mmio invalidation support
From: Michael Ellerman @ 2020-12-10 11:30 UTC (permalink / raw)
  To: fbarrat, ajd, Christophe Lombard, linuxppc-dev
In-Reply-To: <20201125155013.39955-1-clombard@linux.vnet.ibm.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]

On Wed, 25 Nov 2020 16:50:08 +0100, Christophe Lombard wrote:
> OpenCAPI 4.0/5.0 with TLBI/SLBI Snooping, is not used due to performance
> problems caused by the PAU having to process all incoming TLBI/SLBI
> commands which will cause them to back up on the PowerBus.
> 
> When the Address Translation Mode requires TLB operations to be initiated
> using MMIO registers, a set of registers like the following is used:
> • XTS MMIO ATSD0 LPARID register
> • XTS MMIO ATSD0 AVA register
> • XTS MMIO ATSD0 launch register, write access initiates a shoot down
> • XTS MMIO ATSD0 status register
> 
> [...]

Applied to powerpc/next.

[1/5] ocxl: Assign a register set to a Logical Partition
      https://git.kernel.org/powerpc/c/fc1347b5feb685073ce2108c68cd8147340be016
[2/5] ocxl: Initiate a TLB invalidate command
      https://git.kernel.org/powerpc/c/19b311ca51e108b6d8d679496af8635fdc1984a8
[3/5] ocxl: Update the Process Element Entry
      https://git.kernel.org/powerpc/c/d731feea00c7c1734c9697558f2a1962c12d2710
[4/5] ocxl: Add mmu notifier
      https://git.kernel.org/powerpc/c/5f686eea4b3cb1d311f02b81ce4264e66a21d979
[5/5] ocxl: Add new kernel traces
      https://git.kernel.org/powerpc/c/98f5559a439a68e0773f42352f7c0806cac9e76e

cheers

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox