lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 20 Dec 2012 10:38:58 +0000
From:	"Zhang, Lin-Bao (Linux Kernel R&D)" <>
To:	Yinghai Lu <>
CC:	"" <>,
	"" <>,
	"" <>,
	"" <>,
	"" <>, "" <>,
	"" <>,
	"" <>,
	"" <>,
	"" <>
Subject: RE: Why Linux kernel forced to enter X2APIC mode( just because of
 booting cpu has supported x2apic) without depending on BIOS' setting in
 MSR->x2apic enablement bit ?

Hi Yinghai, 

	Maybe two days ago, mis-understand the usage of MSR. 
Today, I carefully researched Intel? 64 Architecture x2APIC Specification which is open for all people.

I think current core argument is our BIOS did following judgement ,
but Linux kernel did not(Linux seems just judge BSP supports x2apic mode or not by CPUID method)
This section describes implications for the x2APIC across system state transitions - 
specifically initialization and booting. 
The default will be for the BIOS to pass the control to the OS with the local x2APICs 
in xAPIC mode if all x2APIC IDs reported by CPUID.0BH:EDX are less than 255, and 
in x2APIC mode if there are any logical processor reporting its x2APIC ID at 255 or 
Our BSP really supports x2apic mode, however,as this spec, our BIOS think some of configuration of server 
could not meet x2apic conditions ,So didn't place local xAPICs into x2apic mode. 
But linux kernel indeed enable x2apic mode(just believe BSP, didn't do above judgement) . so this is the conflict. 

I carefully read Linux kernel source code, I didn't find related code.
BIOS and OS both can configure and enable local xAPICs into x2APIC mode ,but they should follow 
the same spec .  from the spec , we should consider all cores or logical CPUs . 
if I lost some source code , sorry first , could you point me these code ? thanks very much! 

Following are some clarifications for old questions. Thanks very much for Yinghai and others' help.
From spec:
A processor’s support to operate its local APIC in the x2APIC mode can be detected 
by querying the extended feature flag information reported by CPUID. When CPUID 
is executed with EAX = 1, the returned value in ECX[Bit 21] indicates processor’s 
support for the x2APIC mode. If CPUID.(EAX=01H):ECX[Bit 21] is set, then the local 
APIC in the processor supports the x2APIC capability and can be placed into the 
x2APIC mode. This bit is set only when the x2APIC hardware is present. 
? System software can place the local APIC in the x2APIC mode by setting the 
x2APIC mode enable bit (bit 10) in the IA32_APIC_BASE MSR at MSR address 
01BH. The layout for the IA32_APIC_BASE MSR is shown in Figure 2-1.
So ,as above words: 
1, CPUID is just executed to query if CPU has supported x2apic mode.
It is read only.  It is decided by CPU vendor. 
In kernel source  , cpu_has_x2apic() should leverage CPUID interface. 

2, bit 11 and 10 of IA32_APIC_BASE MSR are used to switch to x2apic (EN=1, EXTD=1). 
So I begin to understand that  , OS certainly can control MSR to make CPU enter x2apic mode. 
BIOS also can , OS can also read it and write it as we need. 

> -----Original Message-----
> From: [] On Behalf Of
> Yinghai Lu
> Sent: 2012年12月20日 0:06
> how does BIOS claim?
Sorry for words , BIOS didn't claim , it just didn't set MSR(en=1 , EXTD=1). OS will read it first. 
This just can indicate that before BIOS passing control to OS, local x2APICs running in xAPIC mode. 

> disable that in CPUID?
No , CPUID is read only , "When CPUID is executed with EAX = 1, the returned value in ECX[Bit 21] indicates processor’s 
support for the x2APIC mode." 
BIOS just will query ,can set.  OS also did like this. 

Powered by blists - more mailing lists