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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 91DFAC4338F for ; Fri, 13 Aug 2021 14:49:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3AAAA610E9 for ; Fri, 13 Aug 2021 14:49:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3AAAA610E9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id CE1A28D0003; Fri, 13 Aug 2021 10:49:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C92078D0001; Fri, 13 Aug 2021 10:49:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B81AC8D0003; Fri, 13 Aug 2021 10:49:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0130.hostedemail.com [216.40.44.130]) by kanga.kvack.org (Postfix) with ESMTP id 9C1AB8D0001 for ; Fri, 13 Aug 2021 10:49:26 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 41C831C944 for ; Fri, 13 Aug 2021 14:49:26 +0000 (UTC) X-FDA: 78470340732.12.C5B03CB Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf04.hostedemail.com (Postfix) with ESMTP id D348550000AD for ; Fri, 13 Aug 2021 14:49:25 +0000 (UTC) Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 895F7201E3; Fri, 13 Aug 2021 14:49:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1628866164; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=wKIBL6uzh4EsJDLzBlrYYCv5BAAf1ULSfw0Ye7yXh+E=; b=znMpGiD4YTnMv4no2yvn/2VZro+VgcU88XkoSvPX84QBF3k0mtf42UF9Lu5dqQ+/yKOve8 RVNUD/HYcolixkPWGMSgIXVBD26/BJtGvpLZTx6a1/lWhDdTusWj81R70VjFJDUNlK0KTu /J5C5Synl/7aM5bKo4h0Q98znqy2jeU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1628866164; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=wKIBL6uzh4EsJDLzBlrYYCv5BAAf1ULSfw0Ye7yXh+E=; b=OaAG8lbJbxHrF2Tc9jC2WcIV8UkuHJyin6SXiWeiCCb/VSGf6QGj9qsNfmJnaAYu10+Rzo q+ji4KzaP8km3SDg== Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap1.suse-dmz.suse.de (Postfix) with ESMTPS id BAF9C13806; Fri, 13 Aug 2021 14:49:23 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap1.suse-dmz.suse.de with ESMTPSA id WvJhK3OGFmGjEAAAGKfGzw (envelope-from ); Fri, 13 Aug 2021 14:49:23 +0000 Date: Fri, 13 Aug 2021 16:49:22 +0200 From: Joerg Roedel To: Dave Hansen Cc: Andi Kleen , "Kirill A. Shutemov" , Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Varad Gautam , Dario Faggioli , x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" Subject: Re: [PATCH 1/5] mm: Add support for unaccepted memory Message-ID: References: <20210810062626.1012-1-kirill.shutemov@linux.intel.com> <20210810062626.1012-2-kirill.shutemov@linux.intel.com> <9748c07c-4e59-89d0-f425-c57f778d1b42@linux.intel.com> <17b6a3a3-bd7d-f57e-8762-96258b16247a@intel.com> <796a4b20-7fa3-3086-efa0-2f728f35ae06@linux.intel.com> <3caf5e73-c104-0057-680c-7851476e67ac@linux.intel.com> <25312492-5d67-e5b0-1a51-b6880f45a550@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25312492-5d67-e5b0-1a51-b6880f45a550@intel.com> Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=znMpGiD4; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=OaAG8lbJ; spf=pass (imf04.hostedemail.com: domain of jroedel@suse.de designates 195.135.220.29 as permitted sender) smtp.mailfrom=jroedel@suse.de; dmarc=pass (policy=none) header.from=suse.de X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: D348550000AD X-Stat-Signature: gtzje9wzhdo9hadzdatb3oooxy5ewor9 X-HE-Tag: 1628866165-808641 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: Hi Dave, On Thu, Aug 12, 2021 at 07:14:20AM -0700, Dave Hansen wrote: > maybe_accept_page() > { > unsigned long huge_pfn = page_to_phys(page) / PMD_SIZE; > > /* Test the bit before taking any locks: */ > if (test_bit(huge_pfn, &accepted_bitmap)) > return; > > spin_lock_irq(); > /* Retest inside the lock: */ > if (test_bit(huge_pfn, &accepted_bitmap)) > return; > tdx_accept_page(page, PMD_SIZE); > set_bit(huge_pfn, &accepted_bitmap)); > spin_unlock_irq(); > } Yeah, this could work, but the global lock is likely the show-stopper here. For SNP we also not allowed to double-validate, so we need something that basically indicates 'validation-is-ongoing' on a per 2MB basis. I am not an mm expert, but a page flag probably doesn't work. The flag would be on the head of the 2MB range and when that page is already used somewhere else there is no guarantee that the flag will survive. But correct me if I am wrong here :) The other options I can come up with are not great either: 1) using an AVL bit in the direct-mapping PMD of that page. The page-table would only be walked if the bit in the accept_bitmap is clear. But I am not sure that all memory which needs to be validated is in the direct-map. 2) Use another page-sized bitmap. If the machine has more than 64GB of memory the bit index is wrapped around. This shouldn't be a performance problem at runtime, if this page is only consulted when the valid bit is clear in the accept_bitmap. MM experts could certainly come up with better ideas :) > Yeah, I think the *canonical* source of information for accepts is the > bitmap. The page flags and any static keys or whatever are > less-canonical sources that tell you when you _might_ need to consult > the bitmap. Right, it also helps the kexec case. The only problem left is how to track 4kb shared pages for things like the GHCB. Regards, Joerg