Dear coreboot folks,
Ron, let’s bring this up on the list for broader audience and easier discussion by email.
Jonathan’s patch set »ck804: hide IOAPIC base address in PCI_BASE_ADDRESS_1«  does the following.
Linux unhelpfully "fixes" the value in PCI_BASE_ADDRESS_1 when it is 0xfec00000 (that is, outside the range of bus 0 address space). This causes IOAPIC interrupts to fail to work under Linux. This issue was originally unnoticed by me when testing as sanity checking such as this is not done by NetBSD. Hiding the IOAPIC BAR is done by the OEM BIOS on the ck804 boards I've checked.
The question raised by Ron is, if such hacks should be implemented in coreboot or not.
Am Sonntag, den 13.10.2013, 13:55 -0400 schrieb ron minnich:
"do as the original BIOS does" is an ok rule if the BIOS is clearly right and we are wrong. In this case, Linux is presumably covering for a broken BIOS, but doing it badly. We've seen this before. Yes, let's confront the LKML; some of them read this least and they're usually pretty reasonable (not always :). But let's thoroughly document what's going on. I'm not comfortable with doing a hack like this for one kernel. It's never been a good idea (we've confronted this issue more than once in 14 years). Before we know it we'll be asked to put in gross hacks for Windows too.
Even if Linux gets fixed, what do we do with distributions with older Linux kernels which do not have that fix on current installation media for example? In my opinion it is undesirable to tell people you cannot use that stable distribution because the Linux kernel has a bug. Build your own Linux kernel. The same applies for Microsoft Windows. And there you might even not get it fixed at all. (I do not know, if this particular problem actually exists in Microsoft Windows.) In the end, we want that everything that boots with the vendor BIOS also boots with coreboot, won’t we? Staying compatible with certain hacks the vendor BIOS does is therefore unavoidable.
One alternative would be to add a Kconfig option to enable such hacks. No idea if this is doable or not. In the end Jonathan’s fix seems pretty minimal for the benefit we get.
Paul, you missed part of the picture. Suppose we have a different kernel, which does not have the same bug as Linux has,and that, further, depends on that register being visible? We can't know that such OSes exist, but we do not know that they do not. We'd have to at the very least test some of them. We've always tried to avoid being Linux-centric in coreboot and for the most part have succeeded. Further, hidden registers create their own problems.
This problem has no clear solution. I've always felt that in all cases, we should err on the side of opening up the hardware, and not hiding registers.