linux-kernel - Re: [RFC] [PATCH v2 0/5] Intel Virtual PMU Optimization

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: <20190323172800.GD6058@hirez.programming.kicks-ass.net>
Date:   Sat, 23 Mar 2019 18:28:00 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Like Xu <like.xu@...ux.intel.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        like.xu@...el.com, wei.w.wang@...el.com,
        Andi Kleen <ak@...ux.intel.com>,
        Kan Liang <kan.liang@...ux.intel.com>,
        Ingo Molnar <mingo@...hat.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC] [PATCH v2 0/5] Intel Virtual PMU Optimization

On Sat, Mar 23, 2019 at 10:18:03PM +0800, Like Xu wrote:
> === Brief description ===
> 
> This proposal for Intel vPMU is still committed to optimize the basic
> functionality by reducing the PMU virtualization overhead and not a blind
> pass-through of the PMU. The proposal applies to existing models, in short,
> is "host perf would hand over control to kvm after counter allocation".
> 
> The pmc_reprogram_counter is a heavyweight and high frequency operation
> which goes through the host perf software stack to create a perf event for
> counter assignment, this could take millions of nanoseconds. The current
> vPMU always does reprogram_counter when the guest changes the eventsel,
> fixctrl, and global_ctrl msrs. This brings too much overhead to the usage
> of perf inside the guest, especially the guest PMI handling and context
> switching of guest threads with perf in use.

I think I asked for starting with making pmc_reprogram_counter() less
retarded. I'm not seeing that here.

> We optimize the current vPMU to work in this manner:
> 
> (1) rely on the existing host perf (perf_event_create_kernel_counter)
>     to allocate counters for in-use vPMC and always try to reuse events;
> (2) vPMU captures guest accesses to the eventsel and fixctrl msr directly
>     to the hardware msr that the corresponding host event is scheduled on
>     and avoid pollution from host is also needed in its partial runtime;

If you do pass-through; how do you deal with event constraints?

> (3) save and restore the counter state during vCPU scheduling in hooks;
> (4) apply a lazy approach to release the vPMC's perf event. That is, if
>     the vPMC isn't used in a fixed sched slice, its event will be released.
> 
> In the use of vPMC, the vPMU always focus on the assigned resources and
> guest perf would significantly benefit from direct access to hardware and
> may not care about runtime state of perf_event created by host and always
> try not to pay for their maintenance. However to avoid events entering into
> any unexpected state, calling pmc_read_counter in appropriate is necessary.

what?!

I can't follow that, and the quick look I had at the patches doesn't
seem to help. I did note it is intel only and that is really sad.

It also makes a mess of who programs what msr when.