On Thu, Apr 22, 2021 at 9:14 PM Aaron Lewis <aaronlewis@xxxxxxxxxx> wrote: > > On Thu, Apr 22, 2021 at 5:57 AM Jim Mattson <jmattson@xxxxxxxxxx> wrote: > > > > On Wed, Apr 21, 2021 at 5:28 AM Aaron Lewis <aaronlewis@xxxxxxxxxx> wrote: > > > > > > Add a fallback mechanism to the in-kernel instruction emulator that > > > allows userspace the opportunity to process an instruction the emulator > > > was unable to. When the in-kernel instruction emulator fails to process > > > an instruction it will either inject a #UD into the guest or exit to > > > userspace with exit reason KVM_INTERNAL_ERROR. This is because it does > > > not know how to proceed in an appropriate manner. This feature lets > > > userspace get involved to see if it can figure out a better path > > > forward. > > > > > > Signed-off-by: Aaron Lewis <aaronlewis@xxxxxxxxxx> > > > > The instruction bytes are a good start, but in many cases, they aren't > > sufficient context to decode the next instruction. Should we eagerly > > provide that information in this exit, or should we just let userspace > > gather it via subsequent ioctls if necessary? > > Why is there a concern for the next instruction? This patch is about > userspace helping with the current instruction being emulated. I'm > not sure why we would be concerned about the next one. Sorry; I should have said, "The instruction bytes are a good start, but in many cases, they aren't sufficient context to decode *the* instruction." For example, suppose the first byte is 0x48. Without more context, we don't know if this is a DEC or a REX prefix.
