linux-kernel - Re: [PATCH 7/7] cpuidle/poll_state: replace cpu_relax with smp_cond_load

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: <724589ce-7656-4be0-aa37-f6edeb92e1c4@oracle.com>
Date:   Wed, 22 Nov 2023 23:33:13 +0200
From:   Mihai Carabas <mihai.carabas@...cle.com>
To:     Christoph Lameter <cl@...ux.com>
Cc:     linux-arm-kernel@...ts.infradead.org, kvm@...r.kernel.org,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
        catalin.marinas@....com, will@...nel.org, tglx@...utronix.de,
        mingo@...hat.com, bp@...en8.de, x86@...nel.org, hpa@...or.com,
        pbonzini@...hat.com, wanpengli@...cent.com, vkuznets@...hat.com,
        rafael@...nel.org, daniel.lezcano@...aro.org,
        akpm@...ux-foundation.org, pmladek@...e.com, peterz@...radead.org,
        dianders@...omium.org, npiggin@...il.com,
        rick.p.edgecombe@...el.com, joao.m.martins@...cle.com,
        juerg.haefliger@...onical.com, mic@...ikod.net, arnd@...db.de,
        ankur.a.arora@...cle.com
Subject: Re: [PATCH 7/7] cpuidle/poll_state: replace cpu_relax with
 smp_cond_load_relaxed

La 22.11.2023 22:51, Christoph Lameter a scris:
>
> On Mon, 20 Nov 2023, Mihai Carabas wrote:
>
>> cpu_relax on ARM64 does a simple "yield". Thus we replace it with
>> smp_cond_load_relaxed which basically does a "wfe".
>
> Well it clears events first (which requires the first WFE) and then 
> does a WFE waiting for any events if no events were pending.
>
> WFE does not cause a VMEXIT? Or does the inner loop of 
> smp_cond_load_relaxed now do 2x VMEXITS?
>
> KVM ARM64 code seems to indicate that WFE causes a VMEXIT. See 
> kvm_handle_wfx().

In KVM ARM64 the WFE traping is dynamic: it is enabled only if there are 
more tasks waiting on the same core (e.g. on an oversubscribed system).

In arch/arm64/kvm/arm.c:

  457 >-------if (single_task_running())
  458 >------->-------vcpu_clear_wfx_traps(vcpu);
  459 >-------else
  460 >------->-------vcpu_set_wfx_traps(vcpu);

This of course can be improved by having a knob where you can completly 
disable wfx traping by your needs, but I left this as another subject to 
tackle.