From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1754326AbeAQXjS (ORCPT <rfc822;w@1wt.eu>);
        Wed, 17 Jan 2018 18:39:18 -0500
Received: from mail-pg0-f45.google.com ([74.125.83.45]:34508 "EHLO
        mail-pg0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752791AbeAQXjR (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 17 Jan 2018 18:39:17 -0500
X-Google-Smtp-Source: ACJfBotwZm1unf1X86h+C/zdk5eClqe4Pa6CDybvB22Dj7ZnLgaR6WzIKZdWzkFqlrqCAjEKIL2Wgw==
Date: Wed, 17 Jan 2018 15:39:43 -0800
From: Nicolin Chen <nicoleotsuka@gmail.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>, 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, 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,
        nd@arm.com
Subject: Re: [PATCH RFC v1] arm64: Handle traps from accessing CNTVCT/CNTFRQ
 for CONFIG_COMPAT
Message-ID: <20180117233942.GB2935@Asurada-Nvidia>
References: <1515645816-14063-1-git-send-email-nicoleotsuka@gmail.com>
 <e750e380-f06b-dbbf-a61c-4281c0168b05@arm.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>
 <20180117204154.GA2935@Asurada-Nvidia>
 <20180117233508.45282a7b@m750.lan>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180117233508.45282a7b@m750.lan>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Jan 17, 2018 at 11:35:08PM +0000, Robin Murphy wrote:
> On Wed, 17 Jan 2018 12:41:56 -0800
> Nicolin Chen <nicoleotsuka@gmail.com> wrote:
> 
> > 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?
> 
> Um, perhaps because it's *compat*? How do you envision an AArch32
> MR{R}C instruction targeting r31, exactly? ;)

I see. Thank you, Robin.