All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>,
	Paolo Bonzini <pbonzini@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Amy Wiles <amy.l.wiles@intel.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	jacob.jun.pan@linux.intel.com
Subject: Re: [PATCH] x86/rapl: Do not load in a guest
Date: Fri, 4 Dec 2015 09:46:42 -0800	[thread overview]
Message-ID: <20151204094642.4c5e63e0@icelake> (raw)
In-Reply-To: <20151204115335.GB15308@gmail.com>

On Fri, 4 Dec 2015 12:53:35 +0100
Ingo Molnar <mingo@kernel.org> wrote:

> 
> * Borislav Petkov <bp@alien8.de> wrote:
> 
> > On Fri, Dec 04, 2015 at 11:41:03AM +0100, Paolo Bonzini wrote:
> > > No, please don't.  Why do you need a wrmsr instead of a rdmsr?  If
> > > there's no RAPL domains, the device doesn't load.  On hypervisors,
> > > reading random MSRs is generally safe.
> > 
> > Well, we could not do anything, sure, that's an option too. It would
> > only be the annoying error message. Which is
> > 
> > 	pr_err("no valid rapl domains found in package %d\n",
> > rp->id);
> > 
> > I guess we can tone that down as apparently it is not an error to
> > not have valid rapl domains anymore. Maybe kill it altogether:
> > rapl_detect_topology() will propagate the error and the driver won't
> > load...
> 
Since RAPL is not architectural, consistency of hw support needs lots
of improvement at the least. This error message is valid in other than
VM. Domain detection error already propagated.

> So given than nothing really tells us in a clear way whether RAPL is
> supported or not on that kernel, it might be better to just
> centralize the 'detect RAPL' function, and print "x86/rapl: Feature
> detected" on bootup. That function can also install a synthetic CPUID
> bit, which all other code could use in a clean fashion.
> 
> Since it will be an __init function, there's not much of an overhead
> argument against it.
> 
This is good for the first level RAPL detection. The only way is to
base detection on known CPU models.

But I still think hypervisor check is sufficient. I don't there will
ever be a use case for VM to control platform level power. A disaster
for sure.

> This way it becomes part of the CPUID infrastructure - and eventually
> it might even grow a real CPUID bit in future CPU models.
> 
> and we'll have a lot less RAPL detection muck all around. Win-win.
> 
True, RAPL is not architectural today but it is supported by all Intel
CPUs since SNB.
> Thanks,
> 
> 	Ingo

  reply	other threads:[~2015-12-04 17:47 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-03 18:27 [PATCH] x86/rapl: Do not load in a guest Borislav Petkov
2015-12-03 18:38 ` Jacob Pan
2015-12-03 18:42   ` Borislav Petkov
2015-12-03 18:59     ` Jacob Pan
2015-12-03 23:32       ` Rafael J. Wysocki
2015-12-03 23:25         ` Borislav Petkov
2015-12-04  1:00           ` Rafael J. Wysocki
2015-12-04  7:42 ` Ingo Molnar
2015-12-04  8:22   ` Peter Zijlstra
2015-12-04  8:28     ` Ingo Molnar
2015-12-04 10:19       ` Borislav Petkov
2015-12-04 10:41         ` Paolo Bonzini
2015-12-04 10:56           ` Borislav Petkov
2015-12-04 11:53             ` Ingo Molnar
2015-12-04 17:46               ` Jacob Pan [this message]
2015-12-04 17:52                 ` Paolo Bonzini
2015-12-04 18:04                 ` Borislav Petkov
2015-12-04 18:16                   ` Jacob Pan
2015-12-04 18:28                     ` Borislav Petkov
2015-12-04 18:37                       ` Jacob Pan
2015-12-04 19:41                         ` Borislav Petkov
2015-12-04 17:51     ` Jacob Pan
2015-12-04 22:14       ` Peter Zijlstra
2015-12-04 22:39         ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151204094642.4c5e63e0@icelake \
    --to=jacob.jun.pan@linux.intel.com \
    --cc=acme@kernel.org \
    --cc=amy.l.wiles@intel.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.