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

[Peter Maydell]

On 28 June 2013 08:01, Rob Landley <address@hidden> 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.

> 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?

>> >> 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.

>> >> 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 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.

> 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.

> 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.

-- PMM