On Thu, Apr 04, 2013 at 12:05:51PM +0100, Peter Maydell wrote: > On 28 March 2013 10:28, Peter Maydell <peter.mayd...@linaro.org> wrote: > > On 26 March 2013 21:12, Michael S. Tsirkin <m...@redhat.com> 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.
