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=-9.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 0417BC63777 for ; Mon, 30 Nov 2020 17:58:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 996FB20789 for ; Mon, 30 Nov 2020 17:58:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="XmDjRpd6" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729418AbgK3R5y (ORCPT ); Mon, 30 Nov 2020 12:57:54 -0500 Received: from mail.kernel.org ([198.145.29.99]:50040 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728519AbgK3R5y (ORCPT ); Mon, 30 Nov 2020 12:57:54 -0500 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C7F57206E3; Mon, 30 Nov 2020 17:57:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1606759033; bh=zAn0U39uj2gW7KHPapxndRa/sHkW/TfgOLMEtCLmEaM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XmDjRpd66b8EbduMPVQB7tYz6biMwawTv/Ts3eBO+4iR2AinDnfaxEmyZ/IB2plbC FZUyPivcgpHis+LM08Q8fYpLJieg4CamOuskqhpbI1wj499I3AoJv57yGPcdCgVXvn PrgJiUyAMpcsV0c9teBA8YGvJE9kbQaza7+pRPzo= Date: Mon, 30 Nov 2020 17:57:07 +0000 From: Will Deacon To: Rongwei Wang Cc: catalin.marinas@arm.com, bjorn.andersson@linaro.org, shawnguo@kernel.org, vkoul@kernel.org, geert+renesas@glider.be, Anson.Huang@nxp.com, michael@walle.cc, krzk@kernel.org, olof@lixom.net, vincenzo.frascino@arm.com, ardb@kernel.org, masahiroy@kernel.org, gshan@redhat.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/3] arm64:msr: Add MSR driver Message-ID: <20201130175706.GA25457@willie-the-truck> References: <20201130174833.41315-1-rongwei.wang@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201130174833.41315-1-rongwei.wang@linux.alibaba.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 01, 2020 at 01:48:30AM +0800, Rongwei Wang wrote: > MSR ARM driver aims to provide interfacs for user to read or write data to all > system registers. Its functions is same as MSR driver (x86 platform). It mainly > depends on kprobe and undef exception to read or write system registers > dynamicly. ... but why? These are privileged registers for a reason, and giving userspace access to them is bound to cause serious problems. Why can't we do whatever it is that userspace is trying to do by poking these things in the kernel instead? This interface is a bit like using /dev/mem instead of writing a proper device driver. Thanks, Will