On Tue, Mar 26, 2013 at 11:17:55AM +0000, Peter Maydell wrote: > On 26 March 2013 11:08, Arnd Bergmann <a...@arndb.de> wrote: > > On Tuesday 26 March 2013, Peter Maydell wrote: > >> On 26 March 2013 10:54, Arnd Bergmann <a...@arndb.de> wrote: > >> > Yes, very good. We will probably introduce sparse irq support on > >> > versatile in the near future, and then the value we write into the > >> > PCI_INTERRUPT_LINE field will become arbitrary from qemu's point > >> > of view, but I will make sure that we fix the interrupt mapping > >> > in the kernel at the same time so we always fall into the > >> > "s->broken_irq_mapping = false;" case. > >> > >> Yeah, as long as you avoid the number 27 you're ok :-) > > > > Good point. I guess we'll have to keep using a legacy domain for > > versatile then. > > I'm happy to provide some other way for QEMU to detect a > new working kernel if you want to implement one in the > kernel, if that's cleaner.
That's why I suggested writing some number at offset 0x08 (that's revision ID) in configuration space of device 0 on bus 0. It's guaranteed harmless on real hardware and QEMU could detect this write and say "aha new kernel, even though it uses #27". > >> > We also need to find a way to make the new kernel work with > >> > an old qemu, and I think we can do that by using the versatile-dt > >> > board type with a PCI device node that sets all four lines to > >> > 27, while using the actual interrupt lines for the default > >> > versatile device tree. > >> > >> Personally I'd be happy for you to just say "needs a new QEMU". > >> The broken QEMU is missing so much (including working memory > >> windows) that I think it would be a pain to get the kernel to > >> cope with it. > > > > But it was working earlier, so I'd definitely try not to break > > if at all possible. A lot of people use the verstatile qemu > > model to run kernels and I would not want to deal with the > > complaints I'd get if we break those. Using a separate dts > > file seems easy enough. > > Yeah, but it only worked earlier because the kernel PCI controller > support was so broken and limited, I think. If you run a new > kernel with the old QEMU it won't work even if you avoid the > irq-mapping issues. > > Also I really don't want to get people into the habit of > using a QEMU-specific dts file. The result will be that > nobody will ever move on from that dts file to the one that > gets used with real hardware. > > Plus, you guys make kernel changes that break running on > QEMU all the time, so I don't see that as a big deal really. > (Most recently, vexpress needed a pile of support for the > config registers that define the voltage regulators and clocks.) > > -- PMM I have to agree with that. -- MST