linux-kernel - Re: [PATCH 2/2] x86/acpi: Remove the repeated lapic address override entry parsing

lists.openwall.net		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]

Message-ID: <20160628033050.GA2732@x1.redhat.com>
Date:	Tue, 28 Jun 2016 11:30:50 +0800
From:	Baoquan He <bhe@...hat.com>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:	linux-kernel@...r.kernel.org, x86@...nel.org,
	Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, Borislav Petkov <bp@...e.de>,
	Andy Lutomirski <luto@...nel.org>, Shaohua Li <shli@...com>,
	Hidehiro Kawai <hidehiro.kawai.ez@...achi.com>,
	Juergen Gross <jgross@...e.com>,
	Joerg Roedel <jroedel@...e.de>, Dave Young <dyoung@...hat.com>,
	Lv Zheng <lv.zheng@...el.com>, Toshi Kani <toshi.kani@....com>,
	Mark Salter <msalter@...hat.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>
Subject: Re: [PATCH 2/2] x86/acpi: Remove the repeated lapic address override
 entry parsing

On 06/28/16 at 03:25am, Rafael J. Wysocki wrote:
 
> > diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> > index 9414f84..6ef3694 100644
> > --- a/arch/x86/kernel/acpi/boot.c
> > +++ b/arch/x86/kernel/acpi/boot.c
> > @@ -990,21 +992,6 @@ static int __init acpi_parse_madt_lapic_entries(void)
> >  	if (!boot_cpu_has(X86_FEATURE_APIC))
> >  		return -ENODEV;
> >  
> > -	/*
> > -	 * Note that the LAPIC address is obtained from the MADT (32-bit value)
> > -	 * and (optionally) overridden by a LAPIC_ADDR_OVR entry (64-bit value).
> > -	 */
> > -
> > -	count = acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_APIC_OVERRIDE,
> > -				      acpi_parse_lapic_addr_ovr, 0);
> > -	if (count < 0) {
> > -		printk(KERN_ERR PREFIX
> > -		       "Error parsing LAPIC address override entry\n");
> > -		return count;
> > -	}
> > -
> > -	register_lapic_address(acpi_lapic_addr);
> > -
> 
> I'm not really sure if this change is correct.
> 
> Does it only deal with the override?

Hi Rafael,

Thanks for your comments.

Yes, it only deals with the override and it will call
register_lapic_address to set fixed mapping for lapic and get value for
boot_cpu_physical_apicid. Since this has heen done in
early_acpi_boot_init() there's no need to do it again in
acpi_boot_init().


> 
> >  	count = acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_SAPIC,
> >  				      acpi_parse_sapic, MAX_LOCAL_APIC);
> >  
> > diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> > index 60078a6..504311c 100644
> > --- a/arch/x86/kernel/apic/apic.c
> > +++ b/arch/x86/kernel/apic/apic.c
> > @@ -1799,7 +1799,7 @@ void __init register_lapic_address(unsigned long address)
> >  	if (!x2apic_mode) {
> >  		set_fixmap_nocache(FIX_APIC_BASE, address);
> >  		apic_printk(APIC_VERBOSE, "mapped APIC to %16lx (%16lx)\n",
> > -			    APIC_BASE, mp_lapic_addr);
> > +			    APIC_BASE, address);
> >  	}
> >  	if (boot_cpu_physical_apicid == -1U) {
> >  		boot_cpu_physical_apicid  = read_apic_id();
> > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> > index c4e7b39..059680d 100644
> > --- a/arch/x86/kernel/setup.c
> > +++ b/arch/x86/kernel/setup.c
> > @@ -1157,6 +1157,9 @@ void __init setup_arch(char **cmdline_p)
> >  	 */
> >  	acpi_boot_table_init();
> >  
> > +	/*
> > +	 * AMD NUMA support need get boot_cpu_id earlier.
> > +	 */
> 
> Surely that's not the only goal of early_acpi_boot_init(), is it?

In commit cbf9bd60(acpi: get boot_cpu_id as early for k8_scan_nodes)
Yinghai added early_acpi_boot_init() and called it in amd numa code.
Then commit 2e42060c(x86, uv: add early detection of UV system types)
put it in arch/x86/kernel/setup.c to discover the apic type earlier.

So, you are right. This command adding is not correct.

> 
> >  	early_acpi_boot_init();
> >  
> >  	initmem_init();
> > 
> 
> Please CC ACPI-related patches to linux-acpi@...r.kernel.org.

Will do when repost.

> 
> Thanks,
> Rafael
>