Re: [kvm-unit-tests PATCH v3 3/4] x86/access: Forced emulation support

[Sean Christopherson <seanjc@google.com>]

On Mon, Apr 03, 2023, Mathias Krause wrote:
> On 03.04.23 12:56, Mathias Krause wrote:
> > Add support to enforce access tests to be handled by the emulator, if
> > supported by KVM. Exclude it from the ac_test_exec() test, though, to
> > not slow it down too much.
> 
> I tend to read a lot of objdumps and when initially looking at the
> generated code it was kinda hard to recognize the FEP instruction, as
> the FEP actually decodes to UD2 followed by some IMUL instruction that
> lacks a byte, so when objdump does its linear disassembly, it eats a
> byte from the to-be-emulated instruction. Like, "FEP; int $0xc3" would
> decode to:
>    0:	0f 0b                	ud2
>    2:	6b 76 6d cd          	imul   $0xffffffcd,0x6d(%rsi),%esi
>    6:	c3                   	retq
> This is slightly confusing, especially when the shortened instruction is
> actually a valid one as above ("retq" vs "int $0xc3").
> 
> I have the below diff to "fix" that. It adds 0x3e to the FEP which would
> restore objdump's ability to generate a proper disassembly that won't
> destroy the to-be-emulated instruction. As 0x3e decodes to the DS prefix
> byte, which the emulator assumes by default anyways, this should mostly
> be a no-op. However, it helped me to get a proper code dump.a

I agree that the objdump output is annoying, but I don't love the idea of cramming
in a prefix that's _mostly_ a nop.

Given that FEP utilizes extremely specialized, off-by-default KVM code, what about
reworking FEP in KVM itself to play nice with objdump (and other disasm tools)?
E.g. "officially" change the magic prefix to include a trailing 0x3e.  Though IMO,
even better would be a magic value that decodes to a multi-byte nop, e.g.
0F 1F 44 00 00.  The only "requirement" is that the magic value doesn't get
false positives, and I can't imagine any of our test environments generate a ud2
followed by a multi-byte nop.

Keeping KVM-Unit-Tests and KVM synchronized on the correct FEP value would be a
pain, but disconnects between KVM and KUT are nothing new.