Received-SPF: pass (google.com: domain of linux-kernel+bounces-7269-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Date: Tue, 19 Dec 2023 17:46:12 -0600
From: Michael Roth <michael.roth@amd.com>
To: Borislav Petkov <bp@alien8.de>
CC: <kvm@vger.kernel.org>, <linux-coco@lists.linux.dev>, <linux-mm@kvack.org>,
	<linux-crypto@vger.kernel.org>, <x86@kernel.org>,
	<linux-kernel@vger.kernel.org>, <tglx@linutronix.de>, <mingo@redhat.com>,
	<jroedel@suse.de>, <thomas.lendacky@amd.com>, <hpa@zytor.com>,
	<ardb@kernel.org>, <pbonzini@redhat.com>, <seanjc@google.com>,
	<vkuznets@redhat.com>, <jmattson@google.com>, <luto@kernel.org>,
	<dave.hansen@linux.intel.com>, <slp@redhat.com>, <pgonda@google.com>,
	<peterz@infradead.org>, <srinivas.pandruvada@linux.intel.com>,
	<rientjes@google.com>, <dovmurik@linux.ibm.com>, <tobin@ibm.com>,
	<vbabka@suse.cz>, <kirill@shutemov.name>, <ak@linux.intel.com>,
	<tony.luck@intel.com>, <sathyanarayanan.kuppuswamy@linux.intel.com>,
	<alpergun@google.com>, <jarkko@kernel.org>, <ashish.kalra@amd.com>,
	<nikunj.dadhania@amd.com>, <pankaj.gupta@amd.com>, <liam.merwick@oracle.com>,
	<zhi.a.wang@intel.com>, Brijesh Singh <brijesh.singh@amd.com>
Subject: Re: [PATCH v10 17/50] crypto: ccp: Handle the legacy TMR allocation
 when SNP is enabled
Message-ID: <20231219234612.qaq6bv54jcgo4f2a@amd.com>
References: <20231016132819.1002933-1-michael.roth@amd.com>
 <20231016132819.1002933-18-michael.roth@amd.com>
 <20231208130520.GFZXMUkKR+aexFpxXf@fat_crate.local>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20231208130520.GFZXMUkKR+aexFpxXf@fat_crate.local>
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Dec 2023 16:12:05.6845
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e7c4d304-2869-4127-7563-08dc017668e6
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	SA2PEPF00001507.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7254

On Fri, Dec 08, 2023 at 02:05:20PM +0100, Borislav Petkov wrote:
> On Mon, Oct 16, 2023 at 08:27:46AM -0500, Michael Roth wrote:
> > From: Brijesh Singh <brijesh.singh@amd.com>
> > 
> > The behavior and requirement for the SEV-legacy command is altered when
> > the SNP firmware is in the INIT state. See SEV-SNP firmware specification
> > for more details.
> > 
> > Allocate the Trusted Memory Region (TMR) as a 2mb sized/aligned region
> > when SNP is enabled to satisfy new requirements for the SNP. Continue
> 
> s/the //
> 
> > allocating a 1mb region for !SNP configuration.
> > 
> > While at it, provide API that can be used by others to allocate a page
> 
> "...an API... ... to allocate a firmware page."
> 
> Simple.
> 
> > that can be used by the firmware.
> 
> > The immediate user for this API will be the KVM driver.
> 
> Delete that sentence.
> 
> > The KVM driver to need to allocate a firmware context
> 
> "The KVM driver needs to allocate ...
> 
> > page during the guest creation. The context page need to be updated
> 
> "needs"
> 
> > by the firmware. See the SEV-SNP specification for further details.
> > 
> > Co-developed-by: Ashish Kalra <ashish.kalra@amd.com>
> > Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
> > Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
> > [mdr: use struct sev_data_snp_page_reclaim instead of passing paddr
> >       directly to SEV_CMD_SNP_PAGE_RECLAIM]
> > Signed-off-by: Michael Roth <michael.roth@amd.com>
> > ---
> >  drivers/crypto/ccp/sev-dev.c | 151 ++++++++++++++++++++++++++++++++---
> >  include/linux/psp-sev.h      |   9 +++
> >  2 files changed, 151 insertions(+), 9 deletions(-)
> > 
> > +static int rmp_mark_pages_firmware(unsigned long paddr, unsigned int npages, bool locked)
> > +{
> > +	/* Cbit maybe set in the paddr */
> > +	unsigned long pfn = __sme_clr(paddr) >> PAGE_SHIFT;
> > +	int rc, n = 0, i;
> 
> That n looks like it can be replaced by i.

Indeed, and for snp_reclaim_pages() too by the looks of it. Will fix that up,
along with all the other suggestions.

> > +
> > +void *snp_alloc_firmware_page(gfp_t gfp_mask)
> > +{
> > +	struct page *page;
> > +
> > +	page = __snp_alloc_firmware_pages(gfp_mask, 0, false);
> > +
> > +	return page ? page_address(page) : NULL;
> > +}
> > +EXPORT_SYMBOL_GPL(snp_alloc_firmware_page);
> > +
> > +static void __snp_free_firmware_pages(struct page *page, int order, bool locked)a
> 
> This @locked too is always false. It becomes true later in
> 
> Subject: [PATCH v10 50/50] crypto: ccp: Add panic notifier for SEV/SNP firmware shutdown on kdump
> 
> which talks about some panic notifier running in atomic context. But
> then you can't take locks in atomic context.

In that case, the lock isn't actually taken. locked==true is basically
used to tell the code to not to try to acquire the lock, but the caller
is relying on the fact that all the other CPUs are stopped at that point
so there's no need to protect against multiple concurrent firmware
commands being issued.

> 
> Looks like this whole dance around the locked thing needs a cleanup.

There's another case that will be introduced in the next version of this
series (likely right after this patch) to handle a bug where the buffer used
to access INIT_EX non-volatile data needs to be transitioned to
firmware-owned beforehand. In that case, the CCP cleanup path introduces
another caller of __snp_free_firmware_pages() where locked==true. Maybe this
can be revisited in that context.

Thanks,

Mike


> 
> ...
> 
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette