All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: Intended behavior/usage of SSBD setting
Date: Thu, 20 Oct 2022 13:01:39 +0200	[thread overview]
Message-ID: <Y1Eqk6D0dBDR4m4u@Air-de-Roger> (raw)

Hello,

As part of some follow up improvements to my VIRT_SPEC_CTRL series we
have been discussing what the usage of SSBD should be for the
hypervisor itself.  There's currently a `spec-ctrl=ssbd` option [0],
that has an out of date description, as now SSBD is always offered to
guests on AMD hardware, either using SPEC_CTRL or VIRT_SPEC_CTRL.

It has been pointed out by Andrew that toggling SSBD on AMD using
VIRT_SPEC_CTRL or the non-architectural way (MSR_AMD64_LS_CFG) can
have a high impact on performance, and hence switching it on every
guest <-> hypervisor context switch is likely a very high
performance penalty.

It's been suggested that it could be more appropriate to run Xen with
the guest SSBD selection on those systems, however that clashes with
the current intent of the `spec-ctrl=ssbd` option.

I hope I have captured the expressed opinions correctly in the text
above.

I see two ways to solve this:

 * Keep the current logic for switching SSBD on guest <-> hypervisor
   context switch, but only use it if `spec-ctrl=ssbd` is set on the
   command line.

 * Remove the logic for switching SSBD on guest <-> hypervisor context
   switch, ignore setting of `spec-ctrl=ssbd` on those systems and run
   hypervisor code with the guest selection of SSBD.

Which has raised me the question of whether there's an use case
for always running hypervisor code with SSBD enabled, or that's no
longer relevant if we always offer guests a way for them to toggle the
setting when required.

I would like to settle on a way forward, so we can get this fixed
before 4.17.

Thanks, Roger.

[0] https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html#spec-ctrl-x86


             reply	other threads:[~2022-10-20 11:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-20 11:01 Roger Pau Monné [this message]
2022-10-20 11:22 ` Intended behavior/usage of SSBD setting Jan Beulich
2022-10-20 12:37   ` Roger Pau Monné
2022-10-20 13:25     ` Jan Beulich
2022-10-20 13:56       ` Roger Pau Monné
2022-10-21 21:54 ` Andrew Cooper
2022-10-24  6:45   ` Jan Beulich
2022-10-24  9:32     ` Roger Pau Monné
2022-10-24 10:40       ` Jan Beulich

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=Y1Eqk6D0dBDR4m4u@Air-de-Roger \
    --to=roger.pau@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=xen-devel@lists.xenproject.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.