linux-kernel - Re: [PATCH v4 0/3] KVM/x86: Enhancements to static calls

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]

Message-ID: <ZnGbpizfefZgO0Q5@google.com>
Date: Tue, 18 Jun 2024 07:37:26 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: Wei Wang <wei.w.wang@...el.com>, kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 0/3] KVM/x86: Enhancements to static calls

On Wed, Jun 12, 2024, Paolo Bonzini wrote:
> On Wed, Jun 12, 2024 at 3:23 AM Sean Christopherson <seanjc@...gle.com> wrote:
> >
> > On Tue, 07 May 2024 21:31:00 +0800, Wei Wang wrote:
> > > This patchset introduces the kvm_x86_call() and kvm_pmu_call() macros to
> > > streamline the usage of static calls of kvm_x86_ops and kvm_pmu_ops. The
> > > current static_call() usage is a bit verbose and can lead to code
> > > alignment challenges, and the addition of kvm_x86_ prefix to hooks at the
> > > static_call() sites hinders code readability and navigation. The use of
> > > static_call_cond() is essentially the same as static_call() on x86, so it
> > > is replaced by static_call() to simplify the code. The changes have gone
> > > through my tests (guest launch, a few vPMU tests, live migration tests)
> > > without an issue.
> > >
> > > [...]
> >
> > Applied to kvm-x86 static_calls.  I may or may not rebase these commits
> > depending on what all gets queued for 6.10.  There are already three conflicts
> > that I know of, but they aren't _that_ annoying.  Yet.  :-)
> 
> I think it's best if we apply them directly (i.e. not through a pull
> request), on top of everything else in 6.11.

Works for me.  I'll maintain the branch so that the code stays in -next, and so
that patches that are destined for 6.12+ are built on the new world, and then
post the rebased patches when the time comes.