Messages in this thread | | | Date | Sat, 13 Aug 2022 21:40:14 +0200 | From | Borislav Petkov <> | Subject | Re: [PATCH v2 1/2] x86/sev: Put PSC struct on the stack in prep for unaccepted memory support |
| |
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.
> > 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.
-- Regards/Gruss, Boris.
https://people.kernel.org/tglx/notes-about-netiquette
| |