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: <20150206103111.GA9921@leverpostej>
Date:	Fri, 6 Feb 2015 10:31:12 +0000
From:	Mark Rutland <mark.rutland@....com>
To:	Marc Zyngier <marc.zyngier@....com>,
	Brent Wang <wangbintian@...il.com>
Cc:	"dan.zhao@...ilicon.com" <dan.zhao@...ilicon.com>,
	"btw@...l.itp.ac.cn" <btw@...l.itp.ac.cn>,
	Catalin Marinas <Catalin.Marinas@....com>,
	"wangbinghui@...ilicon.com" <wangbinghui@...ilicon.com>,
	Will Deacon <Will.Deacon@....com>,
	"huxinwei@...wei.com" <huxinwei@...wei.com>,
	"khilman@...aro.org" <khilman@...aro.org>,
	"haojian.zhuang@...aro.org" <haojian.zhuang@...aro.org>,
	"yanhaifeng@...il.com" <yanhaifeng@...il.com>,
	"rob.herring@...aro.org" <rob.herring@...aro.org>,
	"mturquette@...aro.org" <mturquette@...aro.org>,
	"victor.lixin@...ilicon.com" <victor.lixin@...ilicon.com>,
	"xuwei5@...ilicon.com" <xuwei5@...ilicon.com>,
	"jh80.chung@...sung.com" <jh80.chung@...sung.com>,
	"sledge.yanwei@...wei.com" <sledge.yanwei@...wei.com>,
	"kong.kongxinwei@...ilicon.com" <kong.kongxinwei@...ilicon.com>,
	"heyunlei@...wei.com" <heyunlei@...wei.com>,
	"w.f@...wei.com" <w.f@...wei.com>,
	"zhangfei.gao@...aro.org" <zhangfei.gao@...aro.org>,
	"z.liuxinliang@...wei.com" <z.liuxinliang@...wei.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Bintian Wang <bintian.wang@...wei.com>,
	Pawel Moll <Pawel.Moll@....com>,
	"ijc+devicetree@...lion.org.uk" <ijc+devicetree@...lion.org.uk>,
	"puck.chen@...ilicon.com" <puck.chen@...ilicon.com>,
	"olof@...om.net" <olof@...om.net>,
	"robh+dt@...nel.org" <robh+dt@...nel.org>,
	"linux@....linux.org.uk" <linux@....linux.org.uk>,
	"zhenwei.wang@...ilicon.com" <zhenwei.wang@...ilicon.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"guodong.xu@...aro.org" <guodong.xu@...aro.org>,
	"tomeu.vizoso@...labora.com" <tomeu.vizoso@...labora.com>,
	"sboyd@...eaurora.org" <sboyd@...eaurora.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"galak@...eaurora.org" <galak@...eaurora.org>,
	"xuejiancheng@...wei.com" <xuejiancheng@...wei.com>,
	"xuyiping@...ilicon.com" <xuyiping@...ilicon.com>,
	"liguozhu@...ilicon.com" <liguozhu@...ilicon.com>
Subject: Re: [PATCH 3/3] arm64: dts: Add dts files for Hisilicon Hi6220 SoC

On Fri, Feb 06, 2015 at 09:07:10AM +0000, Marc Zyngier wrote:
> On 06/02/15 08:42, Brent Wang wrote:
> 
> [...]
> 
> >>
> >>> +                   <0x0 0xf6802000 0x0 0x2000>, /* GICC */
> >>> +                   <0x0 0xf6804000 0x0 0x2000>, /* GICH */
> >>> +                   <0x0 0xf6806000 0x0 0x2000>; /* GICV */
> >>
> >> I guess no-one's bothered to consider 64k pages?
> >>
> >> Given GICH and GICV, I hope that this platform is booted at EL2?
> > Transfer from EL3 to EL1 directly, keep these two just for future use.
> 
> That's a real shame, as it keeps users away from some key aspects of the
> ARMv8 architecture.

More importantly (and regardless of whether you wish to use the features
provided by EL2), booting at EL2 means that the FW/bootloader needs to
set up far less, and that the kernel can fix up some issues that might
not be immediately apparent...

[...]

> >>> +     timer {
> >>> +             compatible = "arm,armv8-timer";
> >>> +             interrupt-parent = <&gic>;
> >>> +             interrupts = <1 13 0xff08>,
> >>> +                          <1 14 0xff08>,
> >>> +                          <1 11 0xff08>,
> >>> +                          <1 10 0xff08>;
> >>> +             clock-frequency = <1200000>;
> >>> +     };
> >>
> >> NAK. Fix your firmware to configure CNTFRQ, on all CPUs.
> > Fix in next version, maybe it will take some time to change firmware.
> 
> While you're at it, make sure CNTVOFF_EL2 is set to zero on all CPUs
> before dropping to EL1. This tends to be overlooked.

...like differing values of CNTVOFF_EL2.

There seems to be a common misconception that booting at EL2 is a bad
thing to do, when in reality booting at EL1 is more likely to result in
bugs we can't work around.

Is there any reason that you do not wish to boot at EL2, or were you
simply unaware that booting at EL2 was possible/preferred?

Thanks,
Mark.
--
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