How is AHCI implemented on emulators?

[cepanamea]

Hi,

While being in the early stages with my kernel and realizing that many things need storage, I decided to have a hdd driver. According to the wiki, the AHCI standard sounded not so horrible to implement and I started working on that. As you can imagine I failed:) Now the problem is that I can't be sure if my code is faulty (after going back and forth to the docs a lot, I'm reasonably confident it should work well). There is another factor of uncertainty here: the emulator.
Does anyone know how well emulators support the AHCI standard? My experience so far:
1) QEMU - can mount AHCI drives, managed to find them on the PCI bus, but when trying to read the HBA, I only get garbage
2) Bochs - I couldn't get any indication at all that it handles AHCI
3) VMWare - I can detect the drive, but the HBA points to an absurd address in my free memory

Does anyone know for sure if any of these has a decent emulation of AHCI?

[Kazinsal]

I think VirtualBox has a fairly decent AHCI hub emulation. Haven't seen a system choke on it yet.

[cepanamea]

The problem is that on VirtualBox I couldn't discover the drive on the PCI bus. I attached an SSD to the virtual machine, but either it's not considered an AHCI drive or the standard is not implemented at all. Again, it's just what my tests have shown. I'd be happy if someone could contradict me.

[intx13]

Personally I use a cheap PCIE AHCI controller in its own slot and use PCI pass-through to present it to QEMU.

[SpyderTL]

Modern VMs rarely pass-thru commands directly to physical hardware. (The one exception that I've found is for Audio CDs, because it would apparently be very difficult to emulate this... Audio CDs weren't designed for Random Access data, like floppy drives or CD-ROMs. It's essentially one very long stream of 1's and 0's.)

All of these VMs let you choose what interface to expose to the VM/guest OS. So you could have IDE on your physical machine, and AHCI or SCSI on your virtual machine. One of the advantages to a Virtual Machine is that the real hardware can not directly affect the code running on your VM. This gives you a stable "platform" that you can use even if you "move" the VM from an OSX host to a PC.

VirtualBox is open source, so you can just look at their AHCI code and see what it's actually doing... You can see all of the code, online, at http://VirtualBox.org.

But, I would assume that the problem is in your code, until you can prove otherwise. In my experience, the chances that your issue is a bug in the emulator is about 1 out of 100. It's possible, but not likely. I've actually found a bug or two in VirtualBox and VMWare, but I've been doing this for like 6 years.

To put it another way, if a VM couldn't boot Windows, no one would be using it.

[cepanamea]

I wasn't suggesting bus in the emulator, I was asking if this feature is implemented. For example, there was some info that the QEMU driver for AHCI is still in an early stage.
Anyway, since it's more likely it's my code, let me enumerate the steps, as I have understood them:
1. enumerate the devices on the PCI bus, by going through every bus and every device
2. identify those with class 0x01 and subclass 0x06
3. identify the position of the HBA, by reading the BAR5 number (position 0x24)
4. read from HBA

On my experiments with QEMU, I mounted 2 AHCI devices and what I got was address 0x1000 for the first HBA and 0x2000 for the other. Considering the HBA is 0x1100 in size, this was the first clue. Then, just by reading the first item from the HBA, host capabilities, i get a zero, which is impossible.

[Kevin]

I wasn't suggesting bus in the emulator, I was asking if this feature is implemented. For example, there was some info that the QEMU driver for AHCI is still in an early stage.

I didn't have any problems implementing an AHCI driver for it. The only thing I had to add so far on top of that for real hardware was some power management stuff, which is completely ignored by qemu.

On my experiments with QEMU, I mounted 2 AHCI devices and what I got was address 0x1000 for the first HBA and 0x2000 for the other. Considering the HBA is 0x1100 in size, this was the first clue. Then, just by reading the first item from the HBA, host capabilities, i get a zero, which is impossible.

Why would you want two AHCI controllers?

But anyway, the BAR size isn't fixed: "Base Address (BA): Base address of register memory space. This represents a memory space for support of 32 ports. For HBAs that support fewer than 32-ports, more bits are allowed to be RW, and therefore less memory space is consumed. For HBAs that have vendor specific space at the end of the port specific memory space, more bits are allowed to be RO such that more memory space is consumed." The ICH-9 AHCI controller emulated by qemu supports 6 ports, so 0x1000 is enough as the BAR size.

[cepanamea]

Why would you want two AHCI controllers?

Actually I just wanted two separate "hard drives".
Anyway, this does not change the fact that the HBA fields are rubbish. The capability field is 0, which means at least that this HBA doesn't use any ports, and the ports information field is also zero. So I can assume all the other data doesn't have any meaning.

I ran QEMU with a command like this:
qemu -drive id=disk,file=c.img,if=none -device ahci,id=ahci0 -device ide-drive,drive=disk,bus=ahci0.0 -kernel ./Debug/wabbit

[Kevin]

Actually I just wanted two separate "hard drives".

Then you need two -device ide-hd,bus=ahci.0, but not two "ahci" devices, which are the controllers.

Anyway, this does not change the fact that the HBA fields are rubbish. The capability field is 0, which means at least that this HBA doesn't use any ports, and the ports information field is also zero. So I can assume all the other data doesn't have any meaning.

As I said it works fine with my driver, so probably you're not actually reading what you think you're reading. (0 wouldn't mean no ports, but one port. But that's definitely not what you're supposed to see. I get 0x40141f05 for the CAP register on QEMU.)

[cepanamea]

Kevin, maybe you will be kind enough as to show me your QEMU starting script? I get the distinct feeling I'm not configuring it right..

[Kevin]

I used what I think was your command line in order to check if anything unexpected happens there. The only major difference is that I'm booting from the AHCI disk instead of using -kernel. So while I don't have the exact command line here (it was on a different computer) that must have been something like:

qemu-system-x86_64 -drive file=build/images/hd.img,if=none,id=hd -device ahci,id=ahci0 -device ahci,id=ahci1 -device ide-hd,bus=ahci0.0,drive=hd