From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754608AbeAQUlf (ORCPT ); Wed, 17 Jan 2018 15:41:35 -0500 Received: from mail-pf0-f177.google.com ([209.85.192.177]:38471 "EHLO mail-pf0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752068AbeAQUlc (ORCPT ); Wed, 17 Jan 2018 15:41:32 -0500 X-Google-Smtp-Source: ACJfBosy3D4DTw7HgU2FT3HH9f0pZcw+9WZHyWZ5BJwe0DdODY29nHWpaFVqrkj0ORQnBj/X8NiY4A== Date: Wed, 17 Jan 2018 12:41:56 -0800 From: Nicolin Chen To: Marc Zyngier Cc: mark.rutland@arm.com, catalin.marinas@arm.com, will.deacon@arm.com, oleg@redhat.com, cdall@linaro.org, tbaicar@codeaurora.org, julien.thierry@arm.com, Dave.Martin@arm.com, robin.murphy@arm.com, james.morse@arm.com, ard.biesheuvel@linaro.org, xiexiuqi@huawei.com, mingo@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH RFC v1] arm64: Handle traps from accessing CNTVCT/CNTFRQ for CONFIG_COMPAT Message-ID: <20180117204154.GA2935@Asurada-Nvidia> References: <1515645816-14063-1-git-send-email-nicoleotsuka@gmail.com> <20180116203218.GA6318@Asurada-Nvidia> <86r2qpec32.wl-marc.zyngier@arm.com> <20180116213745.GA9545@Asurada-Nvidia> <20180117021346.GA26166@Asurada-Nvidia> <83b9c187-7fbf-3e05-6321-de7fa05fd868@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83b9c187-7fbf-3e05-6321-de7fa05fd868@arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 17, 2018 at 09:03:48AM +0000, Marc Zyngier wrote: > > So ignoring a condition for a Thumb instruction may cause its IT > > scope shifting. For ARM mode, the only penalty could be two Rts > > getting written -- which shouldn't corrupt userspace execution. > > > > Please correct me if I am wrong or not thorough. > > Consider the following: > > mov r0, #0 > mov r1, #0 > cmp r1, #3 > mrrceq r0, r1, cntvct // simplified version > > Oh look, you've corrupted r0 and r1, which should never have be changed. > Whatever uses the content r0 and r1 after the mrrc will misbehave. How > is that an acceptable behaviour? How do you expect userspace to cope > with such a brain damage? > > If you intend to emulate the CPU, you must emulate it fully, to the > letter of the architecture. No ifs, no buts. Thanks for the explain. I see the point here. I saw your version for arm64 compat doesn't check if (rt != 31) as MRS handler does. Is there any reason for that? Thank you Nicolin