From mboxrd@z Thu Jan 1 00:00:00 1970 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 A447F33A9C4 for ; Mon, 23 Mar 2026 19:14:26 +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=1774293267; cv=none; b=shZA9Dk907ILpY/Vw+aBsCQp+SmHrpIZ+zHZMslNx7vBUqjxgRnU8jRgE36hYJ1wxKj3ielDCIcz5sXYHEt97enjvoqpR4YzUPf3GPKZeuxvS6Jgn8kSG0UjEWuzgrcj7FAZEghsxv47MngXVjovhVMrHQIAkmIVMRljokPWYD8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774293267; c=relaxed/simple; bh=3UGWnkxTJY6rkRF/sPPG2HOlItL5Mtqj8T40p+Wqs74=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=hRxVeeQQeyvJ/hakJDR699YVfNlCy5jGqGnQiclgiPYu3EFaSYwOojQaz5Ft3fJU2jmeARgbl2aLJ4jFmW4Q05kj+FhNzsZqqkgWtZ/2dRCvFI4YG14OlcCFg+TfyAaIC7o64G6Yn4FeEZ8FA2vh1aIOmSehzTQEsqy3riq9RYE= 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=LVw+HK7y; 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 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="LVw+HK7y" Received: from [172.27.2.41] (c-76-133-66-138.hsd1.ca.comcast.net [76.133.66.138]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 62NIvpPn2990169 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 23 Mar 2026 11:57:51 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 62NIvpPn2990169 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026022301; t=1774292272; bh=q8yvFCOGLNyxNnoCGtRQCCX1MJeCm8QB5Bwu54UGu+I=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=LVw+HK7yJXxWJC+C5f6Vk5YzQ7q4Qv802attIh19pJMq268JfkbfKgtHcZOYP/Q4C Qa5+RelkAPQfv2Bgq03CCuFBw5lpcDIZKoIP3Nn0498NoIdKqaUX53tJcGjk5g+xwJ gGD+FfANggKRQcOKa+yb0B0AY26EzyQC6UYCCBm6ULqxPYCRk7V41A8b9rcohZklyb e0ntsUtU0sXqYbtEXvtIpzSKhNGsvdy77jhv5cSYzDnGlzV3dKFInNJ5M2X/uI+L8Q 2MfREWmXrc55kAxW5rp6AQ3qvsD2SA2nxTnypahROR9VJy3ZetFV3s2jt0xwEI3PYz wyhjLYw4buyPQ== Message-ID: <55af4420-e230-4f14-a2d3-608f2bc5a412@zytor.com> Date: Mon, 23 Mar 2026 11:57:45 -0700 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 v11 4/4] x86/cpu: Clear feature bits whose dependencies were cleared To: Borislav Petkov , Maciej Wieczor-Retman Cc: tglx@kernel.org, peterz@infradead.org, xin@zytor.com, maciej.wieczor-retman@intel.com, babu.moger@amd.com, chang.seok.bae@intel.com, sohil.mehta@intel.com, dave.hansen@linux.intel.com, jpoimboe@kernel.org, elena.reshetova@intel.com, pawan.kumar.gupta@linux.intel.com, ak@linux.intel.com, darwi@linutronix.de, mingo@redhat.com, x86@kernel.org, linux-kernel@vger.kernel.org References: <20260323163557.GHacFr7VbKIADqonuX@fat_crate.local> <20260323175902.GBacF_ZnWQJJWdOZJT@fat_crate.local> Content-Language: en-US, sv-SE From: "H. Peter Anvin" In-Reply-To: <20260323175902.GBacF_ZnWQJJWdOZJT@fat_crate.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2026-03-23 10:59, Borislav Petkov wrote: > On Mon, Mar 23, 2026 at 05:23:19PM +0000, Maciej Wieczor-Retman wrote: >> Clearing the compile time disabled bits is fairly low effort since it's just >> initializing the cpu_caps_cleared[]. > > and cpu_caps_cleared[] is consulted in apply_forced_caps(). > >> To validate the whole cpuid_deps[] array and add relevant bits to >> cpu_caps_cleared[] would probably require adding another loop that would >> check all of the entries. Since now only SGX has this problem I didn't think >> it warranted adding more than this check in check_cpufeature_deps(). > > So we're going to do half-baked solution again and it'll come to bite us in > the ass later? > > How about we hammer it out properly once and for all? > One could argue that the Right Thing[TM] to do would be to encode the dependencies in a file that can be processed at compile time, and have those features explicitly added to the enabled and disabled masks, basically augmenting Kconfig.cpufeatures. The sanest way to do that would probably be to move cpuid_deps[] from cpuid-deps.c into a standalone file which can be processed by cpufeaturesmask.awk or equivalent. I do have to say that using awk for these things, especially being restricted to POSIX awk, is really awful as it really is pushing the limits of that tool. String processing in C is most definitely no fun either -- the single biggest shortcoming of what is otherwise one of my favorite languages -- but it *would* also be possible to refactor cpuid-deps.c so that it can be compiled in user space and linked with a C tool that would replace cpufeaturesmask.awk, mkcapflags.sh, and boot/mkcpustr.c. This seemed to me to be a bit excessive in terms of churn and complexity, but perhaps this is what you are looking for? -hpa