On Sun, Mar 24, 2013 at 09:16:28PM +0000, Arnd Bergmann wrote: > On Sunday 24 March 2013, Peter Maydell wrote: > > Yeah, ideally being able to detect the buggy kernel would be good; > > I can't see anything at the controller level that would do though, > > and I don't really know enough about PCI to know about generic > > PCI stuff that would work. (Why would the OS need to tell the > > device anything about its IRQ if it's hardwired?) > > 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.
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? > Can you try out what the kernel writes into > that register in qemu, with and without my patches? > > I would expect the numbers to be (64+27) to (64+30), since we > linearize the interrupt numbers so that VIC gets 32 through > 63 and SIC gets 64 through 95. > > Arnd