Re: [Qemu-devel] [PATCH v2 07/11] versatile_pci: Implement the correct PCI IRQ mapping

[Michael S. Tsirkin]

On Tue, Mar 26, 2013 at 11:17:55AM +0000, Peter Maydell wrote:
> On 26 March 2013 11:08, Arnd Bergmann <address@hidden> wrote:
> > On Tuesday 26 March 2013, Peter Maydell wrote:
> >> On 26 March 2013 10:54, Arnd Bergmann <address@hidden> 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