On Fri, Jan 21, 2022 at 07:56:35PM -0500, Nayna Jain wrote:
> PowerVM provides an isolated Platform Keystore(PKS) storage allocation
> for each partition with individually managed access controls to store
> sensitive information securely. Linux Kernel can access this storage by
> interfacing with h
(trying this again, as first time, my message bounced)
I just saw this and have not followed the entire thread from the beginning, but
if you are unsure if a given license text to something on the SPDX License
List, I highly recommend using the SPDX License-diff browser extension / add-on
(for
Running selftest with CONFIG_PPC_IRQ_SOFT_MASK_DEBUG enabled in kernel
triggered below warning:
[ 172.851380] [ cut here ]
[ 172.851391] WARNING: CPU: 8 PID: 2901 at
arch/powerpc/include/asm/hw_irq.h:246 power_pmu_disable+0x270/0x280
[ 172.851402] Modules linked in: dm_
PowerVM guest secure boot intend to use Platform Keystore(PKS) for the
purpose of storing public keys to verify digital signature.
Define sysfs interface to expose PKS variables to userspace to allow
read/write/add/delete operations. Each variable is shown as a read/write
attribute file. The size
PowerVM provides an isolated Platform Keystore(PKS) storage allocation
for each partition with individually managed access controls to store
sensitive information securely. It provides a new set of hypervisor
calls for Linux kernel to access PKS storage.
Define PKS driver using H_CALL interface to
PowerVM provides an isolated Platform Keystore(PKS) storage allocation
for each partition with individually managed access controls to store
sensitive information securely. Linux Kernel can access this storage by
interfacing with hypervisor using a new set of hypervisor calls.
PowerVM guest secur
https://bugzilla.kernel.org/show_bug.cgi?id=213837
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Summary|"Kernel panic - not |[bisected] "Kernel pani
https://bugzilla.kernel.org/show_bug.cgi?id=213837
--- Comment #14 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 300297
--> https://bugzilla.kernel.org/attachment.cgi?id=300297&action=edit
bisect.log
Finally did a bisect which revealed the following commit:
# git bisect good
c2
MMIO emulation can fail if the guest uses an instruction that we are
not prepared to emulate. Since these instructions can be and most
likely are valid ones, this is (slightly) closer to an access fault
than to an illegal instruction, so deliver a Data Storage interrupt
instead of a Program interru
If MMIO emulation fails we don't want to crash the whole guest by
returning to userspace.
The original commit bbf45ba57eae ("KVM: ppc: PowerPC 440 KVM
implementation") added a todo:
/* XXX Deliver Program interrupt to guest. */
and later the commit d69614a295ae ("KVM: PPC: Separate loadstore
e
The MMIO interface between the kernel and userspace uses a structure
that supports a maximum of 8-bytes of data. Instructions that access
more than that need to be emulated in parts.
We currently don't have generic support for splitting the emulation in
parts and each set of instructions needs to
The MMIO emulation code for vector instructions is duplicated between
VSX and VMX. When emulating VMX we should check the VMX copy size
instead of the VSX one.
Fixes: acc9eb9305fe ("KVM: PPC: Reimplement LOAD_VMX/STORE_VMX instruction ...")
Signed-off-by: Fabiano Rosas
Reviewed-by: Nicholas Piggi
Our kvm_arch_vcpu_ioctl_run currently returns the RESUME_HOST values
to userspace, against the API of the KVM_RUN ioctl which returns 0 on
success.
Signed-off-by: Fabiano Rosas
Reviewed-by: Nicholas Piggin
---
This was noticed while enabling the kvm selftests for powerpc. There's
an assert at th
Changes from v3:
Removed all of the low level messages and altered the pr_emerg in the
emulate_mmio to a more descriptive message.
Changed the Program interrupt to a Data Storage. There's an ifdef
needed because this code is shared by HV, PR and booke.
v3:
https://lore.kernel.org/r/2022010721001
The current partition migration implementation does not freeze the
user space and the user space can continue open VAS windows. So
when migration_in_progress flag is enabled, VAS open window
API returns -EBUSY.
Signed-off-by: Haren Myneni
---
arch/powerpc/platforms/pseries/vas.c | 14 +
Since the windows belong to the VAS hardware resource, the
hypervisor expects the partition to close them on source partition
and reopen them after the partition migrated on the destination
machine.
This suspend/resume notifier invokes suspend operation before
and resume operation after migratio
VAS is a hardware engine stays on the chip. So when the partition
migrates, all VAS windows on the source system have to be closed
and reopen them on the destination after migration.
This patch make changes to the current reconfig_open/close_windows
functions to support migration:
- Set VAS_WIN_
Virtual Accelerator Switchboard (VAS) is an engine stays on the
chip. So all windows opened on a specific engine belongs to VAS
the chip. The hypervisor expects the partition to close all
active windows on the sources system and reopen them after
migration on the destination machine.
This patch
I just saw this and have not followed the entire thread from the
beginning, but if you are unsure if a given license text to something on
the SPDX License List, I highly recommend using the SPDX License-diff
browser extension / add-on (for Chrome or Firefox) - once you have that,
you can simply
On Fri, Jan 21, 2022 at 6:03 AM Christophe Leroy
wrote:
>
> Several files are missing SPDX license identifiers.
>
> Following files are given the following SPDX identifier based on the comments
> in the top of the file:
>
> include/asm/ibmebus.h:/* SPDX-License-Identifier: GPL-2.0 OR Open
On Fri, Jan 21, 2022 at 6:03 AM Christophe Leroy
wrote:
>
> Several files are missing SPDX license identifiers.
>
> Following files are given the following SPDX identifier based on the comments
> in the top of the file:
>
> include/asm/epapr_hcalls.h:/* SPDX-License-Identifier: GPL-2.0+ O
The enum led_brightness, which contains the declaration of LED_OFF,
LED_ON, LED_HALF and LED_FULL is obsolete, as the led class now supports
max_brightness.
---
drivers/leds/blink/leds-lgm-sso.c| 8 +++
drivers/leds/flash/leds-ktd2692.c| 4 ++--
drivers/leds/flash/leds-lm3601
The enum led_brightness, which contains the declaration of LED_OFF,
LED_ON, LED_HALF and LED_FULL is obsolete, as the led class now supports
max_brightness.
---
drivers/macintosh/via-pmu-led.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/macintosh/via-pmu-led.c b/dri
PowerVM support two types of credits - Default (uses normal priority
FIFO) and Qality of service (QoS uses high priproty FIFO). The user
decides the number of QoS credits and sets this value with HMC
interface. With the core add/removal, this value can be changed in HMC
which invokes drmgr to com
The hypervisor provides the available VAS GZIP capabilities such
as default or QoS window type and the target available credits in
each type. This patch creates sysfs entries and exports the target,
used and the available credits for each feature.
This interface can be used by the user space to
The VAS window may not be active if the system looses credits and
the NX generates page fault when it receives request on unmap
paste address.
The kernel handles the fault by remap new paste address if the
window is active again, Otherwise return the paste instruction
failure if the executed ins
The user space opens VAS windows and issues NX requests by pasting
CRB on the corresponding paste address mmap. When the system looses
credits due to core removal, the kernel has to close the window in
the hypervisor and make the window inactive by unmapping this paste
address. Also the OS has to
The paste address mapping is done with mmap() after the window is
opened with ioctl. But the window can be closed due to lost credit
due to core removal before mmap(). So if the window is not active,
return mmap() failure with -EACCES and expects the user space reissue
mmap() when the window is a
The hypervisor reduces the available credits if the core is removed
from the LPAR. So there is possibility of using excessive credits
(windows) in the LPAR and the hypervisor expects the system to close
the excessive windows. Even though the user space can continue to use
these windows to send co
VAS windows can be closed in the hypervisor due to lost credits
when the core is removed. If these credits are available later
for core add, reopen these windows and set them active. When the
kernel sees page fault on the paste address, it creates new mapping
on the new paste address. Then the us
The kernel sets the VAS window with partition PID when is opened in
the hypervisor. During DLPAR operation, windows can be closed and
reopened in the hypervisor when the credit is available. So saves
this PID in pseries_vas_window struct when the window is opened
initially and reuse it later duri
The hypervisor assigns credits for each LPAR based on number of
cores configured in that system. So expects to release credits
(means windows) when the core is removed. This patch adds notifier
for core removal/add so that the OS closes windows if the system
looses credits due to core removal and
target/used/avail_creds provides credits usage to user space via
sysfs and the same interface can be used on PowerNV in future.
Remove "lpar" from these names so that applicable on both PowerVM
and PowerNV.
Signed-off-by: Haren Myneni
---
arch/powerpc/platforms/pseries/vas.c | 10 +-
a
PowerPC provides HW compression with NX coprocessor. This feature
is available on both PowerNV and PowerVM and included in Linux.
Since each powerpc chip has one NX coprocessor, the VAS introduces
the concept of windows / credits to manage access to this hardware
resource. On powerVM, these limit
On Fri, Jan 21, 2022 at 04:19:12PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Jan 21, 2022 at 03:13:50PM +, Christophe Leroy wrote:
> > >> - * This file is free software; you can redistribute it and/or modify it
> > >> - * under the terms of the GNU General Public License as published by the
>
Now that gettimeofday.S is unique, move cvdso_call macro
into that file which is the only user.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/vdso/gettimeofday.h | 52 +---
arch/powerpc/kernel/vdso/gettimeofday.S | 44 -
2 files changed, 45 ins
merge vdso64 into vdso32 and rename it vdso.
Signed-off-by: Christophe Leroy
---
arch/powerpc/Makefile | 4 +-
arch/powerpc/kernel/Makefile | 6 +-
.../kernel/{vdso64 => vdso}/.gitignore| 2 +
arch/powerpc/kernel/{vdso32 => vdso}/Makefile | 35
cvdso_call_time macro is very similar to cvdso_call macro.
Add a call_time argument to cvdso_call which is 0 by default
and set to 1 when using cvdso_call to call __c_kernel_time().
Return returned value as is with CR[SO] cleared when it is used
for time().
Signed-off-by: Christophe Leroy
---
VDSO64 cacheflush.S datapage.S gettimeofday.S and vgettimeofday.c
are very similar to their VDSO32 counterpart.
VDSO32 counterpart is already more complete than the VDSO64 version
as it supports both PPC32 vdso and 32 bits VDSO for PPC64.
Use compat macros wherever necessary in PPC32 files
so tha
In order to merge vdso32 and vdso64 build in following patch, rework
Makefile is order to add -32 suffix to VDSO32 object files.
Also change sigtramp.S to sigtramp32.S as VDSO64 sigtramp.S is too
different to be squashed into VDSO32 sigtramp.S at the first place.
gen_vdso_offsets.sh also becomes
On Fri, Jan 21, 2022 at 03:34:24PM +, Christophe Leroy wrote:
>
>
> Le 21/01/2022 à 16:19, Greg Kroah-Hartman a écrit :
> > On Fri, Jan 21, 2022 at 03:13:50PM +, Christophe Leroy wrote:
> >>
> >>
> >> Le 21/01/2022 à 15:35, Greg Kroah-Hartman a écrit :
>
> ...
>
> @@ -20,16 +16,6 @
Le 21/01/2022 à 16:47, kernel test robot a écrit :
> arch/powerpc/kernel/vdso/gettimeofday.S: Assembler messages:
>>> arch/powerpc/kernel/vdso/gettimeofday.S:68: Error: unrecognized opcode:
>>> `cvdso_call_time'
> make[2]: *** [arch/powerpc/kernel/vdso/Makefile:71:
> arch/powerpc/kernel
Hi Christophe,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v5.16 next-20220121]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documente
Le 21/01/2022 à 16:19, Greg Kroah-Hartman a écrit :
> On Fri, Jan 21, 2022 at 03:13:50PM +, Christophe Leroy wrote:
>>
>>
>> Le 21/01/2022 à 15:35, Greg Kroah-Hartman a écrit :
...
@@ -20,16 +16,6 @@
* respects; for example, they cover modification of the file, and
*
On Fri, Jan 21, 2022 at 03:13:50PM +, Christophe Leroy wrote:
>
>
> Le 21/01/2022 à 15:35, Greg Kroah-Hartman a écrit :
> > On Fri, Jan 21, 2022 at 11:03:20AM +, Christophe Leroy wrote:
> >> Several files are missing SPDX license identifiers.
> >>
> >> Following files are given the follow
Le 21/01/2022 à 15:35, Greg Kroah-Hartman a écrit :
> On Fri, Jan 21, 2022 at 11:03:20AM +, Christophe Leroy wrote:
>> Several files are missing SPDX license identifiers.
>>
>> Following files are given the following SPDX identifier based on the
>> comments in the top of the file:
>>
>>
On Fri, Jan 21, 2022 at 11:03:20AM +, Christophe Leroy wrote:
> Several files are missing SPDX license identifiers.
>
> Following files are given the following SPDX identifier based on the comments
> in the top of the file:
Nit, please wrap your changelog text properly.
>
> boot/crts
On Fri, Jan 21, 2022 at 11:03:20AM +, Christophe Leroy wrote:
> Several files are missing SPDX license identifiers.
>
> Following files are given the following SPDX identifier based on the comments
> in the top of the file:
>
> boot/crtsavres.S:/* SPDX-License-Identifier: GPL-2.0+ */
Hi Christophe,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v5.16 next-20220121]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documente
On Fri, Jan 21, 2022 at 02:48:32PM +0530, Aneesh Kumar K.V wrote:
> Michal Suchánek writes:
>
> > Hello,
> >
> > On Wed, Jul 01, 2020 at 12:52:29PM +0530, Aneesh Kumar K.V wrote:
> >> The PAPR based virtualized persistent memory devices are only supported on
> >> POWER9 and above. In the followup
Several files are missing SPDX license identifiers.
Following files are given the following SPDX identifier based on the comments
in the top of the file:
boot/crtsavres.S:/* SPDX-License-Identifier: GPL-2.0+ */
include/asm/epapr_hcalls.h:/* SPDX-License-Identifier: GPL-2.0+ OR BS
Now that gettimeofday.S is unique, move cvdso_call macro
into that file which is the only user.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/vdso/gettimeofday.h | 52 +---
arch/powerpc/kernel/vdso/gettimeofday.S | 44 -
2 files changed, 45 ins
cvdso_call_time macro is very similar to cvdso_call macro.
Add a call_time argument to cvdso_call which is 0 by default
and set to 1 when using cvdso_call to call __c_kernel_time().
Return returned value as is with CR[SO] cleared when it is used
for time().
Signed-off-by: Christophe Leroy
---
merge vdso64 into vdso32 and rename it vdso.
Signed-off-by: Christophe Leroy
---
arch/powerpc/Makefile | 4 +-
arch/powerpc/kernel/Makefile | 6 +-
.../kernel/{vdso64 => vdso}/.gitignore| 2 +
arch/powerpc/kernel/{vdso32 => vdso}/Makefile | 35
In order to merge vdso32 and vdso64 build in following patch, rework
Makefile is order to add -32 suffix to VDSO32 object files.
Also change sigtramp.S to sigtramp32.S as VDSO64 sigtramp.S is too
different to be squashed into VDSO32 sigtramp.S at the first place.
gen_vdso_offsets.sh also becomes
VDSO64 cacheflush.S datapage.S gettimeofday.S and vgettimeofday.c
are very similar to their VDSO32 counterpart.
VDSO32 counterpart is already more complete than the VDSO64 version
as it supports both PPC32 vdso and 32 bits VDSO for PPC64.
Use compat macros wherever necessary in PPC32 files
so tha
On Fri, Jan 21, 2022 at 4:57 PM Arnd Bergmann wrote:
>
> On Fri, Jan 21, 2022 at 7:25 AM Guo Ren wrote:
> > On Thu, Jan 20, 2022 at 10:43 PM Arnd Bergmann wrote:
> > > On Thu, Jan 20, 2022 at 8:39 AM wrote:
>
> > > Are you sure these are the right calling conventions? According to [1],
> > > I
Michal Suchánek writes:
> Hello,
>
> On Wed, Jul 01, 2020 at 12:52:29PM +0530, Aneesh Kumar K.V wrote:
>> The PAPR based virtualized persistent memory devices are only supported on
>> POWER9 and above. In the followup patch, the kernel will switch the
>> persistent
>> memory cache flush function
On board rev A, the network interface labels for the switch ports
written on the front panel are different than on rev B and later.
This patch fixes network interface names for the switch ports according
to labels that are written on the front panel of the board rev B.
They start from ETH3 and end
Christophe Leroy writes:
> Le 01/07/2020 à 09:22, Aneesh Kumar K.V a écrit :
>> Start using dcbstps; phwsync; sequence for flushing persistent memory range.
>> The new instructions are implemented as a variant of dcbf and hwsync and on
>> P8 and P9 they will be executed as those instructions. We
On Fri, Jan 21, 2022 at 7:25 AM Guo Ren wrote:
> On Thu, Jan 20, 2022 at 10:43 PM Arnd Bergmann wrote:
> > On Thu, Jan 20, 2022 at 8:39 AM wrote:
> > Are you sure these are the right calling conventions? According to [1],
> > I think the 64-bit argument should be in an aligned pair of registers
arch_randomize_brk() is only needed for hash on book3s/64, for other
platforms the one provided by the default mmap layout is good enough.
Move it to hash_utils.c and use randomize_page() like the generic one.
And properly opt out the radix case instead of making an assumption
on mmu_highuser_ssi
Select CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT and
remove arch/powerpc/mm/mmap.c
This change reuses the generic framework added by
commit 67f3977f805b ("arm64, mm: move generic mmap layout
functions to mm") without any functional change.
Comparison between powerpc implementation and the gene
Do like most other architectures and provide randomisation also to
"legacy" memory mappings, by adding the random factor to
mm->mmap_base in arch_pick_mmap_layout().
See commit 8b8addf891de ("x86/mm/32: Enable full randomization on
i386 and X86_32") for all explanations and benefits of that mmap
r
hugetlb_get_unmapped_area() is now identical to the
generic version if only RADIX is enabled, so move it
to slice.c and let it fallback on the generic one
when HASH MMU is not compiled in.
Do the same with arch_get_unmapped_area() and
arch_get_unmapped_area_topdown().
Signed-off-by: Christophe Le
Today drivers/pci/controller/pci-xgene.c defines SZ_1T
Move it into linux/sizes.h so that it can be re-used elsewhere.
Cc: Toan Le
Cc: linux-...@vger.kernel.org
Signed-off-by: Christophe Leroy
Reviewed-by: Krzysztof Wilczyński
Acked-by: Bjorn Helgaas
---
drivers/pci/controller/pci-xgene.c |
Use the generic version of arch_hugetlb_get_unmapped_area()
which is now available at all time.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/book3s/64/hugetlb.h | 4 --
arch/powerpc/mm/book3s64/radix_hugetlbpage.c | 55
arch/powerpc/mm/hugetlbpage.c
Use the generic version of arch_get_unmapped_area() which
is now available at all time instead of its copy
radix__arch_get_unmapped_area()
To allow that for PPC64, add arch_get_mmap_base() and
arch_get_mmap_end() macros.
Instead of setting mm->get_unmapped_area() to either
arch_get_unmapped_area(
CONFIG_PPC_MM_SLICES is always selected by hash book3s/64.
CONFIG_PPC_MM_SLICES is never selected by other platforms.
Remove it.
Signed-off-by: Christophe Leroy
Reviewed-by: Nicholas Piggin
---
arch/powerpc/include/asm/hugetlb.h | 2 +-
arch/powerpc/include/asm/paca.h| 7 ---
Since commit 555904d07eef ("powerpc/8xx: MM_SLICE is not needed
anymore") only book3s/64 selects CONFIG_PPC_MM_SLICES.
Move slice.c into mm/book3s64/
Move necessary stuff in asm/book3s/64/slice.h and
remove asm/slice.h
Signed-off-by: Christophe Leroy
Reviewed-by: Nicholas Piggin
---
arch/powe
vma_mmu_pagesize() is only required for slices,
otherwise there is a generic weak version doing the
exact same thing.
Move it to slice.c
Signed-off-by: Christophe Leroy
Reviewed-by: Nicholas Piggin
---
arch/powerpc/mm/hugetlbpage.c | 11 ---
arch/powerpc/mm/slice.c | 9 +
Powerpc needs flags and len to make decision on arch_get_mmap_end().
So add them as parameters to arch_get_mmap_end().
Signed-off-by: Christophe Leroy
Cc: Steve Capper
Cc: Catalin Marinas
Cc: Will Deacon
Acked-by: Catalin Marinas
---
arch/arm64/include/asm/processor.h | 4 ++--
mm/mmap.c
This is a complement of f6795053dac8 ("mm: mmap: Allow for "high"
userspace addresses") for hugetlb.
This patch adds support for "high" userspace addresses that are
optionally supported on the system and have to be requested via a hint
mechanism ("high" addr parameter to mmap).
Architectures such
Unlike most architectures, powerpc can only define at runtime
if it is going to use the generic arch_get_unmapped_area() or not.
Today, powerpc has a copy of the generic arch_get_unmapped_area()
because when selection HAVE_ARCH_UNMAPPED_AREA the generic
arch_get_unmapped_area() is not available.
Commit e7142bf5d231 ("arm64, mm: make randomization selected by
generic topdown mmap layout") introduced a default version of
arch_randomize_brk() provided when
CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT is selected.
powerpc could select CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
but needs to
Rebased on top of powerpc/next branch
This series converts powerpc to default topdown mmap layout.
powerpc requires its own arch_get_unmapped_area() only when
slices are needed, which is only for book3s/64. First part of
the series moves slices into book3s/64 specific directories
and cleans up ot
Hello,
On Wed, Jul 01, 2020 at 12:52:29PM +0530, Aneesh Kumar K.V wrote:
> The PAPR based virtualized persistent memory devices are only supported on
> POWER9 and above. In the followup patch, the kernel will switch the persistent
> memory cache flush functions to use a new `dcbf` variant instruct
Use truncate_if_32bit() when possible instead of open coding.
truncate_if_32bit() returns an unsigned long, so don't use it when
a signed value is expected.
Signed-off-by: Christophe Leroy
---
arch/powerpc/lib/sstep.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/
MSR_64BIT is always defined, no need to hide code using MSR_64BIT
inside an #ifdef __powerpc64__
Signed-off-by: Christophe Leroy
---
arch/powerpc/lib/sstep.c | 8
1 file changed, 8 deletions(-)
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index b7316d697d80..4aabe38
Don't opencode dcache size retrieval based on whether that's ppc32 or ppc64.
Use l1_dcache_bytes()
Signed-off-by: Christophe Leroy
---
arch/powerpc/lib/sstep.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index a94b0
80 matches
Mail list logo
