On Tue, 6 Jun 2023, Gerald Schaefer wrote:
> On Mon, 5 Jun 2023 22:11:52 -0700 (PDT)
> Hugh Dickins wrote:
> > On Thu, 1 Jun 2023 15:57:51 +0200
> > Gerald Schaefer wrote:
> > >
> > > Yes, we have 2 pagetables in one 4K page, which could result in same
> > > rcu_head reuse. It might be possible
Add a little perf tester for interrupts that go to guest, host, and
userspace.
Signed-off-by: Nicholas Piggin
---
tools/testing/selftests/kvm/Makefile | 1 +
.../selftests/kvm/powerpc/interrupt_perf.c| 199 ++
2 files changed, 200 insertions(+)
create mode 100644
TLBIEL virtualisation has been a source of difficulty. The TLBIEL
instruction operates on the TLB of the hardware thread which
executes it, but the behaviour expected by the guest environment
Signed-off-by: Nicholas Piggin
---
tools/testing/selftests/kvm/Makefile | 1 +
Add tests that exercise very basic functions of the kvm selftests
framework, guest creation, ucalls, hcalls, copying data between guest
and host, interrupts and page faults.
These don't stress KVM so much as being useful when developing support
for powerpc.
Acked-by: Michael Ellerman (powerpc)
Implement KVM selftests support for powerpc (Book3S-64).
ucalls are implemented with an unsuppored PAPR hcall number which will
always cause KVM to exit to userspace.
Virtual memory is implemented for the radix MMU, and only a base page
size is supported (both 4K and 64K).
Guest interrupts are
powerpc will require this to allocate MMU tables in guest memory that
are larger than guest base page size.
Signed-off-by: Nicholas Piggin
---
.../selftests/kvm/include/kvm_util_base.h | 2 +
tools/testing/selftests/kvm/lib/kvm_util.c| 44 ---
2 files changed, 29
This series adds initial KVM selftests support for powerpc
(64-bit, BookS, radix MMU).
Since v2:
- Added a couple of new tests (patch 5,6)
- Make default page size match host page size.
- Check for radix MMU capability.
- Build a few more of the generic tests.
Since v1:
- Update MAINTAINERS KVM
virt_arch_pgd_alloc all do the same test and set of pgd_created. Move
this into common code.
Signed-off-by: Nicholas Piggin
---
tools/testing/selftests/kvm/include/kvm_util_base.h | 5 +
tools/testing/selftests/kvm/lib/aarch64/processor.c | 4
On Tue, 6 Jun 2023, Jason Gunthorpe wrote:
> On Mon, Jun 05, 2023 at 10:11:52PM -0700, Hugh Dickins wrote:
>
> > "deposited" pagetable fragments, over in arch/s390/mm/pgtable.c: use
> > the first two longs of the page table itself for threading the list.
>
> It is not RCU anymore if it writes to
Michael is merging KVM PPC patches via the powerpc tree and KVM topic
branches. He doesn't necessarily have time to be across all of KVM so
is reluctant to call himself maintainer, but for the mechanics of how
patches flow upstream, it is maintained and does make sense to have
some contact people
Hi,
On Wed, Jun 7, 2023 at 8:25 AM Petr Mladek wrote:
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 13c6e596cf9e..57f15babe188 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -404,10 +404,9 @@ config HAVE_NMI_WATCHDOG
> depends on HAVE_NMI
> bool
> help
> -
Hi Aneesh,
kernel test robot noticed the following build warnings:
[auto build test WARNING on powerpc/next]
[also build test WARNING on powerpc/fixes akpm-mm/mm-everything linus/master
v6.4-rc5]
[cannot apply to nvdimm/libnvdimm-for-next tip/x86/core nvdimm/dax-misc
next-20230607]
[If your
Hi,
On Wed, Jun 7, 2023 at 8:26 AM Petr Mladek wrote:
>
> The HAVE_ prefix means that the code could be enabled. Add another
> variable for HAVE_HARDLOCKUP_DETECTOR_SPARC64 without this prefix.
> It will be set when it should be built. It will make it compatible
> with the other hardlockup
Hi,
On Wed, Jun 7, 2023 at 8:25 AM Petr Mladek wrote:
>
> arch_touch_nmi_watchdog() needs a different implementation for various
> hardlockup detector implementations. And it does nothing when
> any hardlockup detector is not build at all.
s/build/built/
> arch_touch_nmi_watchdog() has to be
Hi,
On Wed, Jun 7, 2023 at 8:25 AM Petr Mladek wrote:
>
> Hi,
>
> this patchset is supposed to replace the last patch in the patchset cleaning
> up after introducing the buddy detector, see
> https://lore.kernel.org/r/20230526184139.10.I821fe7609e57608913fe05abd8f35b343e7a9aae@changeid
I will
Hi,
On Wed, Jun 7, 2023 at 8:26 AM Petr Mladek wrote:
>
> @@ -1102,6 +1103,14 @@ config HARDLOCKUP_DETECTOR_BUDDY
> depends on !HAVE_HARDLOCKUP_DETECTOR_ARCH
> select HARDLOCKUP_DETECTOR_COUNTS_HRTIMER
>
> +config HARDLOCKUP_DETECTOR_ARCH
> + bool
> + depends on
Hi,
On Wed, Jun 7, 2023 at 8:25 AM Petr Mladek wrote:
>
> The configuration variable HAVE_NMI_WATCHDOG has a generic name but
> it is selected only for SPARC64.
>
> It should _not_ be used in general because it is not integrated with
> the other hardlockup detectors. Namely, it does not support
Hi,
On Wed, Jun 7, 2023 at 8:25 AM Petr Mladek wrote:
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 422f0ffa269e..13c6e596cf9e 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -404,17 +404,27 @@ config HAVE_NMI_WATCHDOG
> depends on HAVE_NMI
> bool
> help
> -
Hi,
On Wed, Jun 7, 2023 at 8:25 AM Petr Mladek wrote:
>
> There are four possible variants of hardlockup detectors:
>
> + buddy: available when SMP is set.
>
> + perf: available when HAVE_HARDLOCKUP_DETECTOR_PERF is set.
>
> + arch-specific: available when HAVE_HARDLOCKUP_DETECTOR_ARCH is
From: Robert Richter
In Restricted CXL Device (RCD) mode a CXL device is exposed as an
RCiEP, but CXL downstream and upstream ports are not enumerated and
not visible in the PCIe hierarchy. [1] Protocol and link errors from
these non-enumerated ports are signaled as internal AER errors, either
Christophe Leroy wrote:
Le 23/05/2023 à 11:31, Naveen N Rao a écrit :
Christophe Leroy wrote:
Ok, I simplified this further, and this is as close to the previous
fast path as we can get (applies atop the original RFC). The only
difference left is the ftrace_rec iterator.
That's not
.ftrace.tramp section is not used for any purpose. This code was added
all the way back in the original commit introducing support for dynamic
ftrace on ppc64 modules. Remove it.
Signed-off-by: Naveen N Rao
---
arch/powerpc/include/asm/module.h | 4
1 file changed, 4 deletions(-)
diff
Now that we validate the ftrace location during initialization in
ftrace_init_nop(), we can simplify ftrace_make_nop() to patch-in the nop
without worrying about the instructions surrounding the ftrace location.
Note that we continue to ensure that we have a bl to
ftrace_[regs_]caller at the
Currently, we validate instructions around the ftrace location every
time we have to enable/disable ftrace. Introduce ftrace_init_nop() to
instead perform all the validation during ftrace initialization. This
allows us to simply patch the necessary instructions during
enabling/disabling ftrace.
Commit 67361cf8071286 ("powerpc/ftrace: Handle large kernel configs")
added ftrace support for ppc64 kernel images with a text section larger
than 32MB. The patch did two things:
1. Add stubs at the end of .text to branch into ftrace_[regs_]caller for
functions that were out of branch range.
2.
Split up ftrace_modify_code() into a few helpers for future use. Also
update error messages accordingly.
Signed-off-by: Naveen N Rao
---
arch/powerpc/kernel/trace/ftrace.c | 51 +-
1 file changed, 29 insertions(+), 22 deletions(-)
diff --git
ftrace_low.S has just the _mcount stub and return_to_handler(). Merge
this back into ftrace_mprofile.S and ftrace_64_pg.S to keep all ftrace
code together, and to allow those to evolve independently.
ftrace_mprofile.S is also not an entirely accurate name since this also
holds ppc32 code. This
Commit 67361cf8071286 ("powerpc/ftrace: Handle large kernel configs")
added ftrace support for ppc64 kernel images with a text section larger
than 32MB. The approach itself isn't specific to ppc64, so extend the
same to also work on ppc32.
While at it, reduce the space reserved for the stub from
Instead of keying off DYNAMIC_FTRACE_WITH_REGS, use FTRACE_REGS_ADDR to
identify the proper ftrace trampoline address to use.
Signed-off-by: Naveen N Rao
---
arch/powerpc/kernel/trace/ftrace.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git
Since we now support DYNAMIC_FTRACE_WITH_ARGS across ppc32 and ppc64
ELFv2, we can simplify function_graph tracer support code in ftrace.c
Signed-off-by: Naveen N Rao
---
arch/powerpc/kernel/trace/ftrace.c | 64 --
1 file changed, 7 insertions(+), 57 deletions(-)
ELFv1 support is deprecated and on the way out. Pre -mprofile-kernel
ftrace support (-pg only) is very limited and is retained primarily for
clang builds. It won't be necessary once clang lands support for
-fpatchable-function-entry.
Copy the existing ftrace code supporting these into
GCC v13.1 updated support for -fpatchable-function-entry on ppc64le to
emit nops after the local entry point, rather than before it. This
allows us to use this in the kernel for ftrace purposes. A new script is
added under arch/powerpc/tools/ to help detect if nops are emitted after
the function
Implement ftrace_replace_code() to consolidate logic from the different
ftrace patching routines: ftrace_make_nop(), ftrace_make_call() and
ftrace_modify_call(). Note that ftrace_make_call() is still required
primarily to handle patching modules during their load time. The other
two routines
ftrace_create_branch_inst() is clearer about its intent than
ftrace_call_replace().
Signed-off-by: Naveen N Rao
---
arch/powerpc/kernel/trace/ftrace.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/kernel/trace/ftrace.c
Now that we validate the ftrace location during initialization in
ftrace_init_nop(), we can simplify ftrace_modify_call() to patch-in the
updated branch instruction without worrying about the instructions
surrounding the ftrace location. Note that we continue to ensure we
have the expected branch
Now that we validate the ftrace location during initialization in
ftrace_init_nop(), we can simplify ftrace_make_call() to replace the nop
without worrying about the instructions surrounding the ftrace location.
Note that we continue to ensure that we have a nop at the ftrace
location before
This is a follow-on RFC to the patch I previously posted here:
http://lore.kernel.org/20230519192600.2593506-1-nav...@kernel.org
Since then, I have split up the patches, picked up a few more changes
and given this more testing. More details in the individual patches.
- Naveen
Naveen N Rao
On Wed Jun 7, 2023 at 3:28 PM EEST, Nayna wrote:
>
> On 6/6/23 16:51, Jarkko Sakkinen wrote:
> > On Tue Jun 6, 2023 at 8:26 PM EEST, Nayna Jain wrote:
> >> On PowerVM guest, variable data is prefixed with 8 bytes of timestamp.
> >> Extract ESL by stripping off the timestamp before passing to ESL
The HAVE_ prefix means that the code could be enabled. Add another
variable for HAVE_HARDLOCKUP_DETECTOR_ARCH without this prefix.
It will be set when it should be built. It will make it compatible
with the other hardlockup detectors.
The change allows to clean up dependencies of PPC_WATCHDOG
and
The HAVE_ prefix means that the code could be enabled. Add another
variable for HAVE_HARDLOCKUP_DETECTOR_SPARC64 without this prefix.
It will be set when it should be built. It will make it compatible
with the other hardlockup detectors.
Before, it is far from obvious that the SPARC64 variant is
The configuration variable HAVE_NMI_WATCHDOG has a generic name but
it is selected only for SPARC64.
It should _not_ be used in general because it is not integrated with
the other hardlockup detectors. Namely, it does not support the hardlockup
specific command line parameters and systcl
HAVE_NMI_WATCHDOG is always enabled when SPARC64 is enabled. The sparc64
implementation is special. It does not support the generic hardlockup
related Kconfig values, command line parameters, and sysctl interface.
Instead it is enabled/disabled by the top-level watchdog interface
that is common
arch_touch_nmi_watchdog() needs a different implementation for various
hardlockup detector implementations. And it does nothing when
any hardlockup detector is not build at all.
arch_touch_nmi_watchdog() has to be declared in linux/nmi.h. It is done
directly in this header file for the perf and
There are four possible variants of hardlockup detectors:
+ buddy: available when SMP is set.
+ perf: available when HAVE_HARDLOCKUP_DETECTOR_PERF is set.
+ arch-specific: available when HAVE_HARDLOCKUP_DETECTOR_ARCH is set.
+ sparc64 special variant: available when HAVE_NMI_WATCHDOG
There are four possible variants of hardlockup detectors:
+ buddy: available when SMP is set.
+ perf: available when HAVE_HARDLOCKUP_DETECTOR_PERF is set.
+ arch-specific: available when HAVE_HARDLOCKUP_DETECTOR_ARCH is set.
+ sparc64 special variant: available when HAVE_NMI_WATCHDOG
Hi,
this patchset is supposed to replace the last patch in the patchset cleaning
up after introducing the buddy detector, see
https://lore.kernel.org/r/20230526184139.10.I821fe7609e57608913fe05abd8f35b343e7a9aae@changeid
There are four possible variants of hardlockup detectors:
+ buddy:
Simplify powernv memory_block_size call back by directly using 1G value
instead of using radix_mem_block_size. Also, remove the variable and use
memory_block_size_bytes() in the kernel mapping function. This gets called
in radix__early_init_mmu() which is called after probe_machine is called
and
Certain devices can possess non-standard memory capacities, not constrained
to multiples of 1GB. Provide a kernel parameter so that we can map the
device memory completely on memory hotplug.
Restrict memory_block_size value to a power of 2 value similar to LMB size.
The memory block size should
On Tue, Jun 06, 2023 at 06:28:26PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and
On Tue, Jun 06, 2023 at 06:28:29PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and
Hey,
On Tue, 6 Jun 2023, Umesh Kalappa via Gcc wrote:
> Question is : Why does GCC choose to use GPR's here and have any
> reference to support this decision ?
You explicitely used -m32 ppc, so
https://www.polyomino.org.uk/publications/2011/Power-Arch-32-bit-ABI-supp-1.0-Unified.pdf
On 6/6/23 16:51, Jarkko Sakkinen wrote:
On Tue Jun 6, 2023 at 8:26 PM EEST, Nayna Jain wrote:
On PowerVM guest, variable data is prefixed with 8 bytes of timestamp.
Extract ESL by stripping off the timestamp before passing to ESL parser.
Cc: sta...@vger.kenrnel.org # v6.3
?
Aah yes.
> On 07-Jun-2023, at 3:40 PM, Nicholas Piggin wrote:
>
> The refcount on mm is dropped before the coprocessor is detached.
>
> Reported-by: Sachin Sant
> Fixes: 7bc6f71bdff5f ("powerpc/vas: Define and use common vas_window struct")
> Fixes: b22f2d88e435c ("powerpc/pseries/vas: Integrate API
The refcount on mm is dropped before the coprocessor is detached.
Reported-by: Sachin Sant
Fixes: 7bc6f71bdff5f ("powerpc/vas: Define and use common vas_window struct")
Fixes: b22f2d88e435c ("powerpc/pseries/vas: Integrate API with open/close
windows")
Signed-off-by: Nicholas Piggin
---
How's
While running powerpc selftests on a Power10 LPAR, following warning
is seen:
[ 43.878929] MCE: CPU25: PID: 6025 Comm: inject-ra-err NIP: [1e48]
[ 43.878933] MCE: CPU25: Initiator CPU
[ 43.878935] MCE: CPU25: Unknown
[ 43.906866] [ cut here ]
[
On Mon Jun 5, 2023 at 4:48 PM AEST, Jordan Niethe wrote:
> A series of hcalls have been added to the PAPR which allow a regular
> guest partition to create and manage guest partitions of its own. Add
> support to KVM to utilize these hcalls to enable running nested guests.
>
> Overview of the new
On Mon Jun 5, 2023 at 4:48 PM AEST, Jordan Niethe wrote:
> The new PAPR nested guest API introduces the concept of a Guest State
> Buffer for communication about L2 guests between L1 and L0 hosts.
>
> In the new API, the L0 manages the L2 on behalf of the L1. This means
> that if the L1 needs to
> Reported-by: Sachin Sant
> Link:
> https://lore.kernel.org/linuxppc-dev/87a5xcgopc.fsf@mail.lhotse/T/#m105488939d0cd9f980978ed2fdeeb89bf731e673
> Fixes: a665eec0a22e1 ("powerpc/64s/radix: Fix mm_cpumask trimming race vs
> kthread_use_mm")
> Signed-off-by: Nicholas Piggin
> ---
> This
On Mon Jun 5, 2023 at 4:48 PM AEST, Jordan Niethe wrote:
> Add wrappers for fpr registers to prepare for supporting PAPR nested
> guests.
>
> Signed-off-by: Jordan Niethe
> ---
> arch/powerpc/include/asm/kvm_book3s.h | 31 +++
> arch/powerpc/include/asm/kvm_booke.h | 10
On Mon Jun 5, 2023 at 4:48 PM AEST, Jordan Niethe wrote:
> There are already some getter and setter functions used for accessing
> vcpu register state, e.g. kvmppc_get_pc(). There are also more
> complicated examples that are generated by macros like
> kvmppc_get_sprg0() which are generated by the
60 matches
Mail list logo
