linux-kernel - Re: [PATCH] KVM: x86: Add a vCPU stat for #AC exceptions

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] [day] [month] [year] [list]

Date:   Wed, 26 Apr 2023 09:56:00 -0700
From:   Sean Christopherson <seanjc@...gle.com>
To:     Anselm Busse <abusse@...zon.com>
Cc:     dwmw@...zon.co.uk, hborghor@...zon.de, sironi@...zon.de,
        Paolo Bonzini <pbonzini@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] KVM: x86: Add a vCPU stat for #AC exceptions

On Wed, Apr 26, 2023, Anselm Busse wrote:
> This patch adds a KVM vCPU stat that reflects the number of #AC
> exceptions caused by a guest. This improves the identification and
> debugging of issues that are possibly caused by guests triggering
> split-locks and allows more insides compared to the current situation
> of having only a warning printed when an #AC exception is raised.

Irrespective of the inaccuracy Xiaoyao pointed out, I don't want to add a one-off
stat for _any_ exception.  I agree with what Marc said[*] when we (Google / GCP)
tried to push our pile o' stats upstream:

 : Because I'm pretty sure that whatever stat we expose, every cloud
 : vendor will want their own variant, so we may just as well put the
 : matter in their own hands.

That doesn't mean I don't want a massive pile of stats about all things KVM, quite
the opposite, but I don't think they belong in upstream where KVM has to maintain
them in perpetuity.  E.g. at some point in the (distant) future, split-lock #AC will
be completely uninteresting because all software will have been updated/fixed.

FWIW, we looked at using eBPF for our out-of-tree stats and ultimately decided that
carrying patches to add our stats would be significantly easier to maintain than an
eBPF-based approach, e.g. rebasing this patch is trivial.  But the challenges we
anticipated with switching to eBPF were largely specific to running at scale.  eBPF
is a very viable approach for gathering information for debug, development,
individual users, etc.

On idea I had for easing the pain of out-of-tree stats was to clean up KVM x86's
tracepoints, e.g. to give eBPF programs more stable and useful hooks, but also to
allow CSPs like us to play macro games to "inject" stats at key points, e.g. add
infrastructure to #define overload tracepoints to make KVM trampoline through
out-of-tree stats code.  But we haven't pursued that idea because (a) as above,
carrying patches for out-of-tree stats requires minimal effort and (b) it wouldn't
eliminate "invasive" code because we'd (GCP) inevitably want stats in places where
a KVM tracepoint makes no sense.

So as much as I advocate for pushing code upstream, this is one of the few areas
where I think it's better to carry code out-of-tree.

[*] https://lore.kernel.org/all/875yusv3vm.wl-maz@kernel.org