qiurui/Centos-kernel-stream-9
1
0
Fork 0
mirror of https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9.git synced 2026-09-09 00:08:12 +08:00
Code Issues Packages Projects Releases Wiki Activity
1,198,313 Commits 5 Branches 2,299 Tags
main
Commit Graph
100 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
Mamatha Inamdar 0c9fe90b0d ppc/fadump: invoke kmsg_dump in fadump panic path 
JIRA: https://issues.redhat.com/browse/RHEL-211104

Conflicts: Fixed compilation issue due to missing definition of kmsg_dump_desc

commit 6ed8332639853b77329594a241eb99fc36d591a2
Author: Shivang Upadhyay <shivangu@linux.ibm.com>
Date:   Sun Apr 12 17:00:57 2026 +0530

    ppc/fadump: invoke kmsg_dump in fadump panic path

    fadump is registered in panic_notifier_list and gets triggered before
    kmsg_dump_desc() in the panic path. As a result, kmsg_dumpers such as
    pstore are not executed during fadump crashes.

    This is problematic because pstore provides a critical fallback mechanism
    for crash analysis. When fadump fails to successfully reboot the system
    or capture a dump, pstore logs may be the only available information from
    the crashed kernel. Without invoking kmsg_dump_desc() in the fadump path,
    we lose this valuable diagnostic data.

    Invoke kmsg_dump_desc() from the fadump panic handler, but only when
    fadump is actually registered (checked via should_fadump_crash()). This
    ensures kmsg_dumpers are called without duplicating the call that occurs
    later in panic() when fadump is not active.

    The call is placed before crash_fadump() to ensure logs are captured
    before the system attempts to trigger the firmware-assisted dump.

    Reported-by: Shirisha G <shirisha@linux.ibm.com>
    Suggested-by: Sourabh Jain <sourabhjain@linux.ibm.com>
    Signed-off-by: Shivang Upadhyay <shivangu@linux.ibm.com>
    Tested-by: Shirisha G <shirisha@linux.ibm.com>
    Reviewed-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
    Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20260412113057.46090-1-shivangu@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-07-23 03:35:22 -04:00
Mamatha Inamdar 6c2472a8ad powerpc/powernv/iommu: iommu incorrectly bypass DMA APIs 
JIRA: https://issues.redhat.com/browse/RHEL-190412

commit 328335a79487ec38d6b0e1aa807785b0f75e594d
Author: Gaurav Batra <gbatra@linux.ibm.com>
Date:   Tue Mar 31 17:30:22 2026 -0500

    powerpc/powernv/iommu: iommu incorrectly bypass DMA APIs

    In a PowerNV environment, for devices that supports DMA mask less than
    64 bit but larger than 32 bits, iommu is incorrectly bypassing DMA
    APIs while allocating and mapping buffers for DMA operations.

    Devices are failing with ENOMEN during probe with the following messages

    amdgpu 0000:01:00.0: [drm] Detected VRAM RAM=4096M, BAR=4096M
    amdgpu 0000:01:00.0: [drm] RAM width 128bits GDDR5
    amdgpu 0000:01:00.0: iommu: 64-bit OK but direct DMA is limited by 0
    amdgpu 0000:01:00.0: dma_iommu_get_required_mask: returning bypass mask 0xfffffffffffffff
    amdgpu 0000:01:00.0:  4096M of VRAM memory ready
    amdgpu 0000:01:00.0:  32570M of GTT memory ready.
    amdgpu 0000:01:00.0: (-12) failed to allocate kernel bo
    amdgpu 0000:01:00.0: [drm] Debug VRAM access will use slowpath MM access
    amdgpu 0000:01:00.0: [drm] GART: num cpu pages 4096, num gpu pages 65536
    amdgpu 0000:01:00.0: [drm] PCIE GART of 256M enabled (table at 0x000000F4FFF80000).
    amdgpu 0000:01:00.0: (-12) failed to allocate kernel bo
    amdgpu 0000:01:00.0: (-12) create WB bo failed
    amdgpu 0000:01:00.0: amdgpu_device_wb_init failed -12
    amdgpu 0000:01:00.0: amdgpu_device_ip_init failed
    amdgpu 0000:01:00.0: Fatal error during GPU init
    amdgpu 0000:01:00.0: finishing device.
    amdgpu 0000:01:00.0: probe with driver amdgpu failed with error -12
    amdgpu 0000:01:00.0:  ttm finalized

    Fixes: 1471c517cf7d ("powerpc/iommu: bypass DMA APIs for coherent allocations for pre-mapped memory")
    Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
    Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
    Reported-by: Dan Horák <dan@danny.cz>
    Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5039
    Tested-by: Dan Horak <dan@danny.cz>
    Closes: https://lore.kernel.org/linuxppc-dev/20260313142351.609bc4c3efe1184f64ca5f44@danny.cz/
    Signed-off-by: Gaurav Batra <gbatra@linux.ibm.com>
    Closes: https://lore.kernel.org/linuxppc-dev/20260313142351.609bc4c3efe1184f64ca5f44@danny.cz/
    [Maddy: Fixed tags]
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20260331223022.47488-1-gbatra@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-07-21 04:52:30 -04:00
Mamatha Inamdar a1adaebba9 powerpc/perf: Update check for PERF_SAMPLE_DATA_SRC marked events 
JIRA: https://issues.redhat.com/browse/RHEL-53366

commit 131717e656b379addb95af2dcb2d90c723bae24b
Author: Shivani Nittor <shivani@linux.ibm.com>
Date:   Tue Apr 21 20:36:28 2026 +0530

    powerpc/perf: Update check for PERF_SAMPLE_DATA_SRC marked events

    The core-book3s PMU sampling code validates the SIER TYPE field
    when PERF_SAMPLE_DATA_SRC is requested. The SIER TYPE field
    indicates the instruction type and is only valid for
    random sampling (marked events). To handle cases observed where
    SIER TYPE could be zero even for marked events,validation was
    added to drop such samples and increment event->lost_samples.

    However, this validation was applied to all samples,
    including continuous sampling. In continuous sampling mode,
    the PMU does not set the SIER TYPE field, so it remains zero.
    As a result, valid continuous samples were incorrectly
    treated as invalid and dropped. Fixed this by gating the
    SIER TYPE validation with mark_event, so the check runs only
    for marked (random) events. Continuous samples now skip this
    check and are recorded normally in the final data recording path.

    Fixes: 2ffb26afa642 ("arch/powerpc/perf: Check the instruction type before creating sample with perf_mem_data_src")
    Signed-off-by: Shivani Nittor <shivani@linux.ibm.com>
    Reviewed-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com>
    Reviewed-by: Athira Rajeev <atrajeev@linux.ibm.com>
    [Maddy: Fixed reviewed-by tag]
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20260421150628.96500-1-shivani@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-07-07 01:06:45 -04:00
Mamatha Inamdar f03eae644d powerpc tools perf: Initialize error code in auxtrace_record_init function 
JIRA: https://issues.redhat.com/browse/RHEL-53366

commit 789d22d77879eabb042627f6627cdb62787bc142
Author: Athira Rajeev <atrajeev@linux.ibm.com>
Date:   Mon May 4 20:43:20 2026 +0530

    powerpc tools perf: Initialize error code in auxtrace_record_init function

    perf trace record fails some cases in powerpc

     # perf test "perf trace record and replay"
     128: perf trace record and replay                                    : FAILED!

      # perf trace record sleep 1
      # echo $?
        32

    This is happening because of non-zero err value from
    auxtrace_record__init() function.

     static int record__auxtrace_init(struct record *rec)
     {
            int err;

            if ((rec->opts.auxtrace_snapshot_opts || rec->opts.auxtrace_sample_opts)
                && record__threads_enabled(rec)) {
                    pr_err("AUX area tracing options are not available in parallel streaming mode.\n");
                    return -EINVAL;
            }

            if (!rec->itr) {
                    rec->itr = auxtrace_record__init(rec->evlist, &err);
                    if (err)
                            return err;
            }

    Here "int err" is not initialised. The code expects "err" to be set from
    auxtrace_record__init() function.

    Update auxtrace_record__init() in arch/powerpc/util/auxtrace.c to clear
    err value in the beginning.

    - Clear err value in beginning of function. Any fail later will
    set appropriate return code to err.

    - Even if we haven't found any event for auxtrace, perf record
    should continue for other events. NULL return
    will indicate that there is no auxtrace record initialized.

    - Not having "err" set here will affect monitoring of other events
    also because perf record will fail seeing random value in err.

    Set err to -EINVAL before invoking auxtrace_record__init() in
    builtin-record.c

    With the fix,

      # perf trace record sleep 1
      [ perf record: Woken up 2 times to write data ]
      [ perf record: Captured and wrote 0.033 MB perf.data (228 samples) ]

    Fixes: 1dbfaf94cf66ec4b ("perf powerpc: Add basic CONFIG_AUXTRACE support for VPA pmu on powerpc")
    Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Athira Rajeev <atrajeev@linux.ibm.com>
    Acked-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Athira Rajeev <atrajeev@linux.ibm.com>
    Cc: Hari Bathini <hbathini@linux.vnet.ibm.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: linuxppc-dev@lists.ozlabs.org
    Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
    Cc: Michael Petlan <mpetlan@redhat.com>
    Cc: Shivani Nittor <shivani@linux.ibm.com>
    Cc: Tanushree Shah <tanushree.shah@ibm.com>
    Cc: Tejas Manhas <tejas.manhas1@ibm.com>
    Cc: Thomas Richter <tmricht@linux.ibm.com>
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-07-07 01:06:42 -04:00
Mamatha Inamdar d7f6e93a11 perf script: Enable to present DTL entries 
JIRA: https://issues.redhat.com/browse/RHEL-53366

commit a0dfb18f7d20ae0b7b5f513fd65882af105bb771
Author: Athira Rajeev <atrajeev@linux.ibm.com>
Date:   Tue Sep 16 10:55:36 2025 +0530

    perf script: Enable to present DTL entries

    The process_event() function in "builtin-script.c" invokes
    perf_sample__fprintf_synth() for displaying PERF_TYPE_SYNTH
    type events.

       if (attr->type == PERF_TYPE_SYNTH && PRINT_FIELD(SYNTH))
            perf_sample__fprintf_synth(sample, evsel, fp);

    perf_sample__fprintf_synth() process the sample depending on the value
    in evsel->core.attr.config. Introduce perf_sample__fprintf_synth_vpadtl()
    and invoke this for PERF_SYNTH_POWERPC_VPA_DTL

    Sample output:

       ./perf record -a -e sched:*,vpa_dtl/dtl_all/ -c 1000000000 sleep 1
       [ perf record: Woken up 1 times to write data ]
       [ perf record: Captured and wrote 0.300 MB perf.data ]

       ./perf script
                perf   13322 [002]   233.835807:                     sched:sched_switch: perf:13322 [120] R ==> migration/2:27 [0]
         migration/2      27 [002]   233.835811:               sched:sched_migrate_task: comm=perf pid=13322 prio=120 orig_cpu=2 dest_cpu=3
         migration/2      27 [002]   233.835818:               sched:sched_stat_runtime: comm=migration/2 pid=27 runtime=9214 [ns]
         migration/2      27 [002]   233.835819:                     sched:sched_switch: migration/2:27 [0] S ==> swapper/2:0 [120]
             swapper       0 [002]   233.835822:                                vpa-dtl: timebase: 338954486062657 dispatch_reason:decrementer_interrupt, preempt_reason:H_CEDE, enqueue_to_dispatch_time:435,                      ready_to_enqueue_time:0, waiting_to_ready_time:34775058, processor_id: 202 c0000000000f8094 plpar_hcall_norets_notrace+0x18 ([kernel.kallsyms])
             swapper       0 [001]   233.835886:                                vpa-dtl: timebase: 338954486095398 dispatch_reason:priv_doorbell, preempt_reason:H_CEDE, enqueue_to_dispatch_time:542,                      ready_to_enqueue_time:0, waiting_to_ready_time:1245360, processor_id: 201 c0000000000f8094 plpar_hcall_norets_notrace+0x18 ([kernel.kallsyms])

    Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Athira Rajeev <atrajeev@linux.ibm.com>
    Tested-by: Tejas Manhas <tejas05@linux.ibm.com>
    Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
    Cc: Aboorva Devarajan <aboorvad@linux.ibm.com>
    Cc: Aditya Bodkhe <Aditya.Bodkhe1@ibm.com>
    Cc: Hari Bathini <hbathini@linux.vnet.ibm.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Shrikanth Hegde <sshegde@linux.ibm.com>
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-07-07 01:06:37 -04:00
Mamatha Inamdar c9fc7dfad5 perf powerpc: Process the DTL entries in queue and deliver samples 
JIRA: https://issues.redhat.com/browse/RHEL-53366

commit 8644834a482a94e7da391a09af4d7f3672a5a400
Author: Athira Rajeev <atrajeev@linux.ibm.com>
Date:   Tue Sep 16 10:55:35 2025 +0530

    perf powerpc: Process the DTL entries in queue and deliver samples

    Create samples from DTL entries for displaying in 'perf report'
    and 'perf script'.

    When the different PERF_RECORD_XX records are processed from perf
    session, powerpc_vpadtl_process_event() will be invoked.

    For each of the PERF_RECORD_XX record, compare the timestamp of perf
    record with timestamp of top element in the auxtrace heap.

    Process the auxtrace queue if the timestamp of element from heap is
    lower than timestamp from entry in perf record.

    Sometimes it could happen that one buffer is only partially processed.

    if the timestamp of occurrence of another event is more than currently
    processed element in the queue, it will move on to next perf record.

    So keep track of position of buffer to continue processing next time.

    Update the timestamp of the auxtrace heap with the timestamp of last
    processed entry from the auxtrace buffer.

    Generate perf sample for each entry in the dispatch trace log.

    Fill in the sample details:
    - sample ip is picked from srr0 field of dtl_entry
    - sample cpu is picked from processor_id of dtl_entry
    - sample id is from sample_id of powerpc_vpadtl
    - cpumode is set to PERF_RECORD_MISC_KERNEL
    - Additionally save the details in raw_data of sample.

    This is to print the relevant fields in perf_sample__fprintf_synth()
    when called from builtin-script

    The sample is processed by calling perf_session__deliver_synth_event()
    so that it gets included in perf report.

    Sample Output:

      ./perf record -a -e sched:*,vpa_dtl/dtl_all/ -c 1000000000 sleep 1
      [ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.300 MB perf.data ]

      ./perf report

      # Samples: 321  of event 'vpa-dtl'
      # Event count (approx.): 321
      #
      # Children      Self  Command  Shared Object      Symbol
      # ........  ........  .......  .................  ..............................
      #
         100.00%   100.00%  swapper  [kernel.kallsyms]  [k] plpar_hcall_norets_notrace

    Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Athira Rajeev <atrajeev@linux.ibm.com>
    Tested-by: Tejas Manhas <tejas05@linux.ibm.com>
    Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
    Cc: Aboorva Devarajan <aboorvad@linux.ibm.com>
    Cc: Aditya Bodkhe <Aditya.Bodkhe1@ibm.com>
    Cc: Hari Bathini <hbathini@linux.vnet.ibm.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Shrikanth Hegde <sshegde@linux.ibm.com>
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-07-07 01:06:31 -04:00
Mamatha Inamdar a18ca1c992 perf powerpc: Allocate and setup aux buffer queue to help co-relate with other events across CPU's 
JIRA: https://issues.redhat.com/browse/RHEL-53366

commit cd1c3b730a2a0455b405d7ecbd02a63b51cdc04b
Author: Athira Rajeev <atrajeev@linux.ibm.com>
Date:   Tue Sep 16 10:55:34 2025 +0530

    perf powerpc: Allocate and setup aux buffer queue to help co-relate with other events across CPU's

    When the Dispatch Trace Log data is collected along with other events
    like sched tracepoint events, it needs to be correlated and present
    interleaved along with these events.

    Perf events can be collected parallely across the CPUs. Hence it needs
    to be ensured events/dtl entries are processed in timestamp order.

    An auxtrace_queue is created for each CPU.

    Data within each queue is in increasing order of timestamp. Each
    auxtrace queue has a array/list of auxtrace buffers.

    When processing the auxtrace buffer, the data is mmapp'ed.

    All auxtrace queues is maintained in auxtrace heap.

    Each queue has a queue number and a timestamp.

    The queues are sorted/added to head based on the time stamp.

    So always the lowest timestamp (entries to be processed first) is on top
    of the heap.

    The auxtrace queue needs to be allocated and heap needs to be populated
    in the sorted order of timestamp.

    The queue needs to be filled with data only once via
    powerpc_vpadtl__update_queues() function.

    powerpc_vpadtl__setup_queues() iterates through all the entries to
    allocate and setup the auxtrace queue.

    To add to auxtrace heap, it is required to fetch the timebase of first
    entry for each of the queue.

    The first entry in the queue for VPA DTL PMU has the boot timebase,
    frequency details which are needed to get timestamp which is required to
    correlate with other events.

    The very next entry is the actual trace data that provides timestamp for
    occurrence of DTL event.

    Formula used to get the timestamp from dtl entry is:

    ((timbase from DTL entry - boot time) / frequency) * 1000000000

    powerpc_vpadtl_decode() adds the boot time and frequency as part of
    powerpc_vpadtl_queue structure so that it can be reused.

    Each of the dtl_entry is of 48 bytes size. Sometimes it could happen
    that one buffer is only partially processed (if the timestamp of
    occurrence of another event is more than currently processed element in
    queue, it will move on to next event).

    In order to keep track of position of buffer, additional fields is added
    to powerpc_vpadtl_queue structure.

    Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Athira Rajeev <atrajeev@linux.ibm.com>
    Tested-by: Tejas Manhas <tejas05@linux.ibm.com>
    Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
    Cc: Aboorva Devarajan <aboorvad@linux.ibm.com>
    Cc: Aditya Bodkhe <Aditya.Bodkhe1@ibm.com>
    Cc: Hari Bathini <hbathini@linux.vnet.ibm.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Shrikanth Hegde <sshegde@linux.ibm.com>
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-07-07 01:06:27 -04:00
Mamatha Inamdar a5e5eb5fd4 perf powerpc: Add event name as vpa-dtl of PERF_TYPE_SYNTH type to present DTL samples 
JIRA: https://issues.redhat.com/browse/RHEL-53366

commit 71feffa9c08675f65192a6b0d6ce168c620ba49a
Author: Athira Rajeev <atrajeev@linux.ibm.com>
Date:   Tue Sep 16 10:55:33 2025 +0530

    perf powerpc: Add event name as vpa-dtl of PERF_TYPE_SYNTH type to present DTL samples

    Dispatch Trace Log details are captured as-is in PERF_RECORD_AUXTRACE
    records.

    To present dtl entries as samples, create an event with name as
    "vpa-dtl" and type PERF_TYPE_SYNTH.

    Add perf_synth_id, "PERF_SYNTH_POWERPC_VPA_DTL" as config value for the
    event.

    Create a sample id to be a fixed offset from evsel id.

    To present the relevant fields from the "struct dtl_entry", prepare the
    entries as events of type PERF_TYPE_SYNTH.

    By defining as PERF_TYPE_SYNTH type, samples can be printed as part of
    perf_sample__fprintf_synth in builtin-script.c

    From powerpc_vpadtl_process_auxtrace_info(), invoke
    auxtrace_queues__process_index() function which will queue the auxtrace
    buffers by invoke auxtrace_queues__add_event().

    Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Athira Rajeev <atrajeev@linux.ibm.com>
    Tested-by: Tejas Manhas <tejas05@linux.ibm.com>
    Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
    Cc: Aboorva Devarajan <aboorvad@linux.ibm.com>
    Cc: Aditya Bodkhe <Aditya.Bodkhe1@ibm.com>
    Cc: Hari Bathini <hbathini@linux.vnet.ibm.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Shrikanth Hegde <sshegde@linux.ibm.com>
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-07-07 01:06:23 -04:00
Mamatha Inamdar e497fc179a perf powerpc: Process auxtrace events and display in 'perf report -D' 
JIRA: https://issues.redhat.com/browse/RHEL-53366

commit c4bbd4ec2e50a9ed7cc379556223977147c59278
Author: Athira Rajeev <atrajeev@linux.ibm.com>
Date:   Tue Sep 16 10:55:32 2025 +0530

    perf powerpc: Process auxtrace events and display in 'perf report -D'

    Add VPA DTL PMU auxtrace process function for "perf report -D".
    The auxtrace event processing functions are defined in file
    "util/powerpc-vpadtl.c".

    Data structures used includes "struct powerpc_vpadtl_queue", "struct
    powerpc_vpadtl" to store the auxtrace buffers in queue. Different
    PERF_RECORD_XXX are generated during recording.

    PERF_RECORD_AUXTRACE_INFO is processed first since it is of type
    perf_user_event_type and perf session event delivers
    perf_session__process_user_event() first.

    Define function powerpc_vpadtl_process_auxtrace_info() to handle the
    processing of PERF_RECORD_AUXTRACE_INFO records.

    In this function, initialize the aux buffer queues using
    auxtrace_queues__init().

    Setup the required infrastructure for aux data processing.

    The data is collected per CPU and auxtrace_queue is created for each
    CPU.

    Define powerpc_vpadtl_process_event() function to process
    PERF_RECORD_AUXTRACE records.

    In this, add the event to queue using auxtrace_queues__add_event() and
    process the buffer in powerpc_vpadtl_dump_event().

    The first entry in the buffer with timebase as zero has boot timebase
    and frequency.

    Remaining data is of format for "struct powerpc_vpadtl_entry".

    Define the translation for dispatch_reasons and preempt_reasons, report
    this when dump trace is invoked via powerpc_vpadtl_dump()

    Sample output:

       ./perf record -a -e sched:*,vpa_dtl/dtl_all/ -c 1000000000 sleep 1
       [ perf record: Woken up 1 times to write data ]
       [ perf record: Captured and wrote 0.300 MB perf.data ]

       ./perf report -D

       0 0 0x39b10 [0x30]: PERF_RECORD_AUXTRACE size: 0x690  offset: 0  ref: 0  idx: 0  tid: -1  cpu: 0
       .
       . ... VPA DTL PMU data: size 1680 bytes, entries is 35
       .  00000000: boot_tb: 21349649546353231, tb_freq: 512000000
       .  00000030: dispatch_reason:decrementer interrupt, preempt_reason:H_CEDE, enqueue_to_dispatch_time:7064, ready_to_enqueue_time:187, waiting_to_ready_time:6611773
       .  00000060: dispatch_reason:priv doorbell, preempt_reason:H_CEDE, enqueue_to_dispatch_time:146, ready_to_enqueue_time:0, waiting_to_ready_time:15359437
       .  00000090: dispatch_reason:decrementer interrupt, preempt_reason:H_CEDE, enqueue_to_dispatch_time:4868, ready_to_enqueue_time:232, waiting_to_ready_time:5100709
       .  000000c0: dispatch_reason:priv doorbell, preempt_reason:H_CEDE, enqueue_to_dispatch_time:179, ready_to_enqueue_time:0, waiting_to_ready_time:30714243
       .  000000f0: dispatch_reason:priv doorbell, preempt_reason:H_CEDE, enqueue_to_dispatch_time:197, ready_to_enqueue_time:0, waiting_to_ready_time:15350648
       .  00000120: dispatch_reason:priv doorbell, preempt_reason:H_CEDE, enqueue_to_dispatch_time:213, ready_to_enqueue_time:0, waiting_to_ready_time:15353446
       .  00000150: dispatch_reason:priv doorbell, preempt_reason:H_CEDE, enqueue_to_dispatch_time:212, ready_to_enqueue_time:0, waiting_to_ready_time:15355126
       .  00000180: dispatch_reason:decrementer interrupt, preempt_reason:H_CEDE, enqueue_to_dispatch_time:6368, ready_to_enqueue_time:164, waiting_to_ready_time:5104665

    Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Athira Rajeev <atrajeev@linux.ibm.com>
    Tested-by: Tejas Manhas <tejas05@linux.ibm.com>
    Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
    Cc: Aboorva Devarajan <aboorvad@linux.ibm.com>
    Cc: Aditya Bodkhe <Aditya.Bodkhe1@ibm.com>
    Cc: Hari Bathini <hbathini@linux.vnet.ibm.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Shrikanth Hegde <sshegde@linux.ibm.com>
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-07-07 01:06:19 -04:00
Mamatha Inamdar a06fbe35f7 perf powerpc: Add basic CONFIG_AUXTRACE support for VPA pmu on powerpc 
JIRA: https://issues.redhat.com/browse/RHEL-53366

commit 1dbfaf94cf66ec4b19945aa4c76901e4af292a48
Author: Athira Rajeev <atrajeev@linux.ibm.com>
Date:   Tue Sep 16 10:55:31 2025 +0530

    perf powerpc: Add basic CONFIG_AUXTRACE support for VPA pmu on powerpc

    The powerpc PMU collecting Dispatch Trace Log (DTL) entries makes use of
    AUX support in perf infrastructure.

    The PMU driver has the functionality to collect trace entries in the aux
    buffer.

    On the tools side, this data is made available as PERF_RECORD_AUXTRACE
    records.

    This record is generated by "perf record" command.

    To enable the creation of PERF_RECORD_AUXTRACE, add functions to
    initialize auxtrace records ie "auxtrace_record__init()".

    Fill in fields for other callbacks like info_priv_size, info_fill, free,
    recording options etc.

    Define auxtrace_type as PERF_AUXTRACE_VPA_DTL.  Add header file to
    define vpa dtl pmu specific details.

    Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Athira Rajeev <atrajeev@linux.ibm.com>
    Tested-by: Tejas Manhas <tejas05@linux.ibm.com>
    Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
    Cc: Aboorva Devarajan <aboorvad@linux.ibm.com>
    Cc: Aditya Bodkhe <Aditya.Bodkhe1@ibm.com>
    Cc: Hari Bathini <hbathini@linux.vnet.ibm.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Shrikanth Hegde <sshegde@linux.ibm.com>
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-07-07 01:06:15 -04:00
Mamatha Inamdar bbba19df30 powerpc/perf/vpa-dtl: Add documentation for VPA dispatch trace log PMU 
JIRA: https://issues.redhat.com/browse/RHEL-53366

commit 4a774b39e68fac7d6c7c9cffeb6a4ea4b6dc8b41
Author: Athira Rajeev <atrajeev@linux.ibm.com>
Date:   Mon Sep 15 15:59:47 2025 +0530

    powerpc/perf/vpa-dtl: Add documentation for VPA dispatch trace log PMU

    Documentation for vpa-dtl (Virtual Processor Area - Dispatch Trace Log)
    PMU interface. And how it can be used to collect the distrace trace log
    entries in perf data, how to process/report as part of perf report/perf
    script.

    Signed-off-by: Athira Rajeev <atrajeev@linux.ibm.com>
    Tested-by: Tejas Manhas <tejas05@linux.ibm.com>
    Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250915102947.26681-8-atrajeev@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-07-07 01:06:10 -04:00
Mamatha Inamdar 3855b023ff powerpc/perf/vpa-dtl: Handle the writing of perf record when aux wake up is needed 
JIRA: https://issues.redhat.com/browse/RHEL-53366

commit b5e71cafa02d4e673639a3bd4c03d84db5dd8b8a
Author: Athira Rajeev <atrajeev@linux.ibm.com>
Date:   Mon Sep 15 15:59:46 2025 +0530

    powerpc/perf/vpa-dtl: Handle the writing of perf record when aux wake up is needed

    Handle the case when the aux buffer is going to be full and
    data needs to be written to the data file. perf_aux_output_begin()
    function checks if there is enough space depending on the values of
    aux_wakeup and aux_watermark which is part of "struct perf_buffer".
    Inorder to maintain where to write to aux buffer, add two fields
    to "struct vpa_pmu_buf". Field "threshold" to indicate total possible
    DTL entries that can be contained in aux buffer and field "full" to
    indicate anytime when buffer is full. In perf_aux_output_end, there
    is check to see if wake up is needed based on aux head value.

    In vpa_dtl_capture_aux(), check if there is enough space to contain the
    DTL data. If not, save the data for available memory and set full to true.
    Set head of private aux to zero when buffer is full so that next data
    will be copied to beginning of the buffer. The address used for copying
    to aux is "aux_copy_buf + buf->head". So once buffer is full, set head
    to zero, so that next time it will be written from start of the buffer.

    Signed-off-by: Athira Rajeev <atrajeev@linux.ibm.com>
    Tested-by: Tejas Manhas <tejas05@linux.ibm.com>
    Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250915102947.26681-7-atrajeev@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-07-07 01:06:06 -04:00
Mamatha Inamdar 4037d0145c powerpc/perf/vpa-dtl: Add support to capture DTL data in aux buffer 
JIRA: https://issues.redhat.com/browse/RHEL-53366

commit 2de8b6dd5ae72eb6fb7c756a3f2c131171fe3b8b
Author: Athira Rajeev <atrajeev@linux.ibm.com>
Date:   Mon Sep 15 15:59:45 2025 +0530

    powerpc/perf/vpa-dtl: Add support to capture DTL data in aux buffer

    vpa dtl pmu has one hrtimer added per vpa-dtl pmu thread. When the
    hrtimer expires, in the timer handler, code is added to save the DTL
    data to perf event record via vpa_dtl_capture_aux() function.
    The DTL (Dispatch Trace Log) contains information
    about dispatch/preempt, enqueue time etc. We directly copy the DTL
    buffer data as part of auxiliary buffer. Data will be written to
    disk only when the allocated buffer is full.

    By this approach, all the DTL data will be present as-is in the
    perf.data. The data will be post-processed in perf tools side when doing
    perf report/perf script and this will avoid time taken to create samples
    in the kernel space.

    To corelate each DTL entry with other events across CPU's, we need to
    map timebase from "struct dtl_entry" which phyp provides with boot
    timebase. This also needs timebase frequency. Define "struct boottb_freq"
    to save these details.

    Added changes to capture the Dispatch Trace Log details to AUX buffer
    in vpa_dtl_dump_sample_data(). Boot timebase and frequency needs to be
    saved only at once, added field to indicate this as part of
    "vpa_pmu_buf" structure.

    perf_aux_output_begin: This function is called before writing to AUX
    area. This returns the pointer to aux area private structure, ie
    "struct vpa_pmu_buf". The function obtains the output handle
    (used in perf_aux_output_end). when capture completes in
    vpa_dtl_capture_aux(), call perf_aux_output_end() to commit the recorded
    data. perf_aux_output_end() is called to move the aux->head of
    "struct perf_buffer" to indicate size of data in aux buffer.
    aux_tail will be moved in perf tools side when writing the data from
    aux buffer to perf.data file in disk.

    It is responsiblity of PMU driver to make sure data is copied between
    perf_aux_output_begin and perf_aux_output_end.

    Signed-off-by: Athira Rajeev <atrajeev@linux.ibm.com>
    Tested-by: Tejas Manhas <tejas05@linux.ibm.com>
    Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250915102947.26681-6-atrajeev@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-07-07 01:06:02 -04:00
Mamatha Inamdar 99f94624fa powerpc/perf/vpa-dtl: Add support to setup and free aux buffer for capturing DTL data 
JIRA: https://issues.redhat.com/browse/RHEL-53366

commit 5d75aed84d3b6d25c7c4bb4a212b14fae4d1020b
Author: Athira Rajeev <atrajeev@linux.ibm.com>
Date:   Mon Sep 15 15:59:44 2025 +0530

    powerpc/perf/vpa-dtl: Add support to setup and free aux buffer for capturing DTL data

    vpa dtl pmu has one hrtimer added per vpa-dtl pmu thread. When the
    hrtimer expires, in the timer handler, code is added to save the DTL
    data to perf event record. DTL (Dispatch Trace Log) contains information
    about dispatch/preempt, enqueue time etc. We directly copy the DTL
    buffer data as part of auxiliary buffer and it will be postprocessed
    later. To enable the support for aux buffer, add the PMU callbacks for
    setup_aux and free_aux.

    In setup_aux, set up pmu-private data structures for an AUX
    area. rb_alloc_aux uses "alloc_pages_node" and returns pointer to each
    page address. Map these pages to contiguous space using vmap and use
    that as base address. The aux private data structure ie,
    "struct vpa_pmu_buf" mainly saves:
    1. buf->base: aux buffer base address
    2. buf->head: offset from base address where data will be written to.
    3. buf->size: Size of allocated memory

    free_aux will free pmu-private AUX data structures.

    Signed-off-by: Athira Rajeev <atrajeev@linux.ibm.com>
    Tested-by: Tejas Manhas <tejas05@linux.ibm.com>
    Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250915102947.26681-5-atrajeev@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-07-07 01:05:57 -04:00
Mamatha Inamdar 6583d671a7 powerpc/vpa_dtl: Add interface to expose vpa dtl counters via perf 
JIRA: https://issues.redhat.com/browse/RHEL-53366

commit 4708fba19adee9ba14ef28af6face4ab043d9cd6
Author: Kajol Jain <kjain@linux.ibm.com>
Date:   Mon Sep 15 15:59:42 2025 +0530

    powerpc/vpa_dtl: Add interface to expose vpa dtl counters via perf

    The pseries Shared Processor Logical Partition(SPLPAR) machines
    can retrieve a log of dispatch and preempt events from the
    hypervisor using data from Disptach Trace Log(DTL) buffer.
    With this information, user can retrieve when and why each dispatch &
    preempt has occurred. Added an interface to expose the Virtual Processor
    Area(VPA) DTL counters via perf.

    The following events are available and exposed in sysfs:

     vpa_dtl/dtl_cede/ - Trace voluntary (OS initiated) virtual processor waits
     vpa_dtl/dtl_preempt/ - Trace time slice preempts
     vpa_dtl/dtl_fault/ - Trace virtual partition memory page faults.
     vpa_dtl/dtl_all/ - Trace all (dtl_cede/dtl_preempt/dtl_fault)

    Added interface defines supported event list, config fields for the
    event attributes and their corresponding bit values which are exported
    via sysfs. User could use the standard perf tool to access perf events
    exposed via vpa-dtl pmu.

    The VPA DTL PMU counters do not interrupt on overflow or generate any
    PMI interrupts. Therefore, the kernel needs to poll the counters, added
    hrtimer code to do that. The timer interval can be provided by user via
    sample_period field in nano seconds. There is one hrtimer added per
    vpa-dtl pmu thread.

    To ensure there are no other conflicting dtl users (example: debugfs dtl
    or /proc/powerpc/vcpudispatch_stats), interface added code to use
    "down_write_trylock" call to take the dtl_access_lock. The dtl_access_lock
    is defined in dtl.h file. Also added global reference count variable called
    "dtl_global_refc", to ensure dtl data can be captured per-cpu. Code also
    added global lock called "dtl_global_lock" to avoid race condition.

    Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
    Tested-by: Tejas Manhas <tejas05@linux.ibm.com>
    Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250915102947.26681-3-atrajeev@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-07-07 01:05:53 -04:00
Mamatha Inamdar fdae64acb5 powerpc/time: Expose boot_tb via accessor 
JIRA: https://issues.redhat.com/browse/RHEL-53366

commit 2dc019ca39347f76891d34a992b67258078aa45d
Author: Aboorva Devarajan <aboorvad@linux.ibm.com>
Date:   Mon Sep 15 15:59:41 2025 +0530

    powerpc/time: Expose boot_tb via accessor

    - Define accessor function get_boot_tb() to safely return boot_tb value,
      this is only needed when running in SPLPAR environments, so the
      accessor is built conditionally under CONFIG_PPC_SPLPAR.

    - Tag boot_tb as __ro_after_init since it is written once at initialized
      and never updated afterwards.

    Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
    Tested-by: Tejas Manhas <tejas05@linux.ibm.com>
    Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250915102947.26681-2-atrajeev@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-07-07 01:05:50 -04:00
Mamatha Inamdar 90c304e113 docs: ABI: sysfs-bus-event_source-devices-vpa-dtl: Document sysfs event format entries for vpa_dtl pmu 
JIRA: https://issues.redhat.com/browse/RHEL-53366

commit 6f2c65680c336a274b69b1fdcbfa2eeb8159bee8
Author: Kajol Jain <kjain@linux.ibm.com>
Date:   Mon Sep 15 15:59:43 2025 +0530

    docs: ABI: sysfs-bus-event_source-devices-vpa-dtl: Document sysfs event format entries for vpa_dtl pmu

    Details are added for the vpa_dtl pmu event and format
    attributes in the ABI documentation.

    Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
    Tested-by: Tejas Manhas <tejas05@linux.ibm.com>
    Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250915102947.26681-4-atrajeev@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-07-07 01:05:46 -04:00
Mamatha Inamdar f0e3d4abff powerpc/pseries: Fix dtl_access_lock to be a rw_semaphore 
JIRA: https://issues.redhat.com/browse/RHEL-53366

commit cadae3a45d23aa4f6485938a67cbc47aaaa25e38
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Mon Aug 19 22:24:01 2024 +1000

    powerpc/pseries: Fix dtl_access_lock to be a rw_semaphore

    The dtl_access_lock needs to be a rw_sempahore, a sleeping lock, because
    the code calls kmalloc() while holding it, which can sleep:

      # echo 1 > /proc/powerpc/vcpudispatch_stats
      BUG: sleeping function called from invalid context at include/linux/sched/mm.h:337
      in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 199, name: sh
      preempt_count: 1, expected: 0
      3 locks held by sh/199:
       #0: c00000000a0743f8 (sb_writers#3){.+.+}-{0:0}, at: vfs_write+0x324/0x438
       #1: c0000000028c7058 (dtl_enable_mutex){+.+.}-{3:3}, at: vcpudispatch_stats_write+0xd4/0x5f4
       #2: c0000000028c70b8 (dtl_access_lock){+.+.}-{2:2}, at: vcpudispatch_stats_write+0x220/0x5f4
      CPU: 0 PID: 199 Comm: sh Not tainted 6.10.0-rc4 #152
      Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries
      Call Trace:
        dump_stack_lvl+0x130/0x148 (unreliable)
        __might_resched+0x174/0x410
        kmem_cache_alloc_noprof+0x340/0x3d0
        alloc_dtl_buffers+0x124/0x1ac
        vcpudispatch_stats_write+0x2a8/0x5f4
        proc_reg_write+0xf4/0x150
        vfs_write+0xfc/0x438
        ksys_write+0x88/0x148
        system_call_exception+0x1c4/0x5a0
        system_call_common+0xf4/0x258

    Fixes: 06220d78f2 ("powerpc/pseries: Introduce rwlock to gatekeep DTLB usage")
    Tested-by: Kajol Jain <kjain@linux.ibm.com>
    Reviewed-by: Nysal Jan K.A <nysal@linux.ibm.com>
    Reviewed-by: Kajol Jain <kjain@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/20240819122401.513203-1-mpe@ellerman.id.au

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-07-07 01:05:43 -04:00
Mamatha Inamdar a17859d433 Updates for IBMVFC_MAX_REQUESTS_DEFAULT 
Upstream Status: RHEL only

Conflicts:
There is a patchset that reworks the queue_depth logic, but that would be harder
if not impossible to get backported into existing RHEL releases,
so easy fix for RHEL is to just patch the default value to 1024

JIRA: https://issues.redhat.com/browse/RHEL-174571

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-06-04 00:49:32 -04:00
Mamatha Inamdar cd82512d5e ibmveth: Disable GSO for packets with small MSS 
JIRA: https://issues.redhat.com/browse/RHEL-164873

commit cc427d24ac6442ffdeafd157a63c7c5b73ed4de4
Author: Mingming Cao <mmc@linux.ibm.com>
Date:   Fri Apr 24 09:29:17 2026 -0700

    ibmveth: Disable GSO for packets with small MSS

    Some physical adapters on Power systems do not support segmentation
    offload when the MSS is less than 224 bytes. Attempting to send such
    packets causes the adapter to freeze, stopping all traffic until
    manually reset.

    Implement ndo_features_check to disable GSO for packets with small MSS
    values. The network stack will perform software segmentation instead.

    The 224-byte minimum matches ibmvnic
    commit <f10b09ef687f> ("ibmvnic: Enforce stronger sanity checks
    on GSO packets")
    which uses the same physical adapters in SEA configurations.

    The issue occurs specifically when the hardware attempts to perform
    segmentation (gso_segs > 1) with a small MSS. Single-segment GSO packets
    (gso_segs == 1) do not trigger the problematic LSO code path and are
    transmitted normally without segmentation.

    Add an ndo_features_check callback to disable GSO when MSS < 224 bytes.
    Also call vlan_features_check() to ensure proper handling of VLAN packets,
    particularly QinQ (802.1ad) configurations where the hardware parser may
    not support certain offload features.

    Validated using iptables to force small MSS values. Without the fix,
    the adapter freezes. With the fix, packets are segmented in software
    and transmission succeeds. Comprehensive regression testing completedd
    (MSS tests, performance, stability).

    Fixes: 8641dd8579 ("ibmveth: Add support for TSO")
    Cc: stable@vger.kernel.org
    Reviewed-by: Brian King <bjking1@linux.ibm.com>
    Tested-by: Shaik Abdulla <shaik.abdulla1@ibm.com>
    Tested-by: Naveed Ahmed <naveedaus@in.ibm.com>
    Signed-off-by: Mingming Cao <mmc@linux.ibm.com>
    Link: https://patch.msgid.link/20260424162917.65725-1-mmc@linux.ibm.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-04-30 20:30:14 -04:00
Mamatha Inamdar 988852685b Documentation/powerpc: update fadump implementation details 
JIRA: https://issues.redhat.com/browse/RHEL-138954

commit 57e6700145c5d1f49c52137e9163f73ec5441256
Author: Sourabh Jain <sourabhjain@linux.ibm.com>
Date:   Tue Apr 23 01:29:32 2024 +0530

    Documentation/powerpc: update fadump implementation details

    The patch titled ("powerpc: make fadump resilient with memory add/remove
    events") has made significant changes to the implementation of fadump,
    particularly on elfcorehdr creation and fadump crash info header
    structure. Therefore, updating the fadump implementation documentation
    to reflect those changes.

    Following updates are done to firmware assisted dump documentation:

    1. The elfcorehdr is no longer stored after fadump HDR in the reserved
       dump area. Instead, the second kernel dynamically allocates memory
       for the elfcorehdr within the address range from 0 to the boot memory
       size. Therefore, update figures 1 and 2 of Memory Reservation during
       the first and second kernels to reflect this change.

    2. A version field has been added to the fadump header to manage the
       future changes to fadump crash info header structure without changing
       the fadump header magic number in the future. Therefore, remove the
       corresponding TODO from the document.

    Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240422195932.1583833-4-sourabhjain@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-04-14 07:33:15 -04:00
Mamatha Inamdar 79c92c2fc8 powerpc/fadump: add hotplug_ready sysfs interface 
JIRA: https://issues.redhat.com/browse/RHEL-138954

commit bc446c5acabadeb38b61b565535401c5dfdd1214
Author: Sourabh Jain <sourabhjain@linux.ibm.com>
Date:   Tue Apr 23 01:29:31 2024 +0530

    powerpc/fadump: add hotplug_ready sysfs interface

    The elfcorehdr describes the CPUs and memory of the crashed kernel to
    the kernel that captures the dump, known as the second or fadump kernel.
    The elfcorehdr needs to be updated if the system's memory changes due to
    memory hotplug or online/offline events.

    Currently, memory hotplug events are monitored in userspace by udev
    rules, and fadump is re-registered, which recreates the elfcorehdr with
    the latest available memory in the system.

    However, the previous patch ("powerpc: make fadump resilient with memory
    add/remove events") moved the creation of elfcorehdr to the second or
    fadump kernel. This eliminates the need to regenerate the elfcorehdr
    during memory hotplug or online/offline events.

    Create a sysfs entry at /sys/kernel/fadump/hotplug_ready to let
    userspace know that fadump re-registration is not required for memory
    add/remove events.

    Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240422195932.1583833-3-sourabhjain@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-04-14 07:33:12 -04:00
Mamatha Inamdar 0f3ea3c25e powerpc: make fadump resilient with memory add/remove events 
JIRA: https://issues.redhat.com/browse/RHEL-138954

commit c6c5b14dac0d1bd0da8b4d1d3b77f18eb9085fcb
Author: Sourabh Jain <sourabhjain@linux.ibm.com>
Date:   Tue Apr 23 01:29:30 2024 +0530

    powerpc: make fadump resilient with memory add/remove events

    Due to changes in memory resources caused by either memory hotplug or
    online/offline events, the elfcorehdr, which describes the CPUs and
    memory of the crashed kernel to the kernel that collects the dump (known
    as second/fadump kernel), becomes outdated. Consequently, attempting
    dump collection with an outdated elfcorehdr can lead to failed or
    inaccurate dump collection.

    Memory hotplug or online/offline events is referred as memory add/remove
    events in reset of the commit message.

    The current solution to address the aforementioned issue is as follows:
    Monitor memory add/remove events in userspace using udev rules, and
    re-register fadump whenever there are changes in memory resources. This
    leads to the creation of a new elfcorehdr with updated system memory
    information.

    There are several notable issues associated with re-registering fadump
    for every memory add/remove events.

    1. Bulk memory add/remove events with udev-based fadump re-registration
       can lead to race conditions and, more importantly, it creates a wide
       window during which fadump is inactive until all memory add/remove
       events are settled.
    2. Re-registering fadump for every memory add/remove event is
       inefficient.
    3. The memory for elfcorehdr is allocated based on the memblock regions
       available during early boot and remains fixed thereafter. However, if
       elfcorehdr is later recreated with additional memblock regions, its
       size will increase, potentially leading to memory corruption.

    Address the aforementioned challenges by shifting the creation of
    elfcorehdr from the first kernel (also referred as the crashed kernel),
    where it was created and frequently recreated for every memory
    add/remove event, to the fadump kernel. As a result, the elfcorehdr only
    needs to be created once, thus eliminating the necessity to re-register
    fadump during memory add/remove events.

    At present, the first kernel prepares fadump header and stores it in the
    fadump reserved area. The fadump header includes the start address of
    the elfcorehdr, crashing CPU details, and other relevant information. In
    the event of a crash in the first kernel, the second/fadump boots and
    accesses the fadump header prepared by the first kernel. It then
    performs the following steps in a platform-specific function
    [rtas|opal]_fadump_process:

    1. Sanity check for fadump header
    2. Update CPU notes in elfcorehdr

    Along with the above, update the setup_fadump()/fadump.c to create
    elfcorehdr and set its address to the global variable elfcorehdr_addr
    for the vmcore module to process it in the second/fadump kernel.

    Section below outlines the information required to create the elfcorehdr
    and the changes made to make it available to the fadump kernel if it's
    not already.

    To create elfcorehdr, the following crashed kernel information is
    required: CPU notes, vmcoreinfo, and memory ranges.

    At present, the CPU notes are already prepared in the fadump kernel, so
    no changes are needed in that regard. The fadump kernel has access to
    all crashed kernel memory regions, including boot memory regions that
    are relocated by firmware to fadump reserved areas, so no changes for
    that either. However, it is necessary to add new members to the fadump
    header, i.e., the 'fadump_crash_info_header' structure, in order to pass
    the crashed kernel's vmcoreinfo address and its size to fadump kernel.

    In addition to the vmcoreinfo address and size, there are a few other
    attributes also added to the fadump_crash_info_header structure.

    1. version:
       It stores the fadump header version, which is currently set to 1.
       This provides flexibility to update the fadump crash info header in
       the future without changing the magic number. For each change in the
       fadump header, the version will be increased. This will help the
       updated kernel determine how to handle kernel dumps from older
       kernels. The magic number remains relevant for checking fadump header
       corruption.

    2. pt_regs_sz/cpu_mask_sz:
       Store size of pt_regs and cpu_mask structure of first kernel. These
       attributes are used to prevent dump processing if the sizes of
       pt_regs or cpu_mask structure differ between the first and fadump
       kernels.

    Note: if either first/crashed kernel or second/fadump kernel do not have
    the changes introduced here then kernel fail to collect the dump and
    prints relevant error message on the console.

    Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240422195932.1583833-2-sourabhjain@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-04-14 07:33:08 -04:00
Mamatha Inamdar 633fa69e64 powerpc/watchpoints: Annotate atomic context in more places 
JIRA: https://issues.redhat.com/browse/RHEL-145581

commit 27646b2e02b096a6936b3e3b6ba334ae20763eab
Author: Benjamin Gray <bgray@linux.ibm.com>
Date:   Tue Aug 29 16:34:57 2023 +1000

    powerpc/watchpoints: Annotate atomic context in more places

    It can be easy to miss that the notifier mechanism invokes the callbacks
    in an atomic context, so add some comments to that effect on the two
    handlers we register here.

    Signed-off-by: Benjamin Gray <bgray@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20230829063457.54157-4-bgray@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-03-06 02:33:08 -05:00
Mamatha Inamdar b4aac36e50 powerpc/watchpoint: Disable pagefaults when getting user instruction 
JIRA: https://issues.redhat.com/browse/RHEL-145581

commit 3241f260eb830d27d09cc604690ec24533fdb433
Author: Benjamin Gray <bgray@linux.ibm.com>
Date:   Tue Aug 29 16:34:56 2023 +1000

    powerpc/watchpoint: Disable pagefaults when getting user instruction

    This is called in an atomic context, so is not allowed to sleep if a
    user page needs to be faulted in and has nowhere it can be deferred to.
    The pagefault_disabled() function is documented as preventing user
    access methods from sleeping.

    In practice the page will be mapped in nearly always because we are
    reading the instruction that just triggered the watchpoint trap.

    Signed-off-by: Benjamin Gray <bgray@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20230829063457.54157-3-bgray@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-03-06 02:33:04 -05:00
Mamatha Inamdar 3b23fd9fdd powerpc/iommu: bypass DMA APIs for coherent allocations for pre-mapped memory 
JIRA: https://issues.redhat.com/browse/RHEL-149742

commit 1471c517cf7dae1a6342fb821d8ed501af956dd0
Author: Gaurav Batra <gbatra@linux.ibm.com>
Date:   Fri Nov 7 10:11:05 2025 -0600

    powerpc/iommu: bypass DMA APIs for coherent allocations for pre-mapped memory

    Leverage ARCH_HAS_DMA_MAP_DIRECT config option for coherent allocations as
    well. This will bypass DMA ops for memory allocations that have been
    pre-mapped.

    Always set device bus_dma_limit when memory is pre-mapped. In some
    architectures, like PowerPC, pmemory can be converted to regular memory via
    daxctl command. This will gate the coherent allocations to pre-mapped RAM
    only, by dma_coherent_ok().

    Signed-off-by: Gaurav Batra <gbatra@linux.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20251107161105.85999-1-gbatra@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-02-27 01:29:22 -05:00
Mamatha Inamdar 1803a248e4 ftrace: bpf: Fix IPMODIFY + DIRECT in modify_ftrace_direct() 
JIRA: https://issues.redhat.com/browse/RHEL-14156

commit 3e9a18e1c3e931abecf501cbb23d28d69f85bb56
Author: Song Liu <song@kernel.org>
Date:   Mon Oct 27 10:50:22 2025 -0700

    ftrace: bpf: Fix IPMODIFY + DIRECT in modify_ftrace_direct()

    ftrace_hash_ipmodify_enable() checks IPMODIFY and DIRECT ftrace_ops on
    the same kernel function. When needed, ftrace_hash_ipmodify_enable()
    calls ops->ops_func() to prepare the direct ftrace (BPF trampoline) to
    share the same function as the IPMODIFY ftrace (livepatch).

    ftrace_hash_ipmodify_enable() is called in register_ftrace_direct() path,
    but not called in modify_ftrace_direct() path. As a result, the following
    operations will break livepatch:

    1. Load livepatch to a kernel function;
    2. Attach fentry program to the kernel function;
    3. Attach fexit program to the kernel function.

    After 3, the kernel function being used will not be the livepatched
    version, but the original version.

    Fix this by adding __ftrace_hash_update_ipmodify() to
    __modify_ftrace_direct() and adjust some logic around the call.

    Signed-off-by: Song Liu <song@kernel.org>
    Reviewed-by: Jiri Olsa <jolsa@kernel.org>
    Link: https://lore.kernel.org/r/20251027175023.1521602-3-song@kernel.org
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org>

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:50:04 -05:00
Mamatha Inamdar eeb3e09cc1 ftrace: Fix BPF fexit with livepatch 
JIRA: https://issues.redhat.com/browse/RHEL-14156

commit 56b3c85e153b84f27e6cff39623ba40a1ad299d3
Author: Song Liu <song@kernel.org>
Date:   Mon Oct 27 10:50:21 2025 -0700

    ftrace: Fix BPF fexit with livepatch

    When livepatch is attached to the same function as bpf trampoline with
    a fexit program, bpf trampoline code calls register_ftrace_direct()
    twice. The first time will fail with -EAGAIN, and the second time it
    will succeed. This requires register_ftrace_direct() to unregister
    the address on the first attempt. Otherwise, the bpf trampoline cannot
    attach. Here is an easy way to reproduce this issue:

      insmod samples/livepatch/livepatch-sample.ko
      bpftrace -e 'fexit:cmdline_proc_show {}'
      ERROR: Unable to attach probe: fexit:vmlinux:cmdline_proc_show...

    Fix this by cleaning up the hash when register_ftrace_function_nolock hits
    errors.

    Also, move the code that resets ops->func and ops->trampoline to the error
    path of register_ftrace_direct(); and add a helper function reset_direct()
    in register_ftrace_direct() and unregister_ftrace_direct().

    Fixes: d05cb470663a ("ftrace: Fix modification of direct_function hash while in use")
    Cc: stable@vger.kernel.org # v6.6+
    Reported-by: Andrey Grodzovsky <andrey.grodzovsky@crowdstrike.com>
    Closes: https://lore.kernel.org/live-patching/c5058315a39d4615b333e485893345be@crowdstrike.com/
    Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
    Cc: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Acked-and-tested-by: Andrey Grodzovsky <andrey.grodzovsky@crowdstrike.com>
    Signed-off-by: Song Liu <song@kernel.org>
    Reviewed-by: Jiri Olsa <jolsa@kernel.org>
    Link: https://lore.kernel.org/r/20251027175023.1521602-2-song@kernel.org
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org>

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:49:58 -05:00
Mamatha Inamdar 4eba0a1d84 powerpc64/modules: replace stub allocation sentinel with an explicit counter 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
        Backport of upstream commit b137312fbf2d. Minor conflict in file
        arch/powerpc/include/asm/module.h due to missing module PCREL
        addressing support (commit 77e69ee7ce07) and conflicts in the
        file arch/powerpc/kernel/module_64.c due to missing commits
        d3e32b997a4c & e6b8940e7e80 resolved appropriately. Also,
        skipped backporting fix commit f6b4df37ebfe as this commit
        subsides that change anyway.

commit b137312fbf2dd1edc39acf7e8e6e8ac0a6ad72c0
Author: Joe Lawrence <joe.lawrence@redhat.com>
Date:   Fri Sep 12 10:27:40 2025 -0400

    powerpc64/modules: replace stub allocation sentinel with an explicit counter

    The logic for allocating ppc64_stub_entry trampolines in the .stubs
    section relies on an inline sentinel, where a NULL .funcdata member
    indicates an available slot.

    While preceding commits fixed the initialization bugs that led to ftrace
    stub corruption, the sentinel-based approach remains fragile: it depends
    on an implicit convention between subsystems modifying different
    struct types in the same memory area.

    Replace the sentinel with an explicit counter, module->arch.num_stubs.
    Instead of iterating through memory to find a NULL marker, the module
    loader uses this counter as the boundary for the next free slot.

    This simplifies the allocation code, hardens it against future changes
    to stub structures, and removes the need for an extra relocation slot
    previously reserved to terminate the sentinel search.

    Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
    Acked-by: Naveen N Rao (AMD) <naveen@kernel.org>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250912142740.3581368-4-joe.lawrence@redhat.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:49:54 -05:00
Mamatha Inamdar c3e31311ea powerpc/ftrace: ensure ftrace record ops are always set for NOPs 
JIRA: https://issues.redhat.com/browse/RHEL-14156

commit 5337609a314828aa2474ac359db615f475c4a4d2
Author: Joe Lawrence <joe.lawrence@redhat.com>
Date:   Fri Sep 12 10:27:38 2025 -0400

    powerpc/ftrace: ensure ftrace record ops are always set for NOPs

    When an ftrace call site is converted to a NOP, its corresponding
    dyn_ftrace record should have its ftrace_ops pointer set to
    ftrace_nop_ops.

    Correct the powerpc implementation to ensure the
    ftrace_rec_set_nop_ops() helper is called on all successful NOP
    initialization paths. This ensures all ftrace records are consistent
    before being handled by the ftrace core.

    Fixes: eec37961a56a ("powerpc64/ftrace: Move ftrace sequence out of line")
    Suggested-by: Naveen N Rao <naveen@kernel.org>
    Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
    Acked-by: Naveen N Rao (AMD) <naveen@kernel.org>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250912142740.3581368-2-joe.lawrence@redhat.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:49:49 -05:00
Mamatha Inamdar 0acc024fc0 redhat: Add CONFIG_PPC_FTRACE_OUT_OF_LINE_NUM_RESERVE 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Upstream Status: RHEL-only

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:49:45 -05:00
Mamatha Inamdar 11d437b265 ftrace: fix incorrect hash size in register_ftrace_direct() 
JIRA: https://issues.redhat.com/browse/RHEL-14156

commit 92f1d3b40179b15630d72e2c6e4e25a899b67ba9
Author: Menglong Dong <menglong8.dong@gmail.com>
Date:   Sun Apr 13 09:44:44 2025 +0800

    ftrace: fix incorrect hash size in register_ftrace_direct()

    The maximum of the ftrace hash bits is made fls(32) in
    register_ftrace_direct(), which seems illogical. So, we fix it by making
    the max hash bits FTRACE_HASH_MAX_BITS instead.

    Link: https://lore.kernel.org/20250413014444.36724-1-dongml2@chinatelecom.cn
    Fixes: d05cb470663a ("ftrace: Fix modification of direct_function hash while in use")
    Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn>
    Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:49:41 -05:00
Mamatha Inamdar cd448c5cb9 kbuild: dummy-tools: pretend we understand -fpatchable-function-entry 
JIRA: https://issues.redhat.com/browse/RHEL-14156

commit 1bfaa37fd3486e66131de9cb87747c84b4c89a05
Author: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Date:   Mon Oct 30 12:34:16 2023 +0100

    kbuild: dummy-tools: pretend we understand -fpatchable-function-entry

    Commit 0f71dcfb4aef ("powerpc/ftrace: Add support for
    -fpatchable-function-entry") added a script to check for
    -fpatchable-function-entry compiler support. The script expects compiler
    to emit the section __patchable_function_entries and few nops after a
    function entry.

    If the compiler understands and emits the above,
    CONFIG_ARCH_USING_PATCHABLE_FUNCTION_ENTRY is set.

    So teach dummy-tools' gcc about this.

    Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
    Reviewed-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:49:36 -05:00
Mamatha Inamdar 5e7937b575 ftrace: Fix modification of direct_function hash while in use 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit d05cb470663a. Minor conflict due to
	inclusion of commit d2cc859cc888 in the build resolved accordingly.

commit d05cb470663a2a1879277e544f69e660208f08f2
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Fri Dec 29 11:51:34 2023 -0500

    ftrace: Fix modification of direct_function hash while in use

    Masami Hiramatsu reported a memory leak in register_ftrace_direct() where
    if the number of new entries are added is large enough to cause two
    allocations in the loop:

            for (i = 0; i < size; i++) {
                    hlist_for_each_entry(entry, &hash->buckets[i], hlist) {
                            new = ftrace_add_rec_direct(entry->ip, addr, &free_hash);
                            if (!new)
                                    goto out_remove;
                            entry->direct = addr;
                    }
            }

    Where ftrace_add_rec_direct() has:

            if (ftrace_hash_empty(direct_functions) ||
                direct_functions->count > 2 * (1 << direct_functions->size_bits)) {
                    struct ftrace_hash *new_hash;
                    int size = ftrace_hash_empty(direct_functions) ? 0 :
                            direct_functions->count + 1;

                    if (size < 32)
                            size = 32;

                    new_hash = dup_hash(direct_functions, size);
                    if (!new_hash)
                            return NULL;

                    *free_hash = direct_functions;
                    direct_functions = new_hash;
            }

    The "*free_hash = direct_functions;" can happen twice, losing the previous
    allocation of direct_functions.

    But this also exposed a more serious bug.

    The modification of direct_functions above is not safe. As
    direct_functions can be referenced at any time to find what direct caller
    it should call, the time between:

                    new_hash = dup_hash(direct_functions, size);
     and
                    direct_functions = new_hash;

    can have a race with another CPU (or even this one if it gets interrupted),
    and the entries being moved to the new hash are not referenced.

    That's because the "dup_hash()" is really misnamed and is really a
    "move_hash()". It moves the entries from the old hash to the new one.

    Now even if that was changed, this code is not proper as direct_functions
    should not be updated until the end. That is the best way to handle
    function reference changes, and is the way other parts of ftrace handles
    this.

    The following is done:

     1. Change add_hash_entry() to return the entry it created and inserted
        into the hash, and not just return success or not.

     2. Replace ftrace_add_rec_direct() with add_hash_entry(), and remove
        the former.

     3. Allocate a "new_hash" at the start that is made for holding both the
        new hash entries as well as the existing entries in direct_functions.

     4. Copy (not move) the direct_function entries over to the new_hash.

     5. Copy the entries of the added hash to the new_hash.

     6. If everything succeeds, then use rcu_pointer_assign() to update the
        direct_functions with the new_hash.

    This simplifies the code and fixes both the memory leak as well as the
    race condition mentioned above.

    Link: https://lore.kernel.org/all/170368070504.42064.8960569647118388081.stgit@devnote2/
    Link: https://lore.kernel.org/linux-trace-kernel/20231229115134.08dd5174@gandalf.local.home

    Cc: stable@vger.kernel.org
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Alexei Starovoitov <ast@kernel.org>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Fixes: 763e34e74b ("ftrace: Add register_ftrace_direct()")
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:49:31 -05:00
Mamatha Inamdar ce8f8eeb95 powerpc64/ftrace: fix module loading without patchable function entries 
JIRA: https://issues.redhat.com/browse/RHEL-14156

commit 534f5a8ba27863141e29766467a3e1f61bcb47ac
Author: Anthony Iliopoulos <ailiop@suse.com>
Date:   Wed Feb 5 00:18:21 2025 +0100

    powerpc64/ftrace: fix module loading without patchable function entries

    get_stubs_size assumes that there must always be at least one patchable
    function entry, which is not always the case (modules that export data
    but no code), otherwise it returns -ENOEXEC and thus the section header
    sh_size is set to that value. During module_memory_alloc() the size is
    passed to execmem_alloc() after being page-aligned and thus set to zero
    which will cause it to fail the allocation (and thus module loading) as
    __vmalloc_node_range() checks for zero-sized allocs and returns null:

    [  115.466896] module_64: cast_common: doesn't contain __patchable_function_entries.
    [  115.469189] ------------[ cut here ]------------
    [  115.469496] WARNING: CPU: 0 PID: 274 at mm/vmalloc.c:3778 __vmalloc_node_range_noprof+0x8b4/0x8f0
    ...
    [  115.478574] ---[ end trace 0000000000000000 ]---
    [  115.479545] execmem: unable to allocate memory

    Fix this by removing the check completely, since it is anyway not
    helpful to propagate this as an error upwards.

    Fixes: eec37961a56a ("powerpc64/ftrace: Move ftrace sequence out of line")
    Signed-off-by: Anthony Iliopoulos <ailiop@suse.com>
    Acked-by: Naveen N Rao (AMD) <naveen@kernel.org>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250204231821.39140-1-ailiop@suse.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:49:26 -05:00
Mamatha Inamdar cfa1d4a16d powerpc: Replace kretprobe code with rethook on powerpc 
JIRA: https://issues.redhat.com/browse/RHEL-14156

commit 19f1bc3fb55452739dd3d56cfd06c29ecdbe3e9f
Author: Abhishek Dubey <adubey@linux.ibm.com>
Date:   Fri Aug 30 07:31:31 2024 -0400

    powerpc: Replace kretprobe code with rethook on powerpc

    This is an adaptation of commit f3a112c0c40d ("x86,rethook,kprobes:
    Replace kretprobe with rethook on x86") to powerpc.

    Rethook follows the existing kretprobe implementation, but separates
    it from kprobes so that it can be used by fprobe (ftrace-based
    function entry/exit probes). As such, this patch also enables fprobe
    to work on powerpc. The only other change compared to the existing
    kretprobe implementation is doing the return address fixup in
    arch_rethook_fixup_return().

    Reference to other archs:
    commit b57c2f124098 ("riscv: add riscv rethook implementation")
    commit 7b0a096436c2 ("LoongArch: Replace kretprobe with rethook")

    Note:
    =====

    In future, rethook will be only for kretprobe, and kretprobe
    will be replaced by fprobe.

    https://lore.kernel.org/all/172000134410.63468.13742222887213469474.stgit@devnote2/

    We will adapt the above implementation for powerpc once its upstream.
    Until then, we can have this implementation of rethook to serve
    current kretprobe usecases.

    Reviewed-by: Naveen Rao <naveen@kernel.org>
    Signed-off-by: Abhishek Dubey <adubey@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240830113131.7597-1-adubey@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:49:22 -05:00
Mamatha Inamdar 1dbe9275d0 powerpc64/ftrace: fix clobbered r15 during livepatching 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit cb5b691f8273. Conflicts owing to missing
	commit 228216716cb5 resolved appropriately.

commit cb5b691f8273432297611863ac142e17119279e0
Author: Hari Bathini <hbathini@linux.ibm.com>
Date:   Thu Apr 17 00:42:27 2025 +0530

    powerpc64/ftrace: fix clobbered r15 during livepatching

    While r15 is clobbered always with PPC_FTRACE_OUT_OF_LINE, it is
    not restored in livepatch sequence leading to not so obvious fails
    like below:

      BUG: Unable to handle kernel data access on write at 0xc0000000000f9078
      Faulting instruction address: 0xc0000000018ff958
      Oops: Kernel access of bad area, sig: 11 [#1]
      ...
      NIP:  c0000000018ff958 LR: c0000000018ff930 CTR: c0000000009c0790
      REGS: c00000005f2e7790 TRAP: 0300   Tainted: G              K      (6.14.0+)
      MSR:  8000000000009033 <SF,EE,ME,IR,DR,RI,LE>  CR: 2822880b  XER: 20040000
      CFAR: c0000000008addc0 DAR: c0000000000f9078 DSISR: 0a000000 IRQMASK: 1
      GPR00: c0000000018f2584 c00000005f2e7a30 c00000000280a900 c000000017ffa488
      GPR04: 0000000000000008 0000000000000000 c0000000018f24fc 000000000000000d
      GPR08: fffffffffffe0000 000000000000000d 0000000000000000 0000000000008000
      GPR12: c0000000009c0790 c000000017ffa480 c00000005f2e7c78 c0000000000f9070
      GPR16: c00000005f2e7c90 0000000000000000 0000000000000000 0000000000000000
      GPR20: 0000000000000000 c00000005f3efa80 c00000005f2e7c60 c00000005f2e7c88
      GPR24: c00000005f2e7c60 0000000000000001 c0000000000f9078 0000000000000000
      GPR28: 00007fff97960000 c000000017ffa480 0000000000000000 c0000000000f9078
      ...
      Call Trace:
        check_heap_object+0x34/0x390 (unreliable)
      __mutex_unlock_slowpath.isra.0+0xe4/0x230
      seq_read_iter+0x430/0xa90
      proc_reg_read_iter+0xa4/0x200
      vfs_read+0x41c/0x510
      ksys_read+0xa4/0x190
      system_call_exception+0x1d0/0x440
      system_call_vectored_common+0x15c/0x2ec

    Fix it by restoring r15 always.

    Fixes: eec37961a56a ("powerpc64/ftrace: Move ftrace sequence out of line")
    Reported-by: Viktor Malik <vmalik@redhat.com>
    Closes: https://lore.kernel.org/lkml/1aec4a9a-a30b-43fd-b303-7a351caeccb7@redhat.com
    Cc: stable@vger.kernel.org # v6.13+
    Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
    Tested-by: Viktor Malik <vmalik@redhat.com>
    Acked-by: Naveen N Rao (AMD) <naveen@kernel.org>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250416191227.201146-1-hbathini@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>

Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
 2026-01-22 06:49:18 -05:00
Mamatha Inamdar 1fa3b93ac3 powerpc/bpf: fix JIT code size calculation of bpf trampoline 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit 59ba025948be. Dropped ppc32 specific BPF
	JIT changes. Also, dropped hunk#1 in bpf_jit_comp64.c file & adjusted
	hunk#3 in bpf_jit.h file owing to missing commit 7e3a68be42e1 and
	relevant backports.

commit 59ba025948be2a92e8bc9ae1cbdaf197660bd508
Author: Hari Bathini <hbathini@linux.ibm.com>
Date:   Tue Apr 22 13:56:09 2025 +0530

    powerpc/bpf: fix JIT code size calculation of bpf trampoline

    arch_bpf_trampoline_size() provides JIT size of the BPF trampoline
    before the buffer for JIT'ing it is allocated. The total number of
    instructions emitted for BPF trampoline JIT code depends on where
    the final image is located. So, the size arrived at with the dummy
    pass in arch_bpf_trampoline_size() can vary from the actual size
    needed in  arch_prepare_bpf_trampoline().  When the instructions
    accounted in  arch_bpf_trampoline_size() is less than the number of
    instructions emitted during the actual JIT compile of the trampoline,
    the below warning is produced:

      WARNING: CPU: 8 PID: 204190 at arch/powerpc/net/bpf_jit_comp.c:981 __arch_prepare_bpf_trampoline.isra.0+0xd2c/0xdcc

    which is:

      /* Make sure the trampoline generation logic doesn't overflow */
      if (image && WARN_ON_ONCE(&image[ctx->idx] >
                            (u32 *)rw_image_end - BPF_INSN_SAFETY)) {

    So, during the dummy pass, instead of providing some arbitrary image
    location, account for maximum possible instructions if and when there
    is a dependency with image location for JIT'ing.

    Fixes: d243b62b7bd3 ("powerpc64/bpf: Add support for bpf trampolines")
    Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
    Closes: https://lore.kernel.org/all/6168bfc8-659f-4b5a-a6fb-90a916dde3b3@linux.ibm.com/
    Cc: stable@vger.kernel.org # v6.13+
    Acked-by: Naveen N Rao (AMD) <naveen@kernel.org>
    Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
    Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250422082609.949301-1-hbathini@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:49:12 -05:00
Mamatha Inamdar d94edbd937 powerpc/ftrace: Fix ftrace bug with KASAN=y 
JIRA: https://issues.redhat.com/browse/RHEL-14156

commit cfec8463d9a19ec043845525fe5fd675e59a8aab
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Thu Nov 7 22:16:30 2024 +1100

    powerpc/ftrace: Fix ftrace bug with KASAN=y

    Booting a KASAN=y kernel with the recently added ftrace out-of-line
    support causes a warning at boot:

      ------------[ cut here ]------------
      Stub index overflow (1729 > 1728)
      WARNING: CPU: 0 PID: 0 at arch/powerpc/kernel/trace/ftrace.c:209 ftrace_init_nop+0x408/0x444
      ...
      NIP ftrace_init_nop+0x408/0x444
      LR  ftrace_init_nop+0x404/0x444
      Call Trace:
        ftrace_init_nop+0x404/0x444 (unreliable)
        ftrace_process_locs+0x544/0x8a0
        ftrace_init+0xb4/0x22c
        start_kernel+0x1dc/0x4d4
        start_here_common+0x1c/0x20
      ...
      ftrace failed to modify
      [<c0000000030beddc>] _sub_I_65535_1+0x8/0x3c
       actual:   00:00:00:60
      Initializing ftrace call sites
      ftrace record flags: 0
       (0)
       expected tramp: c00000000008b418
      ------------[ cut here ]------------

    The function in question, _sub_I_65535_1 is some sort of trampoline
    generated for KASAN, and is in the .text.startup section. That section
    is part of INIT_TEXT, meaning is_kernel_inittext() returns true for it.

    But the script that determines how many out-of-line ftrace stubs are
    needed isn't doesn't consider .text.startup as inittext, leading to
    there not being enough space for the init stubs.

    Conversely the logic to calculate how many stubs are needed for the text
    section isn't filtering out the symbols in .text.startup and so ends up
    over counting.

    Fix both problems by calculating the total number of stubs first, then
    the number that count as inittext, and then subtract the latter from the
    former to get the count for the text section.

    Fixes: eec37961a56a ("powerpc64/ftrace: Move ftrace sequence out of line")
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/20241107111630.31068-1-mpe@ellerman.id.au

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:49:04 -05:00
Mamatha Inamdar b503deac65 powerpc64/bpf: Add support for bpf trampolines 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit d243b62b7bd3. Dropped ppc32 specific BPF
	JIT changes. Also, resolved other conflicts owing to missing commits
	like d00d762daf12, 7d40aff8213c & 7e3a68be42e1. Dropped PCREL specific
	checks with commit 7e3a68be42e1 not being part of this build and with
	commit 661aa880398a missing in this build using PPC64_ELF_ABI_v2
	instead of CONFIG_PPC64_ELF_ABI_V2 for ABI checks. Additionally,
	with commit e6b8940e7e80 that introduced  patch_ulong() not being part
	of this build, using patch_instructions() instead.

commit d243b62b7bd3d5314382d3b54e4992226245e936
Author: Naveen N Rao <naveen@kernel.org>
Date:   Wed Oct 30 12:38:50 2024 +0530

    powerpc64/bpf: Add support for bpf trampolines

    Add support for bpf_arch_text_poke() and arch_prepare_bpf_trampoline()
    for 64-bit powerpc. While the code is generic, BPF trampolines are only
    enabled on 64-bit powerpc. 32-bit powerpc will need testing and some
    updates.

    BPF Trampolines adhere to the existing ftrace ABI utilizing a
    two-instruction profiling sequence, as well as the newer ABI utilizing a
    three-instruction profiling sequence enabling return with a 'blr'. The
    trampoline code itself closely follows x86 implementation.

    BPF prog JIT is extended to mimic 64-bit powerpc approach for ftrace
    having a single nop at function entry, followed by the function
    profiling sequence out-of-line and a separate long branch stub for calls
    to trampolines that are out of range. A dummy_tramp is provided to
    simplify synchronization similar to arm64.

    When attaching a bpf trampoline to a bpf prog, we can patch up to three
    things:
    - the nop at bpf prog entry to go to the out-of-line stub
    - the instruction in the out-of-line stub to either call the bpf trampoline
    directly, or to branch to the long_branch stub.
    - the trampoline address before the long_branch stub.

    We do not need any synchronization here since we always have a valid
    branch target regardless of the order in which the above stores are
    seen. dummy_tramp ensures that the long_branch stub goes to a valid
    destination on other cpus, even when the branch to the long_branch stub
    is seen before the updated trampoline address.

    However, when detaching a bpf trampoline from a bpf prog, or if changing
    the bpf trampoline address, we need synchronization to ensure that other
    cpus can no longer branch into the older trampoline so that it can be
    safely freed. bpf_tramp_image_put() uses rcu_tasks to ensure all cpus
    make forward progress, but we still need to ensure that other cpus
    execute isync (or some CSI) so that they don't go back into the
    trampoline again. While here, update the stale comment that describes
    the redzone usage in ppc64 BPF JIT.

    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/20241030070850.1361304-18-hbathini@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:48:59 -05:00
Mamatha Inamdar 5520112311 powerpc/ftrace: Add support for DYNAMIC_FTRACE_WITH_DIRECT_CALLS 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit a52f6043a223. Conflicts due to missing
	consolidation patches for ppc32 resolved appropriately.

commit a52f6043a2238d656ddd23ce0499cf4f12645faa
Author: Naveen N Rao <naveen@kernel.org>
Date:   Wed Oct 30 12:38:48 2024 +0530

    powerpc/ftrace: Add support for DYNAMIC_FTRACE_WITH_DIRECT_CALLS

    Add support for DYNAMIC_FTRACE_WITH_DIRECT_CALLS similar to the arm64
    implementation.

    ftrace direct calls allow custom trampolines to be called into directly
    from function ftrace call sites, bypassing the ftrace trampoline
    completely. This functionality is currently utilized by BPF trampolines
    to hook into kernel function entries.

    Since we have limited relative branch range, we support ftrace direct
    calls through support for DYNAMIC_FTRACE_WITH_CALL_OPS. In this
    approach, ftrace trampoline is not entirely bypassed. Rather, it is
    re-purposed into a stub that reads direct_call field from the associated
    ftrace_ops structure and branches into that, if it is not NULL. For
    this, it is sufficient if we can ensure that the ftrace trampoline is
    reachable from all traceable functions.

    When multiple ftrace_ops are associated with a call site, we utilize a
    call back to set pt_regs->orig_gpr3 that can then be tested on the
    return path from the ftrace trampoline to branch into the direct caller.

    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/20241030070850.1361304-16-hbathini@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:48:55 -05:00
Mamatha Inamdar 0ff5f782c0 powerpc/ftrace: Add support for DYNAMIC_FTRACE_WITH_CALL_OPS 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit e717754f0bb5. arch/powerpc/Kconfig file
	slightly modified and hunk in arch/powerpc/Makefile dropped as the
	dependent PPC32 changes to enable DYNAMIC_FTRACE_WITH_CALL_OPS are
	not fully backported. Also, hunk#1 & hunk#2 for ftrace_entry.S file
	applied to ftrace_64_mprofile.S due to missing refactoring and ppc32
	& ppc64 consolidation commits like 41315494beed, 228216716cb5 &
	bad90aa52d9a and hunk#3 applied to ftrace_64.S file. Additionally,
	with commit e6b8940e7e80 that introduced  patch_ulong() not being
	part of this build, using patch_instructions() instead.

commit e717754f0bb5c5347aac82232691340955735ce1
Author: Naveen N Rao <naveen@kernel.org>
Date:   Wed Oct 30 12:38:47 2024 +0530

    powerpc/ftrace: Add support for DYNAMIC_FTRACE_WITH_CALL_OPS

    Implement support for DYNAMIC_FTRACE_WITH_CALL_OPS similar to the
    arm64 implementation.

    This works by patching-in a pointer to an associated ftrace_ops
    structure before each traceable function. If multiple ftrace_ops are
    associated with a call site, then a special ftrace_list_ops is used to
    enable iterating over all the registered ftrace_ops. If no ftrace_ops
    are associated with a call site, then a special ftrace_nop_ops structure
    is used to render the ftrace call as a no-op. ftrace trampoline can then
    read the associated ftrace_ops for a call site by loading from an offset
    from the LR, and branch directly to the associated function.

    The primary advantage with this approach is that we don't have to
    iterate over all the registered ftrace_ops for call sites that have a
    single ftrace_ops registered. This is the equivalent of implementing
    support for dynamic ftrace trampolines, which set up a special ftrace
    trampoline for each registered ftrace_ops and have individual call sites
    branch into those directly.

    A secondary advantage is that this gives us a way to add support for
    direct ftrace callers without having to resort to using stubs. The
    address of the direct call trampoline can be loaded from the ftrace_ops
    structure.

    To support this, we reserve a nop before each function on 32-bit
    powerpc. For 64-bit powerpc, two nops are reserved before each
    out-of-line stub. During ftrace activation, we update this location with
    the associated ftrace_ops pointer. Then, on ftrace entry, we load from
    this location and call into ftrace_ops->func().

    For 64-bit powerpc, we ensure that the out-of-line stub area is
    doubleword aligned so that ftrace_ops address can be updated atomically.

    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/20241030070850.1361304-15-hbathini@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:48:50 -05:00
Mamatha Inamdar 07b378fdc2 powerpc64/ftrace: Support .text larger than 32MB with out-of-line stubs 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit cf9bc0efcce2. Conflicts owing to missing
	ftrace_entry.S file due to commits like 41315494beed, 228216716cb5 &
	bad90aa52d9a resolved by patching ftrace_64.S file.

commit cf9bc0efcce2c324314cf7f5138c08f85ef7b5eb
Author: Naveen N Rao <naveen@kernel.org>
Date:   Wed Oct 30 12:38:46 2024 +0530

    powerpc64/ftrace: Support .text larger than 32MB with out-of-line stubs

    We are restricted to a .text size of ~32MB when using out-of-line
    function profile sequence. Allow this to be extended up to the previous
    limit of ~64MB by reserving space in the middle of .text.

    A new config option CONFIG_PPC_FTRACE_OUT_OF_LINE_NUM_RESERVE is
    introduced to specify the number of function stubs that are reserved in
    .text. On boot, ftrace utilizes stubs from this area first before using
    the stub area at the end of .text.

    A ppc64le defconfig has ~44k functions that can be traced. A more
    conservative value of 32k functions is chosen as the default value of
    PPC_FTRACE_OUT_OF_LINE_NUM_RESERVE so that we do not allot more space
    than necessary by default. If building a kernel that only has 32k
    trace-able functions, we won't allot any more space at the end of .text
    during the pass on vmlinux.o. Otherwise, only the remaining functions
    get space for stubs at the end of .text. This default value should help
    cover a .text size of ~48MB in total (including space reserved at the
    end of .text which can cover up to 32MB), which should be sufficient for
    most common builds. For a very small kernel build, this can be set to 0.
    Or, this can be bumped up to a larger value to support vmlinux .text
    size up to ~64MB.

    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/20241030070850.1361304-14-hbathini@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:48:43 -05:00
Mamatha Inamdar 40fc3e5717 powerpc64/ftrace: Move ftrace sequence out of line 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit eec37961a56a. Folded powerpc hunk of
	commit 8212f8986d31 to resolve conflict in arch/powerpc/Kbuild file.
	Resolved conflict in asm/module.h due to commit 4071739249f not being
	part of the build. Conflict in hunk#1 and hunk#2 due to missing
	commits d3e32b997a4c & c12cfe9dee077 and hunk#3 due to missing module
	PCREL addressing support (commit 77e69ee7ce07) resolved for
	module_64.c file. Conflicts owing due to missing commits like
	41315494beed, 228216716cb5 & bad90aa52d9a that refactored the code
	and consolidated PPC32 & PPC64 changes have been resolved by patching
	both ftrace_caller() and ftrace_regs_caller() functions. Also, with
	commit e6b8940e7e80 that introduced  patch_u32() not being part of
	this build, using patch_instruction() instead.

commit eec37961a56aa4f3fe1c33ffd48eec7d1bb0c009
Author: Naveen N Rao <naveen@kernel.org>
Date:   Wed Oct 30 12:38:45 2024 +0530

    powerpc64/ftrace: Move ftrace sequence out of line

    Function profile sequence on powerpc includes two instructions at the
    beginning of each function:
            mflr    r0
            bl      ftrace_caller

    The call to ftrace_caller() gets nop'ed out during kernel boot and is
    patched in when ftrace is enabled.

    Given the sequence, we cannot return from ftrace_caller with 'blr' as we
    need to keep LR and r0 intact. This results in link stack (return
    address predictor) imbalance when ftrace is enabled. To address that, we
    would like to use a three instruction sequence:
            mflr    r0
            bl      ftrace_caller
            mtlr    r0

    Further more, to support DYNAMIC_FTRACE_WITH_CALL_OPS, we need to
    reserve two instruction slots before the function. This results in a
    total of five instruction slots to be reserved for ftrace use on each
    function that is traced.

    Move the function profile sequence out-of-line to minimize its impact.
    To do this, we reserve a single nop at function entry using
    -fpatchable-function-entry=1 and add a pass on vmlinux.o to determine
    the total number of functions that can be traced. This is then used to
    generate a .S file reserving the appropriate amount of space for use as
    ftrace stubs, which is built and linked into vmlinux.

    On bootup, the stub space is split into separate stubs per function and
    populated with the proper instruction sequence. A pointer to the
    associated stub is maintained in dyn_arch_ftrace.

    For modules, space for ftrace stubs is reserved from the generic module
    stub space.

    This is restricted to and enabled by default only on 64-bit powerpc,
    though there are some changes to accommodate 32-bit powerpc. This is
    done so that 32-bit powerpc could choose to opt into this based on
    further tests and benchmarks.

    As an example, after this patch, kernel functions will have a single nop
    at function entry:
    <kernel_clone>:
            addis   r2,r12,467
            addi    r2,r2,-16028
            nop
            mfocrf  r11,8
            ...

    When ftrace is enabled, the nop is converted to an unconditional branch
    to the stub associated with that function:
    <kernel_clone>:
            addis   r2,r12,467
            addi    r2,r2,-16028
            b       ftrace_ool_stub_text_end+0x11b28
            mfocrf  r11,8
            ...

    The associated stub:
    <ftrace_ool_stub_text_end+0x11b28>:
            mflr    r0
            bl      ftrace_caller
            mtlr    r0
            b       kernel_clone+0xc
            ...

    This change showed an improvement of ~10% in null_syscall benchmark on a
    Power 10 system with ftrace enabled.

    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/20241030070850.1361304-13-hbathini@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:48:37 -05:00
Mamatha Inamdar 2292f2102e kbuild: Add generic hook for architectures to use before the final vmlinux link 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit 1198c9c689cf. Conflict in arch/Kconfig,
	with commits 5270316c9fec8 & a88d970c8bb5 not being available, and
	and commit 735e59204b5e being included resolved appropriately.
	Manually patched the hunks for scripts/link-vmlinux.sh file to
	compensate for the missing kbuild related changes and also, patched
	Makefile instead of the file scripts/Makefile.vmlinux due to kbuild
	refactoring changes like 5d4aeffbf709 not being available.

commit 1198c9c689cfdaa2d08eb508c13ff116043f07b7
Author: Naveen N Rao <naveen@kernel.org>
Date:   Wed Oct 30 12:38:44 2024 +0530

    kbuild: Add generic hook for architectures to use before the final vmlinux link

    On powerpc, we would like to be able to make a pass on vmlinux.o and
    generate a new object file to be linked into vmlinux. Add a generic pass
    in Makefile.vmlinux that architectures can use for this purpose.

    Architectures need to select CONFIG_ARCH_WANTS_PRE_LINK_VMLINUX and must
    provide arch/<arch>/tools/Makefile with .arch.vmlinux.o target, which
    will be invoked prior to the final vmlinux link step.

    Acked-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/20241030070850.1361304-12-hbathini@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:48:33 -05:00
Mamatha Inamdar 11d93ecf46 powerpc/ftrace: Add a postlink script to validate function tracer 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit 782f46cbce53. Conflicts owing to missing
	commits d24da1f85530 & 7d40aff8213c resolved appropriately.

commit 782f46cbce5328da9380f166bd31cd17a04a7b10
Author: Naveen N Rao <naveen@kernel.org>
Date:   Wed Oct 30 12:38:43 2024 +0530

    powerpc/ftrace: Add a postlink script to validate function tracer

    Function tracer on powerpc can only work with vmlinux having a .text
    size of up to ~64MB due to powerpc branch instruction having a limited
    relative branch range of 32MB. Today, this is only detected on kernel
    boot when ftrace is init'ed. Add a post-link script to check the size of
    .text so that we can detect this at build time, and break the build if
    necessary.

    We add a dependency on !COMPILE_TEST for CONFIG_HAVE_FUNCTION_TRACER so
    that allyesconfig and other test builds can continue to work without
    enabling ftrace.

    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/20241030070850.1361304-11-hbathini@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:48:28 -05:00
Mamatha Inamdar e5c319a5a2 powerpc64/bpf: Fold bpf_jit_emit_func_call_hlp() into bpf_jit_emit_func_call_rel() 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit 9670f6d2097c. Resolved conflicts owing to
	missing commits 7e3a68be42e1 & 2ecfe59cd7de. Since commit 661aa880398a
	is not part of this build, use PPC64_ELF_ABI_v1 instead of config
	CONFIG_PPC64_ELF_ABI_V1 for ABI checks. Also, convert an existing
	usage of CONFIG_PPC64_ELF_ABI_V1 in this build to use PPC64_ELF_ABI_v1

commit 9670f6d2097c4f97e15c67920dfddc664d7ee91c
Author: Naveen N Rao <naveen@kernel.org>
Date:   Wed Oct 30 12:38:42 2024 +0530

    powerpc64/bpf: Fold bpf_jit_emit_func_call_hlp() into bpf_jit_emit_func_call_rel()

    Commit 61688a82e047 ("powerpc/bpf: enable kfunc call") enhanced
    bpf_jit_emit_func_call_hlp() to handle calls out to module region, where
    bpf progs are generated. The only difference now between
    bpf_jit_emit_func_call_hlp() and bpf_jit_emit_func_call_rel() is in
    handling of the initial pass where target function address is not known.
    Fold that logic into bpf_jit_emit_func_call_hlp() and rename it to
    bpf_jit_emit_func_call_rel() to simplify bpf function call JIT code.

    We don't actually need to load/restore TOC across a call out to a
    different kernel helper or to a different bpf program since they all
    work with the kernel TOC. We only need to do it if we have to call out
    to a module function. So, guard TOC load/restore with appropriate
    conditions.

    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/20241030070850.1361304-10-hbathini@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:48:24 -05:00
Mamatha Inamdar f68e19b596 powerpc/ftrace: Move ftrace stub used for init text before _einittext 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit ed6144656bb1. Resolved conflict due to
	missing commit f3993a0330e.

commit ed6144656bb1ea29ad83671b48a21c89e7873b8a
Author: Naveen N Rao <naveen@kernel.org>
Date:   Wed Oct 30 12:38:41 2024 +0530

    powerpc/ftrace: Move ftrace stub used for init text before _einittext

    Move the ftrace stub used to cover inittext before _einittext so that it
    is within kernel text, as seen through core_kernel_text(). This is
    required for a subsequent change to ftrace.

    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/20241030070850.1361304-9-hbathini@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:48:19 -05:00
Mamatha Inamdar fd513d8d58 powerpc/ftrace: Skip instruction patching if the instructions are the same 
JIRA: https://issues.redhat.com/browse/RHEL-14156

commit 1d59bd2fc07f0b2e643b2a07405cf0717b93984f
Author: Naveen N Rao <naveen@kernel.org>
Date:   Wed Oct 30 12:38:40 2024 +0530

    powerpc/ftrace: Skip instruction patching if the instructions are the same

    To simplify upcoming changes to ftrace, add a check to skip actual
    instruction patching if the old and new instructions are the same. We
    still validate that the instruction is what we expect, but don't
    actually patch the same instruction again.

    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/20241030070850.1361304-8-hbathini@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:48:14 -05:00
Mamatha Inamdar 6f2f625b21 powerpc/ftrace: Remove pointer to struct module from dyn_arch_ftrace 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit 8b0dc1305ea0. Drop changes meant for ELFv1
	& -pg with the corresponding commit 7f7797b37269.

commit 8b0dc1305ea0bbb015b560193cdd76fd4100f062
Author: Naveen N Rao <naveen@kernel.org>
Date:   Wed Oct 30 12:38:39 2024 +0530

    powerpc/ftrace: Remove pointer to struct module from dyn_arch_ftrace

    Pointer to struct module is only relevant for ftrace records belonging
    to kernel modules. Having this field in dyn_arch_ftrace wastes memory
    for all ftrace records belonging to the kernel. Remove the same in
    favour of looking up the module from the ftrace record address, similar
    to other architectures.

    Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/20241030070850.1361304-7-hbathini@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:48:09 -05:00
Mamatha Inamdar 363e2afcc2 powerpc64/ftrace: Nop out additional 'std' instruction emitted by gcc v5.x 
JIRA: https://issues.redhat.com/browse/RHEL-14156

commit 161d62c2b067c4071cb515efe16475171e1c051e
Author: Naveen N Rao <naveen@kernel.org>
Date:   Wed Oct 30 12:38:36 2024 +0530

    powerpc64/ftrace: Nop out additional 'std' instruction emitted by gcc v5.x

    Gcc v5.x emits a 3-instruction sequence for -mprofile-kernel:
            mflr    r0
            std     r0, 16(r1)
            bl      _mcount

    Gcc v6.x moved to a simpler 2-instruction sequence by removing the 'std'
    instruction. The store saved the return address in the LR save area in
    the caller stack frame for stack unwinding. However, with dynamic
    ftrace, we no longer have a call to _mcount on kernel boot when ftrace
    is not enabled. When ftrace is enabled, that store is performed within
    ftrace_caller(). As such, the additional 'std' instruction is redundant.
    Nop it out on kernel boot.

    With this change, we now use the same 2-instruction profiling sequence
    with both -mprofile-kernel, as well as -fpatchable-function-entry on
    64-bit powerpc.

    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/20241030070850.1361304-4-hbathini@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:48:04 -05:00
Mamatha Inamdar d6b8d663e5 powerpc/kprobes: Use ftrace to determine if a probe is at function entry 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Backport:
	Backport of upstream commit be87d713eadd. Resolved conflicts due to
	missing 7d40aff8213c.

commit be87d713eaddf0421ccd61cc060c4c29bc36fc9b
Author: Naveen N Rao <naveen@kernel.org>
Date:   Wed Oct 30 12:38:35 2024 +0530

    powerpc/kprobes: Use ftrace to determine if a probe is at function entry

    Rather than hard-coding the offset into a function to be used to
    determine if a kprobe is at function entry, use ftrace_location() to
    determine the ftrace location within the function and categorize all
    instructions till that offset to be function entry.

    For functions that cannot be traced, we fall back to using a fixed
    offset of 8 (two instructions) to categorize a probe as being at
    function entry for 64-bit elfv2, unless we are using pcrel.

    Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/20241030070850.1361304-3-hbathini@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:47:59 -05:00
Mamatha Inamdar 7105378d55 powerpc/trace: Account for -fpatchable-function-entry support by toolchain 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit 0b9846529e29. Resolve conflicts around
	code refactoring by compiling the appropriate file for MPROFILE_KERNEL
	and ARCH_USING_PATCHABLE_FUNCTION_ENTRY case

commit 0b9846529e29ba988ce88b98df633de79675fcb3
Author: Naveen N Rao <naveen@kernel.org>
Date:   Wed Oct 30 12:38:34 2024 +0530

    powerpc/trace: Account for -fpatchable-function-entry support by toolchain

    So far, we have relied on the fact that gcc supports both
    -mprofile-kernel, as well as -fpatchable-function-entry, and clang
    supports neither. Our Makefile only checks for CONFIG_MPROFILE_KERNEL to
    decide which files to build. Clang has a feature request out [*] to
    implement -fpatchable-function-entry, and is unlikely to support
    -mprofile-kernel.

    Update our Makefile checks so that we pick up the correct files to build
    once clang picks up support for -fpatchable-function-entry.

    [*] https://github.com/llvm/llvm-project/issues/57031

    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/20241030070850.1361304-2-hbathini@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:47:54 -05:00
Mamatha Inamdar 645dbd8200 kbuild: move vmlinux.o rule to the top Makefile 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit 9c5a0ac3c369. Conflicts due to missing
	kbuild refactoring changes in this build resolved appropriately.
	This commit is to ensure the dependency between vmlinux.arch.o, the
	file to pre-link vmlinux for supporting out of line ftrace handler,
	and vmlinux.o is established appropriately and the build rule for
	vmlinux.o target is not hidden in scripts/link-vmlinux.sh file.

commit 9c5a0ac3c36917c4258f734bda98be02ca36b992
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Sun Sep 25 03:19:12 2022 +0900

    kbuild: move vmlinux.o rule to the top Makefile

    Move the build rules of vmlinux.o out of scripts/link-vmlinux.sh to
    clearly separate 1) pre-modpost, 2) modpost, 3) post-modpost stages.
    This will make further refactoring possible.

    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Tested-by: Nick Desaulniers <ndesaulniers@google.com>
    Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:47:50 -05:00
Mamatha Inamdar b51441d014 powerpc/code-patching: Use dedicated memory routines for patching 
JIRA: https://issues.redhat.com/browse/RHEL-14156

commit c3710ee7cd695dc1b0b4b8cfbf464e313467f970
Author: Benjamin Gray <bgray@linux.ibm.com>
Date:   Mon Mar 25 16:28:15 2024 +1100

    powerpc/code-patching: Use dedicated memory routines for patching

    The patching page set up as a writable alias may be in quadrant 0
    (userspace) if the temporary mm path is used. This causes sanitiser
    failures if so. Sanitiser failures also occur on the non-mm path
    because the plain memset family is instrumented, and KASAN treats the
    patching window as poisoned.

    Introduce locally defined patch_* variants of memset that perform an
    uninstrumented lower level set, as well as detecting write errors like
    the original single patch variant does.

    copy_to_user() is not correct here, as the PTE makes it a proper kernel
    page (the EAA is privileged access only, RW). It just happens to be in
    quadrant 0 because that's the hardware's mechanism for using the current
    PID vs PID 0 in translations. Importantly, it's incorrect to allow user
    page accesses.

    Now that the patching memsets are used, we also propagate a failure up
    to the caller as the single patch variant does.

    Signed-off-by: Benjamin Gray <bgray@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240325052815.854044-2-bgray@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:47:46 -05:00
Mamatha Inamdar 8bbb9e7ded powerpc/ftrace: Ignore ftrace locations in exit text sections 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit ea73179e6413. Conflicts in ftrace.h file
	resolved appropriately owing to missing commits d95bf254be5f &
	f3993a0330e2. Conflict in sections.h file due to missing commit
	b150a4d12b91 resolved. Conflict due to missing commit c2cba93d1a5e
	resolved in ftrace.c.

commit ea73179e64131bcd29ba6defd33732abdf8ca14b
Author: Naveen N Rao <naveen@kernel.org>
Date:   Tue Feb 13 23:24:10 2024 +0530

    powerpc/ftrace: Ignore ftrace locations in exit text sections

    Michael reported that we are seeing an ftrace bug on bootup when KASAN
    is enabled and we are using -fpatchable-function-entry:

      ftrace: allocating 47780 entries in 18 pages
      ftrace-powerpc: 0xc0000000020b3d5c: No module provided for non-kernel address
      ------------[ ftrace bug ]------------
      ftrace faulted on modifying
      [<c0000000020b3d5c>] 0xc0000000020b3d5c
      Initializing ftrace call sites
      ftrace record flags: 0
       (0)
       expected tramp: c00000000008cef4
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:2180 ftrace_bug+0x3c0/0x424
      Modules linked in:
      CPU: 0 PID: 0 Comm: swapper Not tainted 6.5.0-rc3-00120-g0f71dcfb4aef #860
      Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries
      NIP:  c0000000003aa81c LR: c0000000003aa818 CTR: 0000000000000000
      REGS: c0000000033cfab0 TRAP: 0700   Not tainted  (6.5.0-rc3-00120-g0f71dcfb4aef)
      MSR:  8000000002021033 <SF,VEC,ME,IR,DR,RI,LE>  CR: 28028240  XER: 00000000
      CFAR: c0000000002781a8 IRQMASK: 3
      ...
      NIP [c0000000003aa81c] ftrace_bug+0x3c0/0x424
      LR [c0000000003aa818] ftrace_bug+0x3bc/0x424
      Call Trace:
       ftrace_bug+0x3bc/0x424 (unreliable)
       ftrace_process_locs+0x5f4/0x8a0
       ftrace_init+0xc0/0x1d0
       start_kernel+0x1d8/0x484

    With CONFIG_FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY=y and
    CONFIG_KASAN=y, compiler emits nops in functions that it generates for
    registering and unregistering global variables (unlike with -pg and
    -mprofile-kernel where calls to _mcount() are not generated in those
    functions). Those functions then end up in INIT_TEXT and EXIT_TEXT
    respectively. We don't expect to see any profiled functions in
    EXIT_TEXT, so ftrace_init_nop() assumes that all addresses that aren't
    in the core kernel text belongs to a module. Since these functions do
    not match that criteria, we see the above bug.

    Address this by having ftrace ignore all locations in the text exit
    sections of vmlinux.

    Fixes: 0f71dcfb4aef ("powerpc/ftrace: Add support for -fpatchable-function-entry")
    Cc: stable@vger.kernel.org # v6.6+
    Reported-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Reviewed-by: Benjamin Gray <bgray@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240213175410.1091313-1-naveen@kernel.org

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:47:41 -05:00
Mamatha Inamdar 4a37497304 powerpc: Fix build issue with LD_DEAD_CODE_DATA_ELIMINATION and FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit 60d77ed24bb3. Conflict due to missing
	commit f8b2336f15f3 resolved appropriately.

commit 60d77ed24bb3068c0837fe45b8921b0a6598829d
Author: Naveen N Rao <naveen@kernel.org>
Date:   Wed Sep 13 19:11:29 2023 +0530

    powerpc: Fix build issue with LD_DEAD_CODE_DATA_ELIMINATION and FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY

    We recently added support for -fpatchable-function-entry and it is
    enabled by default on ppc32 (ppc64 needs gcc v13.1.0). When building the
    kernel for ppc32 and also enabling CONFIG_LD_DEAD_CODE_DATA_ELIMINATION,
    we see the below build error with older gcc versions:
      powerpc-linux-gnu-ld: init/main.o(__patchable_function_entries): error: need linked-to section for --gc-sections

    This error is thrown since __patchable_function_entries section would be
    garbage collected with --gc-sections since it does not reference any
    other kept sections. This has subsequently been fixed with:
      https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=b7d072167715829eed0622616f6ae0182900de3e

    Disable LD_DEAD_CODE_DATA_ELIMINATION for gcc versions before v11.1.0 if
    using -fpatchable-function-entry to avoid this bug.

    Fixes: 0f71dcfb4aef ("powerpc/ftrace: Add support for -fpatchable-function-entry")
    Reported-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20230913134129.2782088-1-naveen@kernel.org

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:47:36 -05:00
Mamatha Inamdar c3aeb79032 powerpc/ftrace: Add support for -fpatchable-function-entry 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit 0f71dcfb4aef. Dropped some hunks that
	depend on missing commits e52ec98c5ab1, 7af82ff90a2b and resolved
	conflicts due to missing PPC32 specific changes like 7dfbfb87c243.
	Also, since commit 5017b4594672 to be able to build big endian with
	ELFv2 ABI is not part of this build, restrict support for
	ARCH_USING_PATCHABLE_FUNCTION_ENTRY to little endian ELFv2 ABI only.

commit 0f71dcfb4aef6043da6cc509e7a7f6a3ae87c12d
Author: Naveen N Rao <naveen@kernel.org>
Date:   Mon Jun 19 15:17:34 2023 +0530

    powerpc/ftrace: Add support for -fpatchable-function-entry

    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 local entry point, or before the global entry point.

    With -fpatchable-function-entry, we no longer have the profiling
    instructions generated at function entry, so we only need to validate
    the presence of two nops at the ftrace location in ftrace_init_nop(). We
    patch the preceding instruction with 'mflr r0' to match the
    -mprofile-kernel ABI for subsequent ftrace use.

    This changes the profiling instructions used on ppc32. The default -pg
    option emits an additional 'stw' instruction after 'mflr r0' and before
    the branch to _mcount 'bl _mcount'. This is very similar to the original
    -mprofile-kernel implementation on ppc64le, where an additional 'std'
    instruction was used to save LR to its save location in the caller's
    stackframe. Subsequently, this additional store was removed in later
    compiler versions for performance reasons. The same reasons apply for
    ppc32 so we only patch in a 'mflr r0'.

    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/68586d22981a2c3bb45f27a2b621173d10a7d092.1687166935.git.naveen@kernel.org

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:47:31 -05:00
Mamatha Inamdar fef83dc822 powerpc/ftrace: Implement ftrace_replace_code() 
JIRA: https://issues.redhat.com/browse/RHEL-14156

commit c91c5a828685563c24ab8879d8386de356d9085a
Author: Naveen N Rao <naveen@kernel.org>
Date:   Mon Jun 19 15:17:33 2023 +0530

    powerpc/ftrace: Implement ftrace_replace_code()

    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 should no longer be called.

    This lays the groundwork to enable better control in patching ftrace
    locations, including the ability to nop-out preceding profiling
    instructions when ftrace is disabled.

    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/c28f852225646b0561bbf3c1d22d03f041ace8e0.1687166935.git.naveen@kernel.org

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:47:17 -05:00
Mamatha Inamdar c73bcd6ddf powerpc/ftrace: Replace use of ftrace_call_replace() with ftrace_create_branch_inst() 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit a26ce4272eea with conflicts due to missing
	commits 96d7a13610ab, af8b9f352ffd & cf9df92a823c resolved appropriately.

commit a26ce4272eea2b20d4f39b9d7e56daf0c77151d8
Author: Naveen N Rao <naveen@kernel.org>
Date:   Mon Jun 19 15:17:32 2023 +0530

    powerpc/ftrace: Replace use of ftrace_call_replace() with ftrace_create_branch_inst()

    ftrace_create_branch_inst() is clearer about its intent than
    ftrace_call_replace().

    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/953513b88fa922ba7a66d772dc1310710efe9177.1687166935.git.naveen@kernel.org

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:47:12 -05:00
Mamatha Inamdar 44ef2e69f9 powerpc/ftrace: Simplify ftrace_modify_call() 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit 67385738e3c2 with conflicts resolved due
	to missing cleanup patches from Christophe.

commit 67385738e3c248673668663ffb434ae4e0abf7f1
Author: Naveen N Rao <naveen@kernel.org>
Date:   Mon Jun 19 15:17:31 2023 +0530

    powerpc/ftrace: Simplify ftrace_modify_call()

    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 instruction at the ftrace location before
    patching it with the updated branch destination.

    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/06275720939f8ee4c2f61c9e9a3e89b1fa3c441d.1687166935.git.naveen@kernel.org

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:47:08 -05:00
Mamatha Inamdar 518eb027fc powerpc/ftrace: Simplify ftrace_make_call() 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit 9365e23b15f2 with conflicts due to
	missing PPC32 and IS_ENABLED changes.

commit 9365e23b15f28b7b3b333a7fc6f4c8e9464ca99f
Author: Naveen N Rao <naveen@kernel.org>
Date:   Mon Jun 19 15:17:30 2023 +0530

    powerpc/ftrace: Simplify ftrace_make_call()

    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 patching it.

    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/2d28866d2f556488a663981abe5621511efb207b.1687166935.git.naveen@kernel.org

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:47:02 -05:00
Mamatha Inamdar 56ae4724d6 powerpc/ftrace: Simplify ftrace_make_nop() 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit 562bde0bfc96. Conflicts due to missing
	cleanup patches around ppc_inst_as_ulong() and IS_ENABLED() resolved
	appropriately.

commit 562bde0bfc968d212d10ba6bf921a0774feebbac
Author: Naveen N Rao <naveen@kernel.org>
Date:   Mon Jun 19 15:17:29 2023 +0530

    powerpc/ftrace: Simplify ftrace_make_nop()

    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 ftrace location before nop-ing it out.

    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/e12ccbf28c50c3a07fb614f4d392e55f7098a729.1687166935.git.naveen@kernel.org

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:46:56 -05:00
Mamatha Inamdar 37e19acc76 powerpc/ftrace: Add separate ftrace_init_nop() with additional validation 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Upstream commit cc93b9233230 backported by resolving conflict due to
	missing commit 76222808fc25 ("powerpc: Move C prototypes out of
	asm-prototypes.h").

commit cc93b9233230312a8a905fabd590c405d60f9edd
Author: Naveen N Rao <naveen@kernel.org>
Date:   Mon Jun 19 15:17:28 2023 +0530

    powerpc/ftrace: Add separate ftrace_init_nop() with additional validation

    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.

    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/f373684081e8e98be09b7f44d2d93069768324dc.1687166935.git.naveen@kernel.org

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:46:52 -05:00
Mamatha Inamdar 92d4d58864 powerpc/ftrace: Stop re-purposing linker generated long branches for ftrace 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit 33bb8a0be9c8 adjusted to handle missing
	cleanup and optimization commits like af8b9f352ffd, e89aa642be21 &
	ae3a2a218821.

commit 33bb8a0be9c826fce545ae390ecaf91e96b5db43
Author: Naveen N Rao <naveen@kernel.org>
Date:   Mon Jun 19 15:17:27 2023 +0530

    powerpc/ftrace: Stop re-purposing linker generated long branches for ftrace

    Commit 67361cf807 ("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. Re-purpose linker-generated long branches to _mcount to instead branch
       to ftrace_[regs_]caller.

    Before that, we only supported kernel .text up to ~32MB. With the above,
    we now support up to ~96MB:
    - The first 32MB of kernel text can branch directly into
      ftrace_[regs_]caller since that symbol is usually at the beginning.
    - The modified long_branch from (2) above is used by the next 32MB of
      kernel text.
    - The next 32MB of kernel text can use the stub at the end of text to
      branch back to ftrace_[regs_]caller.

    While re-purposing the long branch works in practice, it still restricts
    ftrace to kernel text up to ~96MB. The stub at the end of kernel text
    from (1) already enables us to extend ftrace support for kernel text
    up to 64MB, which fulfils the original requirement. Further, once we
    switch to -fpatchable-function-entry, there will not be a long branch
    that we can use.

    Stop re-purposing the linker-generated long branches for ftrace to
    simplify the code. If there are good reasons to support ftrace on
    kernels beyond 64MB, we can consider adding support by using
    -fpatchable-function-entry.

    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/33fa3be97f8e1f2171254ef2e1b0d5c8836c11fd.1687166935.git.naveen@kernel.org

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:46:47 -05:00
Mamatha Inamdar 47da7d1a87 powerpc/ftrace: Refactor ftrace_modify_code() 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit f4fcbf2e093e adjusting for some missing
	cleanup and optimization patches like 2a83afe72a2b5 and bbffdd2fc743.

commit f4fcbf2e093e25a7faa8a3c2a5097524114e9547
Author: Naveen N Rao <naveen@kernel.org>
Date:   Mon Jun 19 15:17:26 2023 +0530

    powerpc/ftrace: Refactor ftrace_modify_code()

    Split up ftrace_modify_code() into a few helpers for future use. Also
    update error messages accordingly.

    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/a8daa49712b44ff539e6c22a2ea649a540386798.1687166935.git.naveen@kernel.org

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:46:43 -05:00
Mamatha Inamdar 63f75075ae powerpc/ftrace: Simplify function_graph support in ftrace.c 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit 96d7a13610ab. Minor conflict due to
	missing commit 7f7797b37269 resolved accordingly.

commit 96d7a13610abcf6bff9d0d0e195c6d2650310125
Author: Naveen N Rao <naveen@kernel.org>
Date:   Mon Jun 19 15:17:22 2023 +0530

    powerpc/ftrace: Simplify function_graph support in ftrace.c

    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 <naveen@kernel.org>
    Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/4dc92c4b1ed444dc62b748ae7327acdb9e096864.1687166935.git.naveen@kernel.org

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:46:39 -05:00
Mamatha Inamdar 1f2d4d0e5a powerpc/ftrace: Use patch_instruction() return directly 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit bbffdd2fc743 with conflict owing to
	inclusion of commit 74726fda9fe3 in the build resolved appropriately.

commit bbffdd2fc743bdc529f9a8264bdb5d3491f58c95
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Mon May 9 07:36:05 2022 +0200

    powerpc/ftrace: Use patch_instruction() return directly

    Instead of returning -EPERM when patch_instruction() fails,
    just return what patch_instruction returns.

    That simplifies ftrace_modify_code():

               0:   94 21 ff c0     stwu    r1,-64(r1)
               4:   93 e1 00 3c     stw     r31,60(r1)
               8:   7c 7f 1b 79     mr.     r31,r3
               c:   40 80 00 30     bge     3c <ftrace_modify_code+0x3c>
              10:   93 c1 00 38     stw     r30,56(r1)
              14:   7c 9e 23 78     mr      r30,r4
              18:   7c a4 2b 78     mr      r4,r5
              1c:   80 bf 00 00     lwz     r5,0(r31)
              20:   7c 1e 28 40     cmplw   r30,r5
              24:   40 82 00 34     bne     58 <ftrace_modify_code+0x58>
              28:   83 c1 00 38     lwz     r30,56(r1)
              2c:   7f e3 fb 78     mr      r3,r31
              30:   83 e1 00 3c     lwz     r31,60(r1)
              34:   38 21 00 40     addi    r1,r1,64
              38:   48 00 00 00     b       38 <ftrace_modify_code+0x38>
                                    38: R_PPC_REL24 patch_instruction

    Before:

               0:   94 21 ff c0     stwu    r1,-64(r1)
               4:   93 e1 00 3c     stw     r31,60(r1)
               8:   7c 7f 1b 79     mr.     r31,r3
               c:   40 80 00 4c     bge     58 <ftrace_modify_code+0x58>
              10:   93 c1 00 38     stw     r30,56(r1)
              14:   7c 9e 23 78     mr      r30,r4
              18:   7c a4 2b 78     mr      r4,r5
              1c:   80 bf 00 00     lwz     r5,0(r31)
              20:   7c 08 02 a6     mflr    r0
              24:   90 01 00 44     stw     r0,68(r1)
              28:   7c 1e 28 40     cmplw   r30,r5
              2c:   40 82 00 48     bne     74 <ftrace_modify_code+0x74>
              30:   7f e3 fb 78     mr      r3,r31
              34:   48 00 00 01     bl      34 <ftrace_modify_code+0x34>
                                    34: R_PPC_REL24 patch_instruction
              38:   80 01 00 44     lwz     r0,68(r1)
              3c:   20 63 00 00     subfic  r3,r3,0
              40:   83 c1 00 38     lwz     r30,56(r1)
              44:   7c 63 19 10     subfe   r3,r3,r3
              48:   7c 08 03 a6     mtlr    r0
              4c:   83 e1 00 3c     lwz     r31,60(r1)
              50:   38 21 00 40     addi    r1,r1,64
              54:   4e 80 00 20     blr

    It improves ftrace activation/deactivation duration by about 3%.

    Modify patch_instruction() return on failure to -EPERM in order to
    match with ftrace expectations. Other users of patch_instruction()
    do not care about the exact error value returned.

    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/49a8597230713e2633e7d9d7b56140787c4a7e20.1652074503.git.christophe.leroy@csgroup.eu

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:46:35 -05:00
Mamatha Inamdar ece5ef0767 powerpc/ftrace: Refactor prepare_ftrace_return() 
JIRA: https://issues.redhat.com/browse/RHEL-14156

commit d996d5053eb5c0abc0358e5670014a62ada6967e
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Mon May 9 07:35:59 2022 +0200

    powerpc/ftrace: Refactor prepare_ftrace_return()

    When we have CONFIG_DYNAMIC_FTRACE_WITH_ARGS,
    prepare_ftrace_return() is called by ftrace_graph_func()
    otherwise prepare_ftrace_return() is called from assembly.

    Refactor prepare_ftrace_return() into a static
    __prepare_ftrace_return() that will be called by both
    prepare_ftrace_return() and ftrace_graph_func().

    It will allow GCC to fold __prepare_ftrace_return() inside
    ftrace_graph_func().

    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/0d42deafe353980c66cf19d3132638c05ba9f4a9.1652074503.git.christophe.leroy@csgroup.eu

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:46:30 -05:00
Mamatha Inamdar 98a093fab4 powerpc/ftrace: Have arch_ftrace_get_regs() return NULL unless FL_SAVE_REGS is set 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit fc75f8733798. Resolved conflict owing to
	missing arch/powerpc/kernel/trace/ftrace_mprofile.S file. Also,
	conflict owing to inclusion of commits 0ef86097f127 & 40b035efe288
	resolved appropriately.

commit fc75f87337983229b7355d6b77f30fb6e7f359ee
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Tue Feb 15 19:31:24 2022 +0100

    powerpc/ftrace: Have arch_ftrace_get_regs() return NULL unless FL_SAVE_REGS is set

    When FL_SAVE_REGS is not set we get here via ftrace_caller()
    which doesn't save all registers.

    ftrace_caller() explicitely clears regs.msr, so we can rely
    on it to know where we come from. We don't expect MSR register
    to be 0 at all when involving ftrace.

    Fixes: 40b035efe288 ("powerpc/ftrace: Implement CONFIG_DYNAMIC_FTRACE_WITH_ARGS")
    Reported-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/2f9a7e898c93cc7438ef5ccd47cb9c3a9c5b53ef.1644949750.git.christophe.leroy@csgroup.eu

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:46:26 -05:00
Mamatha Inamdar a6ccb23e76 powerpc/ftrace: Add recursion protection in prepare_ftrace_return() 
JIRA: https://issues.redhat.com/browse/RHEL-14156

commit df45a55788286c541449d82ee09fef3ac5ff77a1
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Tue Feb 15 19:31:23 2022 +0100

    powerpc/ftrace: Add recursion protection in prepare_ftrace_return()

    The function_graph_enter() does not provide any recursion protection.

    Add a protection in prepare_ftrace_return() in case
    function_graph_enter() calls something that gets
    function graph traced.

    Fixes: 830213786c49 ("powerpc/ftrace: directly call of function graph tracer by ftrace caller")
    Reported-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/74edf2ff0a60e66b0d9225a137100a86a0557032.1644949750.git.christophe.leroy@csgroup.eu

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:46:22 -05:00
Mamatha Inamdar 421278ed38 powerpc/ftrace: Also save r1 in ftrace_caller() 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit 34d8dac807f0. Resolved conflict owing
	to missing arch/powerpc/kernel/trace/ftrace_mprofile.S file.

commit 34d8dac807f0ee3dc42ab45bdb284a3caf2b5ed1
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Tue Feb 15 19:31:22 2022 +0100

    powerpc/ftrace: Also save r1 in ftrace_caller()

    Also save r1 in ftrace_caller()

    r1 is needed during unwinding when the function_graph tracer
    is active.

    Fixes: 830213786c49 ("powerpc/ftrace: directly call of function graph tracer by ftrace caller")
    Reported-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/ff535e86d3a69376a6d89168511d4e403835f18b.1644949750.git.christophe.leroy@csgroup.eu

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:46:17 -05:00
Mamatha Inamdar 32894e8f17 powerpc/ftrace: directly call of function graph tracer by ftrace caller 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Dropped ppc32 changes in this backport of upstream commit 830213786c49.
	Also, the backport of upstream commit 94d095ffa0e1 for RHEL-101598
	dropped the powerpc hunk. Include the missed powerpc hunk, from
	the backport of commit 94d095ffa0e1, while we are here.

commit 830213786c498b0c488fedd2abc15a7ce442b42f
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Mon Dec 20 16:38:35 2021 +0000

    powerpc/ftrace: directly call of function graph tracer by ftrace caller

    Modify function graph tracer to be handled directly by the standard
    ftrace caller.

    This is made possible as powerpc now supports
    CONFIG_DYNAMIC_FTRACE_WITH_ARGS.

    This change simplifies the call of function graph ftrace.

    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/04d196585ff81bde06a000bd9c633a33a5b21130.1640017960.git.christophe.leroy@csgroup.eu

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:46:12 -05:00
Mamatha Inamdar 2f007210aa powerpc/ftrace: Refactor ftrace_{en/dis}able_ftrace_graph_caller 
JIRA: https://issues.redhat.com/browse/RHEL-14156

commit 0c81ed5ed43863d313cf253b0ebada6ea2f17676
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Mon Dec 20 16:38:31 2021 +0000

    powerpc/ftrace: Refactor ftrace_{en/dis}able_ftrace_graph_caller

    ftrace_enable_ftrace_graph_caller() and
    ftrace_disable_ftrace_graph_caller() have common code.

    They will have even more common code after following patch.

    Refactor into a single ftrace_modify_ftrace_graph_caller() function.

    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/f37785a531f1a8f201e1b3da45997a5c77e9d820.1640017960.git.christophe.leroy@csgroup.eu

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:46:08 -05:00
Mamatha Inamdar ee0100d3b4 powerpc/ftrace: Implement CONFIG_DYNAMIC_FTRACE_WITH_ARGS 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit 40b035efe288. Resolved conflicts due to
	missing PPC32 related commits like 7dfbfb87c243c. Also, commit
	0ef86097f127 is already part of this build but with powerpc hunk
	dropped in the backport. Account for the dropped powerpc hunk of
	the backport of commit 0ef86097f127 (RHEL-101598) and make the
	appropriate change in arch-specific livepatch header as well.

commit 40b035efe288f42bbf4483236cde652584ccb64e
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Mon Dec 20 16:38:28 2021 +0000

    powerpc/ftrace: Implement CONFIG_DYNAMIC_FTRACE_WITH_ARGS

    Implement CONFIG_DYNAMIC_FTRACE_WITH_ARGS. It accelerates the call
    of livepatching.

    Also note that powerpc being the last one to convert to
    CONFIG_DYNAMIC_FTRACE_WITH_ARGS, it will now be possible to remove
    klp_arch_set_pc() on all architectures.

    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/5831f711a778fcd6eb51eb5898f1faae4378b35b.1640017960.git.christophe.leroy@csgroup.eu

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:46:04 -05:00
Mamatha Inamdar 3ba3f26252 powerpc/ftrace: Prepare PPC64's ftrace_caller() for CONFIG_DYNAMIC_FTRACE_WITH_ARGS 
JIRA: https://issues.redhat.com/browse/RHEL-14156

Conflicts:
	Backport of upstream commit c75388a8ceff with CONFIG_LIVEPATCH
	instead of CONFIG_LIVEPATCH_64 to avoid entangling with PPC32
	livepatch changes. Also, accounted for commit 41a506ef71eb
	("powerpc/ftrace: Create a dummy stackframe to fix stack unwind")
	backported to fix IBM Bug 207308 (RHEL-56343). Additionally,
	drop the inconsequential restore of r0 in ftrace_regs_caller()
	as r0 is subsequently loaded with the possibly modified LR
	anyway. Note that commit 41315494beed has done this change
	without explicitly mentioning it.

commit c75388a8ceffbf1bf72c61afe66a72e58aa20c74
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Mon Dec 20 16:38:25 2021 +0000

    powerpc/ftrace: Prepare PPC64's ftrace_caller() for CONFIG_DYNAMIC_FTRACE_WITH_ARGS

    In order to implement CONFIG_DYNAMIC_FTRACE_WITH_ARGS, change ftrace_caller()
    to handle LIVEPATCH the same way as frace_caller_regs().

    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/850817333cc76593699032e8e9a70d8c36e1af1e.1640017960.git.christophe.leroy@csgroup.eu

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-22 06:45:59 -05:00
Mamatha Inamdar 1f714a1eb2 powerpc/kexec: Enable SMT before waking offline CPUs 
JIRA: https://issues.redhat.com/browse/RHEL-137134

commit c2296a1e42418556efbeb5636c4fa6aa6106713a
Author: Nysal Jan K.A. <nysal@linux.ibm.com>
Date:   Tue Oct 28 16:25:12 2025 +0530

    powerpc/kexec: Enable SMT before waking offline CPUs

    If SMT is disabled or a partial SMT state is enabled, when a new kernel
    image is loaded for kexec, on reboot the following warning is observed:

    kexec: Waking offline cpu 228.
    WARNING: CPU: 0 PID: 9062 at arch/powerpc/kexec/core_64.c:223 kexec_prepare_cpus+0x1b0/0x1bc
    [snip]
     NIP kexec_prepare_cpus+0x1b0/0x1bc
     LR  kexec_prepare_cpus+0x1a0/0x1bc
     Call Trace:
      kexec_prepare_cpus+0x1a0/0x1bc (unreliable)
      default_machine_kexec+0x160/0x19c
      machine_kexec+0x80/0x88
      kernel_kexec+0xd0/0x118
      __do_sys_reboot+0x210/0x2c4
      system_call_exception+0x124/0x320
      system_call_vectored_common+0x15c/0x2ec

    This occurs as add_cpu() fails due to cpu_bootable() returning false for
    CPUs that fail the cpu_smt_thread_allowed() check or non primary
    threads if SMT is disabled.

    Fix the issue by enabling SMT and resetting the number of SMT threads to
    the number of threads per core, before attempting to wake up all present
    CPUs.

    Fixes: 38253464bc82 ("cpu/SMT: Create topology_smt_thread_allowed()")
    Reported-by: Sachin P Bappalige <sachinpb@linux.ibm.com>
    Cc: stable@vger.kernel.org # v6.6+
    Reviewed-by: Srikar Dronamraju <srikar@linux.ibm.com>
    Signed-off-by: Nysal Jan K.A. <nysal@linux.ibm.com>
    Tested-by: Samir M <samir@linux.ibm.com>
    Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20251028105516.26258-1-nysal@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-06 03:57:07 -05:00
Mamatha Inamdar 82fa202774 powerpc/64s/slb: Fix SLB multihit issue during SLB preload 
JIRA: https://issues.redhat.com/browse/RHEL-104980

commit 00312419f0863964625d6dcda8183f96849412c6
Author: Donet Tom <donettom@linux.ibm.com>
Date:   Thu Oct 30 20:27:26 2025 +0530

    powerpc/64s/slb: Fix SLB multihit issue during SLB preload

    On systems using the hash MMU, there is a software SLB preload cache that
    mirrors the entries loaded into the hardware SLB buffer. This preload
    cache is subject to periodic eviction — typically after every 256 context
    switches — to remove old entry.

    To optimize performance, the kernel skips switch_mmu_context() in
    switch_mm_irqs_off() when the prev and next mm_struct are the same.
    However, on hash MMU systems, this can lead to inconsistencies between
    the hardware SLB and the software preload cache.

    If an SLB entry for a process is evicted from the software cache on one
    CPU, and the same process later runs on another CPU without executing
    switch_mmu_context(), the hardware SLB may retain stale entries. If the
    kernel then attempts to reload that entry, it can trigger an SLB
    multi-hit error.

    The following timeline shows how stale SLB entries are created and can
    cause a multi-hit error when a process moves between CPUs without a
    MMU context switch.

    CPU 0                                   CPU 1
    -----                                    -----
    Process P
    exec                                    swapper/1
     load_elf_binary
      begin_new_exc
        activate_mm
         switch_mm_irqs_off
          switch_mmu_context
           switch_slb
           /*
            * This invalidates all
            * the entries in the HW
            * and setup the new HW
            * SLB entries as per the
            * preload cache.
            */
    context_switch
    sched_migrate_task migrates process P to cpu-1

    Process swapper/0                       context switch (to process P)
    (uses mm_struct of Process P)           switch_mm_irqs_off()
                                             switch_slb
                                               load_slb++
                                                /*
                                                * load_slb becomes 0 here
                                                * and we evict an entry from
                                                * the preload cache with
                                                * preload_age(). We still
                                                * keep HW SLB and preload
                                                * cache in sync, that is
                                                * because all HW SLB entries
                                                * anyways gets evicted in
                                                * switch_slb during SLBIA.
                                                * We then only add those
                                                * entries back in HW SLB,
                                                * which are currently
                                                * present in preload_cache
                                                * (after eviction).
                                                */
                                            load_elf_binary continues...
                                             setup_new_exec()
                                              slb_setup_new_exec()

                                            sched_switch event
                                            sched_migrate_task migrates
                                            process P to cpu-0

    context_switch from swapper/0 to Process P
     switch_mm_irqs_off()
      /*
       * Since both prev and next mm struct are same we don't call
       * switch_mmu_context(). This will cause the HW SLB and SW preload
       * cache to go out of sync in preload_new_slb_context. Because there
       * was an SLB entry which was evicted from both HW and preload cache
       * on cpu-1. Now later in preload_new_slb_context(), when we will try
       * to add the same preload entry again, we will add this to the SW
       * preload cache and then will add it to the HW SLB. Since on cpu-0
       * this entry was never invalidated, hence adding this entry to the HW
       * SLB will cause a SLB multi-hit error.
       */
    load_elf_binary continues...
     START_THREAD
      start_thread
       preload_new_slb_context
       /*
        * This tries to add a new EA to preload cache which was earlier
        * evicted from both cpu-1 HW SLB and preload cache. This caused the
        * HW SLB of cpu-0 to go out of sync with the SW preload cache. The
        * reason for this was, that when we context switched back on CPU-0,
        * we should have ideally called switch_mmu_context() which will
        * bring the HW SLB entries on CPU-0 in sync with SW preload cache
        * entries by setting up the mmu context properly. But we didn't do
        * that since the prev mm_struct running on cpu-0 was same as the
        * next mm_struct (which is true for swapper / kernel threads). So
        * now when we try to add this new entry into the HW SLB of cpu-0,
        * we hit a SLB multi-hit error.
        */

    WARNING: CPU: 0 PID: 1810970 at arch/powerpc/mm/book3s64/slb.c:62
    assert_slb_presence+0x2c/0x50(48 results) 02:47:29 [20157/42149]
    Modules linked in:
    CPU: 0 UID: 0 PID: 1810970 Comm: dd Not tainted 6.16.0-rc3-dirty #12
    VOLUNTARY
    Hardware name: IBM pSeries (emulated by qemu) POWER8 (architected)
    0x4d0200 0xf000004 of:SLOF,HEAD hv:linux,kvm pSeries
    NIP:  c00000000015426c LR: c0000000001543b4 CTR: 0000000000000000
    REGS: c0000000497c77e0 TRAP: 0700   Not tainted  (6.16.0-rc3-dirty)
    MSR:  8000000002823033 <SF,VEC,VSX,FP,ME,IR,DR,RI,LE>  CR: 28888482  XER: 00000000
    CFAR: c0000000001543b0 IRQMASK: 3
    <...>
    NIP [c00000000015426c] assert_slb_presence+0x2c/0x50
    LR [c0000000001543b4] slb_insert_entry+0x124/0x390
    Call Trace:
      0x7fffceb5ffff (unreliable)
      preload_new_slb_context+0x100/0x1a0
      start_thread+0x26c/0x420
      load_elf_binary+0x1b04/0x1c40
      bprm_execve+0x358/0x680
      do_execveat_common+0x1f8/0x240
      sys_execve+0x58/0x70
      system_call_exception+0x114/0x300
      system_call_common+0x160/0x2c4

    >From the above analysis, during early exec the hardware SLB is cleared,
    and entries from the software preload cache are reloaded into hardware
    by switch_slb. However, preload_new_slb_context and slb_setup_new_exec
    also attempt to load some of the same entries, which can trigger a
    multi-hit. In most cases, these additional preloads simply hit existing
    entries and add nothing new. Removing these functions avoids redundant
    preloads and eliminates the multi-hit issue. This patch removes these
    two functions.

    We tested process switching performance using the context_switch
    benchmark on POWER9/hash, and observed no regression.

    Without this patch: 129041 ops/sec
    With this patch:    129341 ops/sec

    We also measured SLB faults during boot, and the counts are essentially
    the same with and without this patch.

    SLB faults without this patch: 19727
    SLB faults with this patch:    19786

    Fixes: 5434ae7462 ("powerpc/64s/hash: Add a SLB preload cache")
    cc: stable@vger.kernel.org
    Suggested-by: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Donet Tom <donettom@linux.ibm.com>
    Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/0ac694ae683494fe8cadbd911a1a5018d5d3c541.1761834163.git.ritesh.list@gmail.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2026-01-05 01:51:58 -05:00
Mamatha Inamdar 6c9e61016b powerpc/64s: Fix VAS mm use after free 
JIRA: https://issues.redhat.com/browse/RHEL-133781

commit b4bda59b47879cce38a6ec5a01cd3cac702b5331
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Wed Jun 7 20:10:24 2023 +1000

    powerpc/64s: Fix VAS mm use after free

    The refcount on mm is dropped before the coprocessor is detached.

    Reported-by: Sachin Sant <sachinp@linux.ibm.com>
    Fixes: 7bc6f71bdf ("powerpc/vas: Define and use common vas_window struct")
    Fixes: b22f2d88e4 ("powerpc/pseries/vas: Integrate API with open/close windows")
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    Tested-by: Sachin Sant <sachinp@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20230607101024.14559-1-npiggin@gmail.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2025-12-09 00:41:34 -05:00
Mamatha Inamdar 99cadfeb8e docs: powerpc: Add htm.rst to table of contents 
JIRA: https://issues.redhat.com/browse/RHEL-52755

commit c361f76da69624ed83d208fbb704d54ae491c52e
Author: Brigham Campbell <me@brighamcampbell.com>
Date:   Tue May 27 23:41:47 2025 -0600

    docs: powerpc: Add htm.rst to table of contents

    Fix the following documentation build error, which was introduced when
    Documentation/arch/powerpc/htm.rst was added to the repository without
    any reference to the document.

    Documentation/arch/powerpc/htm.rst: WARNING: document isn't included in any toctree [toc.not_included]

    Fixes: ab1456c5aa7a ("powerpc/pseries/htmdump: Add documentation for H_HTM debugfs interface")
    Acked-by: Randy Dunlap <rdunlap@infradead.org>
    Tested-by: Randy Dunlap <rdunlap@infradead.org>
    Signed-off-by: Brigham Campbell <me@brighamcampbell.com>
    Tested-by: Athira Rajeev <atrajeev@linux.ibm.com>
    Fixes: ab1456c5aa7a63d5 ("powerpc/pseries/htmdump: Add documentation for H_HTM debugfs interface")
    Signed-off-by: Jonathan Corbet <corbet@lwn.net>
    Link: https://lore.kernel.org/r/20250528054146.2658537-2-me@brighamcampbell.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2025-11-28 05:17:45 -05:00
Mamatha Inamdar 103d7c1dfb Add CONFIG_HTMDUMP 
JIRA: https://issues.redhat.com/browse/RHEL-52755

Upstream Status: RHEL Only

commit ebc07e5487d9d973b84381b0e8a4a84caad23b18
Author: Mamatha Inamdar <minamdar@redhat.com>
Date:   Fri Nov 28 04:12:50 2025 -0500

    Add CONFIG_HTMDUMP

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2025-11-28 04:35:43 -05:00
Mamatha Inamdar 332b710963 powerpc/pseries/htmdump: Add documentation for H_HTM debugfs interface 
JIRA: https://issues.redhat.com/browse/RHEL-52755

commit ab1456c5aa7a63d5145547fc644bd4580dd253f2
Author: Athira Rajeev <atrajeev@linux.ibm.com>
Date:   Sun Apr 20 23:38:44 2025 +0530

    powerpc/pseries/htmdump: Add documentation for H_HTM debugfs interface

    Documentation for HTM (Hardware Trace Macro) debugfs interface
    and how it can be used to configure/control the HTM operations.

    Signed-off-by: Athira Rajeev <atrajeev@linux.ibm.com>
    Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250420180844.53128-10-atrajeev@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2025-11-28 04:35:39 -05:00
Mamatha Inamdar 719cff6e90 powerpc/pseries/htmdump: Add htm capabilities support to htmdump module 
JIRA: https://issues.redhat.com/browse/RHEL-52755

commit 143a2584627cc02af81261c0201f9a69c08241a5
Author: Athira Rajeev <atrajeev@linux.ibm.com>
Date:   Sun Apr 20 23:38:43 2025 +0530

    powerpc/pseries/htmdump: Add htm capabilities support to htmdump module

    Support dumping HTM capabilities information from Hardware
    Trace Macro (HTM) function via debugfs interface. Under
    debugfs folder "/sys/kernel/debug/powerpc/htmdump", add
    file "htmcaps".

    The interface allows only read of this file which will present the
    content of HTM buffer from the hcall.

    Signed-off-by: Athira Rajeev <atrajeev@linux.ibm.com>
    Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250420180844.53128-9-atrajeev@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2025-11-28 04:35:34 -05:00
Mamatha Inamdar eddef6b2ea powerpc/pseries/htmdump: Add htm flags support to htmdump module 
JIRA: https://issues.redhat.com/browse/RHEL-52755

commit d3f24bf27b2de2bbf35faae72ca3a81e23ac9e22
Author: Athira Rajeev <atrajeev@linux.ibm.com>
Date:   Sun Apr 20 23:38:42 2025 +0530

    powerpc/pseries/htmdump: Add htm flags support to htmdump module

    Under debugfs folder, "/sys/kernel/debug/powerpc/htmdump", add file
    "htmflags". Currently supported flag value is to enable/disable
    HTM buffer wrap. wrap is used along with "configure" to prevent
    HTM buffer from wrapping. Writing 1 will set noWrap while
    configuring HTM

    Signed-off-by: Athira Rajeev <atrajeev@linux.ibm.com>
    Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250420180844.53128-8-atrajeev@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2025-11-28 04:35:25 -05:00
Mamatha Inamdar b2ceffd887 powerpc/pseries/htmdump: Add htm setup support to htmdump module 
JIRA: https://issues.redhat.com/browse/RHEL-52755

commit 78fb17ac68bf59e5e36212e34a2b05eec29a389f
Author: Athira Rajeev <atrajeev@linux.ibm.com>
Date:   Sun Apr 20 23:38:41 2025 +0530

    powerpc/pseries/htmdump: Add htm setup support to htmdump module

    Add htm setup support to htmdump module. To use the
    HTM (Hardware Trace Macro), HTM buffer has to be allocated.
    Support setup of HTM buffers via debugfs interface. Under
    debugfs folder, "/sys/kernel/debug/powerpc/htmdump", add file
    "htmsetup". The interface allows setup of HTM buffer by writing
    size of HTM buffer in power of 2 to the "htmsetup" file

    Signed-off-by: Athira Rajeev <atrajeev@linux.ibm.com>
    Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250420180844.53128-7-atrajeev@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2025-11-28 04:35:21 -05:00
Mamatha Inamdar b5eb295c45 powerpc/pseries/htmdump: Add htm info support to htmdump module 
JIRA: https://issues.redhat.com/browse/RHEL-52755

commit dea7384e14e7f9429021544d0d710fbef8445def
Author: Athira Rajeev <atrajeev@linux.ibm.com>
Date:   Sun Apr 20 23:38:40 2025 +0530

    powerpc/pseries/htmdump: Add htm info support to htmdump module

    Support dumping system processor configuration from Hardware
    Trace Macro (HTM) function via debugfs interface. Under
    debugfs folder "/sys/kernel/debug/powerpc/htmdump", add
    file "htminfo".

    The interface allows only read of this file which will present the
    content of HTM buffer from the hcall. The 16th offset of HTM
    buffer has value for the number of entries for array of processors.
    Use this information to copy data to the debugfs file

    Signed-off-by: Athira Rajeev <atrajeev@linux.ibm.com>
    Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250420180844.53128-6-atrajeev@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2025-11-28 04:35:15 -05:00
Mamatha Inamdar e07f2022ac powerpc/pseries/htmdump: Add htm status support to htmdump module 
JIRA: https://issues.redhat.com/browse/RHEL-52755

commit 627cf584f4c36acb52230ffc47403cf9469ec9d0
Author: Athira Rajeev <atrajeev@linux.ibm.com>
Date:   Sun Apr 20 23:38:39 2025 +0530

    powerpc/pseries/htmdump: Add htm status support to htmdump module

    Support dumping status of Hardware Trace Macro (HTM) function
    via debugfs interface. Under debugfs folder
    "/sys/kernel/debug/powerpc/htmdump", add file "htmstatus".
    The interface allows only read of this file which will present the
    content of HTM status buffer from the hcall. The 16th offset of HTM
    status buffer has value for the number of HTM entries in the status
    buffer. Each nest htm status entry is 0x6 bytes, where as core HTM
    status entry is 0x8 bytes. Calculate the number of bytes to read
    based on this detail.

    Signed-off-by: Athira Rajeev <atrajeev@linux.ibm.com>
    Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250420180844.53128-5-atrajeev@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2025-11-28 04:35:12 -05:00
Mamatha Inamdar ff7a35a737 powerpc/pseries/htmdump: Add htm start support to htmdump module 
JIRA: https://issues.redhat.com/browse/RHEL-52755

commit e03e4b12dee95bb87507a50772f927d0eb152ca1
Author: Athira Rajeev <atrajeev@linux.ibm.com>
Date:   Sun Apr 20 23:38:38 2025 +0530

    powerpc/pseries/htmdump: Add htm start support to htmdump module

    Support starting of Hardware Trace Macro (HTM) function
    via debugfs interface. Under debugfs folder
    "/sys/kernel/debug/powerpc/htmdump", add file "htmstart".
    The interface allows starting of htm via this file by
    writing value "1". Also allows stopping of htm tracing by
    writing value "0" to this file. Any other value returns
    -EINVAL.

    Signed-off-by: Athira Rajeev <atrajeev@linux.ibm.com>
    Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250420180844.53128-4-atrajeev@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2025-11-28 04:35:08 -05:00
Mamatha Inamdar 90f61c932e powerpc/pseries/htmdump: Add htm configure support to htmdump module 
JIRA: https://issues.redhat.com/browse/RHEL-52755

commit c6edd034e39f745feb9ad5298b92e0fec5bb9e9f
Author: Athira Rajeev <atrajeev@linux.ibm.com>
Date:   Sun Apr 20 23:38:37 2025 +0530

    powerpc/pseries/htmdump: Add htm configure support to htmdump module

    Support configuring of Hardware Trace Macro (HTM) function
    via debugfs interface. Under debugfs folder
    "/sys/kernel/debug/powerpc/htmdump", add file "htmconfigure".
    The interface allows configuring of htm via this file
    by writing value "1". Allow deconfiguring of htm via this file
    by writing value "0".  Any other value returns -EINVAL.

    Signed-off-by: Athira Rajeev <atrajeev@linux.ibm.com>
    Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250420180844.53128-3-atrajeev@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2025-11-28 04:35:04 -05:00
Mamatha Inamdar 2f0c1ff0e9 powerpc/pseries/htmdump: Add htm_hcall_wrapper to integrate other htm operations 
JIRA: https://issues.redhat.com/browse/RHEL-52755

commit 6e204ef3b73e41e46784fdd298c3d81caed84873
Author: Athira Rajeev <atrajeev@linux.ibm.com>
Date:   Sun Apr 20 23:38:36 2025 +0530

    powerpc/pseries/htmdump: Add htm_hcall_wrapper to integrate other htm operations

    H_HTM (Hardware Trace Macro) hypervisor call is an HCALL to export data
    from Hardware Trace Macro (HTM) function. The debugfs interface to
    export the HTM function data in an lpar currently supports only dumping
    of HTM data in an lpar. To add support for setup, configuration and
    control of HTM function via debugfs interface, update the hcall wrapper
    function. Rename and update htm_get_dump_hardware to htm_hcall_wrapper()
    so that it can be used for other HTM operations as well. Additionally
    include parameter "htm_op". Update htmdump module to check the return
    code of hcall in a separate function so that it can be reused for other
    option too. Add check to disable the interface in guest environment.

    Signed-off-by: Athira Rajeev <atrajeev@linux.ibm.com>
    Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250420180844.53128-2-atrajeev@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2025-11-28 04:35:00 -05:00
Mamatha Inamdar 89973e1846 powerpc: Document details on H_HTM hcall 
JIRA: https://issues.redhat.com/browse/RHEL-52755

commit ddcb883fd49c5d81f0d6e8c60332bab5d3b4c86f
Author: Abhishek Dubey <adubey@linux.ibm.com>
Date:   Mon Jan 13 11:40:39 2025 -0500

    powerpc: Document details on H_HTM hcall

    Add documentation to 'papr_hcalls.rst' describing the
    input, output and return values of the H_HTM hcall as
    per the internal specification.

    Signed-off-by: Abhishek Dubey <adubey@linux.ibm.com>
    Co-developed-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Reviewed-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250113164039.302017-3-adubey@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2025-11-28 04:34:56 -05:00
Mamatha Inamdar e0ceb3de62 powerpc/pseries: Export hardware trace macro dump via debugfs 
JIRA: https://issues.redhat.com/browse/RHEL-52755

commit 81c3d637c30f82966e551452e061d6e7b0d8df37
Author: Abhishek Dubey <adubey@linux.ibm.com>
Date:   Mon Jan 13 11:40:38 2025 -0500

    powerpc/pseries: Export hardware trace macro dump via debugfs

    This patch adds debugfs interface to export Hardware Trace Macro (HTM)
    function data in a LPAR. New hypervisor call "H_HTM" has been
    defined to setup, configure, control and dump the HTM data.
    This patch supports only dumping of HTM data in a LPAR.
    New debugfs folder called "htmdump" has been added under
    /sys/kernel/debug/arch path which contains files need to
    pass required parameters for the H_HTM dump function. New Kconfig
    option called "CONFIG_HTMDUMP" is added in platform/pseries
    for the same.

    With this module loaded, list of files in debugfs path

    /sys/kernel/debug/powerpc/htmdump
    coreindexonchip  htmtype  nodalchipindex  nodeindex  trace

    Signed-off-by: Abhishek Dubey <adubey@linux.ibm.com>
    Co-developed-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Reviewed-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250113164039.302017-2-adubey@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2025-11-28 04:34:53 -05:00
Mamatha Inamdar d18035eef5 powerpc/pseries: Macros and wrapper functions for H_HTM call 
JIRA: https://issues.redhat.com/browse/RHEL-52755

commit 708220ae50251212d8d33683c7b48eb5c4db237e
Author: Abhishek Dubey <adubey@linux.ibm.com>
Date:   Mon Jan 13 11:40:37 2025 -0500

    powerpc/pseries: Macros and wrapper functions for H_HTM call

    Define macros and wrapper functions to handle
    H_HTM (Hardware Trace Macro) hypervisor call.
    H_HTM is new HCALL added to export data from
    Hardware Trace Macro (HTM) function.

    Signed-off-by: Abhishek Dubey <adubey@linux.ibm.com>
    Co-developed-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Reviewed-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250113164039.302017-1-adubey@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2025-11-28 04:34:39 -05:00
Mamatha Inamdar b0979c8a54 powerpc: Export kvm_guest static key, for bcachefs six locks 
JIRA: https://issues.redhat.com/browse/RHEL-52755

commit ee841b77b3bfc3443112b1be53ca23d522b82333
Author: Kent Overstreet <kent.overstreet@linux.dev>
Date:   Wed Sep 13 19:59:03 2023 -0400

    powerpc: Export kvm_guest static key, for bcachefs six locks

    bcachefs's six locks need kvm_guest, via
     ower_on_cpu() ->  vcpu_is_preempted() -> is_kvm_guest()

    Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
    Cc: linuxppc-dev@lists.ozlabs.org
    Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2025-11-28 04:34:34 -05:00
Mamatha Inamdar 375f4d7c56 powerpc/pseries: Define __u{8,32} types in papr_hvpipe_hdr struct 
JIRA: https://issues.redhat.com/browse/RHEL-101849

commit ef104054a312608deab266f95945057fa73eeaad
Author: Haren Myneni <haren@linux.ibm.com>
Date:   Mon Sep 22 02:11:08 2025 -0700

    powerpc/pseries: Define __u{8,32} types in papr_hvpipe_hdr struct

    Fix the the following build errors with CONFIG_UAPI_HEADER_TEST:

    ./usr/include/asm/papr-hvpipe.h:16:9: error: unknown type name 'u8'
       16 |         u8 version;
    ./usr/include/asm/papr-hvpipe.h:17:9: error: unknown type name 'u8'
       17 |         u8 reserved[3];
    ./usr/include/asm/papr-hvpipe.h:18:9: error: unknown type name 'u32'
       18 |         u32 flags;
    ./usr/include/asm/papr-hvpipe.h:19:9: error: unknown type name 'u8'
       19 |         u8 reserved2[40];

    Fixes: 043439ad1a23c ("powerpc/pseries: Define papr-hvpipe ioctl")
    Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
    Signed-off-by: Haren Myneni <haren@linux.ibm.com>
    Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250922091108.1483970-1-haren@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2025-11-04 14:07:14 -05:00
Mamatha Inamdar ad3ca43ab6 powerpc/pseries: HVPIPE changes to support migration 
JIRA: https://issues.redhat.com/browse/RHEL-101849

commit 6d84f85151bbd062d36bda6daf37a73945b471c9
Author: Haren Myneni <haren@linux.ibm.com>
Date:   Tue Sep 9 01:44:01 2025 -0700

    powerpc/pseries: HVPIPE changes to support migration

    The hypervisor assigns one pipe per partition for all sources and
    assigns new pipe after migration. Also the partition ID that is
    used by source as its target ID may be changed after the migration.
    So disable hvpipe during SUSPEND event with ‘hvpipe enable’ system
    parameter value = 0 and enable it after migration during RESUME
    event with  hvpipe enable’ system parameter value = 1.

    The user space calls such as ioctl()/ read() / write() / poll()
    returns  -ENXIO between SUSPEND and RESUME events. The user space
    process can close FD and reestablish connection with new FD after
    migration if needed (Example: source IDs are changed).

    Signed-off-by: Haren Myneni <haren@linux.ibm.com>
    Tested-by: Shashank MS <shashank.gowda@in.ibm.com>
    Reviewed-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
    Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250909084402.1488456-10-haren@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2025-11-04 14:07:10 -05:00
Mamatha Inamdar 028c874224 powerpc/pseries: Enable hvpipe with ibm,set-system-parameter RTAS 
JIRA: https://issues.redhat.com/browse/RHEL-101849

commit 39a08a4f94980518ef2eca3c6c6b61094c99f1af
Author: Haren Myneni <haren@linux.ibm.com>
Date:   Tue Sep 9 01:44:00 2025 -0700

    powerpc/pseries: Enable hvpipe with ibm,set-system-parameter RTAS

    The partition uses “Hypervisor Pipe OS Enablement Notification”
    system parameter token (value = 64) to enable / disable hvpipe in
    the hypervisor. Once hvpipe is enabled, the hypervisor notifies
    OS if the payload is pending for that partition from any source.
    This system parameter token takes 1 byte length of data with
    1 = Enable and 0 = Disable.

    Enable hvpipe in the hypervisor with ibm,set-system-parameter
    RTAS after registering hvpipe event source interrupt.

    Signed-off-by: Haren Myneni <haren@linux.ibm.com>
    Tested-by: Shashank MS <shashank.gowda@in.ibm.com>
    Reviewed-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
    Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250909084402.1488456-9-haren@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2025-11-04 14:07:05 -05:00
Mamatha Inamdar 748f8de8e2 powerpc/pseries: Enable HVPIPE event message interrupt 
JIRA: https://issues.redhat.com/browse/RHEL-101849

Conflicts:
	- Use rtas_token() instead of rtas_function_token()

commit b48b6cc8c655d8cdcf5124ba9901b74c8f759668
Author: Haren Myneni <haren@linux.ibm.com>
Date:   Tue Sep 9 01:43:59 2025 -0700

    powerpc/pseries: Enable HVPIPE event message interrupt

    The hypervisor signals the OS via a Hypervisor Pipe Event external
    interrupt when data is available to be received from the pipe.
    Then the OS  should call RTAS check-exception and provide the input
    Event Mask as defined for the ‘ibm,hvpipe-msg-events’. In response,
    check-exception will return an event log containing an Pipe Events
    message. This message contains the source ID for which this
    message is intended to and the pipe status such as whether the
    payload is pending in the hypervisor or pipe to source is closed.

    If there is any user space process waiting in the wait_queue for
    the payload from this source ID, wake up that process which can
    issue read() to obtain payload with ibm,receive-hvpipe-msg RTAS
    or close FD if the pipe to source is closed.

    The hypervisor has one pipe per partition for all sources and it
    will not deliver another hvpipe event message until the partition
    reads the payload for the previous hvpipe event. So if the source
    ID is not found in the source list, issue the dummy
    ibm,receive-hvpipe-msg RTAS so that pipe will not blocked.

    Register hvpipe event source interrupt based on entries from
    /proc/device-tree//event-sources/ibm,hvpipe-msg-events property.

    Signed-off-by: Haren Myneni <haren@linux.ibm.com>
    Tested-by: Shashank MS <shashank.gowda@in.ibm.com>
    Reviewed-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
    Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250909084402.1488456-8-haren@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2025-11-04 14:07:01 -05:00
Mamatha Inamdar 6768da890e powerpc/pseries: Wakeup hvpipe FD when the payload is pending 
JIRA: https://issues.redhat.com/browse/RHEL-101849

commit da24fb99a1b5cc842b9446f67f6bcda36b49817f
Author: Haren Myneni <haren@linux.ibm.com>
Date:   Tue Sep 9 01:43:58 2025 -0700

    powerpc/pseries: Wakeup hvpipe FD when the payload is pending

    The user space polls on the wait_queue for the payload from the
    specific source. The hypervisor interrupts the OS when the pipe
    status for the specific source is changed such as payload is
    available for the partition or pipe to the source is closed. The
    OS retrieves the HVPIPE event message with check-exception RTAS
    and event message contains the source ID and the pipe status.
    Then wakes up all FDs waiting on the wait_queue so that the user
    space can read the payload or close the FD if the pipe to source
    in the hypervisor is closed.

    The hypervisor assigns one pipe per partition for all sources.
    Hence issue  ibm,receive-hvpipe-msg() to read the pending
    payload during release() before closing FD so that pipe to the
    partition will not be blocked.

    Signed-off-by: Haren Myneni <haren@linux.ibm.com>
    Tested-by: Shashank MS <shashank.gowda@in.ibm.com>
    Reviewed-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
    Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250909084402.1488456-7-haren@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2025-11-04 14:06:56 -05:00
Mamatha Inamdar cfdd96cfce powerpc/pseries: Receive payload with ibm,receive-hvpipe-msg RTAS 
JIRA: https://issues.redhat.com/browse/RHEL-101849

Conflicts:
	- Use rtas_token() instead of rtas_function_token()
	- Use 0 for RTAS_SUCCESS (This definition needs upstream 9592aa5ad59e736
	"powerpc/rtas: Add function return status constants")

commit cebdb522fd3edd1fe05f7b4a74a27da7dd0f8d86
Author: Haren Myneni <haren@linux.ibm.com>
Date:   Tue Sep 9 01:43:57 2025 -0700

    powerpc/pseries: Receive payload with ibm,receive-hvpipe-msg RTAS

    ibm,receive-hvpipe-msg RTAS call is used to receive data from the
    source (Ex: Hardware Management Console) over the hypervisor
    pipe. The hypervisor will signal the OS via a Hypervisor Pipe
    Event external interrupt when data is available to be received
    from the pipe and the event message has the source ID and the
    message type such as payload or closed pipe to the specific
    source. The hypervisor will not generate another interrupt for
    the next payload until the partition reads the previous payload.
    It means the hvpipe is blocked and will not deliver other events
    for any source. The maximum data length of 4048 bytes is
    supported with this RTAS call right now.

    The user space uses read() to receive data from HMC which issues
    ibm,receive-hvpipe-msg RTAS and the kernel returns the buffer
    length (including papr_hvpipe_hdr length) to the user space for
    success or RTAS failure error. If the message is regarding the
    pipe closed, kernel just returns the  papr_hvpipe_hdr with
    flags = HVPIPE_LOST_CONNECTION and expects the user space to
    close FD for the corresponding source.

    ibm,receive-hvpipe-msg RTAS call passes the buffer and returns
    the source ID from where this payload is received and the
    payload length.

    Signed-off-by: Haren Myneni <haren@linux.ibm.com>
    Tested-by: Shashank MS <shashank.gowda@in.ibm.com>
    Reviewed-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
    Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com>
    Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Link: https://patch.msgid.link/20250909084402.1488456-6-haren@linux.ibm.com

Signed-off-by: Mamatha Inamdar <minamdar@redhat.com>
 2025-11-04 14:06:52 -05:00