| 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
| ||
|
Message-ID: <20130607164123.GF3111@e102568-lin.cambridge.arm.com>
Date: Fri, 7 Jun 2013 17:41:23 +0100
From: Lorenzo Pieralisi <lorenzo.pieralisi@....com>
To: James King <james.king@...aro.org>
Cc: "grant.likely@...aro.org" <grant.likely@...aro.org>,
"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
"rob@...dley.net" <rob@...dley.net>,
"linux@....linux.org.uk" <linux@....linux.org.uk>,
"nico@...aro.org" <nico@...aro.org>,
"vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
"namhyung@...nel.org" <namhyung@...nel.org>,
"a.p.zijlstra@...llo.nl" <a.p.zijlstra@...llo.nl>,
"devicetree-discuss@...ts.ozlabs.org"
<devicetree-discuss@...ts.ozlabs.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"patches@...aro.org" <patches@...aro.org>,
"linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>
Subject: Re: [PATCH] arm/dt: Don't add disabled CPUs to system topology
On Fri, Jun 07, 2013 at 12:48:58PM +0100, James King wrote:
> Hi Lorenzo,
>
> On 7 June 2013 11:23, Lorenzo Pieralisi <lorenzo.pieralisi@....com> wrote:
> > Hi James,
> >
> > On Thu, Jun 06, 2013 at 06:11:25PM +0100, James King wrote:
> >> If CPUs are marked as disabled in the devicetree, make sure they do
> >> not exist in the system CPU information and CPU topology information.
> >> In this case these CPUs will not be able to be added to the system later
> >> using hot-plug. This allows a single chip with many CPUs to be easily
> >> used in a variety of hardware devices where they may have different
> >> actual processing requirements (eg for thermal/cost reasons).
> >>
> >> - Change devicetree.c to ignore any cpu nodes marked as disabled,
> >> this effectively limits the number of active cpu cores so no need
> >> for the max_cpus=x in the chosen node.
> >> - Change topology.c to ignore any cpu nodes marked as disabled, this
> >> is where the scheduler would learn about big/LITTLE cores so this
> >> effectively keeps the scheduler in sync.
> >>
> >
> > I have two questions:
> >
> > 1) Since with this approach the DT should change anyway if on different
> > hardware devices based on the same chip you want to allow booting a
> > different number of CPUs, why do not we remove the cpu nodes instead of
> > disabling them ? Put it another way: cpu nodes define a cpu as
> > possible (currently), we can simply remove the node if we do not want
> > that cpu to be seen by the kernel.
>
> The reason we want disabled status rather than just remove the nodes
> is to use a common soc.dtsi file which is included in many board.dts
> files - eg:
>
> file soc.dtsi contains:
>
> cpus {
> cpu0: cpu@0 {
> device_type = "cpu";
> compatible = "arm,cortex-a7";
> reg = <0>;
> cluster = <&cluster0>;
> core = <&core0>;
Minor nit, "cluster" and "core" phandles are not part of cpu the bindings
that will be merged this cycle, I know it is just an example.
> };
>
> cpu1: cpu@1 {
> device_type = "cpu";
> compatible = "arm,cortex-a7";
> reg = <1>;
> cluster = <&cluster0>;
> core = <&core1>;
> };
>
> cpu2: cpu@2 {
> device_type = "cpu";
> compatible = "arm,cortex-a15";
> reg = <2>;
> cluster = <&cluster0>;
> core = <&core2>;
> };
> };
>
> file board1.dts where we want the A15 disabled contains:
>
> /include/ "soc.dtsi"
>
> cpus {
> cpu2: cpu@2 {
> status = "disabled";
> };
> };
Understood, see the other reply as far as the status property is concerned.
> > 2) If we go for the "status" property, why do not we use it to set present
> > mask ? That way the cpu is possible but not present, you cannot
> > hotplug it in. It is a bit of a stretch, granted, the cpu _is_ present,
> > we just want to disable it, do not know how this is handled in x86
> > and other archs though.
>
> I have been struggling to find any equivalent example for another
> arch, so just tried to solve our problem. I guess in the x86 world it
> is less likely to want to disable processors in a SoC for heat/battery
> issues so this has just never arisen. In this case the cpu is
> physically present but not possible, but I am not sure it should be in
> a present mask (giving the impression it can be used). Perhaps you
> could elaborate with an example what you are thinking about here?
I was thinking about using status == "disabled" to mark a cpu as
possible but not present; that is a bad idea for the reason you mentioned
and also for the point Rob raised related to the ePAPR.
I am not sure how we can solve this issue, as I mentioned the easiest
solution consists in not defining cpu nodes in the DT or probably add
an additional property != status with proper bindings attached to it.
Lorenzo
--
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