All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Yazen Ghannam <yazen.ghannam@amd.com>
Cc: Jason Andryuk <jason.andryuk@amd.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	Mario Limonciello <mario.limonciello@amd.com>,
	Thomas Gleixner <tglx@kernel.org>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	Penny Zheng <penny.zheng@amd.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH 2/2] x86/amd_node: Avoid divide by zero on virtualized systems
Date: Tue, 11 Aug 2026 09:21:07 +0100	[thread overview]
Message-ID: <20260811092107.37ef648b@pumpkin> (raw)
In-Reply-To: <20260810144706.GC57095@yaz-khff2.amd.com>

On Mon, 10 Aug 2026 10:47:06 -0400
Yazen Ghannam <yazen.ghannam@amd.com> wrote:

> On Thu, Aug 06, 2026 at 12:01:57PM -0400, Jason Andryuk wrote:
> > On a virtualized system, the number of nodes does not have a
> > relationship to the number of roots.  A Xen PVH dom0 can calculate
> > roots_per_node as 0, which crashes with a divide by zero in:
> > 
> >     if (count++ % roots_per_node)
> > 
> > On a virtualized system, default the value to 1.  The issue is seen with
> > Xen, but it could affect other systems.
> > 
> > Fixes: 0a4b61d9c2e4 ("x86/amd_node: Fix AMD root device caching")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>  
> 
> I agree with the idea with some minor feedback below.
> 
> > ---
> > X86_FEATURE_XENPV is only for PV, but this is observed with a PVH dom0.
> > ---
> >  arch/x86/kernel/amd_node.c | 5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/arch/x86/kernel/amd_node.c b/arch/x86/kernel/amd_node.c
> > index ea553267e5fa..c5025e5291b6 100644
> > --- a/arch/x86/kernel/amd_node.c
> > +++ b/arch/x86/kernel/amd_node.c
> > @@ -286,6 +286,11 @@ static int __init amd_smn_init(void)
> >  		return -ENOMEM;
> >  
> >  	roots_per_node = num_roots / num_nodes;
> > +	if (roots_per_node == 0) {  
> 
> Can be '!roots_per_node'.
> 
> > +		if (!cpu_feature_enabled(X86_FEATURE_HYPERVISOR))
> > +			pr_err(FW_BUG "Error detecting roots per node.\n");
> > +		roots_per_node = 1;
> > +	}  
> 
> I don't think this is necessarily a Firmware bug.
> 
> Likewise, it can be a 'warning' rather than 'error'. I interpret 'error'
> as something known to be incorrect. This was my position before on this
> topic. But the various contrary reports changed my mind (even if they
> come from virtualization).
> 
> Furthermore, I think 'warning' is more appropriate. It says "We found
> something unexpected. We're letting you (the user) know about it. And
> we'll mitigate it to avoid an error."
> 
> Anyways, I just wanted to write out some thoughts since this topic has
> come up a few times.
> 
> Possible rework for the above change:
> 
> 	if (!roots_per_node && !cpu_feature_enabled(X86_FEATURE_HYPERVISOR)
> 		pr_warn("Expected at least 1 root per AMD node.\n");
> 
> 	roots_per_node = max(roots_per_node, 1);

I'd not add the max(), just;
	if (!roots_per_node) {
		roots_per_node = 1;
		if (cpu_feature_enabled(X86_FEATURE_HYPERVISOR)
			pr_warn("Expected at least 1 root per AMD node.\n");
	}

David

> 
> In any case, we should just go with a simple fix for the virt cases.
> 
> I think we could even do away with caching the 'root' devices. But
> that'll be another rework/cleanup.
> 
> Thanks,
> Yazen
> 


  parent reply	other threads:[~2026-08-11  8:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-06 16:01 [PATCH 0/2] x86/amd_node: Fixes for virtualized systems Jason Andryuk
2026-08-06 16:01 ` [PATCH 1/2] x86/amd_node: Remove smn_exclusive Jason Andryuk
2026-08-10 14:07   ` Yazen Ghannam
2026-08-11 14:19     ` Mario Limonciello
2026-08-12 19:28     ` Borislav Petkov
2026-08-06 16:01 ` [PATCH 2/2] x86/amd_node: Avoid divide by zero on virtualized systems Jason Andryuk
2026-08-10 14:47   ` Yazen Ghannam
2026-08-10 20:16     ` Jason Andryuk
2026-08-11  8:21     ` David Laight [this message]
2026-08-11 21:23       ` Jason Andryuk
2026-08-12  7:11         ` David Laight
2026-08-12 19:31     ` Borislav Petkov

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=20260811092107.37ef648b@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jason.andryuk@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --cc=mingo@redhat.com \
    --cc=penny.zheng@amd.com \
    --cc=stable@vger.kernel.org \
    --cc=tglx@kernel.org \
    --cc=x86@kernel.org \
    --cc=yazen.ghannam@amd.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 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.