From: Borislav Petkov <bp@suse.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: x86-ml <x86@kernel.org>, lkml <linux-kernel@vger.kernel.org>,
Andi Kleen <ak@linux.intel.com>,
Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@linux.intel.com>,
Tony Luck <tony.luck@intel.com>
Subject: Re: [GIT PULL] x86/cpu for v5.17
Date: Mon, 10 Jan 2022 19:35:41 +0100 [thread overview]
Message-ID: <Ydx8fUCotPI++UEW@zn.tnic> (raw)
In-Reply-To: <CAHk-=wh+UbGrgH4CzKSoTYGPidyv5isiLMxJKAqnV3NFTiRdaQ@mail.gmail.com>
CCing the folks who were involved in this one...
On Mon, Jan 10, 2022 at 10:18:06AM -0800, Linus Torvalds wrote:
> On Mon, Jan 10, 2022 at 3:16 AM Borislav Petkov <bp@suse.de> wrote:
> >
> > - Avoid writing MSR_CSTAR on Intel due to TDX guests raising a #VE trap
>
> This is all fine, but my reaction to this is that I would have
> expected it to be either a wrmsrl_safe(), or using an actual CPU
> feature check.
>
> Checking for a particular vendor seems a bit hacky. We generally try
> to avoid things like that, don't we?
>
> Not a big deal, I just thought I'd mention it since I reacted to it.
> And we don't seem to have those vendor checks in any of the other code
> that uses MSR_CSTAR (just grepping for that and seeing it mentioned in
> kvm code etc)
Right, the only point for doing the vendor check I see here is, well,
because it is Intel who doesn't have CSTAR, let's check for Intel. But
yeah, we do avoid the vendor checks if it can be helped.
We can do a synthetic X86_FEATURE flag but that would be a waste. So the
_safe thing and keep the comment sounds optimal to me.
I can whip up a patch ontop if people agree.
Thx.
--
Regards/Gruss,
Boris.
SUSE Software Solutions Germany GmbH, GF: Ivo Totev, HRB 36809, AG Nürnberg
next prev parent reply other threads:[~2022-01-10 18:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-10 11:16 [GIT PULL] x86/cpu for v5.17 Borislav Petkov
2022-01-10 18:18 ` Linus Torvalds
2022-01-10 18:35 ` Borislav Petkov [this message]
2022-01-10 19:32 ` Linus Torvalds
2022-01-10 20:10 ` Dave Hansen
2022-01-10 20:15 ` Linus Torvalds
2022-01-11 22:48 ` Sean Christopherson
2022-01-10 18:27 ` pr-tracker-bot
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=Ydx8fUCotPI++UEW@zn.tnic \
--to=bp@suse.de \
--cc=ak@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=tony.luck@intel.com \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.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.