OSDev.org

HI,
just for fun i'm writing a little kernel.
I have implemented some stuff such scheduler,memory manager syscall and other.
Usually i use bochs or quemu and gdb to debug.
At the moment i'm writing ata driver.
I noted a strange behavior under bochs and qemu.
When try to write a sector bochs fire interrupt just after write command.
In real system storage latency is in the milliseconds order.
So my question is:
Bochs/Qemu reflects real hardware ata latency?
Below a snippet code of my driver:

67:out(0xE0 | (io_request->lba >> 24),0x1F6);
68:out((unsigned char)io_request->sector_count,0x1F2);
69 out((unsigned char)io_request->lba,0x1F3);
70 out((unsigned char)(io_request->lba >> ,0x1F4);
71 out((unsigned char)(io_request->lba >> 16),0x1F5);
72 out(io_request->command,0x1F7);

After instruction at line 72 (write command) i receive an interrupt and code jump to int handler:

disable_irq_line(14);
system.int_path_count++;
EOI_TO_SLAVE_PIC
EOI_TO_MASTER_PIC

if (system.device_desc->serving_request->process_context!=NULL)
{
_awake(system.device_desc->serving_request->process_context);
}
system.device_desc->status=DEVICE_IDLE;
enable_irq_line(14);

In this scenario handler try to awake a not sleeping process!!!!
I verified the interrupt refer to previuos command infact disk sector appear written correctly.
Can someone help?

Best Regards
Giuseppe.

I think it's a little unrealistic to expect virtual machines to replicate the seek times of real mechanical disks. Try attaching a real disk to the virtual machine instead of a virtual one and see if you get the same results. Or test the latency of real hardware with an SSD rather than a mechanical hard disk.

Your design obviously contains a race condition that QEMU is helpfully highlighting for you