Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@kernel.org>
To: "Kalra, Ashish" <ashish.kalra@amd.com>, Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@intel.com>,
	mingo@redhat.com, dave.hansen@linux.intel.com, x86@kernel.org,
	hpa@zytor.com, seanjc@google.com, peterz@infradead.org,
	thomas.lendacky@amd.com, herbert@gondor.apana.org.au,
	davem@davemloft.net, ardb@kernel.org, pbonzini@redhat.com,
	aik@amd.com, Michael.Roth@amd.com, KPrateek.Nayak@amd.com,
	Tycho.Andersen@amd.com, Nathan.Fontenot@amd.com,
	ackerleytng@google.com, jackyli@google.com, pgonda@google.com,
	rientjes@google.com, jacobhxu@google.com, xin@zytor.com,
	pawan.kumar.gupta@linux.intel.com, babu.moger@amd.com,
	dyoung@redhat.com, nikunj@amd.com, john.allen@amd.com,
	darwi@linutronix.de, linux-kernel@vger.kernel.org,
	linux-crypto@vger.kernel.org, kvm@vger.kernel.org,
	linux-coco@lists.linux.dev
Subject: Re: [PATCH v8 3/7] crypto/ccp: Disable CPU hotplug while SNP is active
Date: Sun, 21 Jun 2026 12:44:13 +0200	[thread overview]
Message-ID: <87fr2gmav6.ffs@fw13> (raw)
In-Reply-To: <e68a126a-6f2e-4a76-a691-f514b7f37489@amd.com>

On Fri, Jun 19 2026 at 18:51, Ashish Kalra wrote:
> On 6/19/2026 6:20 PM, Borislav Petkov wrote:
>> I'd let tglx maybe give a better idea but this cpu_hotplug_disable static var
>> in kernel/cpu.c could get a getter function and be used instead of you
>> reinventing the wheel in here.
>
> I don't follow — I'm not reinventing anything here. Patch 3 will use
> the existing CPU-hotplug callback interface: cpuhp_setup_state() with
> a down callback that returns -EBUSY to refuse the offline while SNP is
> active. That's the standard mechanism for conditionally preventing a
> CPU offline, and it keeps no private "hotplug disabled" state of its
> own — so there's nothing here for a getter on cpu_hotplug_disabled to
> replace.

That's not a standard mechanism. That's a hack as you have to start the
offlining operation in order to prevent something you already know.

The return code which prevents offlining is there for situations where
the subsystem/driver is momentarily in a state which cannot be
resolved.

That's a very different story than knowing that state at the point of
installing the callback already.

> I chose the cpuhp callback specifically over
> cpu_hotplug_disable_offlining(): the callback can be torn down with
> cpuhp_remove_state() when SNP is fully shut down, which re-enables CPU
> offlining. cpu_hotplug_disable_offlining() sets
> cpu_hotplug_offline_disabled, which is __ro_after_init and one-way —
> there's no interface to clear it, and adding one would mean dropping
> the __ro_after_init marking and a new core "re-enable offlining"
> API. So that route can't re-enable offlining on SNP shutdown without
> new core plumbing, whereas the cpuhp callback gives me that for free.

That's exactly the wrong attitude. Hack around a core limitation in a
random driver by abusing the provided mechanism instead of sitting down
and doing the extra five lines of code which makes it entirely clear
what's going on.

When Boris asked me how to disable hotplug, I had the impression that
this is about permanently preventing it. So I pointed him to
cpu_hotplug_disable_offlining().

If I had known that it's about temporary prevention during runtime of
something, then I'd pointed him to cpu_hotplug_disable()/enable() which
is five lines farther down in cpu.c. It's not rocket science to find
them. The first AI chatbot I asked pointed me to it immediately.

cpu_hotplug_disable()/enable() is _the_ standard mechanism to prevent
hotplug operations temporarily. They return -EBUSY without invoking any
callback or changing any related state.

So what's exactly the new core plumbing you need?

Thanks,

        tglx


  reply	other threads:[~2026-06-21 10:44 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1781419998.git.ashish.kalra@amd.com>
2026-06-15 19:48 ` [PATCH v8 1/7] x86/cpufeatures: Add X86_FEATURE_RMPOPT feature flag Ashish Kalra
2026-06-15 19:48 ` [PATCH v8 2/7] x86/sev: Initialize RMPOPT configuration MSRs Ashish Kalra
2026-06-16  6:03   ` K Prateek Nayak
2026-06-18 18:23     ` Kalra, Ashish
2026-06-18 21:08   ` Tom Lendacky
2026-06-15 19:49 ` [PATCH v8 3/7] crypto/ccp: Disable CPU hotplug while SNP is active Ashish Kalra
2026-06-17  4:33   ` K Prateek Nayak
2026-06-17 22:23     ` Kalra, Ashish
2026-06-18 21:49     ` Tom Lendacky
2026-06-18 21:35   ` Dave Hansen
2026-06-19 20:51     ` Kalra, Ashish
2026-06-19 21:31       ` Kalra, Ashish
2026-06-19 22:10       ` Borislav Petkov
2026-06-19 22:34         ` Kalra, Ashish
2026-06-19 23:20           ` Borislav Petkov
2026-06-19 23:51             ` Kalra, Ashish
2026-06-21 10:44               ` Thomas Gleixner [this message]
2026-06-15 19:49 ` [PATCH v8 4/7] x86/sev: Add support to perform RMP optimizations asynchronously Ashish Kalra
2026-06-16  7:27   ` K Prateek Nayak
2026-06-16 19:56     ` Kalra, Ashish
2026-06-17  4:20       ` K Prateek Nayak
2026-06-17 21:57         ` Kalra, Ashish
2026-06-15 19:49 ` [PATCH v8 5/7] x86/sev: Add interface to re-enable RMP optimizations Ashish Kalra
2026-06-18 21:41   ` Dave Hansen
2026-06-15 19:50 ` [PATCH v8 6/7] KVM: SEV: Perform RMP optimizations on SNP guest shutdown Ashish Kalra
2026-06-18 21:42   ` Dave Hansen
2026-06-15 19:50 ` [PATCH v8 7/7] x86/sev: Add debugfs support for RMPOPT Ashish Kalra
2026-06-18 18:08   ` Borislav Petkov
2026-06-18 19:57     ` Kalra, Ashish
2026-06-18 20:10       ` Borislav Petkov
2026-06-18 21:42       ` Dave Hansen
2026-06-19 21:48         ` Kalra, Ashish

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fr2gmav6.ffs@fw13 \
    --to=tglx@kernel.org \
    --cc=KPrateek.Nayak@amd.com \
    --cc=Michael.Roth@amd.com \
    --cc=Nathan.Fontenot@amd.com \
    --cc=Tycho.Andersen@amd.com \
    --cc=ackerleytng@google.com \
    --cc=aik@amd.com \
    --cc=ardb@kernel.org \
    --cc=ashish.kalra@amd.com \
    --cc=babu.moger@amd.com \
    --cc=bp@alien8.de \
    --cc=darwi@linutronix.de \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=dyoung@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=hpa@zytor.com \
    --cc=jackyli@google.com \
    --cc=jacobhxu@google.com \
    --cc=john.allen@amd.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=nikunj@amd.com \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pgonda@google.com \
    --cc=rientjes@google.com \
    --cc=seanjc@google.com \
    --cc=thomas.lendacky@amd.com \
    --cc=x86@kernel.org \
    --cc=xin@zytor.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox