[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SA1PR11MB6734C0AE97E8B5ACF70CA32AA8959@SA1PR11MB6734.namprd11.prod.outlook.com>
Date: Mon, 10 Apr 2023 19:14:21 +0000
From: "Li, Xin3" <xin3.li@...el.com>
To: "Hansen, Dave" <dave.hansen@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>
CC: "tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...hat.com" <mingo@...hat.com>,
"bp@...en8.de" <bp@...en8.de>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"hpa@...or.com" <hpa@...or.com>,
"peterz@...radead.org" <peterz@...radead.org>,
"andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
"Christopherson,, Sean" <seanjc@...gle.com>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"Shankar, Ravi V" <ravi.v.shankar@...el.com>,
"jiangshanlai@...il.com" <jiangshanlai@...il.com>,
"Kang, Shan" <shan.kang@...el.com>,
"Lutomirski, Andy" <luto@...nel.org>
Subject: RE: [PATCH v8 00/33] x86: enable FRED for x86-64
> 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.
We do have some comments in the commit messages or around the code changes.
However a high level document in the Documentation/x86/ directory probably
works better, I can do that.
>
> 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.
Because FRED code majorly replaces the IDT entry/dispatch/return code, and
makes few changes to the event handlers, our focus was more of to check if
all the event handlers are properly called and returned, which is very well
covered by the existing IDT selftests.
One area we need to add selftests to is the FRED event dispatch framework, to
make sure we cover all the possible dispatch paths.
> 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)
I really appreciate it!
Thanks!
Xin
Powered by blists - more mailing lists