From: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
<xen-devel@lists.xenproject.org>
Cc: "Oleksii Kurochko" <oleksii.kurochko@gmail.com>,
"Community Manager" <community.manager@xenproject.org>,
"Jan Beulich" <jbeulich@suse.com>,
"Roger Pau Monné" <roger.pau@citrix.com>,
"Jason Andryuk" <jason.andryuk@amd.com>
Subject: Re: [PATCH 0/4] x86: Drop cross-vendor support
Date: Fri, 23 Jan 2026 12:39:49 +0100 [thread overview]
Message-ID: <DFVXUPXYSEX5.3KQXARYRRCKZP@amd.com> (raw)
In-Reply-To: <6d41d205-7318-45e4-a487-5e35e398d96a@citrix.com>
On Thu Jan 22, 2026 at 7:19 PM CET, Andrew Cooper wrote:
> On 22/01/2026 5:42 pm, Alejandro Vallejo wrote:
>> On Thu Jan 22, 2026 at 6:10 PM CET, Andrew Cooper wrote:
>>> On 22/01/2026 4:49 pm, Alejandro Vallejo wrote:
>>>> Open question unrelated to the series: Does it make sense to conditionalise the
>>>> MSR handlers for non intercepted MSRs on HVM_FEP?
>>> I'm not quite sure what you're asking here.
>>>
>>> ~Andrew
>> The handlers for LSTAR and the like are dead code with !CONFIG_HVM_FEP as far
>> as I can tell. The question I'm asking is whether there is another code path
>> that might invoke MSR handlers for non-intercepted MSRs. I can't see it, but
>> I'm not sure.
>>
>> If there isn't I'm considering (conditionally) getting rid of them.
>
> Introspection can (and HVMI does) hook them. Changes to LSTAR during
> runtime is usually an exploit in progress.
>
> Nested virt also makes it far more complicated to reason about
> "intercepted or not", given that there are multiple opinions merged
> together.
>
> ~Andrew
nSVM definitely would trigger those, ta.
Conditionally removing nSVM is in our roadmap, and VMI is already gated on
ALTP2M. I'll put this on the pile somewhere.
Cheers,
Alejandro
prev parent reply other threads:[~2026-01-23 11:40 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-22 16:49 [PATCH 0/4] x86: Drop cross-vendor support Alejandro Vallejo
2026-01-22 16:49 ` [PATCH 1/4] x86: Reject CPU policies with vendors other than the host's Alejandro Vallejo
2026-01-22 17:13 ` Teddy Astie
2026-01-23 11:30 ` Alejandro Vallejo
2026-01-23 16:29 ` Andrew Cooper
2026-01-22 16:49 ` [PATCH 2/4] x86/hvm: Disable non-FEP cross-vendor handling in #UD handler Alejandro Vallejo
2026-01-22 17:28 ` Teddy Astie
2026-01-23 12:28 ` Alejandro Vallejo
2026-01-23 18:40 ` Andrew Cooper
2026-01-26 11:58 ` Alejandro Vallejo
2026-01-28 12:38 ` Alejandro Vallejo
2026-01-22 16:49 ` [PATCH 3/4] x86/hvm: Remove cross-vendor checks from MSR handlers Alejandro Vallejo
2026-01-22 17:34 ` Teddy Astie
2026-01-23 18:35 ` Andrew Cooper
2026-01-26 8:40 ` Jan Beulich
2026-01-26 11:32 ` Alejandro Vallejo
2026-01-22 16:49 ` [PATCH 4/4] x86/svm: Drop emulation of Intel's SYSENTER behaviour Alejandro Vallejo
2026-01-22 17:52 ` Teddy Astie
2026-01-23 12:31 ` Alejandro Vallejo
2026-01-23 18:08 ` Andrew Cooper
2026-01-22 17:10 ` [PATCH 0/4] x86: Drop cross-vendor support Andrew Cooper
2026-01-22 17:42 ` Alejandro Vallejo
2026-01-22 18:16 ` Teddy Astie
2026-01-23 12:10 ` Alejandro Vallejo
2026-01-23 14:05 ` Jan Beulich
2026-01-23 15:45 ` Alejandro Vallejo
2026-01-23 18:25 ` Andrew Cooper
2026-01-22 18:19 ` Andrew Cooper
2026-01-23 11:39 ` Alejandro Vallejo [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=DFVXUPXYSEX5.3KQXARYRRCKZP@amd.com \
--to=alejandro.garciavallejo@amd.com \
--cc=andrew.cooper3@citrix.com \
--cc=community.manager@xenproject.org \
--cc=jason.andryuk@amd.com \
--cc=jbeulich@suse.com \
--cc=oleksii.kurochko@gmail.com \
--cc=roger.pau@citrix.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.