Received: by 2002:a05:7208:9594:b0:7e:5202:c8b4 with SMTP id gs20csp874957rbb; Sun, 25 Feb 2024 07:54:55 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCUPLEXJjWVUnAwsGH+OO+zAU6vp3xfXKB5AlTNA07+ZyG2k74oJqU7NmQ0dDKEt+Rhr2KdqSr7vRijMI0QAl2/KupIRlvtM66QYu2aaEA== X-Google-Smtp-Source: AGHT+IElwPuh1clUacBZc8rKLza8RuF6laFvBlsXaeMt+9PVpdxHTbv0bh5qE8SpbuX86Ch6azIZ X-Received: by 2002:a17:903:189:b0:1dc:692:2843 with SMTP id z9-20020a170903018900b001dc06922843mr7016997plg.5.1708876494776; Sun, 25 Feb 2024 07:54:54 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708876494; cv=pass; d=google.com; s=arc-20160816; b=OOvNzbsv+lSKhW/Qo5g4sFp7dJpNT3wUb6onI0R/rONiJl11n0d3QIDPamrRUEl3Gz 7Rv0ZdEJwo6gyXEIyoKHlNLYMEr2tWAE+hveF8ZNFl4cI8RxXx4WE5lqxeLkacYCVICG 1XTP1i4/qwHj9f9rAI9aIzyuWcJIMxUDCfc+i91yf8hAOBdxltTpn8As0gjWOiKw4/M/ /1H+cJ122XfAVTUWP+wcrmcaUicNoJWtlR/mSxKSTLu6XS0SGKnF2F9CDTRaCM5P0Est u20vNizh35dizfZfhryDC/WVXWONt1HN7W6UOKj7niLAYlTquuVNJHZh2ZfzJdK7ewKt KqVg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=13fHlLp09wMSRcCNQb8Rgdy/31NS2eaRWwCyXMf/Id4=; fh=SFiH9HzS9X8YVGoq6B+2XozC9RoPbRa1DWxSUoF+nss=; b=CxBEB81QRMksS1MjeiPOwjcTh9w2MCrHhvARityDKSWCFwxuKtV7l59CuK7gNDM5LR uFTg+8zGvSHBj2BZx9yDDlGUvQquul6D/psBzm4QGeS0qItX2ZaZivC0cggBybo+nI9A NPbITI7M+OQQFdK8P4lghJKRBVB2EX1jAQIdy2SColv5uG7qBu02cuIck8ZWHNbgdLgq mhLrWRwVprPleapWKufuqn4rK/0NrmNCHTxCSnJ/Ir0C9AG7FnqL56ZIVt45biqGSLMJ IAk4uKYE8yxUY6KCeWkLYdghqD8F37KdchPZw/AySRW1DkBlc+OvbiAsbi1M9WilMoVa g3Vg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=LTNlvJm4; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-80169-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-80169-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id f1-20020a170902ff0100b001dbd81089e6si2241943plj.515.2024.02.25.07.54.54 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 25 Feb 2024 07:54:54 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-80169-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=LTNlvJm4; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-80169-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-80169-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 2F9EF28181A for ; Sun, 25 Feb 2024 15:54:54 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9A384175A5; Sun, 25 Feb 2024 15:54:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="LTNlvJm4" Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 CA7E6168DC for ; Sun, 25 Feb 2024 15:54:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708876486; cv=none; b=IhhZWzON26O4BP/jjbMmDC/q4pTjv9DNj9DFDD+8EaDWAU3lxi8mSRcEN4tbDVpPT2lXAXXPPq2yid5CIvkm07kdKqAgi7Vld2aKMQw3OBufelkXOU3WSaUM5DGicSRm7A+3WlFR3gNPZvTnRmCBJSjQJtj0v3YaTqi3J31IFrE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708876486; c=relaxed/simple; bh=a8WuHvI6h6kLGhcZUjOjqEaaYOLzg47IYOWKmjJs8cw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=W13GRoZ4+/Ckqf0FA7KxqL4rdRb8lxsynQGgxifo4egZwIVs97qGjp6vnqtkT2EPJ+4KWucfb1x6NtInNZyW+scsGioTy0DKV1yy3w3TCS01jfBj7JVHRPfvWqd7Dtkt73gkUgB1VaeUOLRDZXDli94gypGWrzwC12FwUEV7S0w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=LTNlvJm4; arc=none smtp.client-ip=198.175.65.16 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708876483; x=1740412483; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=a8WuHvI6h6kLGhcZUjOjqEaaYOLzg47IYOWKmjJs8cw=; b=LTNlvJm4il71MKR7KW6lxlggxAIjLTTQ4Wm0NZpIFcQkVvaO1WwCRhLg btvOz9FSuEnucqJ8VFsgauBQa2fJ66B32xtzwanl7LFyJUn1h1GxOBSZJ JJHW1PU1GNXgv6zfrlaGsRkIxlyj8TCHC28xP7aRRTR9PAztM/+RMoKnM e6aEghrOzQNL1zN+hK30+tWfDEmhO1bueJQElw6vzUJkV2BLmDxarieVw 85fRcWbonQTB8tvcJxDj51o0vKUnpn20qz8cxIqR244Qccutid9R97RCM wBm36HRE7n+u5HBueP8nIWzmk+poeSAvo42brlrMTXltj05oXPSizBQAf g==; X-IronPort-AV: E=McAfee;i="6600,9927,10995"; a="3296457" X-IronPort-AV: E=Sophos;i="6.06,185,1705392000"; d="scan'208";a="3296457" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Feb 2024 07:54:43 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10995"; a="937028120" X-IronPort-AV: E=Sophos;i="6.06,185,1705392000"; d="scan'208";a="937028120" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga001.fm.intel.com with ESMTP; 25 Feb 2024 07:54:38 -0800 Received: by black.fi.intel.com (Postfix, from userid 1000) id B60FB425; Sun, 25 Feb 2024 17:54:36 +0200 (EET) Date: Sun, 25 Feb 2024 17:54:36 +0200 From: "Kirill A. Shutemov" To: Dave Hansen Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "Rafael J. Wysocki" , Peter Zijlstra , Adrian Hunter , Kuppuswamy Sathyanarayanan , Elena Reshetova , Jun Nakajima , Rick Edgecombe , Tom Lendacky , "Kalra, Ashish" , Sean Christopherson , "Huang, Kai" , Baoquan He , kexec@lists.infradead.org, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCHv7 08/16] x86/tdx: Account shared memory Message-ID: References: <20240212104448.2589568-1-kirill.shutemov@linux.intel.com> <20240212104448.2589568-9-kirill.shutemov@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Feb 23, 2024 at 11:08:18AM -0800, Dave Hansen wrote: > On 2/12/24 02:44, Kirill A. Shutemov wrote: > > The kernel will convert all shared memory back to private during kexec. > > The direct mapping page tables will provide information on which memory > > is shared. > > > > It is extremely important to convert all shared memory. If a page is > > missed, it will cause the second kernel to crash when it accesses it. > > > > Keep track of the number of shared pages. This will allow for > > cross-checking against the shared information in the direct mapping and > > reporting if the shared bit is lost. > > > > Include a debugfs interface that allows for the check to be performed at > > any point. > > When I read this, I thought you were going to do some automatic > checking. Could you make it more clear here that it's 100% up to the > user to figure out if the numbers in debugfs match and whether there's a > problem? This would also be a great place to mention that the whole > thing is racy. What about this: Include a debugfs interface to dump the number of shared pages in the direct mapping and the expected number. There is no serialization against memory conversion. The numbers might not match if access to the debugfs interface races with the conversion. > > +static atomic_long_t nr_shared; > > + > > +static inline bool pte_decrypted(pte_t pte) > > +{ > > + return cc_mkdec(pte_val(pte)) == pte_val(pte); > > +} > > Name this pte_is_decrypted(), please. But why? pte_decrypted() is consistent with other pte helpers pte_none(), pte_present, pte_dirty(), ... > > /* Called from __tdx_hypercall() for unrecoverable failure */ > > noinstr void __noreturn __tdx_hypercall_failed(void) > > { > > @@ -821,6 +829,11 @@ static int tdx_enc_status_change_finish(unsigned long vaddr, int numpages, > > if (!enc && !tdx_enc_status_changed(vaddr, numpages, enc)) > > return -EIO; > > > > + if (enc) > > + atomic_long_sub(numpages, &nr_shared); > > + else > > + atomic_long_add(numpages, &nr_shared); > > + > > return 0; > > } > > > > @@ -896,3 +909,59 @@ void __init tdx_early_init(void) > > > > pr_info("Guest detected\n"); > > } > > + > > +#ifdef CONFIG_DEBUG_FS > > +static int tdx_shared_memory_show(struct seq_file *m, void *p) > > +{ > > + unsigned long addr, end; > > + unsigned long found = 0; > > + > > + addr = PAGE_OFFSET; > > + end = PAGE_OFFSET + get_max_mapped(); > > + > > + while (addr < end) { > > + unsigned long size; > > + unsigned int level; > > + pte_t *pte; > > + > > + pte = lookup_address(addr, &level); > > + size = page_level_size(level); > > + > > + if (pte && pte_decrypted(*pte)) > > + found += size / PAGE_SIZE; > > + > > + addr += size; > > + > > + cond_resched(); > > + } > > This is totally racy, right? Nothing prevents the PTE from > flip-flopping all over the place. Yes. > > + seq_printf(m, "Number of shared pages in kernel page tables: %16lu\n", > > + found); > > + seq_printf(m, "Number of pages accounted as shared: %16ld\n", > > + atomic_long_read(&nr_shared)); > > + return 0; > > +} > > Ditto with 'nr_shared'. There's nothing to say that the page table walk > has anything to do with 'nr_shared' by the time we get down here. > > That's not _fatal_ for a debug interface, but the pitfalls need to at > least be discussed. Better yet would be to make sure this and the cpa > code don't stomp on each other. Serializing is cumbersome here. I can also just drop the interface. -- Kiryl Shutsemau / Kirill A. Shutemov