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

[Peter Maydell]

On 4 April 2013 11:58, Michael S. Tsirkin <address@hidden> wrote:
> On Thu, Apr 04, 2013 at 12:05:51PM +0100, Peter Maydell wrote:
>> On 28 March 2013 10:28, Peter Maydell <address@hidden> wrote:
>> > On 26 March 2013 21:12, Michael S. Tsirkin <address@hidden> 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