All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kashyap Chamarthy <kchamart@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: pbonzini@redhat.com, qemu-devel@nongnu.org, ehabkost@redhat.com
Subject: Re: [PATCH] docs: qemu-cpu-models: Document '-noTSX' variants and 'mds-no'
Date: Tue, 21 Jan 2020 18:59:18 +0100	[thread overview]
Message-ID: <20200121175918.GD20791@paraplu> (raw)
In-Reply-To: <20200121164508.GB635404@redhat.com>

On Tue, Jan 21, 2020 at 04:45:08PM +0000, Daniel P. Berrangé wrote:
> On Thu, Jan 16, 2020 at 06:36:38PM +0100, Kashyap Chamarthy wrote:

[...]

> >  @table @option
> > +
> > +@item @code{Cascadelake-Server-noTSX}
> 
> Also needs
> 
>    @item @code{Cascadelake-Server}

Will add.

> > +
> > +Intell Xeon Processor (Cascade Lake, 2019-2020), with "stepping" levels
> 
> s/Intell/Intel/
> 
> s/-2020//  as we only need the initial year of introduction IMHO.

Will do.  (I wasn't sure, hence I put both years :-))

> > +6 or 7 only.  (The Cascade Lake Xeon processor with @b{stepping 5 is
> > +vulnerable to MDS variants}; refer below.)
> > +
> > +@code{/proc/cpuinfo}.
> > +
> > +The @code{mds-no} bit does not show up under @code{/proc/cpuinfo}.
> > +Rather it shows up under the @code{sysfs}, as
> > +@code{/sys/devices/system/cpu/vulnerabilities/mds:Not affected}
> 
> We already talk about this later on we I thin kwe can trim the
> /proc/cpinfo bit

True, will remove this redundancy.

[...]

> > +@item @code{mds-no}
> > +
> > +This is an MSR (Model-Specific Register) used by QEMU to indicate that
> > +the host is @i{not} vulnerable to any of the MDS variants ([MFBDS]
> > +CVE-2018-12130, [MLPDS] CVE-2018-12127, [MSBDS] CVE-2018-12126).
> > +
> > +Note that there are @i{three} versions of Intel's Cascade Lake
> > +processor, as distinguished by their "stepping" levels 5, 6, and 7.  The
> > +CPU with stepping "5" is @b{vulnerable to MDS variants}; and the CPUs
> > +with steppings "6" and "7" are @b{not vulnerable} to the above mentioned
> > +MDS variants.  The processor "stepping" is reported in
> > +@code{/proc/cpuinfo}.
> > +
> > +Confusingly, the @code{mds-no} bit does not show up under
> > +@code{/proc/cpuinfo} inside the guest.  Rather the kernel uses it to
> > +fill in the @code{sysfs}, as
> > +@code{/sys/devices/system/cpu/vulnerabilities/mds: Not affected},
> > +assuming the processor is running with stepping 6 or 7.
> 
> I think we can simplify this a little - we don't need to talk
> about CPU steppings - the user simply needs to know whether the
> sysfs file reports vulnerable or not.
> 
> So perhaps this text:
> 
>   Recommended to inform the guest OS that the host is @i{not]
>   vulnerable to any of the MDS variants ([MFBDS]
>   CVE-2018-12130, [MLPDS] CVE-2018-12127, [MSBDS] CVE-2018-12126).
> 
>   This is a MSR feature rather than a CPUID feature, so will not
>   appear in the Linux @code{/proc/cpuinfo} in the host or guest.
> 
>   It should only be enabled for VMs if the host reports
>   @code{Not affected} in the
>   @code{/sys/devices/system/cpu/vulnerabilities/mds} file.

Your phrasing is indeed simpler and more to-the-point; will incorporate
it.

I'll also add similar sections about the other two MSRs: 'taa-no' and
'tsx-ctrl' (as mentioned here:
https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg03685.html).

Thanks for the careful review.

-- 
/kashyap



      reply	other threads:[~2020-01-21 18:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-16 17:36 [PATCH] docs: qemu-cpu-models: Document '-noTSX' variants and 'mds-no' Kashyap Chamarthy
2020-01-17 13:22 ` Kashyap Chamarthy
2020-01-21 16:45 ` Daniel P. Berrangé
2020-01-21 17:59   ` Kashyap Chamarthy [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=20200121175918.GD20791@paraplu \
    --to=kchamart@redhat.com \
    --cc=berrange@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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.