Hey Mike, I wrote this last year, I think its a bug in qemu: Does this fix your issue?
Author: Damien Zammit <[email protected]> Date: Sun Jun 22 21:45:26 2025 +1000 hw/i386/pc_piix.c: Add IRQs 14,15 as MADT overrides When PIIX3 IDE is used, these two interrupts are active-low level-triggered but are not set as MADT overrides. Since the default for legacy interrupts is on rising edge, these two extra MADT isa irq overrides are needed. Signed-off-by: Damien Zammit <[email protected]> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c index ea7572e783..7320563890 100644 --- a/hw/i386/pc_piix.c +++ b/hw/i386/pc_piix.c @@ -181,6 +181,11 @@ static void pc_init1(MachineState *machine, const char *pci_type) } } + /* Add IRQ 14,15 to MADT overrides for PIIX3 IDE */ + if (pcmc->pci_enabled) { + x86ms->pci_irq_mask |= (1<<14) | (1<<15); + } + pc_machine_init_sgx_epc(pcms); x86_cpus_init(x86ms, pcmc->default_cpu_version); Damien On 26/9/26 10:39 am, Damien Zammit wrote: > Hi Mike, > > Did you end up sending mail to NetBSD to ask about rump? > I can't find the thread. > It might be worth asking them about this particular issue as well. > > I read somewhere on netbsd's mailing list archives that they > have to use -M q35 as well for qemu to work correctly (which > basically bypasses the piix3 ide controller). > > Damien > > On 8/9/26 10:11 pm, Michael Kelly wrote: >> I've been trying to get my old hardware machine working with SATA disk >> controller operating in 'Native IDE compatibility mode'. This is >> detected correctly by rumpkernel in the same way as when using Qemu and >> i440fx machine. I've managed to get it working with 2 changes: >> >> 1) The IRQ configuration for this controller should always use the >> legacy IRQ and not that provided by the ACPI tables. On my machine the >> ACPI table still includes a mapping from 14 to 19 even though the legacy >> controller mode is configured. Hurd therefore wrongly chooses 19 for the >> IRQ. >> >> NetBSD arch amd64 implements pciide_machdep_compat_intr_establish() >> which only attempts a legacy IRQ configuration and correctly chooses 14. >> This function is also implemented within rump but basically just calls >> into the normal interrupt establishment code losing the 'legacy only' >> context. I hacked something together for test purposes but a proper fix >> might be to alter rump's pciide_machdep_compat_intr_establish() to >> provide the missing context so Hurd can choose to call ACPI translation >> or not. >> >> 2) Perhaps the more difficult issue relates to the IOAPIC interrupt >> configuration. Looking at gnumach/i386/i386at/ioapic.c, >> ioapic_configure() configures pins 14 and 15 with level triggering and >> active low. I think that historically these were configured as legacy >> IRQs having edge triggering and active high but were changed to allow >> Qemu IDE on piix3 to work. On my hardware machine, these pins need to be >> configured as legacy pins (active high/edge triggered). >> >> I'd have expected that Qemu would emulate pins 14 and 15 as active >> high/edge triggered but it seems not as booting a virtual machine >> (i440fx) with my changes does not work correctly and has interrupt >> loss/timeout issues. The strange thing is that booting NetBSD with the >> same virtual machine works correctly and yet that seems to configure the >> interrupt as active high/edge triggered. I can't explain this >> inconsistency at the moment. >> >> Can anyone can shed any light on the interrupt configuration issue? >> >> Cheers, >> >> Mike. >> >>
