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.
