From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59905) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNinT-0003ei-Il for qemu-devel@nongnu.org; Thu, 04 Apr 2013 07:57:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UNinL-0002gK-7S for qemu-devel@nongnu.org; Thu, 04 Apr 2013 07:57:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:27840) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNinK-0002g2-Uv for qemu-devel@nongnu.org; Thu, 04 Apr 2013 07:57:31 -0400 Date: Thu, 4 Apr 2013 13:58:14 +0300 From: "Michael S. Tsirkin" Message-ID: <20130404105814.GA6328@redhat.com> References: <1364293331-8722-1-git-send-email-peter.maydell@linaro.org> <201303261054.59928.arnd@arndb.de> <201303261108.50434.arnd@arndb.de> <20130326211256.GD19899@redhat.com> 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 Thu, Apr 04, 2013 at 12:05:51PM +0100, Peter Maydell wrote: > On 28 March 2013 10:28, Peter Maydell wrote: > > On 26 March 2013 21:12, Michael S. Tsirkin wrote: > >> On Tue, Mar 26, 2013 at 11:17:55AM +0000, Peter Maydell wrote: > >>> 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". > > > > OK, that makes sense. > > In fact I've just realised that "allow new kernels to use #27 > without getting the back-compat broken irq mapping" conflicts > with "allow new kernels to kexec old broken kernels". Could you clarify why, pls? Also - does this really matter so much? kexec between version is always a risky affair... > So the > easiest approach is just to drop the code which allows us to > switch back to broken mode again. Then the new kernel's init > code can force non-broken mode by writing something other than > #27 to some device's PCI_INTERRUPT_LINE register, and then > is free to use #27 if it wants to. > > -- PMM I'm fine with this too.