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

[Rob Landley]

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