On Thu, Sep 18, 2025 at 02:10:03PM +0200, Stefan Fritsch wrote:
> 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;
>  }
>

ok mlarkin if you add a comment explaining what's going on here. I know the plan
is to only temporarily do this workaround but it would be nice if someone were
to read the code to understand why this is here.

-ml