Regarding items 3) and 4):
3) Indeed, bhyve does not explicitly forbid writing to 0x3c. I meant
the following. The interrupt line is set is pci_emul.c in bhyve:
pci_set_cfgdata8(pi, PCIR_INTLINE, pirq_irq(ii->ii_pirq_pin)); Bhyve
asserts interrupts with pci_irq_assert in amd64/pci_irq.c. We need
this line: vm_isa_assert_irq(pi->pi_vmctx, pirq->reg & PIRQ_IRQ,
pi->pi_lintr.ioapic_irq); pirq->reg & PIRQ_IRQ is literally the same
as pirq_irq(ii->ii_pirq_pin). Now, if something (e.g. UEFI firmware,
bootloader) writes to PCIR_INTLINE bhyve will still send interrupts
with the number that was there before the write, while the OS will
expect an interrupt with the new number. I treat this as a bug in
bhyve (but it affects nobody, because newer OSes do not use the 8259
interrupt controller).
Ah yes, I think that's correct. I'm assuming that you're using EFI to
boot, and bhyve/EFI recently changed to have PCI setup done by
EFI and not in bhyve as before. Sounds like this is an extreme corner
case that was broken by that. Not surprising: any o/s that supports EFI
boot could be expected to support IOAPIC interrupts at a minimum.
4) It's commenting the lock what makes an effect. I commented
pci_generate_msi just in case because it's not needed for Mezzano,
but runs protected by the mutex which is now gone. This is a
backtrace and thread list when bhyve hangs up if the mutex is not
commented out:
I suspect this might be related to the above.
I think implementing IOAPIC in MEzzano is the best option indeed,
but I have a little experience. I'll see what I can do.
See figures 3-2 through 3-5 in the Intel MP spec for an explanation of
how it all fits together
https://web.archive.org/web/20121002210153/http://download.intel.com/design/archives/processors/pro/docs/24201606.pdf
later,
Peter.
