qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 00/10] Fix versatile_pci (and break versatilepb


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 00/10] Fix versatile_pci (and break versatilepb linux guests!)
Date: Sun, 24 Mar 2013 16:49:37 +0000

On 24 March 2013 15:58, Aurelien Jarno <address@hidden> wrote:
> On Sun, Mar 24, 2013 at 11:32:30AM +0000, 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:

>> Patchset tested on both versatilepb and realview, using a set of
>> Linux kernel patches written by Arnd Bergmann:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2010-October/029040.html
>> which were in turn tested against real PB926 and PB1176 hardware.
>>
>>
>>  * WARNING WARNING *
>>
>> This patchset will break any use of PCI (including the default SCSI
>> card) on versatilepb with current Linux kernels, because those kernels
>
> Do you mean Versatile/PB and not Versatile/AB, or actually both?

I mean PB. The AB doesn't have a PCI controller (though we incorrectly
model it as having one; I suppose we could patch QEMU to stop doing
that).

>> have the matching bug in interrupt mapping to old QEMU.
>
> How is real hardware working with this bug?

It doesn't. Unless you apply Arnd's patches, PCI support
on real hardware is flat out broken. (This was never noticed
because (a) real hardware is getting rare by now and (b) the
PCI backplane is even rarer.)

>> I've provided a property for enabling the old broken IRQ mapping;
>> this can be enabled with the command line option:
>>       -global versatile_pci.broken-irq-mapping=1
>>
>> (If anybody wants to suggest a better way of handling this please do.)
>
> Do you have a pointer to the corresponding kernel patch? Is it possible
> to get the kernel to detect if it should use the correct or the broken
> IRQ mapping?

I linked to the kernel patches above. It might I guess be possible
to identify a fixed QEMU (if nothing else we could put something
into QEMU that was identifiable); that still leaves existing kernels
breaking, though.

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]