From: Thomas Gleixner <tglx@linutronix.de>
To: speck@linutronix.de
Subject: Re: [PATCH 1/1] SMTDOCv2 0
Date: Sun, 8 Jul 2018 12:19:59 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.21.1807081210240.1589@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20180708034511.GL25550@tassilo.jf.intel.com>
On Sat, 7 Jul 2018, speck for Andi Kleen wrote:
> On Sat, Jul 07, 2018 at 11:39:02AM +0200, speck for Thomas Gleixner wrote:
> > On some? L1TF affects every fricking Intel CPU with EPT except a few ATOMs.
>
> Think what will the state be when someone reads this in two years.
It's not rocket science to spell it out in a way which is still valid in
two years.
> > > +arbitrary data in the L1D cache of the CPU core in the guest, potentially allowing
> > > +to read data from outside the VM.
> >
> > This really wants to be explained so that the admin who is supposed to read
> > that understands the mechanims at least at the high level. That
> > 'may/potentially' weasel wording is not at all helpful to make decisions
> > about the mitigations.
>
> There will be an Intel white paper with details, we can point to that later.
> I don't think going into micro architectural details here will
> help any admin.
It's not about micro architectural details, but there needs to be some high
level explanation so the administrator can make a judgement about the
different mitigation methods.
> > Fails? How should someone who is not familiar with the deep details of that
> > decided that the above fails?
>
> It's a list of actions all with preconditions. For each it is clear
> if you can or cannot do the action.
Oh well..
> > > +SMT improves performance so it should be only disabled when absolutely
> >
> > SMT improves performance depending on the workload. There are workloads
> > which are negatively impacted by SMT.
> >
> > That said, this all wants to be properly structured and explained in
> > detail. A hastily cobbled together string of syllables does not make a
> > document which is intended to provide guidance to people who do not have a
> > deep technical insight into this.
>
> We can perhaps expand some things slightly.
>
> But I doubt any admin is interested in reading a novel on this here. I
> certainly wouldn't be. There will be plenty of other material elsewhere for
> people who want all the gory details.
Nobody asks you to write a novel. But a consice documentation is surely
due. Aside of that it does not matter how much other material will be
available. This is about documentation the kernel provides and I consider
it bad practice to throw a few bones into a text file just to claim that we
have documentation. You might be content with that scrap paper, but most
people prefer and appreciate proper written documentation.
Thanks,
tglx
prev parent reply other threads:[~2018-07-08 10:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-06 22:24 [MODERATED] [PATCH 1/1] SMTDOCv2 0 Andi Kleen
2018-07-07 9:39 ` Thomas Gleixner
2018-07-08 3:45 ` [MODERATED] " Andi Kleen
2018-07-08 10:19 ` Thomas Gleixner [this message]
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=alpine.DEB.2.21.1807081210240.1589@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=speck@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).