lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ee2a1209-8572-a147-fdac-1a3d83862022@gmail.com>
Date:   Fri, 8 Oct 2021 11:34:05 +0800
From:   Like Xu <like.xu.linux@...il.com>
To:     Song Liu <songliubraving@...com>
Cc:     Peter Zijlstra <peterz@...radead.org>, bpf <bpf@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>,
        Kernel Team <Kernel-team@...com>,
        Andrii Nakryiko <andrii@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        "like.xu@...ux.intel.com" <like.xu@...ux.intel.com>,
        Andi Kleen <andi@...stfloor.org>,
        "Liang, Kan" <kan.liang@...el.com>
Subject: Re: bpf_get_branch_snapshot on qemu-kvm

On 30/9/2021 4:05 am, Song Liu wrote:
> Hi Kan,
> 
>> On Sep 29, 2021, at 9:35 AM, Liang, Kan <kan.liang@...el.com> wrote:
>>
>>>>> - get confirmation that clearing GLOBAL_CTRL is suffient to supress
>>>>>   PEBS, in which case we can simply remove the PEBS_ENABLE clear.
>>>>
>>>> How should we confirm this? Can we run some tests for this? Or do we
>>>> need hardware experts' input for this?
>>>
>>> I'll put it on the list to ask the hardware people when I talk to them next. But
>>> maybe Kan or Andi know without asking.
>>
>> If the GLOBAL_CTRL is explicitly disabled, the counters do not count anymore.
>> It doesn't matter if PEBS is enabled or not.
>>
>> See 6c1c07b33eb0 ("perf/x86/intel: Avoid unnecessary PEBS_ENABLE MSR
>> access in PMI "). We optimized the PMU handler base on it.
> 
> Thanks for these information!
> 
> IIUC, all we need is the following on top of bpf-next/master:
> 
> diff --git i/arch/x86/events/intel/core.c w/arch/x86/events/intel/core.c
> index 1248fc1937f82..d0d357e7d6f21 100644
> --- i/arch/x86/events/intel/core.c
> +++ w/arch/x86/events/intel/core.c
> @@ -2209,7 +2209,6 @@ intel_pmu_snapshot_branch_stack(struct perf_branch_entry *entries, unsigned int
>          /* must not have branches... */
>          local_irq_save(flags);
>          __intel_pmu_disable_all(false); /* we don't care about BTS */

If the value passed in is true, does it affect your use case?

> -       __intel_pmu_pebs_disable_all();

In that case, we can reuse "static __always_inline void intel_pmu_disable_all(void)"
regardless of whether PEBS is supported or enabled inside the guest and the host ?

>          __intel_pmu_lbr_disable();

How about using intel_pmu_lbr_disable_all() to cover Arch LBR?

>          /*            ... until here */
>          return __intel_pmu_snapshot_branch_stack(entries, cnt, flags);
> @@ -2223,7 +2222,6 @@ intel_pmu_snapshot_arch_branch_stack(struct perf_branch_entry *entries, unsigned
>          /* must not have branches... */
>          local_irq_save(flags);
>          __intel_pmu_disable_all(false); /* we don't care about BTS */
> -       __intel_pmu_pebs_disable_all();
>          __intel_pmu_arch_lbr_disable();
>          /*            ... until here */
>          return __intel_pmu_snapshot_branch_stack(entries, cnt, flags);
> 
> 
> In the test, this does eliminate the warning.
> 
> Thanks,
> Song
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ