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: <568E9CB2.60301@roeck-us.net>
Date:	Thu, 7 Jan 2016 09:13:22 -0800
From:	Guenter Roeck <linux@...ck-us.net>
To:	Peter Maydell <peter.maydell@...aro.org>,
	Lorenzo Pieralisi <lorenzo.pieralisi@....com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Mark Rutland <mark.rutland@....com>,
	Will Deacon <will.deacon@....com>,
	QEMU Developers <qemu-devel@...gnu.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [Qemu-devel] arm64 qemu tests failing in linux-next since 'arm64:
 kernel: enforce pmuserenr_el0 initialization and restore'

On 01/07/2016 08:56 AM, Peter Maydell wrote:
> On 7 January 2016 at 16:37, Lorenzo Pieralisi <lorenzo.pieralisi@....com> wrote:
>> On Thu, Jan 07, 2016 at 03:58:15PM +0000, Peter Maydell wrote:
>>> On 7 January 2016 at 15:53, Lorenzo Pieralisi <lorenzo.pieralisi@....com> wrote:
>>>> Ok, thanks for looking into this. I wonder why reading pmcr_el0 does
>>>> not suffer from the same problem though.
>>>
>>> Just a pragmatic thing on QEMU's end, I expect -- the kernel already
>>> touched PMCR_EL0 and we wanted to be able to boot it, so we have an
>>> implementation of it.
>>
>> If that's the case, that was the wrong approach IMHO. QEMU has to comply
>> with the Aarch64 architecture which means that either the CPU it models
>> has a Performance Monitors extension or it does not. If reading pmcr_el0
>> does not fault I could tell you this is a QEMU regression because currently
>> it _does_ model pmcr_el0 while (hopefully) ID_AA64DFR0_EL1 PMUVer reports
>> it should not.
>
> I agree it's a bug, but QEMU simply doesn't have enough
> developers to become fully compliant with the architecture (ie to
> implement every part of it completely). So we concentrate on the
> parts that people are actually using, and fill in the rest and
> fix the bugs as time permits or as real guest software starts to
> use it.
>
> If you want a guaranteed matches-the-architecture software model
> of an ARM CPU then other models are available :-)
>
I think it would be better to convince ARM to put some manpower into
enhancing qemu, instead of telling them to use some other model ;-).

Guenter

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