OSDev.org

Short version:

Executing "in %dx, %eax" in vmware appears to crash vmware; but, things work as expected in VirtualBox and on actual hardware.

Long version:

I am trying to write very basic programmed IO for ATA. I began with the example Bare Bones OS (http://wiki.osdev.org/Bare_Bones), which works as expected. Next, I was trying to do some very simple programmed IO (mostly to figure out how it worked) (http://lateblt.tripod.com/atapi.htm). That code works as expected on VirtualBox and on real hardware; but, crashes vmware.

I removed all of the code except this single instruction: "in %dx, %eax", and the vmware still crashes. When I look in the vmware log file, this appears to be the source of the problem:

2017-04-07T12:22:01.334-04:00| vcpu-0| I125: Unknown int 10h func 0x0000

I have double-checked that the vm does have an IDE bus, and I've tried rebuilding the vm and re-installing vmware. Any ides of what to try next?

(If it helps, I've included more of the log file below.)

2017-04-07T12:21:59.022-04:00| vcpu-0| I125: pciBridge7:7: ISA/VGA decoding enabled (ctrl 0004)
2017-04-07T12:21:59.082-04:00| vcpu-0| I125: VIDE: Curr CHS info cyls: 4161 heads: 16 sects: 63 lba_cap: 4194304
2017-04-07T12:21:59.100-04:00| vcpu-0| I125: BIOS-UUID is 56 4d b3 c7 ad 87 ac 17-68 9f 67 30 3d 3c 80 7e
2017-04-07T12:21:59.114-04:00| vmx| I125: VNET: MACVNetLinkStateTimerHandler: 'ethernet0' state from 6 to 1.
2017-04-07T12:21:59.792-04:00| vcpu-0| I125: VIDE: Curr CHS info cyls: 4161 heads: 16 sects: 63 lba_cap: 4194304
2017-04-07T12:22:01.334-04:00| vcpu-0| I125: Unknown int 10h func 0x0000
2017-04-07T12:22:01.335-04:00| vcpu-0| W115: MONITOR PANIC: vcpu-0:VERIFY devices/vide/vide.c:1741
2017-04-07T12:22:01.335-04:00| vcpu-0| I125: Core dump with build build-3770994
2017-04-07T12:22:01.335-04:00| vcpu-0| W115: Writing monitor corefile "/home/kurmasz/vmware/IO/vmmcores.gz"
2017-04-07T12:22:01.338-04:00| vcpu-0| W115: Dumping core for vcpu-0
2017-04-07T12:22:01.338-04:00| vcpu-0| I125: Beginning monitor coredump
2017-04-07T12:22:01.378-04:00| mks| W115: Panic in progress... ungrabbing
2017-04-07T12:22:01.378-04:00| mks| I125: MKS: Release starting (panic).
2017-04-07T12:22:01.380-04:00| mks| I125: MKS: Release finished (panic).
2017-04-07T12:22:01.879-04:00| vcpu-0| I125: End monitor coredump
2017-04-07T12:22:02.169-04:00| vcpu-0| I125: Coredump encountered overflow 5874:5874 (302 duplicates)
2017-04-07T12:22:02.208-04:00| vcpu-0| W115:
2017-04-07T12:22:02.208-04:00| vcpu-0| W115+ The core dump limit is set to ZERO; no core dump should be expected
2017-04-07T12:22:02.332-04:00| vcpu-0| W115: Core dumped.
2017-04-07T12:22:02.333-04:00| vcpu-0| I125: Core dump pipes to process /usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e %P %I, core file unreliable
2017-04-07T12:22:02.333-04:00| vcpu-0| W115: A core file is available in "/home/kurmasz/vmware/IO/core.18529"
2017-04-07T12:22:02.333-04:00| vcpu-0| I125: Msg_Post: Error
2017-04-07T12:22:02.333-04:00| vcpu-0| I125: [msg.log.error.unrecoverable] VMware Workstation unrecoverable error: (vcpu-0)
2017-04-07T12:22:02.333-04:00| vcpu-0| I125+ vcpu-0:VERIFY devices/vide/vide.c:1741
2017-04-07T12:22:02.333-04:00| vcpu-0| I125: [msg.panic.haveLog] A log file is available in "/home/kurmasz/vmware/IO/vmware.log".
2017-04-07T12:22:02.333-04:00| vcpu-0| I125: [msg.panic.requestSupport.withoutLog] You can request support.

You need to use "inb %dx, %al". The status / command register is a 1-byte register, not a 4-byte register.

Reading the wrong size register is technically undefined behavior; some emulations silently supply undefined values and some emulations fail safe.

(For anyone wondering how I know which register... I work at VMware and the file + line number was unambiguous).