On 4 April 2013 11:58, Michael S. Tsirkin <m...@redhat.com> wrote: > 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?
Either we provide a path for QEMU's state to go from "this is a new kernel and we act like hardware" to "this is an old kernel and we do not", or we don't. If we provide a way for that state transition to occur, then new kernels can't use #27; if we don't, then the kexec'd old kernel wouldn't see the old broken mapping it expects. I only stuck the "allow us to go back to the old mapping" code in there because I didn't see why it would hurt at the time. > Also - does this really matter so much? > kexec between version is always a risky affair... I agree, which is why I'm dropping that idea. -- PMM