Re: [Qemu-devel] [PATCH v4 00/11] Fix versatile_pci

[Peter Maydell]

On 8 April 2013 18:37, Rob Landley <address@hidden> wrote:
> On 04/06/2013 10:44:25 AM, Peter Maydell wrote:
>>
>> This patch series fixes a number of serious bugs in our emulation of
>> the PCI controller found on VersatilePB and the early Realview boards:
>>  * our interrupt mapping was totally wrong
>
>
> Yes. Yes it was. However, what you were doing matched the kernel for many
> years.

> The kernel guys have screwed this up three consecutive times, as described
> here:
>
>   http://landley.net/hg/aboriginal/rev/7bf850767bb8
>
> Because as far as I can tell, nobody has any test hardware for this anymore.

There is some but it's pretty rare.

>> This version of the patchset avoids breaking legacy Linux guests
>> by automatically detecting those broken kernels and switching back
>> to the old mapping. This works by looking at the values the kernel
>> writes to the PCI_INTERRUPT_LINE register in the config space, which
>> is effectively the interrupt number the kernel expects the device
>> to be using. If this doesn't match reality we use the broken mapping.
>> (Thanks to Michael S. Tsirkin for this suggestion.)
>
>
> My concern here was that you'd going to change qemu so it doesn't run the
> old images, and require a very new qemu to run the new images, so there will
> be an incompatible flag day.

No, it doesn't break old images, as the paragraph you quote clearly
states. Yes, if the kernel guys fix the kernel you'll need a newer
QEMU to run that. However as the kernel patches have been floating around
unapplied since 2011 you can draw your own conclusions about how quickly
the kernel will get fixed.

> Yay improving the latest and greatest, but when I'm regression testing as
> many different platforms as I can get working, stuff tends to break. (The
> most recent target-specific one for me on the QEMU side was probably the
> powerpc video thing,
> http://landley.net/notes-2012.html#17-11-2012 . Other than the 1.3/1.4
> general TCG instability which was the translation unit size being calculated
> wrong.) This is why I can't demand my users upgrade each time I do a
> release: the target they're interested in might not work because my images
> depend on things you don't regression test much.

Yes, TCG and minor platform emulation is to some extent on a 'best
effort' basis. Unfortunately we have neither the developer resources
nor the automated test infrastructure to do better; if you can help
on either front do say.

> I'm glad to see you're addressing backwards compatability, but it looks like
> I might have to patch my kernels to write the _old_ value to this register
> in order to get something that runs on old qemu?

If you want to run on a QEMU predating this patchset then you need
to have a kernel which expects the old and broken behaviour, yes.
This patchset is to some extent futureproofing in that it ensures
that if the kernel guys actually fix the versatilepb PCI code at
some future date the QEMU that is out in the wild will still cope.

> Because I broke my kernel
> to fit what qemu was doing, and I dunno when this register write changed. (I
> _do_ know that what the kernel guys have been doing to versatile is insane
> and inconsistent, and if you change your code to humor them they'll probably
> break it again. Their register mapping in 3.8 was so wrong even _I_ could
> tell.)

I don't have any interest in adding workarounds to QEMU for kernel
versions which didn't work on any QEMU version or on real hardware.
I do care about making QEMU work like the hardware, and about keeping
it working with kernels that assume the old longstanding QEMU
behaviour. This patchset satisfies both those goals.

If you have issues with the kernel breaking things then you need to
take it up with the kernel developers.

-- PMM