On 06/29/2013 06:03:26 AM, Peter Maydell wrote:
On 28 June 2013 08:01, Rob Landley <r...@landley.net> wrote:
> Now that the next kernel's about to come out, I'm trying to get my
arm
> versatile image to work under qemu 1.5.0. The old kernel doesn't
work, and
> the current vanilla kernel doesn't work. This change broke it.
>
> I'm testing current linux-git both with and without this patch:
>
> --- linux/arch/arm/mach-versatile/pci.c 2013-04-28
19:36:01.000000000 -0500
> +++ linux.bak/arch/arm/mach-versatile/pci.c 2013-04-29
> 19:09:44.857097553 -0500
> @@ -333,7 +333,7 @@
> * 26 1 IRQ_SIC_PCI2
> * 27 1 IRQ_SIC_PCI3
> */
> - irq = IRQ_SIC_PCI0 + ((slot - 24 + pin - 1) & 3);
> + irq = 59; //IRQ_SIC_PCI0 + ((slot - 24 + pin - 1) & 3);
>
> return irq;
> }
>
> With the patch, qemu 1.2.0 works, but qemu 1.5 versatile does not
work with
> or without the patch.
The "with the patch" case is uninteresting, because it's not
actually a fix for anything, it's just a change that happened
to work with old QEMU, and it's not a change that is in upstream
Linux.
I want to create a kernel image that works with the existing QEMU image
people are likely to have installed on their systems, _and_ with
current versions of QEMU.
Is that what you consider "uninteresting"?
> Here's a test image to demonstrate the problem: it works fine under
qemu
> 1.2.0, but doesn't under 1.5.0:
>
> http://landley.net/aboriginal/bin/system-image-armv5l.tar.bz2
>
> Extract it and ./run-emulator.sh. You get a shell prompt from
1.2.0, from
> 1.5.0 it never gets a scsi interrupt, and after a timeout goes into
an
> abort/reset loop.
Is this an image with your patch or without it? Does it work
if you use the -global option to force legacy IRQ mapping?
Under qemu 1.2? It goes:
qemu-system-arm: Property '.broken-irq-mapping' not found
See "backwards compatability", above.
I am trying to produce "an image that runs under qemu". That level of
genericity worked for several years, at least ever since 1.0. When it
stopped, I complained. You seem to be expressing incredulity at the
concept.
>> >> This version of the patchset avoids breaking legacy Linux guests
>> >> by automatically detecting those broken kernels and switching
back
>> >> to the old mapping.
>
>
> As testing with the above image confirms: it does not.
I tested with several separate variants of the Linux kernel.
I tried building a vanilla linux 3.10 kernel, and it doesn't work on
qemu 1.5. I confirmed their current interrupt mapping does not match
any known hardware or emulator, and that it changed more than once in
incompatible ways as they did wild-ass-guess du jour about what it
should be now.
The fact it was obviously untested (or it wouldn't keep changing, since
there presumably is just one right answer) says to me that this
hardware is difficult ot come by. (The fact the IRQ spent over 5 years
in the old state before anyone noticed would also imply a lack of test
hardware.) However, it's useful to emulate because you can stick a PCI
bus in it, meaning you can stick arbitrary devices (hard drive and
network card) into said bus.
So I did the obvious-to-me thing and patched it back to how it _was_,
which is the only thing that works with previous versions of QEMU. You
seem to find this approach shocking and unexpected. Do you have a
better way to achieve compatability with older versions of qemu _and_
current versions? (I'm open to suggestions...)
>> >> 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.)
>
> Define "reality".
"would work on real hardware".
The stuff that's so rare the kernel guys couldn't find any to test on?
Maybe I haven't been clear: I want something that works with current
QEMU _and_ old QEMU.
Your paragraph above implies that there's smoething _different_ I can
write to PCI_INTERRUPT_LINE that will trigger the old behavior. So my
patch to do the old IRQ (which worked fine with qemu 1.2) needs to be
bigger to humor QEMU's heuristic. I'll try to figure out how to extend
my patch to avoid triggering your new "does not work" mode.
Let's see, stick a printf into qemu, and:
=====Write 60=12,59=====
So it's requesting IRQ 59, and QEMU's reponse is to _not_ give it IRQ
59 unless we trigger the "broken" flag.
So... real hardware doesn't get the IRQ it requests? Using the reqested
IRQ is "broken"? (Apparently your patch for a real hardware kernel
doesn't request the IRQ it's going to use? I'm confused...)
Right, easy enough to fix:
--- a/arch/arm/mach-versatile/pci.c
+++ b/arch/arm/mach-versatile/pci.c
@@ -333,7 +333,13 @@ static int __init versatile_map_irq(const struct
pci_dev *dev, u8 slot, u8 pin)
* 26 1 IRQ_SIC_PCI2
* 27 1 IRQ_SIC_PCI3
*/
- irq = IRQ_SIC_PCI0 + ((slot - 24 + pin - 1) & 3);
+ // Hit QEMU 1.5.0 and later with a brick so it uses the IRQ we
say.
+ dev->bus->ops->write(dev->bus, dev->devfn, PCI_INTERRUPT_LINE,
1, 27);
+
+ // The kernel has no clue where IRQs are, and its current
assignments
+ // match neither the hardware nor historic QEMU. Use historic
QEMU
+ // for compatability with old versions.
+ irq = 59; //IRQ_SIC_PCI0 + ((slot - 24 + pin - 1) & 3);
return irq;
}
That should work with new _and_ old QEMU.
> The kernel changed what irqs it was expecting _three_times_ last
year, and
> as far as I can tell none of them were what they were _trying_ to
do.
>
> Here's my blog entry and the source control comments where I
diagnosed this
> stuff to show that the kernel guys have no flipping CLUE how an arm
> versatile board actually works:
I agree that the kernel has made a bit of a mess in this area,
so we don't need to have that argument again.
Can we have the backwards compatability argument?
> The kernel code in this area is CRAP, has changed multiple times in
> semi-random ways, has obviously NEVER been tested on real hardware,
and if
> you've implemented what the actual versatile documentation says
it's clearly
> not what the kernel is doing.
I tested these changes against a patchset which Arnd wrote which
I can guarantee was tested on real hardware because I did the
testing myself.
Where is this patch? (Was it submitted upstream to linux-kernel?)
> Do you have a kernel that runs under current qemu arm versatile
emulation? I
> can poke around and figure out which irqs it expects _now_, but
it's not
> "right" and presumably you're just going to change it again when
you realize
> what qemu is doing and what the unpatched kernel is doing don't
match.
The ones on http://people.debian.org/~aurel32/qemu/armel/
should work.
I'm not seeing a patch there.
Rob