From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6F2A8C0650F for ; Thu, 8 Aug 2019 09:35:32 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 41F4F2187F for ; Thu, 8 Aug 2019 09:35:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="S2OZ0tjC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 41F4F2187F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=M3kXu0MS/GK3Dc4XIuEAd/QwMCfurCF0sPlP3LOPehs=; b=S2OZ0tjCgEp5dl 4GsssOTlSB7Em54+FNVVBWNPyVArc4mYCpFNeDz/80ea1mGX1u/PSSj+oyOgKZ6ReWyhQ10obmrte xCfXGuKUPS7bz9CkDUe9BwCUQfiummbdZmObsQL0YgoCG4ljTOyr/23X+WPFtim9bmOT60X5RPMcP ZCGMrOcDsM99/Tx2q0sYVNHAGHxUCWWgW/pk/MWzprqEIaCrbJDx+BuIde9cXi1FcWVZl92IWxcIW 5CwishMLXJzZxFcYiOTjAm+It/AVwWlAF4H5cJ9Nsi7VWRBna5G/MqjyKUPTr42WbyMngiqcQShgf KS5mz35HMDeS7pQPscVA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hvepX-00074n-2U; Thu, 08 Aug 2019 09:35:31 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hvepT-00073s-It for linux-arm-kernel@lists.infradead.org; Thu, 08 Aug 2019 09:35:28 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2DFBE1576; Thu, 8 Aug 2019 02:35:27 -0700 (PDT) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 46D993F706; Thu, 8 Aug 2019 02:35:26 -0700 (PDT) Date: Thu, 8 Aug 2019 10:35:24 +0100 From: Dave Martin To: Stefan Agner Subject: Re: Detecting AArch32 support from a AArch64 process in user space Message-ID: <20190808093522.GG10425@arm.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190808_023527_715536_BD3C7B8F X-CRM114-Status: GOOD ( 25.43 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Marc Zyngier , ynorov@caviumnetworks.com, will.deacon@arm.com, linux-arm-kernel@lists.infradead.org, suzuki.poulose@arm.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Aug 08, 2019 at 09:36:42AM +0200, Stefan Agner wrote: > [resend this time with the correct mailing list address] > > Hello, > > I am trying to detect whether an ARMv8 system running in AArch64 state > supports AArch32 state from a user space process. The arm64_features[] > in Why? Is this just for diagnostic purposes, or some programmatic reason? In the latter case, just try to do what ever it is you want to do that depends on AArch32: if it fails, you don't have AArch32. > arch/arm64/kernel/cpufeature.c lists a CPU feature "32-bit EL0 Support". > However, afaik this CPU feature is not directly exposed to user-space. > The features do get printed in the kernel log, but that requires > privileges and only works directly after boot. There is Please don't scrape dmesg :) However, detecting AArch32 support is a bit annoying due to the fact that there's no hwcap or similar. > system_supports_32bit_el0() which is used in various places in the arm64 > architecture code. One of the instances where I can make sense of from > user space is through the personality system call. One idea is to call > personality(PER_LINUX32). It would then return error code 22 in case > 32-bit is not supported in user space. However, if successful this > changes the personality of the current process which might have side > effects which I do not want...? > > I started to ask myself what PER_LINUX32 actually changes. From what I > can tell it only changes the behavior of /proc/cpuinfo? The personality > seems not to be applied automatically to 32-bit processes, so this is a > opt-in backward compatibility feature? Basically yes. Nonetheless, this is probably a reasonable way to test for AArch32 userspace support. > To be on the safe side, I was thinking about executing the system call > in a separate process. However, at that point I could also just execute > a statically linked AArch32 binary and see whether I get a "exec format > error". I guess this could then be either due to missing AArch32 CPU > support or the kernel not being compiled with 32-bit compatibility. personality() returns the old personality, so you providing you don't have multiple threads you can probably try to set it to PER_LINUX32 and then restore it. Otherwise, you would need to fork and try personality() from the child. Or as you suggest, try to exec a 32-bit binary. > At last I was considering reading directly from the CPU. But from what I > understand the register used in the kernel to determine 32-bit > compatibility (ID_AA64PFR0_EL1) is not accessible by user space (due to > the suffix _EL1). > > Any advice/thoughts on this topic? This register is emulated for userspace, so you can read it. However, the relevant field gets masked out, so this is probably not much use to you. We could expose the field, but a test that relies on it wouldn't be backwards compatible. If you just want to do this test from a script for diagnostic purposes and the filesystem has util-linux, then something like linux32 /bin/true might also work (this is effectively a scripted version of the personality(PER_LINUX32) test). Cheers ---Dave _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel