From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) (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 0ED0631A553 for ; Thu, 27 Nov 2025 07:36:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764228967; cv=none; b=BXAH54z9NoVeqY6Eg5m16PQoui65zJasjYyY8enD87Bb+UPvw6MccdZD3v0JXtA/zGu6CH6JQcKvDyauSzvhwGlyttWAapk61z6ake/BYToUPn2ICDyxO3Tlw4xWzVxop1sZOM/XtsWNjXXEO1saFyK/jraSJTOPanKpRa2kR9w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764228967; c=relaxed/simple; bh=M3w0bNtAIwlj3x4MgmwliTzrK4xVv0hZ0kZu7Q9lO5g=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=VbHpvM4eDVZt4S2EYX9pGuYcAxsweeLRSRF5GW0HC5S+/2QNSQuQ3Ree60yEimom4ZennEyxcRrzFok0KYb3biOWE3V0c+UWCImxs8+5++l9SsAvDXaVnFH1JNB6xQAAlX2Yc4fprKAzT0yAKWDj45aWiBNZAxQ/O62NyWYhCLQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=VURqwO22; arc=none smtp.client-ip=209.85.208.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="VURqwO22" Received: by mail-ed1-f49.google.com with SMTP id 4fb4d7f45d1cf-640a0812658so1069282a12.0 for ; Wed, 26 Nov 2025 23:36:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1764228963; x=1764833763; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :from:references:cc:to:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=Ry5Icad7K57cHxBgAf3HDM0tDnRTn+wmwX3MBtvtGHg=; b=VURqwO22Cm/XK65iLfaBDIdHoMa40QcmnGNEQziDVco6FDjFPB2RTr5rFGHZ2Vx54A A8GIxWM9mI+z7iYw7X02ddH5fEVnjQpTszBAwrXQz1Y1RE6tKucBUPSrszMBWHe8Tp/5 Q094vTkIMLxMHda6mBix1AV2nhfuvqwsVOkich107UEZR9aiWYmlYu30+T8OaKCnrIOJ FXriag9D1lxa+tT1m73v4umMQvbS75PGJQ7qjU/PRDOgSqLPtzcDm+wXq+jU60NAbjFA 2AmV58g7YcPDu12KMFUsC1/dYo36JOYBHhb1Xnkpzp0Yok+5A8eH0klFanegn3diasKk /M9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764228963; x=1764833763; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :from:references:cc:to:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Ry5Icad7K57cHxBgAf3HDM0tDnRTn+wmwX3MBtvtGHg=; b=ggmhUsYrrjHvCj9msSLJQSOO8ivD6AyjS/exJqZzMlpUtT05j5yOektN8b99ijHclw rwH2Bdl2p3Bg4ryapMLei54zq3aJTrTb3S/JBv/8DqjKOyRESf46CZVF/qINKhC0Epbn 4EKHe1cKAIdJIgAZSajSYhZCn2S0+gzATQEo9OUayS2vm85MLHgqn3ceQdFeGm//wv2N 8UmGpp2LvLf0Gq/dTzAcUbygm5b4qMW81rZxDm+57NhZ1Zh9UGzSpwBq8ZZ/lR+o7aHu EFbUmRoauRKd322wfAku9hYaCUA4s7jSrpISZ0tRDKCmR3j3FYNZT6zapTWOdmSI9xTO jFKw== X-Forwarded-Encrypted: i=1; AJvYcCWxMJNwPBLG4dF5S0I+ZwNfRovpBsk+nfq0dkiy/JRn0Obg2AOWUMTlNVJGV0sVYFLadqE4dUuDtZMJHx8=@vger.kernel.org X-Gm-Message-State: AOJu0YwP9MmqDFXbnOUXwuMFTkRxNdcKoJ9+zUEbNvEM3Cn34u3vwJxh j2n+DecKrQtto97xkY/il1pXnEiP08S6XdlIAi2mKiICMMEGAGFGe3Bb41KAiMqPTEs= X-Gm-Gg: ASbGncsrzszIJ6y3Q7B4FzrcZvjX3cGkOXFBBqRpdMoXb3ygvYbeGsxi3bYRWl/uKZO 9noiLwY53jALpoDoT/QGvIjMA0krvFwUaKw/0UKJ5T8Q3kJBuoydp0RpwR4W+5EZBxQTiyWhA+X /YmV9tB7jrWRoTiCYcGvaCNUMCyyjQILGeQKq1g3lhm3Nco0qQhTnsg9KEGNLf2H9WyGfE5ZkRK BkVtq4op8aWP3cM1+CJyA7mmEJXnLXRTCRun3KKkdSZn+TiJSOAwoVjHU0aaGf5BCMgKTpi+BBh mntINQRuVtp1+QzyHG8ho8IcNgT0cB/4kQq2+R98napQQsT+eEfI481lIkK5dS4gAq1EXcFrED7 rr5F+MlKpQbvwQjABaGb1QNaBhfAiaY2uHyhPsV0m+0OwXtkCiIuSWE+OZWlUqL61Eolw+dbyA7 WHRfjVJDB8q/2RuGU0Ha5tHHRE8rztKn6b+g5t X-Google-Smtp-Source: AGHT+IHp0jLzCQvHPIiwFS2ld5NvIqb51lIrHzbEzK1vWd7M0358Smsxo4Tuy9moUFCwEdKgCWpmpg== X-Received: by 2002:a17:907:1b12:b0:b76:7e0e:4246 with SMTP id a640c23a62f3a-b76c546da56mr1052544166b.12.1764228963207; Wed, 26 Nov 2025 23:36:03 -0800 (PST) Received: from [192.168.0.20] (nborisov.ddns.nbis.net. [85.187.216.236]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b76f4d533f2sm94542266b.0.2025.11.26.23.36.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 Nov 2025 23:36:02 -0800 (PST) Message-ID: <69a2dee2-f6a5-4c1b-9daa-8c32ff7c3956@suse.com> Date: Thu, 27 Nov 2025 09:36:00 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 06/16] x86/virt/tdx: Improve PAMT refcounts allocation for sparse memory To: "Edgecombe, Rick P" , "kvm@vger.kernel.org" , "linux-coco@lists.linux.dev" , "Huang, Kai" , "Li, Xiaoyao" , "Hansen, Dave" , "Zhao, Yan Y" , "Wu, Binbin" , "kas@kernel.org" , "seanjc@google.com" , "mingo@redhat.com" , "linux-kernel@vger.kernel.org" , "tglx@linutronix.de" , "Yamahata, Isaku" , "pbonzini@redhat.com" , "Annapurve, Vishal" , "Gao, Chao" , "bp@alien8.de" , "x86@kernel.org" Cc: "kirill.shutemov@linux.intel.com" References: <20251121005125.417831-1-rick.p.edgecombe@intel.com> <20251121005125.417831-7-rick.p.edgecombe@intel.com> <7dd848e5735105ac3bf01b2f2db8b595045f47ad.camel@intel.com> From: Nikolay Borisov Content-Language: en-US Autocrypt: addr=nik.borisov@suse.com; keydata= xsFNBGcrpvIBEAD5cAR5+qu30GnmPrK9veWX5RVzzbgtkk9C/EESHy9Yz0+HWgCVRoNyRQsZ 7DW7vE1KhioDLXjDmeu8/0A8u5nFMqv6d1Gt1lb7XzSAYw7uSWXLPEjFBtz9+fBJJLgbYU7G OpTKy6gRr6GaItZze+r04PGWjeyVUuHZuncTO7B2huxcwIk9tFtRX21gVSOOC96HcxSVVA7X N/LLM2EOL7kg4/yDWEhAdLQDChswhmdpHkp5g6ytj9TM8bNlq9I41hl/3cBEeAkxtb/eS5YR 88LBb/2FkcGnhxkGJPNB+4Siku7K8Mk2Y6elnkOctJcDvk29DajYbQnnW4nhfelZuLNupb1O M0912EvzOVI0dIVgR+xtosp66bYTOpX4Xb0fylED9kYGiuEAeoQZaDQ2eICDcHPiaLzh+6cc pkVTB0sXkWHUsPamtPum6/PgWLE9vGI5s+FaqBaqBYDKyvtJfLK4BdZng0Uc3ijycPs3bpbQ bOnK9LD8TYmYaeTenoNILQ7Ut54CCEXkP446skUMKrEo/HabvkykyWqWiIE/UlAYAx9+Ckho TT1d2QsmsAiYYWwjU8igXBecIbC0uRtF/cTfelNGrQwbICUT6kJjcOTpQDaVyIgRSlUMrlNZ XPVEQ6Zq3/aENA8ObhFxE5PLJPizJH6SC89BMKF3zg6SKx0qzQARAQABzSZOaWtvbGF5IEJv cmlzb3YgPG5pay5ib3Jpc292QHN1c2UuY29tPsLBkQQTAQoAOxYhBDuWB8EJLBUZCPjT3SRn XZEnyhfsBQJnK6byAhsDBQsJCAcCAiICBhUKCQgLAgQWAgMBAh4HAheAAAoJECRnXZEnyhfs XbIQAJxuUnelGdXbSbtovBNm+HF3LtT0XnZ0+DoR0DemUGuA1bZAlaOXGr5mvVbTgaoGUQIJ 3Ejx3UBEG7ZSJcfJobB34w1qHEDO0pN9orGIFT9Bic3lqhawD2r85QMcWwjsZH5FhyRx7P2o DTuUClLMO95GuHYQngBF2rHHl8QMJPVKsR18w4IWAhALpEApxa3luyV7pAAqKllfCNt7tmed uKmclf/Sz6qoP75CvEtRbfAOqYgG1Uk9A62C51iAPe35neMre3WGLsdgyMj4/15jPYi+tOUX Tc7AAWgc95LXyPJo8069MOU73htZmgH4OYy+S7f+ArXD7h8lTLT1niff2bCPi6eiAQq6b5CJ Ka4/27IiZo8tm1XjLYmoBmaCovqx5y5Xt2koibIWG3ZGD2I+qRwZ0UohKRH6kKVHGcrmCv0J YO8yIprxgoYmA7gq21BpTqw3D4+8xujn/6LgndLKmGESM1FuY3ymXgj5983eqaxicKpT9iq8 /a1j31tms4azR7+6Dt8H4SagfN6VbJ0luPzobrrNFxUgpjR4ZyQQ++G7oSRdwjfIh1wuCF6/ mDUNcb6/kA0JS9otiC3omfht47yQnvod+MxFk1lTNUu3hePJUwg1vT1te3vO5oln8lkUo9BU knlYpQ7QA2rDEKs+YWqUstr4pDtHzwQ6mo0rqP+zzsFNBGcrpvIBEADGYTFkNVttZkt6e7yA LNkv3Q39zQCt8qe7qkPdlj3CqygVXfw+h7GlcT9fuc4kd7YxFys4/Wd9icj9ZatGMwffONmi LnUotIq2N7+xvc4Xu76wv+QJpiuGEfCDB+VdZOmOzUPlmMkcJc/EDSH4qGogIYRu72uweKEq VfBI43PZIGpGJ7TjS3THX5WVI2YNSmuwqxnQF/iVqDtD2N72ObkBwIf9GnrOgxEyJ/SQq2R0 g7hd6IYk7SOKt1a8ZGCN6hXXKzmM6gHRC8fyWeTqJcK4BKSdX8PzEuYmAJjSfx4w6DoxdK5/ 9sVrNzaVgDHS0ThH/5kNkZ65KNR7K2nk45LT5Crjbg7w5/kKDY6/XiXDx7v/BOR/a+Ryo+lM MffN3XSnAex8cmIhNINl5Z8CAvDLUtItLcbDOv7hdXt6DSyb65CdyY8JwOt6CWno1tdjyDEG 5ANwVPYY878IFkOJLRTJuUd5ltybaSWjKIwjYJfIXuoyzE7OL63856MC/Os8PcLfY7vYY2LB cvKH1qOcs+an86DWX17+dkcKD/YLrpzwvRMur5+kTgVfXcC0TAl39N4YtaCKM/3ugAaVS1Mw MrbyGnGqVMqlCpjnpYREzapSk8XxbO2kYRsZQd8J9ei98OSqgPf8xM7NCULd/xaZLJUydql1 JdSREId2C15jut21aQARAQABwsF2BBgBCgAgFiEEO5YHwQksFRkI+NPdJGddkSfKF+wFAmcr pvICGwwACgkQJGddkSfKF+xuuxAA4F9iQc61wvAOAidktv4Rztn4QKy8TAyGN3M8zYf/A5Zx VcGgX4J4MhRUoPQNrzmVlrrtE2KILHxQZx5eQyPgixPXri42oG5ePEXZoLU5GFRYSPjjTYmP ypyTPN7uoWLfw4TxJqWCGRLsjnkwvyN3R4161Dty4Uhzqp1IkNhl3ifTDYEvbnmHaNvlvvna 7+9jjEBDEFYDMuO/CA8UtoVQXjy5gtOhZZkEsptfwQYc+E9U99yxGofDul7xH41VdXGpIhUj 4wjd3IbgaCiHxxj/M9eM99ybu5asvHyMo3EFPkyWxZsBlUN/riFXGspG4sT0cwOUhG2ZnExv XXhOGKs/y3VGhjZeCDWZ+0ZQHPCL3HUebLxW49wwLxvXU6sLNfYnTJxdqn58Aq4sBXW5Un0Q vfbd9VFV/bKFfvUscYk2UKPi9vgn1hY38IfmsnoS8b0uwDq75IBvup9pYFyNyPf5SutxhFfP JDjakbdjBoYDWVoaPbp5KAQ2VQRiR54lir/inyqGX+dwzPX/F4OHfB5RTiAFLJliCxniKFsM d8eHe88jWjm6/ilx4IlLl9/MdVUGjLpBi18X7ejLz3U2quYD8DBAGzCjy49wJ4Di4qQjblb2 pTXoEyM2L6E604NbDu0VDvHg7EXh1WwmijEu28c/hEB6DwtzslLpBSsJV0s1/jE= In-Reply-To: <7dd848e5735105ac3bf01b2f2db8b595045f47ad.camel@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 26.11.25 г. 22:47 ч., Edgecombe, Rick P wrote: > Kiryl, curious if you have any comments on the below... > > On Wed, 2025-11-26 at 16:45 +0200, Nikolay Borisov wrote: >>> +static int pamt_refcount_populate(pte_t *pte, unsigned long addr, void >>> *data) >>> +{ >>> + struct page *page; >>> + pte_t entry; >>> + >>> + page = alloc_page(GFP_KERNEL | __GFP_ZERO); >>> + if (!page) >>>     return -ENOMEM; >>> >>> + entry = mk_pte(page, PAGE_KERNEL); >>> + >>> + spin_lock(&init_mm.page_table_lock); >>> + /* >>> + * PAMT refcount populations can overlap due to rounding of the >>> + * start/end pfn. Make sure the PAMT range is only populated once. >>> + */ >>> + if (pte_none(ptep_get(pte))) >>> + set_pte_at(&init_mm, addr, pte, entry); >>> + else >>> + __free_page(page); >>> + spin_unlock(&init_mm.page_table_lock); >> >> nit: Wouldn't it be better to perform the pte_none() check before doing >> the allocation thus avoiding needless allocations? I.e do the >> alloc/mk_pte only after we are 100% sure we are going to use this entry. > > Yes, but I'm also wondering why it needs init_mm.page_table_lock at all. Here is > my reasoning for why it doesn't: > > apply_to_page_range() takes init_mm.page_table_lock internally when it modified > page tables in the address range (vmalloc). It needs to do this to avoid races > with other allocations that share the upper level page tables, which could be on > the ends of area that TDX reserves. > > But pamt_refcount_populate() is only operating on the PTE's for the address > range that TDX code already controls. Vmalloc should not free the PMD underneath > the PTE operation because there is an allocation in any page tables it covers. > So we can skip the lock and also do the pte_none() check before the page > allocation as Nikolay suggests. I agree with your analysis but this needs to be described not only in the commit message but also as a code comment because you intentionally omit locking since that particular pte (at that point) can only have a single user so no race conditions are possible. > > Same for the depopulate path.