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]
Date:	Mon, 30 May 2011 12:00:39 +0200
From:	Robert Richter <robert.richter@....com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"oprofile-list@...ts.sourceforge.net" 
	<oprofile-list@...ts.sourceforge.net>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [GIT PULL] oprofile fixes for v2.6.40

On 27.05.11 08:23:01, Ingo Molnar wrote:
> 
> * Robert Richter <robert.richter@....com> wrote:
> 
> > Robert Richter (1):
> >       oprofile, x86: Enable preemption during pci device setup in IBS init
> 
> I'm wondering about this bit, as from a preempt_enable()/disable() 
> pattern POV it looks bogus. It does:
> 
>         preempt_disable();
>         for (offset = 1; offset < APIC_EILVT_NR_MAX; offset++) {
>                 if (get_eilvt(offset))
>                         break;
>         }
>         preempt_enable();
> 
> 	...
> 
> 
> 	ret = setup_ibs_ctl(offset);
> 
> So whatever condition it established at the get_eilvt() stage might 
> not be valid at the setup_ibs_ctl() point: we might be on a different 
> CPU.
> 
> Or are the IBS MSRs (which get twiddled in get_eilvt() absolutely 
> symmetric across all CPUs, thus making this a preempt invariant 
> thing? In that case we'd at least need a big fat comment in the code 
> as it's not obvious at all ...

The MSRC001_103A (IBS Control Register) register contains the LVT
offset. It is a per-node msr and a read-only copy of F3x1CC (pci
device register). The offset must be valid (bit set) and not yet taken
by another vector (kernel keeps track of it in eilvt_offsets).  Though
offsets must be the same on all nodes, the kernel implementation uses
same offsets on all cores of the system.

The BIOS is responsible to setup the vector. If the vector in IBS_CTL
is invalid or already taken, we reassign a different offset in
force_ibs_eilvt_setup() (family 10h only).

In get_eilvt()/setup_APIC_eilvt() there are reads and writes to the
local apic. Preemption must be disabled to not be switched to another
cpu in the middle of a sequence.

> But i really do not see how this can work. get_eilvt() twiddles the 
> APIC LVT of this current CPU. Does IBS only activate on a single CPU? 
> How will this LVT entry be cleared on deinit?

This is done on the current cpu to get the offset which is then used
on all cpus of the system. The actually per-core setup for ibs is in
op_amd_setup_ctrs(). Deinit is in op_amd_cpu_shutdown().

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center

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