[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Ydx8fUCotPI++UEW@zn.tnic>
Date: Mon, 10 Jan 2022 19:35:41 +0100
From: Borislav Petkov <bp@...e.de>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: x86-ml <x86@...nel.org>, lkml <linux-kernel@...r.kernel.org>,
Andi Kleen <ak@...ux.intel.com>,
Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
Tony Luck <tony.luck@...el.com>
Subject: Re: [GIT PULL] x86/cpu for v5.17
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@...e.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
Powered by blists - more mailing lists