Received: by 2002:ab2:6c55:0:b0:1fd:c486:4f03 with SMTP id v21csp25132lqp; Tue, 11 Jun 2024 13:16:27 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCW7c36WBBOeBWNFEZZvkVM/q7l4SkTIoEZpkXwyhfD013I2tggJHzkiw5nTqg2HgYrprVhseh15ob0DkilIC7T27JJGLqH8CqL1pvN2uA== X-Google-Smtp-Source: AGHT+IHuA/SiHnhNlQgGBUkZ7ax2sVnFOXgplnlvfPiJlBBYjMGj+kmUrMzmbWqvJX1GXPTNSri6 X-Received: by 2002:ac8:5f89:0:b0:43e:3d8b:b6b9 with SMTP id d75a77b69052e-44041cdf0femr162191161cf.44.1718136986843; Tue, 11 Jun 2024 13:16:26 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1718136986; cv=pass; d=google.com; s=arc-20160816; b=OCizY+hoAJEKmOfcpukTVHRSXZwsN+Q4P/pV/ZqL8Qak3NiFunOb1+Oj6RhUQam4ot QofwKIo16YTIw+upf8Nx/d2scENNwLtWJIMV2p23ZUEj1s3w2wAxHgczMhhAKA0ehlR7 MveJKdYTsccLYTeudPXSRhh94TLzg5aTbuTS7HjnA005ZGzZqcLbE22Im8lfz3UOABFa 5QIolvO4l3irdssy8DGvEQAZQbiwJOKfxRSYhOjER6DTrtKzvXX24j2yl85KEWlVkGkT 4forw8e5f+OyXnWrVab6GtUlDEcV3o1bX5y1Snp7XvE28uOEvQhDiTZtR2+gOuN8bNN9 k/rQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:references:in-reply-to :user-agent:subject:cc:to:from:date:dkim-signature:dkim-filter; bh=WhP585hb/L47fJhChNfJiVXpMXU0QH1KtWBu/UgVVp4=; fh=q+yEP/KNizDQHoiRwJ3H8UYHQw9+MjfuqtpcDJXQ6R8=; b=KsjNUIHybuesu4vrJoAis5GctWjLUKxcAMNqpcGcQxcHxKujOJGXCaKc4TMW4gI1z1 U0gFLU0PW64qyGeKzYVAqgWIPMAg/aW3OrQwDO8ggYA7qmnfsajdtv/JKPBF8lX6g+2M Nycp7BS885D54NDfQ/NAQebsWVrn1NbdeSFSNx5siyXOqd06H1X2vda6IPy68iZw2SQo 4mwv89nPpngNWKTWFwYUZYpY+nIHAhSMZZdm7wgzM9d7R/N+1vwxwYoHTSJ6kkp7np7K rrQEcv017a0oqLJwYoiD1DRbDVe6/BHZ5dqtHD6IwZpkJgLgLXWFTR3QQQwSYUBHYb5i eq6Q==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@zytor.com header.s=2024051501 header.b=O4UuX8Jx; arc=pass (i=1 spf=pass spfdomain=zytor.com dkim=pass dkdomain=zytor.com dmarc=pass fromdomain=zytor.com); spf=pass (google.com: domain of linux-kernel+bounces-210567-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-210567-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=zytor.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id d75a77b69052e-4413236f874si31779371cf.222.2024.06.11.13.16.26 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Jun 2024 13:16:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-210567-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@zytor.com header.s=2024051501 header.b=O4UuX8Jx; arc=pass (i=1 spf=pass spfdomain=zytor.com dkim=pass dkdomain=zytor.com dmarc=pass fromdomain=zytor.com); spf=pass (google.com: domain of linux-kernel+bounces-210567-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-210567-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=zytor.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 ny.mirrors.kernel.org (Postfix) with ESMTPS id 79EDD1C21F3E for ; Tue, 11 Jun 2024 20:16:26 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1EC9714535A; Tue, 11 Jun 2024 20:16:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=zytor.com header.i=@zytor.com header.b="O4UuX8Jx" Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) (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 64F8612E61; Tue, 11 Jun 2024 20:16:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718136979; cv=none; b=O84KcacIsUWi7Hb3HUeWUgoU8WpoMFj2Yu1KBqZKe0OzI3mcljMZ3NohJ5fgczkiXtGcCvUAfyUPZw5C/buD2FR5F5hRC+FLPvoOh+KWLO/iKcfd/g4sxUfuwh17QmId8BALwTVTUzds9ROVir3Dar7OOVa80PA3vQmMvhXUfp0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718136979; c=relaxed/simple; bh=HAK2OHutCS/Lj87z2/N+VGndKX2mskGP86pdblWyp2w=; h=Date:From:To:CC:Subject:In-Reply-To:References:Message-ID: MIME-Version:Content-Type; b=eVQdZjdKYWwDw1kYllGc9YHhavqydKMXq79PFqqBcj+TOAvxxLlx9vShDrio+g2w2hPOyMC05LCZBIcOYYx9Ttmmm+gcuLxPYOigpsBxRN576CDMJIvonZfK5eD9RUFXMAUzTED+d4uxGkOE0QWwTgvgIOnt1fEgJ5dqK7ht+/w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com; spf=pass smtp.mailfrom=zytor.com; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=O4UuX8Jx; arc=none smtp.client-ip=198.137.202.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zytor.com Received: from [127.0.0.1] ([99.8.153.148]) (authenticated bits=0) by mail.zytor.com (8.17.2/8.17.1) with ESMTPSA id 45BKFlxc3470245 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 11 Jun 2024 13:15:48 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 45BKFlxc3470245 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2024051501; t=1718136948; bh=WhP585hb/L47fJhChNfJiVXpMXU0QH1KtWBu/UgVVp4=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=O4UuX8JxWZ947o1nr0MB5zU/V06HeNWKwliayCcDZnsAHeOrt4o2lUoSETF6zXMJS 4Vk3TDyfCmEuxcaIBmO8HV2zutSuK1IC06IQGhMhPMoXOfv9CeQiFNFzlnoQ2kMyuX ZaFnylG5wmSmOEZ/XkYdAqpBFXiQIhiT7XYs+h+8W88/KXyOVTz9OzMSjXz7M7bneA fTPuP5G9l5DhfrQBXIFZToLzbt6VFaQurfP2keJN6BGHm2kxFzbuLPhFlHgXz+KVNm YlvUobF5pCM+xy1q/jT7FfyO8+2APpYo+fJ9dSLjzUph5utoiEx6n5gchN6vzeP6O2 8bWk8Q9JcO62g== Date: Tue, 11 Jun 2024 13:15:43 -0700 From: "H. Peter Anvin" To: Rasmus Villemoes , Peter Zijlstra , Linus Torvalds CC: Ingo Molnar , Borislav Petkov , Thomas Gleixner , Josh Poimboeuf , Linux Kernel Mailing List , the arch/x86 maintainers , linux-arch Subject: Re: [PATCH] x86: add 'runtime constant' infrastructure User-Agent: K-9 Mail for Android In-Reply-To: <8eb5960f-17f9-4d94-9b52-dea8b475e9dc@zytor.com> References: <20240608193504.429644-2-torvalds@linux-foundation.org> <20240610104352.GT8774@noisy.programming.kicks-ass.net> <8eb5960f-17f9-4d94-9b52-dea8b475e9dc@zytor.com> Message-ID: 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=utf-8 Content-Transfer-Encoding: quoted-printable On June 11, 2024 12:43:02 PM PDT, "H=2E Peter Anvin" wrot= e: >On 6/10/24 06:38, Rasmus Villemoes wrote: >> On 10/06/2024 12=2E43, Peter Zijlstra wrote: >>> On Sat, Jun 08, 2024 at 12:35:05PM -0700, Linus Torvalds wrote: >>=20 >>>> Comments? >>>=20 >>> It obviously has the constraint of never running the code before the >>> corresponding runtime_const_init() has been done, otherwise things wil= l >>> go sideways in a hurry, but this also makes the whole thing a *lot* >>> simpler=2E >>>=20 >>> The only thing I'm not sure about is it having a section per symbol, >>> given how jump_label and static_call took off, this might not be >>> scalable=2E >>>=20 >>> Yes, the approach is super simple and straight forward, but imagine >>> there being like a 100 symbols soon :/ >>>=20 >>> The below hackery -- it very much needs cleanup and is only compiled o= n >>> x86_64 and does not support modules, boots for me=2E >>=20 >> As can be seen in my other reply, yes, I'm also worried about the >> scalability and would like to see this applied to more stuff=2E >>=20 >> But if we do this, surely that's what scripts/sorttable is for, right? >>=20 >> Alternatively, if we just keep emitting to per-symbol >> __runtime_const_##sym sections but collect them in one __runtime_const, >> just using __runtime_const { *(SORT_BY_NAME(__runtime_const_*)) } in th= e >> linker script should already be enough to allow that binary search to >> work (with whatever : AT(ADDR() =2E=2E=2E ) magic is also required), wi= th no >> post-processing at build or runtime required=2E >>=20 > >As far as one section per symbol, this is *exactly* what the linker table= infrastructure was intended to make clean and scalable=2E > >I think rejecting it was a big mistake=2E It is really a very useful gene= ral piece of infrastructure, and IMNSHO the whole notion of "oh, we won't e= ver need that many such tables" is just plain wrong (as evidenced here=2E) > >Either way, the problem isn't that hard; you end up doing something like: > >struct runtime_const { > unsigned int size; > reladdr_t entries[0]; >}; > >#define DECLARE_RUNTIME_CONST(sym,type) \ >extern struct runtime_const sym;\ >asm("=2Epushsection \"runtime_const_" #sym "=2EStart\",\"a\"\n\t" > "=2Eglobl " #sym "\n" > #sym ": =2Eint 2f - 1f\n\t" > "1:\n" > "=2Epopsection\n\t" > "=2Epushsection \"runtime_const_" #sym "=2E_end\",\"a\"\n\t" > "2:\n" > "=2Epopsection\n\t"); > >=2E=2E=2E and add a common suffix, say, "=2Eentry", for the entry section= names=2E Then SORT_BY_NAME() will handle the rest=2E > > -hpa > Ok, the section naming is obviously bogus, but=2E=2E=2E I just had an idea how to clearly make this type-safe as a benefit=2E I'm = at a school event right now but I'll hack up a demo as soon as I get home= =2E