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 3D95823DD for ; Tue, 10 May 2022 18:32:21 +0000 (UTC) Received: from zn.tnic (p5de8eeb4.dip0.t-ipconnect.de [93.232.238.180]) (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 1E0DA1EC0354; Tue, 10 May 2022 20:32:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1652207536; 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=YwlI4SOdaCiIF2T0fRasnf3pb0Dz0W+PbTJT112BTbI=; b=qtivRA6UZ8N6glsgC7YCH4Cm2zMMzUrDPR5yH/pAfaBCOygYNvflOfciVP7oT8Np8O/88W CgzdPyC6lZl0zGjd536DXox2BLwQQZXRDAB0JHlgjwISgp0GqwOGue4hyBNWd+iqwogCc/ /bYQ0+dDaSjuHp0NUl7USPvcr5qTq8s= Date: Tue, 10 May 2022 20:32:23 +0200 From: Borislav Petkov To: "Kirill A. Shutemov" Cc: "Kirill A. Shutemov" , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel , Ard Biesheuvel , Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Varad Gautam , Dario Faggioli , Dave Hansen , Brijesh Singh , Mike Rapoport , David Hildenbrand , x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCHv5 08/12] x86/mm: Provide helpers for unaccepted memory Message-ID: References: <20220425033934.68551-1-kirill.shutemov@linux.intel.com> <20220425033934.68551-9-kirill.shutemov@linux.intel.com> <20220506161359.4j5j5fxrw53fdbyr@box.shutemov.name> 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: <20220506161359.4j5j5fxrw53fdbyr@box.shutemov.name> On Fri, May 06, 2022 at 07:13:59PM +0300, Kirill A. Shutemov wrote: > Failure to accept the memory is fatal. Why pretend it is not? > > For TDX it will result in a crash on the first access. Prolonging the > suffering just make it harder to understand what happened. Ok then. Does that panic message contain enough info so that the acceptance failure can be debugged? Just "Cannot accept memory" doesn't seem very helpful to me... > That's true. Note also that the check is inherently racy. Other CPU can > get the range or subrange accepted just after spin_unlock(). > > The check indicates that accept_memory() has to be called on the range > before first access. > > Do you have problem with a name? Maybe has_unaccepted_memory()? I have a problem with the definition of this function, what it is supposed to do and how it is supposed to be used. Right now, it looks weird and strange: is it supposed to check for *all* in-between (start, end)? It doesn't, atm, so what's the meaning of @start and @end then at all? -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette