1. 19 10月, 2021 5 次提交
  2. 30 9月, 2021 4 次提交
  3. 28 9月, 2021 1 次提交
  4. 24 9月, 2021 2 次提交
    • O
      selftests: KVM: Explicitly use movq to read xmm registers · 386ca9d7
      Oliver Upton 提交于
      Compiling the KVM selftests with clang emits the following warning:
      
      >> include/x86_64/processor.h:297:25: error: variable 'xmm0' is uninitialized when used here [-Werror,-Wuninitialized]
      >>                return (unsigned long)xmm0;
      
      where xmm0 is accessed via an uninitialized register variable.
      
      Indeed, this is a misuse of register variables, which really should only
      be used for specifying register constraints on variables passed to
      inline assembly. Rather than attempting to read xmm registers via
      register variables, just explicitly perform the movq from the desired
      xmm register.
      
      Fixes: 783e9e51 ("kvm: selftests: add API testing infrastructure")
      Signed-off-by: NOliver Upton <oupton@google.com>
      Message-Id: <20210924005147.1122357-1-oupton@google.com>
      Reviewed-by: NRicardo Koller <ricarkol@google.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      386ca9d7
    • O
      selftests: KVM: Call ucall_init when setting up in rseq_test · fbf094ce
      Oliver Upton 提交于
      While x86 does not require any additional setup to use the ucall
      infrastructure, arm64 needs to set up the MMIO address used to signal a
      ucall to userspace. rseq_test does not initialize the MMIO address,
      resulting in the test spinning indefinitely.
      
      Fix the issue by calling ucall_init() during setup.
      
      Fixes: 61e52f16 ("KVM: selftests: Add a test for KVM_RUN+rseq to detect task migration bugs")
      Signed-off-by: NOliver Upton <oupton@google.com>
      Message-Id: <20210923220033.4172362-1-oupton@google.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      fbf094ce
  5. 23 9月, 2021 1 次提交
    • M
      KVM: x86: selftests: test simultaneous uses of V_IRQ from L1 and L0 · 1ad32105
      Maxim Levitsky 提交于
      Test that if:
      
      * L1 disables virtual interrupt masking, and INTR intercept.
      
      * L1 setups a virtual interrupt to be injected to L2 and enters L2 with
        interrupts disabled, thus the virtual interrupt is pending.
      
      * Now an external interrupt arrives in L1 and since
        L1 doesn't intercept it, it should be delivered to L2 when
        it enables interrupts.
      
        to do this L0 (abuses) V_IRQ to setup an
        interrupt window, and returns to L2.
      
      * L2 enables interrupts.
        This should trigger the interrupt window,
        injection of the external interrupt and delivery
        of the virtual interrupt that can now be done.
      
      * Test that now L2 gets those interrupts.
      
      This is the test that demonstrates the issue that was
      fixed in the previous patch.
      Signed-off-by: NMaxim Levitsky <mlevitsk@redhat.com>
      Message-Id: <20210914154825.104886-3-mlevitsk@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      1ad32105
  6. 22 9月, 2021 8 次提交
  7. 19 9月, 2021 5 次提交
    • A
      perf bpf: Ignore deprecation warning when using libbpf's btf__get_from_id() · 219d720e
      Andrii Nakryiko 提交于
      Perf code re-implements libbpf's btf__load_from_kernel_by_id() API as
      a weak function, presumably to dynamically link against old version of
      libbpf shared library. Unfortunately this causes compilation warning
      when perf is compiled against libbpf v0.6+.
      
      For now, just ignore deprecation warning, but there might be a better
      solution, depending on perf's needs.
      Signed-off-by: NAndrii Nakryiko <andrii@kernel.org>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: kernel-team@fb.com
      LPU-Reference: 20210914170004.4185659-1-andrii@kernel.org
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      219d720e
    • I
      libperf evsel: Make use of FD robust. · aba5daeb
      Ian Rogers 提交于
      FD uses xyarray__entry that may return NULL if an index is out of
      bounds. If NULL is returned then a segv happens as FD unconditionally
      dereferences the pointer. This was happening in a case of with perf
      iostat as shown below. The fix is to make FD an "int*" rather than an
      int and handle the NULL case as either invalid input or a closed fd.
      
        $ sudo gdb --args perf stat --iostat  list
        ...
        Breakpoint 1, perf_evsel__alloc_fd (evsel=0x5555560951a0, ncpus=1, nthreads=1) at evsel.c:50
        50      {
        (gdb) bt
         #0  perf_evsel__alloc_fd (evsel=0x5555560951a0, ncpus=1, nthreads=1) at evsel.c:50
         #1  0x000055555585c188 in evsel__open_cpu (evsel=0x5555560951a0, cpus=0x555556093410,
            threads=0x555556086fb0, start_cpu=0, end_cpu=1) at util/evsel.c:1792
         #2  0x000055555585cfb2 in evsel__open (evsel=0x5555560951a0, cpus=0x0, threads=0x555556086fb0)
            at util/evsel.c:2045
         #3  0x000055555585d0db in evsel__open_per_thread (evsel=0x5555560951a0, threads=0x555556086fb0)
            at util/evsel.c:2065
         #4  0x00005555558ece64 in create_perf_stat_counter (evsel=0x5555560951a0,
            config=0x555555c34700 <stat_config>, target=0x555555c2f1c0 <target>, cpu=0) at util/stat.c:590
         #5  0x000055555578e927 in __run_perf_stat (argc=1, argv=0x7fffffffe4a0, run_idx=0)
            at builtin-stat.c:833
         #6  0x000055555578f3c6 in run_perf_stat (argc=1, argv=0x7fffffffe4a0, run_idx=0)
            at builtin-stat.c:1048
         #7  0x0000555555792ee5 in cmd_stat (argc=1, argv=0x7fffffffe4a0) at builtin-stat.c:2534
         #8  0x0000555555835ed3 in run_builtin (p=0x555555c3f540 <commands+288>, argc=3,
            argv=0x7fffffffe4a0) at perf.c:313
         #9  0x0000555555836154 in handle_internal_command (argc=3, argv=0x7fffffffe4a0) at perf.c:365
         #10 0x000055555583629f in run_argv (argcp=0x7fffffffe2ec, argv=0x7fffffffe2e0) at perf.c:409
         #11 0x0000555555836692 in main (argc=3, argv=0x7fffffffe4a0) at perf.c:539
        ...
        (gdb) c
        Continuing.
        Error:
        The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (uncore_iio_0/event=0x83,umask=0x04,ch_mask=0xF,fc_mask=0x07/).
        /bin/dmesg | grep -i perf may provide additional information.
      
        Program received signal SIGSEGV, Segmentation fault.
        0x00005555559b03ea in perf_evsel__close_fd_cpu (evsel=0x5555560951a0, cpu=1) at evsel.c:166
        166                     if (FD(evsel, cpu, thread) >= 0)
      
      v3. fixes a bug in perf_evsel__run_ioctl where the sense of a branch was
          backward.
      Signed-off-by: NIan Rogers <irogers@google.com>
      Acked-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lore.kernel.org/lkml/20210918054440.2350466-1-irogers@google.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      aba5daeb
    • M
      perf machine: Initialize srcline string member in add_location struct · 57f0ff05
      Michael Petlan 提交于
      It's later supposed to be either a correct address or NULL. Without the
      initialization, it may contain an undefined value which results in the
      following segmentation fault:
      
        # perf top --sort comm -g --ignore-callees=do_idle
      
      terminates with:
      
        #0  0x00007ffff56b7685 in __strlen_avx2 () from /lib64/libc.so.6
        #1  0x00007ffff55e3802 in strdup () from /lib64/libc.so.6
        #2  0x00005555558cb139 in hist_entry__init (callchain_size=<optimized out>, sample_self=true, template=0x7fffde7fb110, he=0x7fffd801c250) at util/hist.c:489
        #3  hist_entry__new (template=template@entry=0x7fffde7fb110, sample_self=sample_self@entry=true) at util/hist.c:564
        #4  0x00005555558cb4ba in hists__findnew_entry (hists=hists@entry=0x5555561d9e38, entry=entry@entry=0x7fffde7fb110, al=al@entry=0x7fffde7fb420,
            sample_self=sample_self@entry=true) at util/hist.c:657
        #5  0x00005555558cba1b in __hists__add_entry (hists=hists@entry=0x5555561d9e38, al=0x7fffde7fb420, sym_parent=<optimized out>, bi=bi@entry=0x0, mi=mi@entry=0x0,
            sample=sample@entry=0x7fffde7fb4b0, sample_self=true, ops=0x0, block_info=0x0) at util/hist.c:288
        #6  0x00005555558cbb70 in hists__add_entry (sample_self=true, sample=0x7fffde7fb4b0, mi=0x0, bi=0x0, sym_parent=<optimized out>, al=<optimized out>, hists=0x5555561d9e38)
            at util/hist.c:1056
        #7  iter_add_single_cumulative_entry (iter=0x7fffde7fb460, al=<optimized out>) at util/hist.c:1056
        #8  0x00005555558cc8a4 in hist_entry_iter__add (iter=iter@entry=0x7fffde7fb460, al=al@entry=0x7fffde7fb420, max_stack_depth=<optimized out>, arg=arg@entry=0x7fffffff7db0)
            at util/hist.c:1231
        #9  0x00005555557cdc9a in perf_event__process_sample (machine=<optimized out>, sample=0x7fffde7fb4b0, evsel=<optimized out>, event=<optimized out>, tool=0x7fffffff7db0)
            at builtin-top.c:842
        #10 deliver_event (qe=<optimized out>, qevent=<optimized out>) at builtin-top.c:1202
        #11 0x00005555558a9318 in do_flush (show_progress=false, oe=0x7fffffff80e0) at util/ordered-events.c:244
        #12 __ordered_events__flush (oe=oe@entry=0x7fffffff80e0, how=how@entry=OE_FLUSH__TOP, timestamp=timestamp@entry=0) at util/ordered-events.c:323
        #13 0x00005555558a9789 in __ordered_events__flush (timestamp=<optimized out>, how=<optimized out>, oe=<optimized out>) at util/ordered-events.c:339
        #14 ordered_events__flush (how=OE_FLUSH__TOP, oe=0x7fffffff80e0) at util/ordered-events.c:341
        #15 ordered_events__flush (oe=oe@entry=0x7fffffff80e0, how=how@entry=OE_FLUSH__TOP) at util/ordered-events.c:339
        #16 0x00005555557cd631 in process_thread (arg=0x7fffffff7db0) at builtin-top.c:1114
        #17 0x00007ffff7bb817a in start_thread () from /lib64/libpthread.so.0
        #18 0x00007ffff5656dc3 in clone () from /lib64/libc.so.6
      
      If you look at the frame #2, the code is:
      
      488	 if (he->srcline) {
      489          he->srcline = strdup(he->srcline);
      490          if (he->srcline == NULL)
      491              goto err_rawdata;
      492	 }
      
      If he->srcline is not NULL (it is not NULL if it is uninitialized rubbish),
      it gets strdupped and strdupping a rubbish random string causes the problem.
      
      Also, if you look at the commit 1fb7d06a, it adds the srcline property
      into the struct, but not initializing it everywhere needed.
      
      Committer notes:
      
      Now I see, when using --ignore-callees=do_idle we end up here at line
      2189 in add_callchain_ip():
      
      2181         if (al.sym != NULL) {
      2182                 if (perf_hpp_list.parent && !*parent &&
      2183                     symbol__match_regex(al.sym, &parent_regex))
      2184                         *parent = al.sym;
      2185                 else if (have_ignore_callees && root_al &&
      2186                   symbol__match_regex(al.sym, &ignore_callees_regex)) {
      2187                         /* Treat this symbol as the root,
      2188                            forgetting its callees. */
      2189                         *root_al = al;
      2190                         callchain_cursor_reset(cursor);
      2191                 }
      2192         }
      
      And the al that doesn't have the ->srcline field initialized will be
      copied to the root_al, so then, back to:
      
      1211 int hist_entry_iter__add(struct hist_entry_iter *iter, struct addr_location *al,
      1212                          int max_stack_depth, void *arg)
      1213 {
      1214         int err, err2;
      1215         struct map *alm = NULL;
      1216
      1217         if (al)
      1218                 alm = map__get(al->map);
      1219
      1220         err = sample__resolve_callchain(iter->sample, &callchain_cursor, &iter->parent,
      1221                                         iter->evsel, al, max_stack_depth);
      1222         if (err) {
      1223                 map__put(alm);
      1224                 return err;
      1225         }
      1226
      1227         err = iter->ops->prepare_entry(iter, al);
      1228         if (err)
      1229                 goto out;
      1230
      1231         err = iter->ops->add_single_entry(iter, al);
      1232         if (err)
      1233                 goto out;
      1234
      
      That al at line 1221 is what hist_entry_iter__add() (called from
      sample__resolve_callchain()) saw as 'root_al', and then:
      
              iter->ops->add_single_entry(iter, al);
      
      will go on with al->srcline with a bogus value, I'll add the above
      sequence to the cset and apply, thanks!
      Signed-off-by: NMichael Petlan <mpetlan@redhat.com>
      CC: Milian Wolff <milian.wolff@kdab.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Fixes: 1fb7d06a ("perf report Use srcline from callchain for hist entries")
      Link: https //lore.kernel.org/r/20210719145332.29747-1-mpetlan@redhat.com
      Reported-by: NJuri Lelli <jlelli@redhat.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      57f0ff05
    • A
      perf script: Fix ip display when type != attr->type · ff6f41fb
      Adrian Hunter 提交于
      set_print_ip_opts() was not being called when type != attr->type
      because there is not a one-to-one relationship between output types
      and attr->type. That resulted in ip not printing.
      
      The attr_type() function is removed, and the match of attr->type to
      output type is corrected.
      
      Example on ADL using taskset to select an atom cpu:
      
       # perf record -e cpu_atom/cpu-cycles/ taskset 0x1000 uname
       Linux
       [ perf record: Woken up 1 times to write data ]
       [ perf record: Captured and wrote 0.003 MB perf.data (7 samples) ]
      
       Before:
      
        # perf script | head
               taskset   428 [-01] 10394.179041:          1 cpu_atom/cpu-cycles/:
               taskset   428 [-01] 10394.179043:          1 cpu_atom/cpu-cycles/:
               taskset   428 [-01] 10394.179044:         11 cpu_atom/cpu-cycles/:
               taskset   428 [-01] 10394.179045:        407 cpu_atom/cpu-cycles/:
               taskset   428 [-01] 10394.179046:      16789 cpu_atom/cpu-cycles/:
               taskset   428 [-01] 10394.179052:     676300 cpu_atom/cpu-cycles/:
                 uname   428 [-01] 10394.179278:    4079859 cpu_atom/cpu-cycles/:
      
       After:
      
        # perf script | head
               taskset   428 10394.179041:          1 cpu_atom/cpu-cycles/:  ffffffff95a0bb97 __intel_pmu_enable_all.constprop.48+0x47 ([kernel.kallsyms])
               taskset   428 10394.179043:          1 cpu_atom/cpu-cycles/:  ffffffff95a0bb97 __intel_pmu_enable_all.constprop.48+0x47 ([kernel.kallsyms])
               taskset   428 10394.179044:         11 cpu_atom/cpu-cycles/:  ffffffff95a0bb97 __intel_pmu_enable_all.constprop.48+0x47 ([kernel.kallsyms])
               taskset   428 10394.179045:        407 cpu_atom/cpu-cycles/:  ffffffff95a0bb97 __intel_pmu_enable_all.constprop.48+0x47 ([kernel.kallsyms])
               taskset   428 10394.179046:      16789 cpu_atom/cpu-cycles/:  ffffffff95a0bb97 __intel_pmu_enable_all.constprop.48+0x47 ([kernel.kallsyms])
               taskset   428 10394.179052:     676300 cpu_atom/cpu-cycles/:      7f829ef73800 cfree+0x0 (/lib/libc-2.32.so)
                 uname   428 10394.179278:    4079859 cpu_atom/cpu-cycles/:  ffffffff95bae912 vma_interval_tree_remove+0x1f2 ([kernel.kallsyms])
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Reviewed-by: NKan Liang <kan.liang@linux.intel.com>
      Cc: Jin Yao <yao.jin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Link: http://lore.kernel.org/lkml/20210911133053.15682-1-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      ff6f41fb
    • R
      perf annotate: Fix fused instr logic for assembly functions · 7efbcc8c
      Ravi Bangoria 提交于
      Some x86 microarchitectures fuse a subset of cmp/test/ALU instructions
      with branch instructions, and thus perf annotate highlight such valid
      pairs as fused.
      
      When annotated with source, perf uses struct disasm_line to contain
      either source or instruction line from objdump output. Usually, a C
      statement generates multiple instructions which include such
      cmp/test/ALU + branch instruction pairs. But in case of assembly
      function, each individual assembly source line generate one
      instruction.
      
      The 'perf annotate' instruction fusion logic assumes the previous
      disasm_line as the previous instruction line, which is wrong because,
      for assembly function, previous disasm_line contains source line.  And
      thus perf fails to highlight valid fused instruction pairs for assembly
      functions.
      
      Fix it by searching backward until we find an instruction line and
      consider that disasm_line as fused with current branch instruction.
      
      Before:
               │    cmpq    %rcx, RIP+8(%rsp)
          0.00 │      cmp    %rcx,0x88(%rsp)
               │    je      .Lerror_bad_iret      <--- Source line
          0.14 │   ┌──je     b4                   <--- Instruction line
               │   │movl    %ecx, %eax
      
      After:
               │    cmpq    %rcx, RIP+8(%rsp)
          0.00 │   ┌──cmp    %rcx,0x88(%rsp)
               │   │je      .Lerror_bad_iret
          0.14 │   ├──je     b4
               │   │movl    %ecx, %eax
      Reviewed-by: NJin Yao <yao.jin@linux.intel.com>
      Signed-off-by: NRavi Bangoria <ravi.bangoria@amd.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Kim Phillips <kim.phillips@amd.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Link: https //lore.kernel.org/r/20210911043854.8373-1-ravi.bangoria@amd.com
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      7efbcc8c
  8. 16 9月, 2021 2 次提交
  9. 14 9月, 2021 5 次提交
  10. 13 9月, 2021 1 次提交
  11. 12 9月, 2021 6 次提交