Messages in this thread | | | Date | Sat, 5 Feb 2022 00:35:57 +0300 | From | "Kirill A. Shutemov" <> | Subject | Re: [PATCHv2 28/29] x86/tdx: Warn about unexpected WBINVD |
| |
On Wed, Feb 02, 2022 at 02:46:17AM +0100, Thomas Gleixner wrote: > On Mon, Jan 24 2022 at 18:02, Kirill A. Shutemov wrote: > > > WBINVD causes #VE in TDX guests. There's no reliable way to emulate it. > > The kernel can ask for VMM assistance, but VMM is untrusted and can ignore > > the request. > > > > Fortunately, there is no use case for WBINVD inside TDX guests. > > If there is not usecase, then why > > > Warn about any unexpected WBINVD. > > instead of terminating the whole thing? > > I'm tired of the "let us emit a warning in the hope it gets fixed' > thinking.
I probably misunderstood what you meant in the previous WBINVD thread[1] by:
Then you have the #VE handler which just acts on any other wbinvd invocation via warn, panic, whatever, no?
I went the warn path because I think it is consistent with BUG() vs. WARN() policy: "Use WARN() and WARN_ON() instead, and handle the "impossible" error condition as gracefully as possible."[2]
IMO, ignored WBINVD has less chance to lead user data loss than panic().
Anyway, I'm okay dropping the patch. It will bring us to "terminate whole thing" solution. I just wanted to explain why the patch is present in the series.
[1] https://lore.kernel.org/all/87lf126010.ffs@tglx/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/deprecated.rst
-- Kirill A. Shutemov
| |