Re: [Qemu-devel] [PATCH 4/7] target-i386: Dump illegal opcodes with -d unimp

[Paolo Bonzini <pbonzini@redhat.com>]

On 03/03/2016 20:06, Richard Henderson wrote:
> On 03/03/2016 02:08 AM, Paolo Bonzini wrote:
>>> Do you want LOG_UNIMP or LOG_GUEST_ERROR?
>>
>> I would actually use LOG_IN_ASM.  As you noticed, guests sometimes use
>> illegal opcodes; another example is Xen's hypercall interface.
>>
>> On 03/03/2016 07:57, Hervé Poussineau wrote:
>>> This patch is not quiet on some operating systems:
>>> OS/2:
>>> ILLOPC: 000172e1: 0f a6
>>>
>>> Windows XP:
>>> ILLOPC: 00020d1a: c4 c4
>>>
>>> And very verbose in Windows 3.11, Windows 9x:
>>> ILLOPC: 000ffb17: 63
>>> ILLOPC: 000ffb17: 63
>>>
>>> Is it normal?
>>
>> Yes, it is.  As usual, Raymond Chen explains what's going on:
>>
>> https://blogs.msdn.microsoft.com/oldnewthing/20041215-00/?p=37003
> 
> Wow.  That's... interesting.

It's actually even more interesting (the explanation is in the book) if
you notice that 0xffb17 is in the middle of the BIOS.  Indeed Windows 95
first locates a single 0x63 in the BIOS (so that it's ROM and no one can
write a different byte).  Then the 32-bit code can use a system service
that allocates a callback from 16-bit MS-DOS.  That service gets a
32-bit address for the 32-bit code and returns a real-mode address to be
used in 16-bit code.

The kick is that all the real-mode addresses point to that single 0x63
that was found in ROM.  For example in the case above the real-mode
addresses could be FFB1:07, FFB0:17, FFAF:27, etc.  The illegal opcode
exception handler looks at the segment to figure out which 32-bit
address to jump to.

There are also cases where the ARPL is patched into existing code (like
a breakpoint) to trap that code to 32-bit.  But this one using the ROM
is much cooler.

Paolo