On Wed, Oct 21, 2020 at 06:11:09AM -0700, Srinivas Pandruvada wrote:
> That is the problem. There is no public document.
Well, considering how important this functionality has become, maybe
they should be made public and maybe there should be a kernel undervolt
driver, as peterz suggests.
> > I d
On Tue, Oct 20, 2020 at 10:21:48AM -0700, Srinivas Pandruvada wrote:
> On Mon, 2020-10-19 at 19:15 +0200, Borislav Petkov wrote:
> These command id are model specific. There is no guarantee that even
> meaning changes. So I don't think we should write any code in kernel
> which can't stick.
>
>
On Tue, 2020-10-20 at 12:40 -0700, Dave Hansen wrote:
> On 10/20/20 11:40 AM, Srinivas Pandruvada wrote:
> > On Tue, 2020-10-20 at 19:47 +0200, Borislav Petkov wrote:
> > > On Tue, Oct 20, 2020 at 10:21:48AM -0700, Srinivas Pandruvada
> > > wrote:
> > > > These command id are model specific. There
On 10/20/20 11:40 AM, Srinivas Pandruvada wrote:
> On Tue, 2020-10-20 at 19:47 +0200, Borislav Petkov wrote:
>> On Tue, Oct 20, 2020 at 10:21:48AM -0700, Srinivas Pandruvada wrote:
>>> These command id are model specific. There is no guarantee that
>>> even
>>> meaning changes. So I don't think we
On Tue, 2020-10-20 at 19:47 +0200, Borislav Petkov wrote:
> On Tue, Oct 20, 2020 at 10:21:48AM -0700, Srinivas Pandruvada wrote:
> > These command id are model specific. There is no guarantee that
> > even
> > meaning changes. So I don't think we should write any code in
> > kernel
> > which can't
On Tue, Oct 20, 2020 at 10:21:48AM -0700, Srinivas Pandruvada wrote:
> These command id are model specific. There is no guarantee that even
> meaning changes. So I don't think we should write any code in kernel
> which can't stick.
Ok, is there a common *set* of values present on all models?
A co
On Mon, 2020-10-19 at 19:15 +0200, Borislav Petkov wrote:
> On Tue, Sep 08, 2020 at 06:02:05PM -0700, Srinivas Pandruvada wrote:
> > The actual OC mailbox implementation itself is implemented in Linux
> > in
> > intel_turbo_max_3 driver. So that is public.
> > So someone can develop a driver and pr
On Tue, Sep 08, 2020 at 06:02:05PM -0700, Srinivas Pandruvada wrote:
> The actual OC mailbox implementation itself is implemented in Linux in
> intel_turbo_max_3 driver. So that is public.
> So someone can develop a driver and provide some sysfs to send mailbox
> commands, but kernel can't validate
On Tue, Sep 8, 2020 at 6:02 PM Srinivas Pandruvada
wrote:
>
> On Tue, 2020-09-08 at 21:30 +0200, Borislav Petkov wrote:
> > On Tue, Sep 08, 2020 at 12:18:38PM -0700, Sultan Alsawaf wrote:
> > > I'd like to point out that on Intel's recent 14nm parts,
> > > undervolting
> > > is not so much for squ
On Tue, Sep 8, 2020 at 3:32 PM Matthew Garrett wrote:
>
> On Tue, Sep 8, 2020 at 1:35 PM Andy Lutomirski wrote:
>
> > Undervolting is a bit different. It’s a genuinely useful configuration that
> > can affect system stability. In general, I think it should be allowed, and
> > it should have a
On Tue, 2020-09-08 at 21:30 +0200, Borislav Petkov wrote:
> On Tue, Sep 08, 2020 at 12:18:38PM -0700, Sultan Alsawaf wrote:
> > I'd like to point out that on Intel's recent 14nm parts,
> > undervolting
> > is not so much for squeezing every last drop of performance out of
> > the
> > SoC as it is f
On Tue, Sep 8, 2020 at 1:35 PM Andy Lutomirski wrote:
> Undervolting is a bit different. It’s a genuinely useful configuration that
> can affect system stability. In general, I think it should be allowed, and
> it should have a real driver in tree.
Agree that this should be a proper driver ra
> On Sep 8, 2020, at 12:30 PM, Borislav Petkov wrote:
>
> On Tue, Sep 08, 2020 at 12:18:38PM -0700, Sultan Alsawaf wrote:
>> I'd like to point out that on Intel's recent 14nm parts, undervolting
>> is not so much for squeezing every last drop of performance out of the
>> SoC as it is for nece
On Tue, Sep 08, 2020 at 12:18:38PM -0700, Sultan Alsawaf wrote:
> I'd like to point out that on Intel's recent 14nm parts, undervolting
> is not so much for squeezing every last drop of performance out of the
> SoC as it is for necessity.
Sounds to me that this undervolting functionality should
On Tue, Sep 08, 2020 at 08:01:12PM +0200, Borislav Petkov wrote:
> On Tue, Sep 08, 2020 at 07:42:12PM +0200, Jason A. Donenfeld wrote:
> > Are you prepared to track down all the MSRs that might maybe do
> > something naughty?
>
> I'm not prepared - that's why this MSR filtering. To block *all* dir
On Tue, Sep 8, 2020 at 8:01 PM Borislav Petkov wrote:
>
> On Tue, Sep 08, 2020 at 07:42:12PM +0200, Jason A. Donenfeld wrote:
> > Are you prepared to track down all the MSRs that might maybe do
> > something naughty?
>
> I'm not prepared - that's why this MSR filtering. To block *all* direct
> MSR
On Tue, Sep 08, 2020 at 07:42:12PM +0200, Jason A. Donenfeld wrote:
> Are you prepared to track down all the MSRs that might maybe do
> something naughty?
I'm not prepared - that's why this MSR filtering. To block *all* direct
MSR accesses from userspace in the future.
> Does `dd` warn when you r
On Tue, Sep 8, 2020 at 7:36 PM Borislav Petkov wrote:
>
> On Tue, Sep 08, 2020 at 07:29:11PM +0200, Jason A. Donenfeld wrote:
> > Well that's not cool.
>
> So you're saying that if someone wants to kill its box by poking at that
> MSR, we should just let her/him?
>
> If anything, I think that a BI
On Tue, Sep 08, 2020 at 07:29:11PM +0200, Jason A. Donenfeld wrote:
> Well that's not cool.
So you're saying that if someone wants to kill its box by poking at that
MSR, we should just let her/him?
If anything, I think that a BIG FAT WARNING at least would make sense.
Now, if there were a proper
On Tue, Sep 08, 2020 at 10:10:17AM -0700, Srinivas Pandruvada wrote:
> > > - if (reg == MSR_IA32_ENERGY_PERF_BIAS)
> > > + switch (reg) {
> > > + case MSR_IA32_ENERGY_PERF_BIAS:
> There is already sysfs interface for it.
So someone needs to convert all those to it:
tools/power/cpupower/utils/help
On Tue, Sep 8, 2020 at 7:26 PM Borislav Petkov wrote:
>
> On Tue, Sep 08, 2020 at 07:12:44PM +0200, Jason A. Donenfeld wrote:
> > > Overclocking is not architectural I/F and is supported by some special
> > > CPU skews. I can't find any public document to specify the commands
> > > which can be us
On Tue, Sep 08, 2020 at 07:12:44PM +0200, Jason A. Donenfeld wrote:
> > Overclocking is not architectural I/F and is supported by some special
> > CPU skews. I can't find any public document to specify the commands
> > which can be used via this OC mailbox. I have to check internally to
> > see if
On Tue, Sep 8, 2020 at 7:10 PM Srinivas Pandruvada
wrote:
>
> On Mon, 2020-09-07 at 12:06 +0200, Borislav Petkov wrote:
> > + Srinivas.
> > + kitsunyan.
> >
> > On Mon, Sep 07, 2020 at 11:48:43AM +0200, Jason A. Donenfeld wrote:
> > > Popular tools, like intel-undervolt, use MSR 0x150 to control t
On Mon, 2020-09-07 at 12:06 +0200, Borislav Petkov wrote:
> + Srinivas.
> + kitsunyan.
>
> On Mon, Sep 07, 2020 at 11:48:43AM +0200, Jason A. Donenfeld wrote:
> > Popular tools, like intel-undervolt, use MSR 0x150 to control the
> > CPU
> > voltage offset. In fact, evidently the intel_turbo_max_3
On Mon, Sep 7, 2020 at 1:11 PM Borislav Petkov 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
On Mon, Sep 07, 2020 at 01:15:14PM +0200, Jason A. Donenfeld wrote:
> 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
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
Hi Borislav,
On Mon, Sep 7, 2020 at 12:06 PM Borislav Petkov wrote:
>
> + Srinivas.
> + kitsunyan.
>
> On Mon, Sep 07, 2020 at 11:48:43AM +0200, Jason A. Donenfeld wrote:
> > Popular tools, like intel-undervolt, use MSR 0x150 to control the CPU
> > voltage offset. In fact, evidently the intel_tu
+ Srinivas.
+ kitsunyan.
On Mon, Sep 07, 2020 at 11:48:43AM +0200, Jason A. Donenfeld wrote:
> Popular tools, like intel-undervolt, use MSR 0x150 to control the CPU
> voltage offset. In fact, evidently the intel_turbo_max_3 driver in-tree
> also uses this MSR. So, teach the kernel's MSR list about
Popular tools, like intel-undervolt, use MSR 0x150 to control the CPU
voltage offset. In fact, evidently the intel_turbo_max_3 driver in-tree
also uses this MSR. So, teach the kernel's MSR list about this, so that
intel-undervolt and other such tools don't spew warnings to dmesg, while
unifying the
30 matches
Mail list logo
