From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id CC6E2C61DA3 for ; Tue, 21 Feb 2023 21:15:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5BC7F6B0072; Tue, 21 Feb 2023 16:15:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 56D896B0073; Tue, 21 Feb 2023 16:15:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 40D0D6B0074; Tue, 21 Feb 2023 16:15:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 31DAE6B0072 for ; Tue, 21 Feb 2023 16:15:22 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id E96F1A079D for ; Tue, 21 Feb 2023 21:15:21 +0000 (UTC) X-FDA: 80492554842.24.30F56DE Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) by imf16.hostedemail.com (Postfix) with ESMTP id DBF21180019 for ; Tue, 21 Feb 2023 21:15:19 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=OrCTf5cZ; spf=pass (imf16.hostedemail.com: domain of zhi.wang.linux@gmail.com designates 209.85.167.44 as permitted sender) smtp.mailfrom=zhi.wang.linux@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677014120; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=gHZsoxAUB1qOQOkvHNT7weaGeMzKDk1Ga8sccYf8xcg=; b=lq+HLA0m3Pz172hczszfCpLOCqR9v7OUHRWiWbIMjl//iLl6aLbrr7yNEvk4w6FZChcgY3 9oZl7+sjCHtxwNNBAXCD1kiSy+KucHnyf4XLU77GGiH+4l/JkjZn/y9NaPYzPYm1jxh8ql +ok1x7hUsXbXXFlR2Ksgo26TzpjvLcw= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=OrCTf5cZ; spf=pass (imf16.hostedemail.com: domain of zhi.wang.linux@gmail.com designates 209.85.167.44 as permitted sender) smtp.mailfrom=zhi.wang.linux@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677014120; a=rsa-sha256; cv=none; b=6bzufLT+w7/VcB8Ij1S5w8OlPZsYJ6Yj5/OgPign2RhgG6KgAvOguSoX0rsyouU2NI2pTC I5eAlkEU7G2on5WGZHwXWIEMlDXrIEghgflvHlMRyEkye2xowmVJ/37OsNaLGqQwm4iN+2 TOHMdW/f9JvwPY0JuuVCqERZ4hW5+Vw= Received: by mail-lf1-f44.google.com with SMTP id m7so7380193lfj.8 for ; Tue, 21 Feb 2023 13:15:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=gHZsoxAUB1qOQOkvHNT7weaGeMzKDk1Ga8sccYf8xcg=; b=OrCTf5cZvZYUFHI/0GymXf51VnjzTEY6BgE6OrAmYOmm3bTTSSA/UOLWlCMCPQgC55 aq/YEqGEdbQYHMH3n0OOtLUx4JdtIzXhNaW/00LFoLB5SuhiiGu50b+Z01CJUMHv5p/4 NYLXgGXknyT5MCEWl49qH7N0/jJyC7vfTes8ZPD0yelwnYzHg1uB20y5h9njG0maWaBv /g66EkEgzHXRbMhMWWYfDGeCcIN5xCebQHh1hIY7T+cZOXQ3CrYc+/9NCPUq2UhZvxYv m43zjB2VgOxSsjzRswksXL8PVuUPSf74n7sRrPJFEMiAbtLH1ZcEF2jFhHBc/ZUjU8VN ky8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=gHZsoxAUB1qOQOkvHNT7weaGeMzKDk1Ga8sccYf8xcg=; b=BuLtEF5n7jGpVcnwivTxBDIJeEAfL3UO43diWG1N8s3fDajRbpEfA7RbKRLPbYD62E UfeggqjZjdXdoL8iQBiWJJAzbie2ayMCoutoY24b/h3p8T4lSfKyx5+aSSg2ign1/Xny umKrv5neaouWjBmp67RobKTKSLV4CIF1c9w7Q5Y6PMV/UEsm+Gn8jZhnJgVZ7mEUecFy 15MMgrAB+4/qiDGJgILbzIoRyQ+LYJHu7gVILAqgacjkHiU1c9eTZ1h45qm2J5htVblR 7OXjdhqTm3sGnbmokVqj2B3X+guqgDhYVour9LYkXbFmXcvxUDXMJC1zXGOlj2bHJtmj IF7Q== X-Gm-Message-State: AO0yUKUqGQDCrNWyJ3aw+Qk6/FPEnpOD+VeiJFUWfVfuC8jS/0gfIAd6 cX1yajZmeRYpe0VzlgpaOI8= X-Google-Smtp-Source: AK7set8NjTzhXspfN0nv7/0jUg0gxiYbQwoM+JmD4tCTFmj26oQh0HeivTpT3TU1zBHWBaGTqt8wqQ== X-Received: by 2002:a19:7014:0:b0:4d0:e044:f865 with SMTP id h20-20020a197014000000b004d0e044f865mr1873623lfc.6.1677014117822; Tue, 21 Feb 2023 13:15:17 -0800 (PST) Received: from localhost (88-115-161-74.elisa-laajakaista.fi. [88.115.161.74]) by smtp.gmail.com with ESMTPSA id v23-20020a197417000000b004d23763fe96sm1941493lfe.72.2023.02.21.13.15.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Feb 2023 13:15:17 -0800 (PST) Date: Tue, 21 Feb 2023 23:15:14 +0200 From: Zhi Wang To: "Kalra, Ashish" Cc: Michael Roth , 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, bp@alien8.de, vbabka@suse.cz, kirill@shutemov.name, ak@linux.intel.com, tony.luck@intel.com, marcorr@google.com, sathyanarayanan.kuppuswamy@linux.intel.com, alpergun@google.com, dgilbert@redhat.com, jarkko@kernel.org, nikunj.dadhania@amd.com, Brijesh Singh Subject: Re: [PATCH RFC v8 24/56] crypto: ccp: Handle the legacy TMR allocation when SNP is enabled Message-ID: <20230221231514.00004b27@gmail.com> In-Reply-To: References: <20230220183847.59159-1-michael.roth@amd.com> <20230220183847.59159-25-michael.roth@amd.com> <20230221112823.000063e4@gmail.com> X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: DBF21180019 X-Rspam-User: X-Stat-Signature: 4n3uwq8yctscru9q7z49b5dbja8e9his X-HE-Tag: 1677014119-492275 X-HE-Meta: U2FsdGVkX1/bGCUlVUgp0bgPp4HeuH/Bkl5aL7S6Lpa2TXRqALuDv1rfPH1hxOqO8dcB+ds1gWaBwVEjKNCoXRI+b8OY03hTry84b5oPClNvUZlYdBKQWUpBrwyI7GyJV+sZJnxVJl/sAsEZIWQJGfem5k0/i645u0u1GuxRvFDzGP/GDRHh+Db69KpJBV6/x9qptAzuFq0f8Ld6GzMu0QCXsYYAizpGs9rnW8h2AUK82nAtzd46mz4wH0WiO3y9pCG0NJBgHl+NNnQxg1SOjl3veAxZQ49kZg6gnCH4fhl+mD2gXEDygqUXFI4R6xwbatOR452cC3PRbncpn3EIP87ua2b3l0Pruls05M4Avs3cfgmQ2KkLZw1Tfb+CSL5BGs/MsIp/kMHm5ScHSDr+VuI5khXd8zafvGyawzMRfvSzpNlPnzX2ew0EqLBNiC4vC3vrJAtSTIXVmsQ06pfNBcKrPP9HtIXd/jcH42nMoqcGCZBUlLJTkX0RXGuoTpp/KBJ4qOFl0Dj00OqS2Af6bGo1wbhh9gG++udKlRh4yYNxta1hnduDAT2ED2ppRjFTIw0uss/b8XLs2C+6/0be+cG3iTCgoOQ9e0IwbQ1ybJv8GBqV8qkrAc4usXXyIcz42P5xm2UslqM+ZknwR6ruVQBGgHyYa247G1JNC985eRINkBXbQfRhM54POUbZSjTQooW/qjOybtYZseqqf37wo/nB0Dbq9jgCZg+/jY+bpMj+YI/rxOYx3ys0M65h5+68iHJqRQWFMIf8uCQbzdzyQ/oN+WzDwirTwRE0li0/T8pQNnwIfy7Uc4L2dCmsJrP0OW5djxfCiMVkEU/0SFnq1DIYfN3gjMicjFDT4SbwbxYZUiQ5T6pwgWIa5qdHz58r9NeWq2xl5ZdpVoBP4ZOtIVMo4JOTxnINJT+b7GexuRTOoKmoEWMniJvjmWODa20TQ5XlF46Rm81bvgeh2Ob y3Pa4bSM kBzHnx8V+p+z1Pad2IKu/+nvqxKz8Qk3YIoFR9rnDM5IFcIwd4Od7sxYtHpiX1hKYoy5IWXK7BZHXDcsGFNWx5XGkIGANT7zblkG+4JI4/OeDdL4vNYcmL2FOUfEMBhgbjuoWUk+ggAqscvl4kUe5pcB6dr602CahAwZJv9mQ9RmqA6HNz+BS85BGUHftoMhcc9ybLhajuZ1UC55zlPUhG6LC0rvHTq4VTrwK3i71WQ427h7Gttif1k0SdiaIungEN3aYvGefeFmvYUD/X7iUTGe5RRid5JTj/3gwTgIUrztNID5gNtBsEIxg8zGgdODG6t9inLbwrHR6hBvn6viOF9jsb8EfJkmoN9wovLKqDE9JyEZe07G99D9OirCdTfCdWElMpDsuSxOMQS6tVame9RuaWhXUGji1LsgahTxJzDYMxPafXymeOVaySt/TQtnbZRo+JqRRwU38set4LOSP7CqsnWydq0mycEwvJ+lhhHTYZEutT90iYLCADKTmDBufkVh9 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, 21 Feb 2023 09:31:01 -0600 "Kalra, Ashish" wrote: > >> +static int snp_reclaim_pages(unsigned long paddr, unsigned int npages, bool locked) > >> +{ > >> + /* Cbit maybe set in the paddr */ > > > > This is confusing. > > > > I suppose C-bit is treated as a attribute of PTE in the kernel not part of the > > PA. It means only a PTE might carry a C-bit. > > > > snp_reclaim_pages() is also called for reclaiming guest memory, in which > case the (guest) paddr will have the C-bit set. Hence this C-bit > handling is done within snp_reclaim_pages() so that the callers don't > need to handle it explicitly. Thanks for the explanation. Do you mean it will be used like that in the later patch? Sorry if it is in the later patch as I was making progress slowly. It is quite a big patch set. At least, I don't see that kind of usage in the current patch. Feel free to correct me if I am wrong. The call chains: __snp_free_firmware_page() snp_reclaim_pages(); As __snp_free_firmware_page() takes struct page*, all the follwing coversion from it would not carry C-bit. __snp_alloc_firmware_pages() rmp_mark_pages_firmware() snp_reclaim_pages() As __snp_alloc_firmware_page() allocates page with struct page*, the same conclusion as above. > > > > The paddr is from __pa(page_address()). It is not extracted from a PTE. Thus, the > > return from them should never have a C-bit. > > > > BTW: Wouldn't it be better to have pfn as input param instead of paddr? > > > > The caller has struct page, calling snp_reclaim_pages(page_to_pfn(page), xxxxx) > > would be much clearer than the current conversion: > > page_address() (struct page is converted to VA), __pa() (VA is converted to PA) > > in the caller and then PA is converted to pfn here. > > > >> + unsigned long pfn = __sme_clr(paddr) >> PAGE_SHIFT; > >> + int ret, err, i, n = 0; > >> + > > > > should be unsigned int i, n; as the input param npage is unsigned int. > > > >> + if (!pfn_valid(pfn)) { > >> + pr_err("%s: Invalid PFN %lx\n", __func__, pfn); > >> + return 0; > >> + } > >> + > >> + for (i = 0; i < npages; i++, pfn++, n++) { > >> + paddr = pfn << PAGE_SHIFT; > >> + > >> + if (locked) > >> + ret = __sev_do_cmd_locked(SEV_CMD_SNP_PAGE_RECLAIM, &paddr, &err); > >> + else > >> + ret = sev_do_cmd(SEV_CMD_SNP_PAGE_RECLAIM, &paddr, &err); > >> + > >> + if (ret) > >> + goto cleanup; > >> + > >> + ret = rmp_make_shared(pfn, PG_LEVEL_4K); > >> + if (ret) > >> + goto cleanup; > >> + } > >> + > >> + return 0; > >> + > >> +cleanup: > >> + /* > >> + * If failed to reclaim the page then page is no longer safe to > >> + * be release back to the system, leak it. > >> + */ > >> + snp_mark_pages_offline(pfn, npages - n); > >> + return ret; > >> +} > >> + > >> +static int rmp_mark_pages_firmware(unsigned long paddr, unsigned int npages, bool locked) > > > > The same comment as above. Better take pfn or page instead of paddr with > > redundant conversions. > > > > Again, the paddr can point to guest memory so it can have C-bit set. > > Thanks, > Ashish > > >> +{ > >> + /* Cbit maybe set in the paddr */ > >> + unsigned long pfn = __sme_clr(paddr) >> PAGE_SHIFT; > >> + int rc, n = 0, i; > >> + > >> + for (i = 0; i < npages; i++, n++, pfn++) { > >> + rc = rmp_make_private(pfn, 0, PG_LEVEL_4K, 0, true); > >> + if (rc) > >> + goto cleanup; > >> + } > >> + > >> + return 0; > >> + > >> +cleanup: > >> + /* > >> + * Try unrolling the firmware state changes by > >> + * reclaiming the pages which were already changed to the > >> + * firmware state. > >> + */ > >> + snp_reclaim_pages(paddr, n, locked); > >> + > >> + return rc; > >> +} > >> +