On 2/12/22 6:42 PM, Marc Orr wrote: > On Wed, Feb 9, 2022 at 8:44 AM Varad Gautam <varad.gautam@xxxxxxxx> wrote: >> >> Processing #VC exceptions on AMD SEV-ES requires instruction decoding >> logic to set up the right GHCB state before exiting to the host. >> >> Pull in the instruction decoder from Linux for this purpose. >> >> Origin: Linux 64222515138e43da1fcf288f0289ef1020427b87 >> >> Signed-off-by: Varad Gautam <varad.gautam@xxxxxxxx> >> --- >> lib/x86/insn/inat-tables.c | 1566 ++++++++++++++++++++++++++++++++++++ >> lib/x86/insn/inat.c | 86 ++ >> lib/x86/insn/inat.h | 233 ++++++ >> lib/x86/insn/inat_types.h | 18 + >> lib/x86/insn/insn.c | 778 ++++++++++++++++++ >> lib/x86/insn/insn.h | 280 +++++++ >> x86/Makefile.common | 2 + >> 7 files changed, 2963 insertions(+) >> create mode 100644 lib/x86/insn/inat-tables.c > > In Linux, this file is generated. Why not take the scripts to generate > it -- rather than the generated file? > Sounds better, I will generate it in v3. >> create mode 100644 lib/x86/insn/inat.c >> create mode 100644 lib/x86/insn/inat.h >> create mode 100644 lib/x86/insn/inat_types.h >> create mode 100644 lib/x86/insn/insn.c >> create mode 100644 lib/x86/insn/insn.h > > I diffed all of these files against their counterparts in Linus' tree > at SHA1 64222515138e. I saw differences for insn.c and insn.h. Is that > intended? > The diff is because I needed to fixup some of the insn decoder code to build here (eg, include paths, unavailable definitions). But I see how that would lead to confusion whenever these files need an update, and it's better to minimize the diff. I'll go with taking the insn decoder code as-is from Linux, and try keeping the requirements into an additional .h that glues the decoder to KUT. > Also, should we add a README to this directory to explain that the > code was obtained from upstream, how this was done, and when/how to > update it? > Makes sense.
