Re: [PATCH v2 1/2] x86/sev: Put PSC struct on the stack in prep for unaccepted memory support

[Tom Lendacky]

On 8/13/22 14:40, Borislav Petkov wrote:
> On Fri, Aug 12, 2022 at 09:51:41AM -0500, Tom Lendacky wrote:
> > On 8/12/22 09:33, Borislav Petkov wrote:
> > > On Fri, Aug 12, 2022 at 09:11:25AM -0500, Tom Lendacky wrote:
> > > > There was a whole discussion on this
> > >
> > > Pointer to it?
> >
> > It starts here: https://lore.kernel.org/lkml/658c455c40e8950cb046dd885dd19dc1c52d060a.1659103274.git.thomas.lendacky@xxxxxxx/
>
> So how come none of the rationale for the on-stack decision vs a single
> buffer with a spinlock protection hasn't made it to this patch?
>
> We need to have the reason why this thing is changed documented
> somewhere.

Yup, was all being addressed in v3 based on Dave's comments.

> > > So smaller, on-stack PSC but lockless is still better than a bigger one
> > > but with synchronized accesses to it?
>
> That thing.
>
> That decision for on-stack buffer needs explaining why.
>
> > > > Well when we don't know which GHCB is in use, using that reserved area in
> > > > the GHCB doesn't help.
> > >
> > > What do you mean?
> > >
> > > The one which you read with
> > >
> > > 	data = this_cpu_read(runtime_data);
> >
> > Memory acceptance is called before the per-CPU GHCBs have been allocated
> > and so you would be actually be using early boot GHCB. And that is decided
> > based on the #VC handler that is invoked - but in this case we're not
> > coming through the #VC handler to accept memory.
>
> But then ghcb_percpu_ready needs to be a per-CPU variable too! Because
> it is set right after snp_register_per_cpu_ghcb() which works on the
> *per-CPU* GHCB.

No, and the code comment will explain this. Since the APs only ever use 
the per-CPU GHCB there is no concern as to when there is a switch over 
from the early boot GHCB to the per-CPU GHCB, so a single global variable 
is all that is needed.

I'll send out v3 soon.

Thanks,
Tom

>