Problem with SVGA VM86 Virtual PC

[lweb20]

I tested on all virtual machines (Bochs, qemu, VMWare, VirtualBox) and my real PC the next code and working correctly.

Code: Select all

mov ah, 0x4F
mov al, 0x0	; GET VBE INFO
mov di, VESA_INFO
int 0x10

I use this code for check VME (and work correctly on all virtual machines):

Code: Select all

CPUID_Regs regs;
cpuid_features(&regs);

unsigned int cr4 = getCR4();

if(TestBits(regs.EDX, CPUID_VME))
{
	cr4 = SetBits(cr4, CR4_VME);
}
else
{
	cr4 = ClearBits(cr4, CR4_VME);
}
	
setCR4(cr4);

I have a working VM86 monitor. But.. in Virtual PC (without support for VME) I get a GPF in instruction 0x66.

This is a dump:
CODE: 0x0000C800:0x000011EC
EFLAGS: 0x00030046 VM RF IOPL0
ERROR CODE: 0x00000000

Instruction: 0x66

Any ideas? This is very strange. Thanks in advance

[Combuster]

If you looked up the opcode 0x66, you'll see it's not enough to identify the cause of the GPF. It's not even an instruction.

[Nable]

AFAIR, 0x66 is not an instruction, (/me quickly looked into Opcode.txt guide) it's a data-size prefix. So at least you have to use some debugging tools to find the exact faulting instruction. Btw, Virtual PC is a pile of problematic software + VM86 is a dead way if you are planning x86_64 support. It may be better to let these things rest in peace.

[lweb20]

AFAIR, 0x66 is not an instruction, (/me quickly looked into Opcode.txt guide) it's a data-size prefix. So at least you have to use some debugging tools to find the exact faulting instruction. Btw, Virtual PC is a pile of problematic software + VM86 is a dead way if you are planning x86_64 support. It may be better to let these things rest in peace.

thanks! I'll see what bytes follow.

[lweb20]

AFAIR, 0x66 is not an instruction, (/me quickly looked into Opcode.txt guide) it's a data-size prefix. So at least you have to use some debugging tools to find the exact faulting instruction. Btw, Virtual PC is a pile of problematic software + VM86 is a dead way if you are planning x86_64 support. It may be better to let these things rest in peace.

thanks! I'll see what bytes follow.

Oh.. Follow pushfd instruction (0x66 0x9C) but pushfd in bios code?? I can't believe it. Where do I get the list of opcodes?

[Nable]

You can find my link to Opcode.txt file, use some web-site such as http://sandpile.org/ or just open Intel's Instruction Reference manual.
Btw, I don't see anything wrong with 'pushfd' - it's often used, especially for interrupt handlers.

[alexfru]

PUSHFD/POPFD have special behavior in virtual 8086 mode. See the documentation.

[lweb20]

You can find my link to Opcode.txt file, use some web-site such as http://sandpile.org/ or just open Intel's Instruction Reference manual.
Btw, I don't see anything wrong with 'pushfd' - it's often used, especially for interrupt handlers.

Thanks, "pushfd" seems strange to me because is a 32 bit instruction in VM86 mode (is not the same as pushf)

PUSHFD/POPFD have special behavior in virtual 8086 mode. See the documentation.

ok, I'll check.

[lweb20]

You can find my link to Opcode.txt file, use some web-site such as http://sandpile.org/ or just open Intel's Instruction Reference manual.
Btw, I don't see anything wrong with 'pushfd' - it's often used, especially for interrupt handlers.

Thanks, "pushfd" seems strange to me because is a 32 bit instruction in VM86 mode (is not the same as pushf)

PUSHFD/POPFD have special behavior in virtual 8086 mode. See the documentation.

ok, I'll check.

Edit:

From Intel Volume 3B System Programming Guide Part 2

When an IA-32 processor is running in virtual-8086 mode, the CLI, STI, PUSHF, POPF, INT n, and IRET instructions
are sensitive to IOPL. The IN, INS, OUT, and OUTS instructions, which are sensitive to IOPL in protected mode, are
not sensitive in virtual-8086 mode.

And where is pushfd?

[Gigasoft]

PUSHFD is just the name assemblers use for the 32-bit form of PUSHF.

[lweb20]

PUSHFD is just the name assemblers use for the 32-bit form of PUSHF.

I know but... it seemed strange to see 32-bit code on VM86. Problem solved. Thanks to all.