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 4390BC433EF for ; Wed, 11 May 2022 01:13:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BBD5B6B0071; Tue, 10 May 2022 21:13:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B94A16B0072; Tue, 10 May 2022 21:13:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A36786B0073; Tue, 10 May 2022 21:13:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 970566B0071 for ; Tue, 10 May 2022 21:13:50 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 6D34C2F826 for ; Wed, 11 May 2022 01:13:50 +0000 (UTC) X-FDA: 79451690220.18.A24B101 Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) by imf02.hostedemail.com (Postfix) with ESMTP id A1F73800AE for ; Wed, 11 May 2022 01:13:42 +0000 (UTC) Received: by mail-lf1-f41.google.com with SMTP id bu29so1043013lfb.0 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=RqcaMgU/1YjtZbYvfAW4hLBaC0T77+hVao4fPAsqfyQMNS8lRz6OJfo0tRE1pO1e07 rRO0f/YZf/fgIC0wOablWshWlpc/0scpkaSM57okkkaR2xlnd6j5dTnGnhrCHt4nY5XW 2PxrGW8CVZC0QWYMsshS7UnCQBKWEBf++sHsp6R/0jW2Ubh93tijb550toM4uoyEUsZy 53wYjxiQ7zQsS/zZCvcf/WLUQ+w0NZtjrao3e9sc9uhWKTB3gfTcDOfHyMlvUJ4zqDfu WuC6t5Cm9X01TLQ9sWvVncdv285UyYbXZNSFDrA+sC1e74QArHPQBnLXlhHjgk67b+2W uPxw== X-Gm-Message-State: AOAM531cvItti/sbWggiC/kPi6EcUVGSI3P+rp9vPsszzeVfifBa+VC+ aN6tUi5yMShAcwj9YMx8X8Y26g== 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: A1F73800AE X-Stat-Signature: mt5r8js7c8pgqfbamcabtdktcw7oim9h Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=shutemov-name.20210112.gappssmtp.com header.s=20210112 header.b=SITdpMnl; dmarc=none; spf=none (imf02.hostedemail.com: domain of kirill@shutemov.name has no SPF policy when checking 209.85.167.41) smtp.mailfrom=kirill@shutemov.name X-Rspam-User: X-HE-Tag: 1652231622-975655 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, 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