NetBSD Problem Report #42597

From www@NetBSD.org  Sat Jan  9 10:37:36 2010
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 75D6563C504
	for <gnats-bugs@gnats.NetBSD.org>; Sat,  9 Jan 2010 10:37:36 +0000 (UTC)
Message-Id: <20100109103734.7167963C503@www.NetBSD.org>
Date: Sat,  9 Jan 2010 10:37:34 +0000 (UTC)
From: murray@river-styx.org
Reply-To: murray@river-styx.org
To: gnats-bugs@NetBSD.org
Subject: LAPIC MSR address mask 4 bits short
X-Send-Pr-Version: www-1.0

>Number:         42597
>Category:       port-amd64
>Synopsis:       LAPIC MSR address mask 4 bits short
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    port-amd64-maintainer
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jan 09 10:40:00 +0000 2010
>Closed-Date:    Fri Aug 11 06:31:10 +0000 2017
>Last-Modified:  Tue Nov 21 15:05:01 +0000 2017
>Originator:     Murray Armfield
>Release:        NetBSD-current
>Organization:
N/A
>Environment:
N/A
>Description:
The Intel 64 and IA32 Architectures Software Developer's Manual Vol 3A in chapter 10.4.4 states that the APIC Base field component of the IA32_APIC_BASE MSR uses bits 12 through to 35. This translates to an address mask of 0xffffff000. (6 f's)

The address mask found in current sources, file sys/arch/x86/include/i82489reg.h line 153 defines LAPIC_MSR_ADDR as 0xfffff000 (5 f's).

This is 4 bits short of the possible address mask. The IA32_APIC_BASE MSR is 64 bits wide.
>How-To-Repeat:
Code inspection & read the Intel documentation
>Fix:
--- sys/arch/x86/include/i82489reg.h.orig       2010-01-09 10:36:06.000000000 +0000
+++ sys/arch/x86/include/i82489reg.h
@@ -150,5 +150,5 @@
 #define        LAPIC_MSR       0x001b
 #      define  LAPIC_MSR_BSP           0x00000100      /* boot processor */
 #      define  LAPIC_MSR_ENABLE        0x00000800      /* software enable */
-#      define  LAPIC_MSR_ADDR          0xfffff000      /* physical address */
+#      define  LAPIC_MSR_ADDR          0xffffff000     /* physical address */


>Release-Note:

>Audit-Trail:
From: David Laight <david@l8s.co.uk>
To: gnats-bugs@NetBSD.org
Cc: port-amd64-maintainer@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: port-amd64/42597: LAPIC MSR address mask 4 bits short
Date: Sat, 9 Jan 2010 11:33:49 +0000

 On Sat, Jan 09, 2010 at 10:40:01AM +0000, murray@river-styx.org wrote:
 >  #      define  LAPIC_MSR_ENABLE        0x00000800      /* software enable */
 > -#      define  LAPIC_MSR_ADDR          0xfffff000      /* physical address */
 > +#      define  LAPIC_MSR_ADDR          0xffffff000     /* physical address */

 That value is out of range for an integer constant.
 I'd have to read the docs, but aren't the MSRs accessed using special
 instructions - do that have > 32 bits physical address, especially on i386?

 	David

 -- 
 David Laight: david@l8s.co.uk

From: murray@river-styx.org
To: gnats-bugs@NetBSD.org
Cc: david@l8s.co.uk
Subject: Re: port-amd64/42597: LAPIC MSR address mask 4 bits short
Date: Sun, 10 Jan 2010 12:03:56 +1100

 Hi David,
    Yeah, the MSR's are read using special instructions, specifically using
 the assembly routines rdmsr and wrmsr where hi 32 bits are in rdx and
 low 32 bits in rax. The Intel documentation doesn't mention any
 variations to this instruction for all 64 and IA-32 platform's, other
 than on models which don't have the instructions in the first place.
    I overlooked the i386 aspects of my suggested change and I see that it
 is not quite so straight forward. On standard i386 platform's i guess
 that the upper 4 bits past 32 are not relevant for addressing. When
 running, say PAE, where the address space is bigger might allow for
 such possible addresses of an APIC.
    A little more thought required here...
 Take care,
    murray armfield


 > The following reply was made to PR port-amd64/42597; it has been noted by
 > GNATS.
 >
 > From: David Laight <david@l8s.co.uk>
 > To: gnats-bugs@NetBSD.org
 > Cc: port-amd64-maintainer@netbsd.org, gnats-admin@netbsd.org,
 > 	netbsd-bugs@netbsd.org
 > Subject: Re: port-amd64/42597: LAPIC MSR address mask 4 bits short
 > Date: Sat, 9 Jan 2010 11:33:49 +0000
 >
 >  On Sat, Jan 09, 2010 at 10:40:01AM +0000, murray@river-styx.org wrote:
 >  >  #      define  LAPIC_MSR_ENABLE        0x00000800      /* software
 > enable */
 >  > -#      define  LAPIC_MSR_ADDR          0xfffff000      /* physical
 > address */
 >  > +#      define  LAPIC_MSR_ADDR          0xffffff000     /* physical
 > address */
 >
 >  That value is out of range for an integer constant.
 >  I'd have to read the docs, but aren't the MSRs accessed using special
 >  instructions - do that have > 32 bits physical address, especially on
 > i386?
 >
 >  	David
 >
 >  --
 >  David Laight: david@l8s.co.uk
 >
 >

From: "Maxime Villard" <maxv@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/42597 CVS commit: src/sys/arch/x86/include
Date: Fri, 11 Aug 2017 06:27:12 +0000

 Module Name:	src
 Committed By:	maxv
 Date:		Fri Aug 11 06:27:12 UTC 2017

 Modified Files:
 	src/sys/arch/x86/include: specialreg.h

 Log Message:
 Add a comment about APICBASE_PHYSADDR. Has to do with PR/42597.


 To generate a diff of this commit:
 cvs rdiff -u -r1.100 -r1.101 src/sys/arch/x86/include/specialreg.h

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->closed
State-Changed-By: maxv@NetBSD.org
State-Changed-When: Fri, 11 Aug 2017 06:31:10 +0000
State-Changed-Why:
On some CPUs, the mask is variable-sized, the size being indicated in a
cpuid leaf. But verily, as I said in the comment I added right above the
APICBASE_PHYSADDR definition, we're only interested in the initial value,
which is necessarily < 32bits. So the definition is correct, and there's
nothing to be changed. I'm closing this PR.

Thanks for the report


From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/42597 CVS commit: [netbsd-8] src
Date: Tue, 21 Nov 2017 15:03:20 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Tue Nov 21 15:03:20 UTC 2017

 Modified Files:
 	src/sys/arch/x86/include [netbsd-8]: specialreg.h
 	src/sys/arch/x86/x86 [netbsd-8]: cpu_topology.c identcpu.c
 	src/usr.sbin/cpuctl/arch [netbsd-8]: i386.c

 Log Message:
 Pull up following revision(s) (requested by msaitoh in ticket #365):
 	sys/arch/x86/include/specialreg.h: revision 1.99
 	usr.sbin/cpuctl/arch/i386.c: revision 1.75
 	usr.sbin/cpuctl/arch/i386.c: revision 1.76
 	usr.sbin/cpuctl/arch/i386.c: revision 1.77
 	usr.sbin/cpuctl/arch/i386.c: revision 1.78
 	sys/arch/x86/x86/identcpu.c: revision 1.56
 	sys/arch/x86/x86/identcpu.c: revision 1.57
 	sys/arch/x86/x86/cpu_topology.c: revision 1.10
 	sys/arch/x86/include/specialreg.h: revision 1.100
 	sys/arch/x86/include/specialreg.h: revision 1.101
 	sys/arch/x86/include/specialreg.h: revision 1.102
 	sys/arch/x86/include/specialreg.h: revision 1.103
 	sys/arch/x86/include/specialreg.h: revision 1.104
 	sys/arch/x86/include/specialreg.h: revision 1.105
 Add EFER_TCE. This would be an interesting feature to have, since it
 reduces the indirect cost of invlpg; but I'm not convinced the way we
 flush upper-levels is correct for this yet.
 Fix typo in comment
 Add a comment about APICBASE_PHYSADDR. Has to do with PR/42597.
   Define CPUID Fn00000001 %ebx bits and use them. No functional change.
 Set ci->ci_cflush_lsize correctly. This bug was added in the last commit(1.56).
   Add the following instruction bits in Structured Extended Flags Enumeration
 Leaf from "Intel Architecture Instruction Set Extensions and Future Features
 Programming Reference" (319433-030):
 	AVX512_IFMA
 	AVX512_VBMI
 	AVX512_VBMI2
 	GFNI
 	VAES
 	VPCLMULQDQ
 	AVX512_VNNI
 	AVX512_BITALG
 	AVX512_VPOPCNTDQ
 	AVX512_4VNNIW
 	AVX512_4FMAPS
 - Print ci_feat_val[5] (Structured Extended Feature leaf Fn0000_0007 %ebx) on
    AMD, too.
 - Print ci_feat_val[6] (Fn0000_0007 %ecx) on Intel.
 Update from the latest Intel SDM:
   0x5c: Atom (Goldmont)
   0x5f: Atom (Goldmont, Denverton)
   0x7a: Atom (Goldmont Plus)
   Add Turbo Boost Max Technology 3.0 bit.
 Update from Intel SDM:
   0x55: Xeon Scalable (Skylake)
   0x57: Xeon Phi [357]200 (Knights Landing)
   0x66: Future Core (Cannon Lake)
   0x85: Future Xeon Phi (Knights Mill)
   Add the following bits in AMD Fn8000000a %edx features (SVM features):
 	PFThreshold (PAUSE filter threshold)
 	AVIC (AMD virtual interrupt controller)
 	V_VMSAVE_VMLOAD (virtualized VMSAVE and VMLOAD)
 	vGIF (virtualized GIF)


 To generate a diff of this commit:
 cvs rdiff -u -r1.98 -r1.98.2.1 src/sys/arch/x86/include/specialreg.h
 cvs rdiff -u -r1.9 -r1.9.22.1 src/sys/arch/x86/x86/cpu_topology.c
 cvs rdiff -u -r1.55 -r1.55.2.1 src/sys/arch/x86/x86/identcpu.c
 cvs rdiff -u -r1.74 -r1.74.6.1 src/usr.sbin/cpuctl/arch/i386.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

>Unformatted:

Home	PR Database Search