Messages in this thread | | | Date | Sun, 14 Aug 2022 08:36:47 -0500 | Subject | Re: [PATCH v2 1/2] x86/sev: Put PSC struct on the stack in prep for unaccepted memory support | From | 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@amd.com/ > > 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
>
| |