linux-kernel - Re: [PATCH v2] x86: Bypass legacy PIC and PIT in ACPI hardware reduced mode

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: <20150311062324.GA29788@gmail.com>
Date:	Wed, 11 Mar 2015 07:23:24 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	"Li, Aubrey" <aubrey.li@...ux.intel.com>
Cc:	Ingo Molnar <mingo@...hat.com>,
	"alan@...ux.intel.com" <alan@...ux.intel.com>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"Brown, Len" <len.brown@...el.com>,
	"H. Peter Anvin" <hpa@...ux.intel.com>, x86@...nel.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] x86: Bypass legacy PIC and PIT in ACPI hardware
 reduced mode


* Li, Aubrey <aubrey.li@...ux.intel.com> wrote:

> On a platform in ACPI Hardware-reduced mode, the legacy PIC and PIT
> may not be initialized even though they may be present in silicon.
> Touching these legacy components causes unexpected result on system.

s/causes unexpected result on system/
  causes unexpected results on the system

> 
> On Bay Trail-T(ASUS-T100) platform, touching these legacy components

s/On Bay Trail-T(ASUS-T100) platform/
  On the Bay Trail-T(ASUS-T100) platform

> blocks platform hardware low idle power state(S0ix) during system
> suspend. So we should bypass them in ACPI hardware reduced mode.
> 
> Suggested-by: Arjan van de Ven <arjan@...ux.intel.com>
> Signed-off-by: Li Aubrey <aubrey.li@...ux.intel.com>
> Cc: Len Brown <len.brown@...el.com>
> Cc: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> Cc: Alan Cox <alan@...ux.intel.com>
> ---
>  arch/x86/kernel/acpi/boot.c | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
> 
> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> index b9e30da..1e5a7865 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -1343,6 +1343,24 @@ static int __init dmi_ignore_irq0_timer_override(const struct dmi_system_id *d)
>  }
>  
>  /*
> + * ACPI offers an alternative platform interface model that removes
> + * ACPI hardware requirements for platforms that do not implement
> + * the PC Architecture.
> + *
> + * We initialize the Hardware-reduced ACPI model here
> + */
> +static void __init acpi_reduced_hw_init(void)
> +{
> +	/*
> +	 * Override x86_init functions and bypass legacy pic
> +	 * in Hardware-reduced ACPI mode
> +	 */
> +	x86_init.timers.timer_init	= x86_init_noop;
> +	x86_init.irqs.pre_vector_init	= x86_init_noop;
> +	legacy_pic			= &null_legacy_pic;
> +}
> +
> +/*
>   * If your system is blacklisted here, but you find that acpi=force
>   * works for you, please contact linux-acpi@...r.kernel.org
>   */
> @@ -1541,6 +1559,9 @@ int __init early_acpi_boot_init(void)
>  	 */
>  	early_acpi_process_madt();
>  
> +	if (acpi_gbl_reduced_hardware)
> +		acpi_reduced_hw_init();

Ok, my final bike shed painting job would be to move the 
'acpi_gbl_reduced_hardware' flag check inside acpi_reduced_hw_init(): 
that makes it nicely self-sustained and all in a single place.

With that fixed it looks good to me.

Should I merge it for v4.0 upstream merge, in tip:x86/urgent?

The 'touches hardware in unexpected ways' aspect qualifies it for 
urgent treatment IMO.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/