From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2899915A7 for ; Wed, 11 May 2022 01:13:49 +0000 (UTC) Received: by mail-lf1-f42.google.com with SMTP id t25so945924lfg.7 for ; Tue, 10 May 2022 18:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Bz7T0QeLgAJ6DucemKvTFSRRlyGBkltInGSYnDXnR6E=; b=SITdpMnlNlx+3zL+SdaU/V7AVAmvkiqPssMcBSWZWWDUdtfPM2FI3GlFrfXkRXujBX 9DWIF4Ur9OceQgYPcvcJD9fJw9kaCM0AzQ4sZUpZoprhUue1tO/tTqWR5hLzH1p6ksQR 00Sf1wl28/tqU/6fg3271g6fUeNlfzqwzZNRgg52wEaXuyvenE+FO7wFGU35V0JkRyE/ KeKZekt1aeYzaQ0P/YK4BNZk+xtI8SMHuieVKGSc8Vjj/SDBRoUU3xQ0u7y1HOm5z/Lx tGHJClst604ij70mzpHhoKbFU46qmOdfa5hyokCbDK1fsQLPyd7EbGxQ37aGOSA7H/7s ZRaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Bz7T0QeLgAJ6DucemKvTFSRRlyGBkltInGSYnDXnR6E=; b=5tDoTJNc2c3oGUFSqlmr1eFfQu9C92w/MLjhT6z4eQxD9L6IUH6AdxSK16wohgAZrA 1jNZyJccUSYetjXdd0snNpyrMpZdt1jgnXOVX0Wc0s36ByJN6WF4fuhfvMGSKFnmo035 3rjaBZQ5yWtI+kmKei1fS998HzZZFo+wOej+kUHq2MLgPCviMwW2eujOcrqg8F1FaUhk Ha2m9xfG9eY+ZGcn9zxo/7HCGToszcA1mteJ+DM2ycvv91Q4pb93/LMZGlDgivHowyHE jSYQBDo28doRUInMN/QOx7LfI2Hm+eAIff7SQtWlGrW7xykcePoCddjXL0jl71u/l93D wddQ== X-Gm-Message-State: AOAM531ug0S+GnR7+PXTMscga+gisHf1hmMsjkY4Nrdj/1sTxLdgI63Z u6tSQQ9dSrN9OLgRV19/fDaeEA== X-Google-Smtp-Source: ABdhPJxs/icOeGtB0xTHmPLhJmWFLDgo13VXMOYoMaE6Q8CFmDYapX/c98WO7YQadPeColzl9WZUJg== X-Received: by 2002:a05:6512:32ca:b0:473:cb3d:6ca2 with SMTP id f10-20020a05651232ca00b00473cb3d6ca2mr18143399lfg.261.1652231628067; Tue, 10 May 2022 18:13:48 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id o9-20020ac24349000000b0047428dbea1csm56357lfl.303.2022.05.10.18.13.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 May 2022 18:13:47 -0700 (PDT) Received: by box.localdomain (Postfix, from userid 1000) id 75072104757; Wed, 11 May 2022 04:15:35 +0300 (+03) Date: Wed, 11 May 2022 04:15:35 +0300 From: "Kirill A. Shutemov" To: Borislav Petkov 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: <20220511011535.or73rm6oviwa5niy@box.shutemov.name> 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=us-ascii Content-Disposition: inline In-Reply-To: On Tue, May 10, 2022 at 08:32:23PM +0200, Borislav Petkov wrote: > 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... Okay. Fair enough. I will change it to panic("Cannot accept memory: unknown platform."); > > > 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? It checks if the range of memory requires accept_memory() call before it can be accessed. If any part of the range is not accepted, the call is required. accept_memory() knows what exactly has to be done. Note that accept_memory() call is harmless for any valid memory range. It can be called on already accepted memory. -- Kirill A. Shutemov