Index | Thread | Search

From:
Stefan Fritsch <sf@sfritsch.de>
Subject:
Re: SEV-ES multiprocessor support
To:
Mark Kettenis <mark.kettenis@xs4all.nl>
Cc:
tech@openbsd.org, mlarkin@nested.page
Date:
Thu, 18 Sep 2025 14:10:03 +0200

Download raw body.

Thread
On Thu, 18 Sep 2025, Mark Kettenis wrote:

> > Date: Thu, 18 Sep 2025 13:17:32 +0200 (CEST)
> > From: Stefan Fritsch <sf@sfritsch.de>
> > 
> > Hi,
> > 
> > one remaining problem with SEV-ES is that we don't support multiprocessor 
> > yet, and booting openbsd in a SEV-ES VM that has several VCPUs hangs at
> > 
> > cpu3 at mainbus0: apid 3 (application processor)
> > cpu3: failed to become ready
> > cpu3: failed to identify
> > 
> > Sometimes it continues after some time, but often it does not. I am not 
> > sure if the problem is on our side or if there is some error handling 
> > missing in qemu/KVM. Even if it does not hang, some things do not work 
> > correctly, like sysctl hw.ncpu is wrong, top gives warnings, ...
> > 
> > In any case, I think this should be fixed somehow before the release, in 
> > order to avoid support requests on the lists. There are two ways forward:
> > 
> > 1) try to get SEV-ES MP support finished before the release.
> > 
> > 2) commit some workaround that prevents openbsd from trying to use the 
> > application processors if SEV-ES is enabled. Likely in cpu_match().
> > 
> > The diff that implements MP support is attached below. With this diff, 
> > openbsd works for me in a 4 VCPU VM with SEV-ES enabled.
> > 
> > There is also the question if we actually need MP support for SEV-ES. 
> > SEV-ES is just a intermediate step and in the end, most people will want 
> > to use SEV-SNP (supported in Zen 3 Epyc CPUs and later). MP CPU bringup is 
> > again a bit different with SEV-SNP compared to SEV-ES, though the larger 
> > part of the diff is needed for both variants. In my opinion, skipping MP 
> > support for SEV-ES and only implementing it for SEV-SNP later is also an 
> > option.
> > 
> > I doubt there is enough time for 1). But I could start splitting the diff 
> > into reviewable parts and we will see how far we get.
> > 
> > What do you think?
> 
> I think no.  If it isn't finished, it isn't finished.  Therwe will be
> time to do things properly after the tree unlocks.

Fine with me. Then I would like to commit the small diff below to fix
the hangs mentioned above.

ok? Or is there a better way?


diff --git a/sys/arch/amd64/amd64/cpu.c b/sys/arch/amd64/amd64/cpu.c
index 2611859f3f5..98b97892a1f 100644
--- a/sys/arch/amd64/amd64/cpu.c
+++ b/sys/arch/amd64/amd64/cpu.c
@@ -484,6 +484,10 @@ cpu_match(struct device *parent, void *match, void *aux)
 	if (cf->cf_unit >= MAXCPUS)
 		return 0;
 
+	if (ISSET(cpu_sev_guestmode, SEV_STAT_ES_ENABLED) &&
+	    cf->cf_unit >= 1)
+		return 0;
+
 	return 1;
 }