On 24 March 2013 21:37, Michael S. Tsirkin <[email protected]> wrote: > On Sun, Mar 24, 2013 at 09:16:28PM +0000, Arnd Bergmann wrote: >> I think it actually does on versatile and other platforms on which >> the kernel probes the PCI bus itself, rather than relying on firmware >> to have resources assigned in advance. >> >> IIRC, the PCI_INTERRUPT_LINE pci config space byte (0x3c) is purely >> informational and used as a way to communicate the interrupt number >> from the bus scan code (assumed to be a PC BIOS in the PCI spec, >> but drivers/pci/setup-irq.c in case of versatile+linux) to a device >> driver. >> >> So the kernel should actually write the proper interrupt number in >> there. In future kernels, this may not necessarily be the hardware >> number, but today it is.
OK, so I've now tested, and the kernel writes the interrupt number (27..30) into PCI_INTERRUPT_LINE, so we can successfully use this to detect broken kernels and switch to the old irq mapping. (Broken kernels write 27 regardless of slot number, good ones write 27..30 depending on slot number.) [patches in progress, will send later.] > For future kernels, let's build in some hook that let > qemu detect a non broken guest. How about writing > some magic value into revision ID or some other > readonly field? So do we still need the non-broken-guest detection hook too? We could maybe steal a bit in PCI_FLAGS for this, but somebody would need to check the behaviour of the hardware if you try to write to the reserved bits on real hardware. (Usually it's RAZ/WI or reads-as-written, either of which would be OK here.) thanks -- PMM
