mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "George Spelvin" <linux@horizon.com>
To: bp@alien8.de, mcfadden8@llnl.gov
Cc: a.p.zijlstra@chello.nl, acme@infradead.org, ak@linux.intel.com,
	andriy.shevchenko@linux.intel.com, brgerst@gmail.com,
	dan.j.williams@intel.com, dyoung@redhat.com, hpa@zytor.com,
	jolsa@redhat.com, linux-kernel@vger.kernel.org,
	linux@horizon.com, luto@kernel.org, mingo@kernel.org,
	mingo@redhat.com, pavel@ucw.cz, tglx@linutronix.de,
	viro@zeniv.linux.org.uk, x86@kernel.org, yu.c.chen@intel.com
Subject: Re: [PATCH 0/4] MSR: MSR: MSR Whitelist and Batch Introduction
Date: 29 Feb 2016 12:53:18 -0500	[thread overview]
Message-ID: <20160229175318.14183.qmail@ns.horizon.com> (raw)
In-Reply-To: <20160229145859.GA3724@pd.tnic>

Borislav Petkov <bp@alien8.de> wrote:
> What should be done, instead, is implement all functionality you need in
> the respective drivers with proper error and input sanity-checking done
> by the OS. Also, OS has other agents poking at them so it should be the
> arbiter controlling access and so on.
> 
> IMNSVHO.

I worry that this is this too ambitious a goal.  Who is volunteering
to actually do this?

It takes quite a while to find a good OS-level abstraction (remember
wakelocks?), and MSRs are the CPU architect's equivalent of ioctls.
So they're a bit of a mess, and there will keep being new ones.

I agree with you about anything that's going to see widespread use, but
for specialized (apparently mostly HPC) use where the application really
is heavily optimized for specific CPU models, perhaps dangerous-but-simple
is good enough?

The proposed interface is simple and imposes very little maintenance
burden on the kernel.  My main objection is that it's yet another
special-case permission system.  Are we *sure* we'll never want to have
to classes of users with different access rights?

  parent reply	other threads:[~2016-02-29 17:53 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-26  0:02 Marty McFadden
2016-02-26  0:02 ` [PATCH 1/4] MSR: Prep for separating msr.c into three files Marty McFadden
2016-02-26  2:56   ` kbuild test robot
2016-02-26 10:08   ` Andy Shevchenko
2016-02-26  0:02 ` [PATCH 2/4] " Marty McFadden
2016-02-26  0:02 ` [PATCH 3/4] MSR: msr Whitelist Implementation Marty McFadden
2016-02-26  1:05   ` [PATCH] MSR: fix badzero.cocci warnings kbuild test robot
2016-02-26  1:05   ` [PATCH 3/4] MSR: msr Whitelist Implementation kbuild test robot
2016-02-26  0:02 ` [PATCH 4/4] MSR: msr Batch processing feature Marty McFadden
2016-02-26  2:48   ` Andy Lutomirski
2016-03-03 17:21   ` One Thousand Gnomes
2016-03-03 23:09     ` Mcfadden, Marty Jay
2016-02-26  7:37 ` [PATCH 0/4] MSR: MSR: MSR Whitelist and Batch Introduction Ingo Molnar
2016-02-28 18:54   ` Mcfadden, Marty Jay
2016-02-28 19:01     ` Borislav Petkov
2016-02-29  2:55       ` Mcfadden, Marty Jay
2016-02-29 14:58         ` Borislav Petkov
2016-02-29 16:31           ` Henrique de Moraes Holschuh
2016-02-29 17:22             ` Borislav Petkov
2016-02-29 17:53           ` George Spelvin [this message]
2016-02-29 18:20             ` Borislav Petkov
2016-02-29 22:35               ` Mcfadden, Marty Jay
2016-02-29 23:41                 ` Borislav Petkov
2016-03-01 19:01                   ` Rountree, Barry L.
2016-03-03  0:40                     ` Andy Lutomirski
2016-03-01  8:02                 ` Thomas Gleixner
2016-03-01 18:29                   ` Rountree, Barry L.
2016-03-01 18:38                     ` Borislav Petkov
2016-02-29 17:17         ` Andy Lutomirski

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=20160229175318.14183.qmail@ns.horizon.com \
    --to=linux@horizon.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@infradead.org \
    --cc=ak@linux.intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=dan.j.williams@intel.com \
    --cc=dyoung@redhat.com \
    --cc=hpa@zytor.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mcfadden8@llnl.gov \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=pavel@ucw.cz \
    --cc=tglx@linutronix.de \
    --cc=viro@zeniv.linux.org.uk \
    --cc=x86@kernel.org \
    --cc=yu.c.chen@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®