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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <43F901BD926A4E43B106BF17856F07559A257FE1@orsmsx508.amr.corp.intel.com>
Date:	Thu, 17 Dec 2009 17:14:32 -0800
From:	"Pan, Jacob jun" <jacob.jun.pan@...el.com>
To:	"H. Peter Anvin" <hpa@...ux.intel.com>
CC:	Cyrill Gorcunov <gorcunov@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"x86@...nel.org" <x86@...nel.org>
Subject: RE: [PATCH 2/2] x86/apic: check global clockevent in lapic timer
 setup



>-----Original Message-----
>From: H. Peter Anvin [mailto:hpa@...ux.intel.com]
>Sent: Thursday, December 17, 2009 2:34 PM
>To: Pan, Jacob jun
>Cc: Cyrill Gorcunov; linux-kernel@...r.kernel.org; x86@...nel.org
>Subject: Re: [PATCH 2/2] x86/apic: check global clockevent in lapic timer setup
>
>On 12/17/2009 02:31 PM, Pan, Jacob jun wrote:
>>> Wouldn't be better to operate the same way as in case of "noapictimer"
>>> boot option. I guess the non-pc x86 midplatforms you're mentioning
>>> do not use SMP ever but just to be consistent in code.
>>>
>> [[JPAN]] We do use SMP with hyper threading in Moorestown.
>> In that case we have a per cpu platform timer without global clockevent.
>> so i think we don't want the dummy lapic event. we don't want to use the
>> broadcast mechanism as mentioned in the comments before disabling lapic
>> timer.
>>
>> For moorestown, I can use x86_init.timers.setup_percpu_clockev
>> abstraction function so that Moorestown platform does not need to call
>> setup_boot_APIC_clock() if per cpu platform timer is used. so many IFs :).
>>
>> But in the case of having constant and always on LAPIC timer, we still do
>> not want the dummy lapic clockevent and the broadcast. we will just have
>> per cpu always on local apic timers without global clockevent device.
>
>OK, I'm not entirely sure I follow this, and I'm not sure someone trying
>to understand the code in five years would, either.  I don't really see
>the above translating into "we don't have a global clockevent, therefore
>we shouldn't initialize (but should still not disable) the local APIC
>timer."
>
>	-hpa
[[JPAN]] There is some thing wrong in my logic.

If we have always running lapic timer, and per cpu platform timers, we would
still want to set up the lapic timer without global clockevent, just without
calibration. perhaps use a platform specific setup_percpu_clockev() function.

So i don't think we need this patch at the moment, maybe we only need to do a
sanity check for global clockevent in calibrate_APIC_clock().

Honestly, i don't fully understand how the dummy lapic event device is related
to the broadcast mechanism. can someone explain why we register the dummy
lapic clockevent?

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ