[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210203120037.GA13819@zn.tnic>
Date: Wed, 3 Feb 2021 13:00:37 +0100
From: Borislav Petkov <bp@...en8.de>
To: Tom Lendacky <thomas.lendacky@....com>
Cc: Andy Lutomirski <luto@...capital.net>,
Masami Hiramatsu <mhiramat@...nel.org>,
X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 00/19] x86/insn: Add an insn_decode() API
On Sun, Dec 27, 2020 at 09:26:04AM -0600, Tom Lendacky wrote:
> > We could also say that probably there should be a way to say "decode
> > only the first insn in the buffer and ignore the rest". That is all up
> > to the use cases so I'm looking for suggestions here.
>
> That's the way it works today, right? One instruction, no matter the length
> of the buffer (assuming the length is long enough to include a full
> instruction)?
>
> Because the callers of the decode may rely on parsing only the current
> instruction (like SEV-ES), it should probably default to that (although most
> of the call points are being updated so you could supply a boolean to
> indicate one vs many instructions). The caller doesn't necessarily know the
> length of the instruction, so it may provide a buffer of max instruction
> length.
>
> Also, if you want to parse more than one instruction at a time, wouldn't you
> need to maintain register context within the parsing, I don't think that is
> done today. Or you could chain together some instruction contexts to
> identify each instruction that was parsed?
Yah, let's leave it all to the one who actually needs multiple insn
parsing.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists