From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CE6734424 for ; Mon, 31 Oct 2022 21:15:46 +0000 (UTC) Received: from zn.tnic (p200300ea9733e7f5329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:9733:e7f5:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id DFF1F1EC0430; Mon, 31 Oct 2022 22:15:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1667250944; h=from:from: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:in-reply-to:in-reply-to: references:references; bh=DgU+XgOhdBAORYCQvXhnNLYByJbTFJfkVBopLrqf9iI=; b=UBchbjp0cXfAYDiw9MvIMfTMohAQvNHSEOqD0qqH300draA9eAuqTP3tB0n+GzdafOpSSF Wn3qr3VbpZy/af3JUemdiT8IjltBlnFK4Jwa7BMsG/jgkXRWcGI5AozcGEKCyqA4ThKP5g w59EfXwJZcbCayMtLfvJao65kEkVlNU= Date: Mon, 31 Oct 2022 22:15:41 +0100 From: Borislav Petkov To: "Kalra, Ashish" Cc: vbabka@suse.cz, x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@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, michael.roth@amd.com, 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 Subject: Re: [PATCH Part2 v6 14/49] crypto: ccp: Handle the legacy TMR allocation when SNP is enabled Message-ID: References: <3a51840f6a80c87b39632dc728dbd9b5dd444cd7.1655761627.git.ashish.kalra@amd.com> <380c9748-1c86-4763-ea18-b884280a3b60@amd.com> <6511c122-d5cc-3f8d-9651-7c2cd67dc5af@amd.com> Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6511c122-d5cc-3f8d-9651-7c2cd67dc5af@amd.com> On Mon, Oct 31, 2022 at 03:10:16PM -0500, Kalra, Ashish wrote: > Just to add here, writing to any of these pages from the Host > will trigger a RMP #PF which will cause the RMP page fault handler > to send a SIGBUS to the current process, as this page is not owned > by Host. And kill the host process? So this is another "policy" which sounds iffy. If we kill the process, we should at least say why. Are we doing that currently? > So calling memory_failure() is proactively doing the same, marking the > page as poisoned and probably also killing the current process. But the page is not suffering a memory failure - it cannot be reclaimed for whatever reason. Btw, how can that reclaim failure ever happen? Any real scenarios? Anyway, memory failure just happens to fit what you wanna do but you can't just reuse that - that's hacky. What is the problem with writing your own function which does that? Also, btw, please do not top-post. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette