All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ashish Kalra" <Ashish.Kalra@amd.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v8 7/7] x86/sev: Add debugfs support for RMPOPT
Date: Mon, 15 Jun 2026 20:07:20 +0000	[thread overview]
Message-ID: <20260615200721.4600C1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <cc9aa9b6cfa2ce826f2ad53f8a13d3b7bf0790b6.1781419998.git.ashish.kalra@amd.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Broadcasting the RMPOPT instruction to cpu_online_mask in debugfs can trigger a kernel panic (#UD/#GP) if a core's primary thread is offline.
--

commit bd48c96c2b885c0673d20119de172ea1dd26cdf2
Author: Ashish Kalra <ashish.kalra@amd.com>

x86/sev: Add debugfs support for RMPOPT

This commit adds a debugfs interface to report per-CPU RMPOPT status across
all system RAM.

> diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
> --- a/arch/x86/virt/svm/sev.c
> +++ b/arch/x86/virt/svm/sev.c

[ ... ]

> @@ -669,6 +686,115 @@ static long rmpopt_leader_fn(void *arg)

[ ... ]

> +static int rmpopt_table_seq_show(struct seq_file *seq, void *v)
> +{
> +	phys_addr_t *curr_paddr = v;
> +
> +	guard(mutex)(&rmpopt_show_mutex);
> +
> +	seq_printf(seq, "Memory @%3lluGB: ",
> +		   *curr_paddr >> (get_order(SZ_1G) + PAGE_SHIFT));
> +
> +	/*
> +	 * Query all online CPUs rather than just rmpopt_cpumask (primary
> +	 * threads only). The RMPOPT instruction only needs to run on one
> +	 * thread per core for the optimization to take effect, but debugfs
> +	 * reporting requires the RMPOPT status across all CPUs.
> +	 * Performance is not a concern for this diagnostic interface.
> +	 *
> +	 * This is safe because RMPOPT_BASE MSR is per-core and
> +	 * snp_prepare() ensures all CPUs are online when the MSR is
> +	 * programmed during snp_setup_rmpopt().
> +	 */
> +	cpumask_clear(&rmpopt_report_cpumask);
> +	on_each_cpu_mask(cpu_online_mask, rmpopt_report_status,
> +			 (void *)*curr_paddr, true);

[Severity: High]
Could broadcasting to cpu_online_mask here trigger a kernel panic
if a core's primary thread is offline?

In snp_setup_rmpopt(), the base msr is only programmed on cpus in
rmpopt_cpumask, which is strictly limited to online primary threads:

if (topology_is_primary_thread(cpu))
        cpumask_set_cpu(cpu, &rmpopt_cpumask);

If a core's primary thread is offline but its secondary thread is online,
the secondary thread will be included in cpu_online_mask, but the msr for
its core will remain unprogrammed.

When this debugfs file is read, that secondary thread will receive the ipi
and execute the rmpopt instruction in rmpopt_report_status(). Because its
core's msr was never enabled, won't executing the instruction raise
a fatal invalid opcode exception and panic the kernel?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1781419998.git.ashish.kalra@amd.com?part=7

      reply	other threads:[~2026-06-15 20:07 UTC|newest]

Thread overview: 12+ 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-15 20:14   ` sashiko-bot
2026-06-15 19:49 ` [PATCH v8 3/7] crypto/ccp: Disable CPU hotplug while SNP is active Ashish Kalra
2026-06-15 20:14   ` sashiko-bot
2026-06-15 19:49 ` [PATCH v8 4/7] x86/sev: Add support to perform RMP optimizations asynchronously Ashish Kalra
2026-06-15 20:07   ` sashiko-bot
2026-06-15 19:49 ` [PATCH v8 5/7] x86/sev: Add interface to re-enable RMP optimizations Ashish Kalra
2026-06-15 19:50 ` [PATCH v8 6/7] KVM: SEV: Perform RMP optimizations on SNP guest shutdown Ashish Kalra
2026-06-15 20:06   ` sashiko-bot
2026-06-15 19:50 ` [PATCH v8 7/7] x86/sev: Add debugfs support for RMPOPT Ashish Kalra
2026-06-15 20:07   ` sashiko-bot [this message]

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=20260615200721.4600C1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Ashish.Kalra@amd.com \
    --cc=kvm@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.