linux-kernel - Re: [PATCH] Option to disable AMD C1E (allows dynticks to work)

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: <alpine.LFD.0.99999.0712141835510.3668@localhost.localdomain>
Date:	Fri, 14 Dec 2007 19:07:30 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Eduard-Gabriel Munteanu <eduard.munteanu@...ux360.ro>
cc:	Andi Kleen <andi@...stfloor.org>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] Option to disable AMD C1E (allows dynticks to work)

On Fri, 14 Dec 2007, Eduard-Gabriel Munteanu wrote:

> LAPIC is seemingly disabled (C1E detection code does this), but
> clockevents still tries to use it, instead of relying on HPET.

It relies on HPET. The LAPIC is just used as a mechanism which allows
us to broadcast the tick to both cores.

> I'll look into this, but please give me a heads up if you know more
> about what's happening. Looks like fixing this is better than using
> LAPIC for dynticks (and disabling C1E) on such systems.

Yes, it's definitely worth fixing, but it's not trivial:

For Highres/dyntick we need per CPU clock event devices to avoid
serialization and broadcasting overhead in the normal operation mode.

The LAPIC timer is per CPU, fast and the best thing we have, except
for C1E enabled AMD systems.

The perfect solution for those systems would be to use the HPET
channels seperately as per CPU clock event devices. Venki tried this
some time ago, but it's hard to resolve simply because none of the
BIOSes gives us an idea to which interrupts we can route the HPET
channel interrupts. The only choice we have is to use the legacy
interrupts, which gives us the headache of emulating the RTC via the
HPET and some other stupid legacy issues.

We can not utilize the broadcast mechanism of the cpuidle code because
we do not have an idea that we are going into C1E as it is done
magically in the SMM code. To work around this is we would need to add
the broadcast notification to the halt(), safe_halt(), pm_idle_halt()
variants which float around in the kernel and make this conditional on
the C1E detection. That's nasty, but it seems the only solution for
now.

Thanks,

	tglx

--
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/