Received: by 2002:a89:288:0:b0:1f7:eeee:6653 with SMTP id j8csp131345lqh; Mon, 6 May 2024 13:42:09 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXkhMbVNBdbAyTkOTAiifyjoE8eT22qD432sKclG6IwFrkIJnsFKJtWCX70Bd/XjT7CVwmww7e84eaJq/I0YqfUK8QgDUDRJf2P0DgVbg== X-Google-Smtp-Source: AGHT+IE3zqiiDa2WG5xX2n5l/Wnl+/TXanIpiOX0lEJ63X94NUAogkubm4pr1M0sgUYxwmJrZ2gv X-Received: by 2002:a17:906:3ec2:b0:a52:2441:99c with SMTP id d2-20020a1709063ec200b00a522441099cmr6136472ejj.69.1715028129118; Mon, 06 May 2024 13:42:09 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1715028129; cv=pass; d=google.com; s=arc-20160816; b=pbJieXJJsLDhnwqn/qdDM7JvmOqMgeGFd37nUProdx727OzunfbLDRrH7HfqBRo1V1 teg3CAnww6id1ELGhc4+74UPd3sTZ3D8bAteM2ayxqDA4PwlPTQJDZKPumDPF92yy6Ag E8ffYMTM6sdazCxoxY5G990Q1q2PjCKe54OTqUa6YrTevnjZxJaE1vUly5XYYhtCjT0q CghEg8t75ZL2lbu5QsY5bthYWDyYYJEHXTo92jcvwnal+xkNqL9nyMTnOj5WD5Rxakhf wiER7madYb5XN2ALeIraSJxhwApsy7fmptlv86jFkkeFGRDw7LKqxSAUNc0jQOFLVnh1 cWWA== 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=0LflWE2JuzRmPEbrUvaFejnNRek7Vnu/L/ikNUfZW8Y=; fh=lxk+RvRezZ2XdeqcUekliP1X0ajcmlwf4vpqZg41Bzk=; b=u7grC2OPikssqLwiOIvAF63DRAZXsSCBp3/GSXSBmgJePQBDcUVqw6EKhhCPZFn8Op sQlNAYRGMTTeSB+UAlUkMmmVo0+ox/GvmC9hPdUvjdPjrXVcpipH+YBdL+ukznoYf9uh cMDNxLNlT+/sDDrtM8E8QYNcKg2/L2pm6TsEndA8LjyFgqNOGkFc30uQK5KFElrqUTed BSZ/IytivebnGUG8auCd/2HGEAHOTg+Q6v2OiCJSE1zwydY7VOnlBpEYsyDli8UBWoFw MbHwrJNom8MKsxhsNl2t3TyZGoxs/FkyGgCv6Q/HDhimsxEMRFFr5YHdsaDsSzLEcO+m PFXg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=BU5s3pTv; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-170079-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-170079-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id x20-20020a170906711400b00a59a221dca9si3222214ejj.522.2024.05.06.13.42.09 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 May 2024 13:42:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-170079-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=BU5s3pTv; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-170079-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-170079-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 am.mirrors.kernel.org (Postfix) with ESMTPS id CE8C71F23625 for ; Mon, 6 May 2024 15:37:34 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 21571155390; Mon, 6 May 2024 15:37:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="BU5s3pTv" Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.19]) (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 69BBF1DDD1 for ; Mon, 6 May 2024 15:37:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.19 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715009849; cv=none; b=C0O7Cjy1E+ComYU2Pk+6c5pkK1dhfumP02aPXFu2Xr8tqpfwBHnqpt+PhKqEI8r5y5A7+6AI4rc/xPRKwFdMBzzZ0sGdrJTd7bOQJ7lqzY+8X9cGQEUJEtd+vZU8ZN3dey6Rg1rSSztZdAZL0z6Wrlh8/ILAuXxQgp74gCjc7Hs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715009849; c=relaxed/simple; bh=u4Wbi+kWAVVOkhZHAsKkhw70PBDqYs/mFsVXLQcsk3I=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=hMZl8txZHo6GQ6cDVWxjT4oZrLLmg9DB8u21hogdtjbbgyoL91EaTF++0vNKryjSxURd0YMRit01yU+lFvWo/evc055X29HDHNAr0ThZXhaTcvOV0DvhSHzhTZMAcuYrGKx68MSCdbCgdBXaE6sI5sSyHXVgm54BtZl+PUhrSo4= 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=BU5s3pTv; arc=none smtp.client-ip=198.175.65.19 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=1715009846; x=1746545846; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=u4Wbi+kWAVVOkhZHAsKkhw70PBDqYs/mFsVXLQcsk3I=; b=BU5s3pTvTQbvLxo13/pKxVagcRlA+QY6JLZ74zpPHpL5XcQggQczNvVv pgBZ2tFuqUhhhWAUmRCPeiGMCAGqVoxqcbCVTYOtGOqzKebwCIze8bufS q3e8WrUweySQBGxYgYaYbym23o5ycUdhszd6TcgxEDNheekGqY/LZfyYc 2Z3put3m3QJTyJXaUGnjfq+V4F89MVfP8t0kI+opoxBWTwqty4077bjMa qj6UmdFQ8nhoHZGJVvyW1G9ZJ5bHBAoKWwL6ngUeCnxWBhOao39Gzf3ZD gCwmLaeRgWxmLramyBsMp2N89kwn4A1WKJ25cDk+hTW4XvzZqRUAc/VLw Q==; X-CSE-ConnectionGUID: /4zh8ZKkTlSpWN/Khr8dEg== X-CSE-MsgGUID: WV4HnkVDRuObGl7iATKYKw== X-IronPort-AV: E=McAfee;i="6600,9927,11065"; a="10608288" X-IronPort-AV: E=Sophos;i="6.07,258,1708416000"; d="scan'208";a="10608288" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 May 2024 08:37:26 -0700 X-CSE-ConnectionGUID: 3HZKYHL6T1iq+bktUHzxsg== X-CSE-MsgGUID: Qu6O7tEHQ1+L0dn0IGA/aw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,258,1708416000"; d="scan'208";a="59384212" Received: from black.fi.intel.com ([10.237.72.28]) by fmviesa001.fm.intel.com with ESMTP; 06 May 2024 08:37:21 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 9D7D9161; Mon, 06 May 2024 18:37:19 +0300 (EEST) Date: Mon, 6 May 2024 18:37:19 +0300 From: "Kirill A. Shutemov" To: Borislav Petkov Cc: Thomas Gleixner , Ingo Molnar , 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, Tao Liu Subject: Re: [PATCHv10 10/18] x86/tdx: Convert shared memory back to private on kexec Message-ID: References: <20240409113010.465412-1-kirill.shutemov@linux.intel.com> <20240409113010.465412-11-kirill.shutemov@linux.intel.com> <20240505121319.GAZjd337gHC0uhk6aM@fat_crate.local> 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: <20240505121319.GAZjd337gHC0uhk6aM@fat_crate.local> On Sun, May 05, 2024 at 02:13:19PM +0200, Borislav Petkov wrote: > On Tue, Apr 09, 2024 at 02:30:02PM +0300, Kirill A. Shutemov wrote: > > TDX guests allocate shared buffers to perform I/O. It is done by > > allocating pages normally from the buddy allocator and converting them > > to shared with set_memory_decrypted(). > > > > The second kernel has no idea what memory is converted this way. It only > > "The kexec-ed kernel..." > > is more precise. "second kernel" is nomenclature kexec folks are using, but okay. > > @@ -831,6 +833,73 @@ static int tdx_enc_status_change_finish(unsigned long vaddr, int numpages, > > return 0; > > } > > > > +/* Stop new private<->shared conversions */ > > +static void tdx_kexec_stop_conversion(bool crash) > > +{ > > + /* > > + * Crash kernel reaches here with interrupts disabled: can't wait for > > + * conversions to finish. > > + * > > + * If race happened, just report and proceed. > > + */ > > + bool wait_for_lock = !crash; > > You don't need that bool - use crash. Dave suggested the variable for documentation purposes. https://lore.kernel.org/all/0b70ee1e-4bb5-4867-9378-f5723ca091d5@intel.com I'm fine either way. > > + > > + 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)) { > > + int pages = size / PAGE_SIZE; > > + > > + /* > > + * Touching memory with shared bit set triggers implicit > > + * conversion to shared. > > + * > > + * Make sure nobody touches the shared range from > > + * now on. > > + */ > > lockdep_assert_irqs_disabled() ? Yep. > > + set_pte(pte, __pte(0)); > > + > > + if (!tdx_enc_status_changed(addr, pages, true)) { > > + pr_err("Failed to unshare range %#lx-%#lx\n", > > + addr, addr + size); > > Why are we printing something here if we're not really acting up on it? > > Who should care here? The only thing we can do at this point on failure is panic. It think it is reasonable to proceed, especially for crash case. The print leaves a trace in the log to give a clue for debug. One possible reason for the failure is if kdump raced with memory conversion. In this case shared bit in page table got set (or not cleared form shared->private conversion), but the page is actually private. So this failure is not going to affect the kexec'ed kernel. > > +static DECLARE_RWSEM(mem_enc_lock); > > + > > +/* > > + * Stop new private<->shared conversions. > > + * > > + * Taking the exclusive mem_enc_lock waits for in-flight conversions to complete. > > + * The lock is not released to prevent new conversions from being started. > > + * > > + * If sleep is not allowed, as in a crash scenario, try to take the lock. > > + * Failure indicates that there is a race with the conversion. > > + */ > > +bool stop_memory_enc_conversion(bool wait) > > This is a global function which means, it should be called: > > set_memory_enc_stop_conversion() > > or so. With the proper prefix and so on. Sure. > > +{ > > + if (!wait) > > + return down_write_trylock(&mem_enc_lock); > > + > > + down_write(&mem_enc_lock); > > + > > + return true; > > +} > > + > > static int __set_memory_enc_dec(unsigned long addr, int numpages, bool enc) > > { > > - if (cc_platform_has(CC_ATTR_MEM_ENCRYPT)) > > - return __set_memory_enc_pgtable(addr, numpages, enc); > > + int ret = 0; > > > > - return 0; > > + if (cc_platform_has(CC_ATTR_MEM_ENCRYPT)) { > > + if (!down_read_trylock(&mem_enc_lock)) > > + return -EBUSY; > > This function is called on SEV* and HyperV and the respective folks need > to at least ack this new approach. > > I see Ashish's patch adds the respective stuff: > > https://lore.kernel.org/r/c24516a4636a36d57186ea90ae26495b3c1cfb8b.1714148366.git.ashish.kalra@amd.com > > which leaves HyperV. You'd need to Cc them on the next submission. Okay. -- Kiryl Shutsemau / Kirill A. Shutemov