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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 76E4AC433EF for ; Tue, 10 May 2022 18:32:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348963AbiEJSc1 (ORCPT ); Tue, 10 May 2022 14:32:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35612 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348808AbiEJScX (ORCPT ); Tue, 10 May 2022 14:32:23 -0400 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7F1994E38A; Tue, 10 May 2022 11:32:21 -0700 (PDT) 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220506161359.4j5j5fxrw53fdbyr@box.shutemov.name> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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