From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44162) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKbAV-0004vA-6E for qemu-devel@nongnu.org; Tue, 26 Mar 2013 17:12:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKbAR-000862-Sw for qemu-devel@nongnu.org; Tue, 26 Mar 2013 17:12:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:22719) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKbAR-00085n-LO for qemu-devel@nongnu.org; Tue, 26 Mar 2013 17:12:27 -0400 Date: Tue, 26 Mar 2013 23:12:56 +0200 From: "Michael S. Tsirkin" Message-ID: <20130326211256.GD19899@redhat.com> References: <1364293331-8722-1-git-send-email-peter.maydell@linaro.org> <201303261054.59928.arnd@arndb.de> <201303261108.50434.arnd@arndb.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v2 07/11] versatile_pci: Implement the correct PCI IRQ mapping List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Arnd Bergmann , patches@linaro.org, Will Deacon , qemu-devel@nongnu.org, Paul Brook , Andreas =?iso-8859-1?Q?F=E4rber?= , Aurelien Jarno On Tue, Mar 26, 2013 at 11:17:55AM +0000, Peter Maydell wrote: > On 26 March 2013 11:08, Arnd Bergmann wrote: > > On Tuesday 26 March 2013, Peter Maydell wrote: > >> On 26 March 2013 10:54, Arnd Bergmann 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