All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <jbeulich@suse.com>
Cc: "Roger Pau Monné" <roger.pau@citrix.com>,
	"Jason Andryuk" <jason.andryuk@amd.com>,
	"Xenia Ragiadakou" <xenia.ragiadakou@amd.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	xen-devel@lists.xenproject.org
Subject: Re: [RFC PATCH 09/11] x86: Migrate spec_ctrl vendor checks to x86_vendor_is()
Date: Thu, 11 Dec 2025 17:58:34 +0100	[thread overview]
Message-ID: <DEVJPCRTRA9Z.2JNMRFAN47BU8@amd.com> (raw)
In-Reply-To: <15659af8-4604-455a-b7de-91c4df213ab5@citrix.com>

On Thu Dec 11, 2025 at 4:38 PM CET, Andrew Cooper wrote:
> On 11/12/2025 10:31 am, Alejandro Vallejo wrote:
>> Seeing how both you and Andrew seem onboard with dropping cross-vendor support
>
> I found another cross-vendor dropping which you'll want to look into.
>
> struct svm_vcpu contains three guest_sysenter_* MSRs.
>
> In AMD CPUs, these MSRs only have 32 bits of storage, with the upper
> halfs write-discard.  They are switched via VMLOAD/VMSAVE.
>
> However, in the cross-vendor case, the upper halves are needed for 64bit
> kernels setting up SYSENTER support.  Therefore, they're unconditionally
> intercepted so we can avoid losing the upper half.
>
> By dropping cross-vendor support, we can get rid of these fields, allow
> the guest unconditional access, and simply the MSR intercept logic a little.
>
> ~Andrew

Sounds straightforward, I'll add it to the pile.

Cheers,
Alejandro


  reply	other threads:[~2025-12-11 16:59 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-26 16:44 [RFC PATCH 00/11] x86 vendor check optimisations Alejandro Vallejo
2025-11-26 16:44 ` [RFC PATCH 01/11] x86: Add more granularity to the vendors in Kconfig Alejandro Vallejo
2025-11-27  9:43   ` Jan Beulich
2025-11-27 12:36     ` Alejandro Vallejo
2025-11-27 13:19       ` Jan Beulich
2025-11-27 13:44         ` Alejandro Vallejo
2025-11-27 14:00           ` Jan Beulich
2025-11-27  9:59   ` Jan Beulich
2025-11-27 12:37     ` Alejandro Vallejo
2025-11-27 21:01   ` Andrew Cooper
2025-11-26 16:44 ` [RFC PATCH 02/11] x86: Reject CPU policies with vendors other than the host's Alejandro Vallejo
2025-11-27 20:15   ` Andrew Cooper
2025-11-26 16:44 ` [RFC PATCH 03/11] x86: Add x86_vendor_is() by itself before using it Alejandro Vallejo
2025-11-27 10:46   ` Jan Beulich
2025-11-27 13:15     ` Alejandro Vallejo
2025-11-27 13:37       ` Jan Beulich
2025-11-27 14:06         ` Alejandro Vallejo
2025-11-27 14:14           ` Jan Beulich
2025-11-27 20:36       ` Andrew Cooper
2025-11-28  9:08         ` Alejandro Vallejo
2025-11-26 16:44 ` [RFC PATCH 04/11] x86: Refactor early vendor lookup code to use x86_vendor_is() Alejandro Vallejo
2025-11-27 10:51   ` Jan Beulich
2025-11-27 13:35     ` Alejandro Vallejo
2025-11-26 16:44 ` [RFC PATCH 05/11] x86: Conditionalise the inclusion of Hygon/Centaur/Shanghai cpu/ files Alejandro Vallejo
2025-11-26 16:44 ` [RFC PATCH 06/11] x86: Migrate switch-based vendor checks to x86_vendor_is() Alejandro Vallejo
2025-11-26 16:44 ` [RFC PATCH 07/11] x86: Migrate MSR handler " Alejandro Vallejo
2025-11-26 16:44 ` [RFC PATCH 08/11] x86: Migrate insn emulator to use x86_vendor_is() Alejandro Vallejo
2025-11-26 16:44 ` [RFC PATCH 09/11] x86: Migrate spec_ctrl vendor checks to x86_vendor_is() Alejandro Vallejo
2025-12-08 16:01   ` Jan Beulich
2025-12-08 16:04   ` Jan Beulich
2025-12-11 10:31     ` Alejandro Vallejo
2025-12-11 15:38       ` Andrew Cooper
2025-12-11 16:58         ` Alejandro Vallejo [this message]
2025-11-26 16:44 ` [RFC PATCH 10/11] x86: Migrate everything under cpu/ to use x86_vendor_is() Alejandro Vallejo
2025-11-26 16:44 ` [RFC PATCH 11/11] x86: Migrate every remaining raw vendor check to x86_vendor_is() Alejandro Vallejo
2025-11-27 22:11 ` [RFC PATCH 00/11] x86 vendor check optimisations Andrew Cooper
2025-11-28  9:18   ` Alejandro Vallejo

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=DEVJPCRTRA9Z.2JNMRFAN47BU8@amd.com \
    --to=alejandro.garciavallejo@amd.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jason.andryuk@amd.com \
    --cc=jbeulich@suse.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    --cc=xenia.ragiadakou@amd.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 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.