From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 206A2343D68 for ; Mon, 18 Aug 2025 17:00:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755536408; cv=none; b=N90SMnQNBlIuU/Lr7uz3pvlX99F022C7wBfF7sPDCykhNKPneYteGXQ3oFplbM8j8VIVsXJ6Ij9IVHUfe7BSF8+/NGtHY5U5BhlKA3a9nyT0d8uuyoYRKF2U5VXc/s2MCMoD1qAxcLjPcGvJHoAXv1jVsaNbagnD4xYAYZEaH8A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755536408; c=relaxed/simple; bh=uHO+5UGTXCFLqgCRByT85ahgS97z/GDSSKPRDkUM38U=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PNuGynf9wQmG+vXDapmo+IWLGDOWSWM+3fcSzpcpl21cbcQJkImPJgwKHGY0kiv1I4NS3j4ktmIscq0wHVIp8sCi8XuthElif6p0DgfyM2Zp+o6i2SWF/gSfW0/Dd1bEjwDDFo3qd2TE68Nw/KLY5dQscnBvt34W2QitB+69VpA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=ndOqgRK3; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=iYyrUX4t; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="ndOqgRK3"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="iYyrUX4t" Date: Mon, 18 Aug 2025 19:00:03 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1755536405; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JK2fvOJ8FC8e7QmXUAN4QIVvXniykVvupKasMJEv4gA=; b=ndOqgRK3QwBf/a4UVfQNsCj01ioiTN8y78gBmTSstl+7E55Ud45VMYR87WSRknb8NuLZDS DcgRD2V2c3UhxC8UvXMRX8MSOWlP/3p9kYjqel7yZcZRRP29uvvbDTg+YtMXAIsO5cmjxe y/AZlgzWM6gVBYyA2cGoJxqNAiflgBry+YI3yKzdwbcqLns96GTq3P6gnUdqCcR5DLA4f+ H96TWw+awYF/e6Czsm9B93LX1E4T1h8gOvW6Jw4a/OloYHQDPSCfOr0kBjsJlwXZgVuPiZ 1uzY3foKfpd8TIKJyx29Tm8Pf32BfsqrEfoV/3sVHZbFkqtXzhZidJEG1/BZRg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1755536405; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JK2fvOJ8FC8e7QmXUAN4QIVvXniykVvupKasMJEv4gA=; b=iYyrUX4tDYZZbGshEPoPtj185dTaHhL6He9GUWrrPVKiKx2k7oEUq4mDVJPleI/omeiSHd cJY1XcQ2+JqfYJCg== From: "Ahmed S. Darwish" To: David Woodhouse Cc: Dave Hansen , Borislav Petkov , Ingo Molnar , Dave Hansen , Thomas Gleixner , Andrew Cooper , "H. Peter Anvin" , Sean Christopherson , Peter Zijlstra , Sohil Mehta , John Ogness , x86@kernel.org, x86-cpuid@lists.linux.dev, LKML Subject: Re: [PATCH v4 28/34] x86/cacheinfo: Use parsed CPUID(0x80000005) and CPUID(0x80000006) Message-ID: References: <20250815070227.19981-1-darwi@linutronix.de> <20250815070227.19981-29-darwi@linutronix.de> <4a680b7d-2ecb-4579-a5ea-b612c08ebefa@intel.com> Precedence: bulk X-Mailing-List: x86-cpuid@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Hi! On Mon, 18 Aug 2025, David Woodhouse wrote: > > How about automatically building the cast into the macro invocation... > > #define cpuid_leaf(c, l) ((struct cpuid_leaf_ ## l *)__cpuid_leaf(c, l) > #define cpuid_lead_index(c, l, i) ((struct cpuid_leaf_ ## l ## _ ## i) __cpuid_leaf_index(c, l, i) > There are zero casts needed by this model. From patch 07/34 ("x86/cpuid: Introduce a centralized CPUID data model"), the access CPUID parser APIs just dissolve into: const struct leaf_0x7_0 *l7_0; const struct leaf_0x7_1 *l7_1; l7_0 = cpuid_subleaf(c, 0x7, 0); | | └────────┐ | └─────────┐ | * * * &c.cpuid.leaf_0x7_0[0] l7_1 = cpuid_subleaf(c, 0x7, 1); | | └────────┐ | └─────────┐ | * * * &c.cpuid.leaf_0x7_1[0] where, for example, the data type of 'c.cpuid.leaf_0x7_0[0]' is native 'struct leaf_0x7_0', and so on. The per-CPU CPUID table(s) are built in a /fully-typed/ form: struct leaf_0x0_0 leaf_0x0_0[1]; struct leaf_0x1_0 leaf_0x1_0[1]; struct leaf_0x2_0 leaf_0x2_0[1]; struct leaf_0x4_0 leaf_0x4_0[8]; struct leaf_0x16_0 leaf_0x16_0[1]; struct leaf_0x80000000_0 leaf_0x80000000_0[1]; struct leaf_0x80000005_0 leaf_0x80000005_0[1]; struct leaf_0x80000006_0 leaf_0x80000006_0[1]; struct leaf_0x8000001d_0 leaf_0x8000001d_0[8]; Then, the exported CPUID parser APIs do some CPP tokenization magic to access such fully-typed data -- no casting needed. The only exception is raw EAX->EDX register access: /** * cpuid_leaf_regs() - Access parsed CPUID data in raw format * @_cpuinfo: CPU capability structure reference ('struct cpuinfo_x86') * @_leaf: CPUID leaf, in compile-time 0xN format * * Similar to cpuid_leaf(), but returns a raw 'struct cpuid_regs' pointer to * the parsed CPUID data instead of a "typed" pointer. */ #define cpuid_leaf_regs(_cpuinfo, _leaf) \ ((struct cpuid_regs *)(cpuid_leaf(_cpuinfo, _leaf))) But the usage of this raw-access API is very limited. This is by design, as one of the purpose of this work was to ensure type safety and avoid call-site bit fiddling. Thanks! -- Ahmed S. Darwish Linutronix GmbH