OSDev.org

Hi,

I have a problem running ioapic on virtual box.

I managed to program the IOAPIC with ATA devices to fire interrupts 14 and 15 with DMA data transfer and make it work on Bochs.

The problem is that the same code does not work on virtual box.

I parse the ACPI tables and read IOAPC configuration form MADT.

The only difference that I noticed is the on Bochs I get one interrupt source override, while on Virtualbox is get 2 interrupt source override.

The details of the interrupt source override in bochs are:
Bus: 0x0
src: 0x0
GSI: 0x2
flags: 0x0

The details of the interrupt source override in virtualbox are:
#1:
Bus: 0x0
src: 0x0
GSI: 0x2
flags: 0x0

#2:
Bus: 0x0
src: 0x9
GSI: 0x9
flags: 0xd

For both the GSI base is 0x0.

I appreciate if anyone has gone through this and know what could be the problem with virtual box and willing to share the information.

In the case of virtualbox, the interrupts do not fire upon initiating DMA data transfer while in case of bochs it works as expected.

Thanks,
Karim.

First, make sure the I/O APIC is configured correctly. Since there is no interrupt overrides for the ATA IRQs, make sure that the I/O APIC entry for them is configured to use active high polarity, and edge trigger mode, which are the defaults for ISA IRQs if the firmware doesn't indicate otherwise. The I/O APIC Wiki entry has more information on this.

Next, make sure the IRQs from the ATA channels are enabled. Do this by clearing bit 1 of the device alternate control register (normally at I/O port 0x3F6, but could be different, see below.)

Next, make sure the I/O ports that are being used are correct. This is unlikely to happen on emulators, but will hit you when you use real hardware. Basically, scan the PCI bus for a PCI IDE controller. If you find one, BAR0 contains the base I/O port of the primary channel, BAR1 contains the base I/O port of the primary channel alternate control, BAR2 contains the base I/O port of the secondary channel and BAR3 contains the base I/O port of the secondary channel alternate control. If any of these values are zero or one, you can assume the defaults; 0x1F0, 0x3F6, 0x170 and 0x376. The IRQ being used should also be read from the PCI configuration space, and you should not assume IRQs 14 and 15.

Since you are using DMA transfers anyway, you are already using the PCI IDE controller. Make sure that it is allowed to access I/O port space, bus-master DMA and send interrupts, by setting/clearing appropriate bits in the PCI command register.

EDIT: In general, using PCI IRQs without a proper ACPI AML interpreter will give you very fragile code, that works by chance on some PCs and won't work on others. As such, if you're going to use PCI IRQs in any way, don't use the I/O APIC for those, and stick to the legacy PIC. An alternative (and easier) option, that I myself made, is to make all PCI device drivers rely on polling, and not IRQs, because it reduces the need of an AML interpreter. But if you feel like writing one, then go ahead. It would be inspiring.

Hi,

Don't forget that for ATA controllers there are 3 different cases:

• It's an ISA ATA controller. In this case it will use ISA IRQs 14 or 15 and the ISA IO ports.
• It's a PCI ATA controller emulating a legacy ISA ATA controller. In this case it will probably be 2 controllers in one device (primary and secondary ATA controller), and will still use ISA IRQs 14 and 15 (and will not use PCI IRQs, and there's no need to worry about ACPI AML), and will still use ISA IO ports for the controller itself (and the first few BARs will be ignored), but the BAR for the DMA will be used (if it supports DMA).
• It's a PCI ATA controller in "native mode". In this case it will use PCI IRQs (and won't use ISA IRQs 14 and 15, and you will need to worry about ACPI's AML to determine how it's connected to IO APIC if it doesn't also support MSI); and it will use all the BARs properly (and won't use the legacy ISA IO ports).

For PCI ATA controllers, the "programming interface" field in the device's PCI configuration space will tell you if each ATA controller is in native mode or legacy ISA emulation mode. If I remember correctly there's a few flags to say if the device supports native mode and/or legacy ISA emulation mode (that can't be modified); and a few flags to say what mode the device is currently using. If an ATA controller within the device supports both modes, then the bits that say what mode the device is using can be written to (to change the mode the corresponding ATA controller is uses).

For detection; I'd disable PCI devices and probe for ISA ATA controllers. Then I'd re-enable PCI devices. If there was an ISA ATA controller then all PCI ATA controllers must be configured for "native mode" (or left disabled if they don't support native mode); otherwise it will conflict with the IO ports that the ISA ATA controller uses. If there wasn't any ISA ATA controller/s then one and only one PCI device (containing a primary and secondary controller) can be configured for ISA emulation (if one of them support it).

Note that for PCI you can have any number of PCI ATA controllers in native mode (all using different IO ports configured in their BARs, etc) without conflicts - e.g. 10 PCI devices with 2 ATA controllers per device (for 20 ATA controllers and up to 40 hard disks).


Cheers,

Brendan