Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200907094843.1949-1-Jason@zx2c4.com> <20200907100647.GB10657@zn.tnic>
 <CAHmME9o_Odo97K7QXKO=konVE-UxR7iBCE5S8uAJgc=kJ2EgsA@mail.gmail.com> <20200907111109.GB16029@zn.tnic>
In-Reply-To: <20200907111109.GB16029@zn.tnic>
From:   "Jason A. Donenfeld" <Jason@zx2c4.com>
Date:   Mon, 7 Sep 2020 13:15:14 +0200
Message-ID: <CAHmME9pR5Z+G5Z-+-11Hr2gO+SXY6oVoDF+p0Ox7V1oHNVsBvg@mail.gmail.com>
Subject: Re: [PATCH] x86/msr: do not warn on writes to OC_MAILBOX
To:     Borislav Petkov <bp@alien8.de>
Cc:     Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
        kitsunyan <kitsunyan@airmail.cc>, X86 ML <x86@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Sep 7, 2020 at 1:11 PM Borislav Petkov <bp@alien8.de> wrote:
>
> Hi,
>
> On Mon, Sep 07, 2020 at 12:46:35PM +0200, Jason A. Donenfeld wrote:
> > Are you sure that intel-undervolt using OC_MAILBOX from userspace is
> > actually a "misuse"? Should the kernel or kernel drivers actually be
> > involved with the task of underclocking? This seems pretty squarely in
> > the realm of "hobbyists poking and prodding at their CPUs" rather than
> > something made for a kernel driver, right?
>
> The only thing I'm sure is that *if* it makes sense for any driver to
> control something in the hardware over MSRs, it should *not* poke at
> naked MSRs but use a proper interface.
>
> I'd leave it to the people who actually need this interface, to explain
> why they do.
>
> > Also, what was the justification for whitelisting
> > MSR_IA32_ENERGY_PERF_BIAS?
>
> That's:
>
> tools/power/x86/x86_energy_perf_policy/x86_energy_perf_policy.c
>
> Once that thing gets converted to a proper interface too, that MSR goes
> off the allowlist too.

Gotcha. So your perspective is that the goal is actually to have no
list at all in the end, because all MSR writes should go through sysfs
interfaces and such, always? I certainly like that goal -- it'd make a
whole lot of CPU functionality a lot more discoverable and easier to
tinker with. In practice, it seems like that's a hard goal to
accomplish, with different MSRs having different semantics and
meanings of different bit offsets, and a great deal of them aren't
actually publicly documented by Intel. Were you hoping to just handle
these piece by piece, and eventually Linux will have a decent
compendium of MSRs? That sure would be nice. Is Intel on board with
that plan?

Jason