From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 25431382391 for ; Mon, 30 Mar 2026 06:11:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774851087; cv=none; b=sFiwBZR/jv+g6R5WAIm+ETc/9W1zGgmro+AD/ZctfEt9spr/KXS3Bi183XSTPHnjhT6/Mv/kGSYZ8n21JkzP5T2fMJgtzi+moZw6Peqo+7oEzBGG+SLGFuKhHVXC7PNUWUVxBvizZd+RtcuHqawFCD9y9K7ehigqpSXTxKPX3bo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774851087; c=relaxed/simple; bh=92v10qPz0eeZciUr548id/gjysm+XeyvzSfKESVADzk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=k+aXJRGGoLTf9J92+o0Cs2FmX5kxEKPoIYKkZJce4S1vI6SDctQWngcT5eqabewtSUJmnNoVoQjZC0RNi+TMOVKFVveXsWkoNgUKJsQh4VJJLwofh0Jjm/ziWvTyKoAFW6cV9wbIj/oLu1qsJOhoRqsjIPoIgU2NZYNAZLPOD28= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=EqQUILJO; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="EqQUILJO" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1774851085; x=1806387085; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=92v10qPz0eeZciUr548id/gjysm+XeyvzSfKESVADzk=; b=EqQUILJOVmeVaFextKPE22L3D3R/qyYMiVuienfIQVKa9HmanhNjrFw1 VIz/PHGiL9XOsh5tb8Di1yeT+bRNTgiq2rlovNiifqqYk1KVknrexEbtG GeVJsq+mYp1s27Kc+qhaqpm2tdrvHg+qoJNgdHwELByTlvYIjMXRNIY3D o7t0M6Mgn/Jd+Ig9xwANvmQnRXh+0O8cNQ6BZcyQks5jajh50V8LxxgXB 4jHaW7S6u1iLJ/EoqeF5vL89R0siyp9wLUfrZH9e93TMy+Fq9sTJE2kTp tD10IlweHebrBpKuCHj2hYskdJ7vPfOLD/zjMVsQGxA3yQ8HYbvIQdq9S A==; X-CSE-ConnectionGUID: NCeySa8QSHiL/Of0NwWzFg== X-CSE-MsgGUID: 8wneDwtqQ5G4YipUw5aYkQ== X-IronPort-AV: E=McAfee;i="6800,10657,11743"; a="79738248" X-IronPort-AV: E=Sophos;i="6.23,149,1770624000"; d="scan'208";a="79738248" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Mar 2026 23:11:24 -0700 X-CSE-ConnectionGUID: zLc+gh0dSKeWM0n5NAxEwA== X-CSE-MsgGUID: eyv9N595Q1OuEf9WmXp9Bg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,149,1770624000"; d="scan'208";a="230024760" Received: from tassilo.jf.intel.com (HELO tassilo) ([10.54.38.190]) by ORVIESA003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Mar 2026 23:11:24 -0700 Date: Sun, 29 Mar 2026 23:11:19 -0700 From: Andi Kleen To: Maciej Wieczor-Retman Cc: bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, xin@zytor.com, chang.seok.bae@intel.com, mingo@redhat.com, elena.reshetova@intel.com, maciej.wieczor-retman@intel.com, babu.moger@amd.com, sohil.mehta@intel.com, pawan.kumar.gupta@linux.intel.com, pmladek@suse.com, nik.borisov@suse.com, ptesarik@suse.com, darwi@linutronix.de, tglx@kernel.org, peterz@infradead.org, jpoimboe@kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH v12 0/4] x86: Capability bits fix and required bits sanity check Message-ID: References: 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: I'm not sure what the point of this check is. Obviously the kernel cannot handle it, short of refusing to boot which would be far too drastic. And if it's just for having something in the kernel log, who would look for this? Any possible symptoms from a bogus cpuid will be far disconnected from that particular log location. Further, there's also no evidence that it is a real practical problem. If anything it could likely only come from rogue VMMs, but these don't seem to be common. But VMMs normally don't really disable ISA, so even if the CPUID is inconsistent things will still likely work because the actual instructions are fine. Assuming it was a real problem, you could just do it in a user program, why put it into the kernel and waste everyone's memory? (this cannot be initcode due to hotplug) Also it seems to violate Steinbach's system programing maxim (never check for something you don't know how to handle) -Andi