[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f3b12e7a-3536-c0af-2c67-d94c56b6fcc5@intel.com>
Date: Mon, 10 Apr 2023 11:37:19 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Xin Li <xin3.li@...el.com>, linux-kernel@...r.kernel.org,
x86@...nel.org, kvm@...r.kernel.org
Cc: tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
dave.hansen@...ux.intel.com, hpa@...or.com, peterz@...radead.org,
andrew.cooper3@...rix.com, seanjc@...gle.com, pbonzini@...hat.com,
ravi.v.shankar@...el.com, jiangshanlai@...il.com,
shan.kang@...el.com, Andy Lutomirski <luto@...nel.org>
Subject: Re: [PATCH v8 00/33] x86: enable FRED for x86-64
On 4/10/23 01:14, Xin Li wrote:
> This patch set enables FRED for x86-64.
I'm worried we're just in a patchbomb-once-a-week mode with FRED at this
point. There wasn't a single comment on v7 so, of course, here's v8 a
week later.
FRED is a rare CPU feature because it's universally wanted. Us software
folks have been begging for it for a looooooooong time. Is there anyone
out there that has any doubts that the kernel will support (this) FRED
eventually?
The code also looks pretty reasonable.
I do think it's missing some Documentation, and the cover letter is bit
sparse. It would be nice to see some high-level information about
things like, for instance, why there needs to be FRED refactoring for
NMI/#PF/#DB/#MC specifically, but not other exceptions.
There also aren't any new selftests. I faintly recall some tweak to the
selftests recently that was FRED-oriented, but I'd still expect all the
selftests that poke at the entry code to be perturbed by this a bit.
Basically, if anyone else has been procrastinating on reviewing this
set, now is probably the time to dig in. (I'll include myself in that
category, btw)
Powered by blists - more mailing lists