From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 93E9F3CC7E3 for ; Fri, 15 May 2026 13:54:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778853279; cv=none; b=bQfRHlsVvmkwsT8iqCEEQmvm9MWMYrzPoP1pvGzFCpog4seGKDuWqSISX0ncNadi37a1Ck8+kxZ0NHQmcEwm9kVusnrAsHKhsi0hBYZqx0tGsLYAOixrcqeXzLIXc3YuqwSRPnibC1GXR71VoTITSXCN9IdvY4kphiDi//o9Sfs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778853279; c=relaxed/simple; bh=3vfyDrp/rUynePSzn4JqbKs1v0gM5SGIB2jbOUwXuLg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=k8jV6Du4FszIchhjky+E3FJnmM+fA2FQwclcVxFt7tOMbusC2nmOsJwWfpNT0Lcgv5sYExhG/U5Tm8a0RnJI0w/WQHefmes77FrjK4/qdnpymA6D7u9WlSDtS3I2OeWOSYMfuk8ZiJQlqZaouqGTnz2NvMa63uy3Eg6UA3TatjQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MmUT6d/G; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MmUT6d/G" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A311DC2BCB0; Fri, 15 May 2026 13:54:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778853279; bh=3vfyDrp/rUynePSzn4JqbKs1v0gM5SGIB2jbOUwXuLg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=MmUT6d/G9XE+w+PVvGyxEO41NIV5WX6JX9QcNFAsUfRav9KG6r8Jotzk0uBZYBHQz FHS+DgYbQuN9arKmisWt6lh9aTLPHS7Mgo1YQNKCFHAt35ZqPJpLcxcuO8Ex38+d2W 3ZZURFhZ6F+m7gYm/iq+XPTFv1tqEfNwWrS3N/GjgbIv7i9Kg1Vc2gnokYddkZ0tns POzopW/+vt/tBMjfsTRRVUpeIxu7tkGT+fE0kG25qRyUqf21tejzaMltsIclI0WvCU 7Z6ABYyTUiKZbAkpTRZOE7zjN2TiHXra1PeumiDKJHzcw/i4G41seI5rYMA48BMZQH +LdnNOgeVgeVA== Date: Fri, 15 May 2026 19:20:54 +0530 From: Naveen N Rao To: Christian Ludloff Cc: x86@kernel.org, Thomas Gleixner , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Nikunj A Dadhania , Manali Shukla , Bharata B Rao , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 2/3] x86/apic: Introduce a variable to track the number of EILVT registers 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Fri, May 15, 2026 at 06:30:07AM -0700, Christian Ludloff wrote: > On Fri, May 15, 2026 at 4:48 AM Christian Ludloff wrote: > > > > > + if (cpu_feature_enabled(X86_FEATURE_EXTAPIC)) > > > + apic_eilvt_count = APIC_EFEAT_XLC(apic_read(APIC_EFEAT)); > > > > BKDG #21656, #21922, and #24141 for K7 were not published. > > If you find them internally at AMD, consider publishing them. :) > > That way they could be archived, and referenced from then on. > > minor extra K7 quirk, documented in the K7 datasheet (#21016): > > before model 2, the chip was missing two of the pins required for > proper APIC operation – so the APIC didn't quite work back then > > > BKDG #26094 for K8 Fam Fh DDR1 documents 4 extended LVTs. > > I mis-read that one – correction – it's 0 there, not 4 > > also, supposedly no bit 31 = 1 in the version register, but does have > registers 400h and 410h (but not the other/later extended registers) > > > BKDG #32559 for K8 Fam Fh DDR2 documents 1 extended LVT. > > BKDG #41256 for K8 Fam 11h (LG) documents 4 extended LVTs. > > > > Fam 10h/12h, 14h and 16h, and 15h all have 4 – no surprises. > > > > The Fam 10h BKDG (#31116) has an explicit entry in its "Major > > Changes Relative to Family 0Fh Processors" section: "Number > > of extended LVT interrupts in APIC increased to 4." – AMD may > > want to clarify what was correct vs not for those old K8 models. > > per the correction above – K8 went from 0 to 1 to 4 extended LVTs Right, I looked up what I could. The fallback below is explicitly for addressing those. > > > > + if (!apic_eilvt_count && boot_cpu_data.x86_vendor == X86_VENDOR_AMD) > > > + apic_eilvt_count = APIC_EILVT_NR_AMD_10H; > > > > This seems... unsafe? > > double-check it w.r.t. K7 and K8 Fam Fh DDR1, please This fallback exists purely to retain the current default (except that it is now restricted to AMD processors) The default being 4 (rather than 1 or even 0) is not really an issue because this function won't be invoked for older processors. The common case is for this to be invoked with a BIOS-provided offset. The only exception is for IBS for family 0x10, but that family has 4 extended LVTs present (see ibs_eilvt_setup()). - Naveen