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.
I build system images that are working on versatilePB right now, with
the 3.8 kernel.
http://landley.net/aboriginal/bin/system-image-armv5l.tar.bz2
Grab that, ./run-emulator.sh and it should boot to a shell prompt
within which you can compile hello world.
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. (But no other board emulation I've tried lets me stick a PCI
bus and a scsi controller, ethernet, and serial port into an arm board
along with enough memory to natively compile stuff.)
This past release I tried to fix it up properly:
http://landley.net/notes.html#15-03-2013
http://landley.net/notes.html#16-03-2013
And then I gave up and hit it with a rock:
http://landley.net/hg/aboriginal/rev/96fb8598a446
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.
This is especially a concern for me because I had to go back to qemu
1.2.0 to get stable builds on all my targets, because the 1.3.0 and
1.4.0 releases were both broken:
http://landley.net/aboriginal/news.html
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.
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? 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.)
Rob
