All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
	"Jan Beulich" <jbeulich@suse.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>, "Wei Liu" <wl@xen.org>
Subject: Re: [PATCH v2 2/3] x86: Expose Automatic IBRS to guests
Date: Wed, 31 May 2023 13:38:56 +0100	[thread overview]
Message-ID: <3f009cf5-852a-abb8-814b-a63f05e37a16@citrix.com> (raw)
In-Reply-To: <64770ce3.050a0220.fb998.7ff6@mx.google.com>

On 31/05/2023 10:01 am, Alejandro Vallejo wrote:
> On Tue, May 30, 2023 at 06:31:03PM +0100, Andrew Cooper wrote:
>> I've committed this, but made two tweaks to the commit message.  First,
>> "x86/hvm" in the subject because it's important context at a glance.
> Sure, that makes sense.
>
>> Second, I've adjusted the bit about PV guests.  The reason why we can't
>> expose it yet is because Xen doesn't currently context switch EFER
>> between PV guests.
>>
>> ~Andrew
> We could of course context switch EFER sensibly, but what would that mean
> for Automatic IBRS? It can't be trivially used for domain-to-domain
> isolation because every domain is in a co-equal protection level. Is there
> a non-obvious edge that exposing some interface to it gives for PV? The
> only useful case I can think of is PVH, and that seems to be subsumed by
> HVM.

Hence why it's fine to not worry about PV for now.

Right now, when we decide to use IBRS on AMD, we set it unilaterally. 
This turns out to be better performance than flipping it on privilege
changes (whether that's non-Xen <-> Xen, or guest user <-> kernel).

PV guests are obscure corner cases these days, and fall outside of
anything the hardware vendors care about when it comes to prediction
mode.  The only sane option is to have Xen explicitly tell the the PV
guest what Xen is doing, and let the guest decide if it wants to do
anything further in terms of protections.

~Andrew


  reply	other threads:[~2023-05-31 12:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-30 13:58 [PATCH v2 0/3] Add Automatic IBRS support Alejandro Vallejo
2023-05-30 13:58 ` [PATCH v2 1/3] x86: Add bit definitions for Automatic IBRS Alejandro Vallejo
2023-05-30 17:29   ` Andrew Cooper
2023-05-31  8:42     ` Alejandro Vallejo
2023-05-30 13:58 ` [PATCH v2 2/3] x86: Expose Automatic IBRS to guests Alejandro Vallejo
2023-05-30 17:31   ` Andrew Cooper
2023-05-31  9:01     ` Alejandro Vallejo
2023-05-31 12:38       ` Andrew Cooper [this message]
2023-05-30 13:58 ` [PATCH v2 3/3] x86: Add support for AMD's Automatic IBRS Alejandro Vallejo
2023-06-01 10:35   ` Jan Beulich
2023-06-01 10:36     ` Andrew Cooper

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=3f009cf5-852a-abb8-814b-a63f05e37a16@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=alejandro.vallejo@cloud.com \
    --cc=jbeulich@suse.com \
    --cc=roger.pau@citrix.com \
    --cc=wl@xen.org \
    --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.