qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 07/11] versatile_pci: Implement the correct P


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v2 07/11] versatile_pci: Implement the correct PCI IRQ mapping
Date: Tue, 26 Mar 2013 11:17:55 +0000

On 26 March 2013 11:08, Arnd Bergmann <address@hidden> wrote:
> On Tuesday 26 March 2013, Peter Maydell wrote:
>> On 26 March 2013 10:54, Arnd Bergmann <address@hidden> wrote:
>> > Yes, very good.  We will probably introduce sparse irq support on
>> > versatile in the near future, and then the value we write into the
>> > PCI_INTERRUPT_LINE field will become arbitrary from qemu's point
>> > of view, but I will make sure that we fix the interrupt mapping
>> > in the kernel at the same time so we always fall into the
>> > "s->broken_irq_mapping = false;" case.
>>
>> Yeah, as long as you avoid the number 27 you're ok :-)
>
> Good point. I guess we'll have to keep using a legacy domain for
> versatile then.

I'm happy to provide some other way for QEMU to detect a
new working kernel if you want to implement one in the
kernel, if that's cleaner.

>> > We also need to find a way to make the new kernel work with
>> > an old qemu, and I think we can do that by using the versatile-dt
>> > board type with a PCI device node that sets all four lines to
>> > 27, while using the actual interrupt lines for the default
>> > versatile device tree.
>>
>> Personally I'd be happy for you to just say "needs a new QEMU".
>> The broken QEMU is missing so much (including working memory
>> windows) that I think it would be a pain to get the kernel to
>> cope with it.
>
> But it was working earlier, so I'd definitely try not to break
> if at all possible. A lot of people use the verstatile qemu
> model to run kernels and I would not want to deal with the
> complaints I'd get if we break those. Using a separate dts
> file seems easy enough.

Yeah, but it only worked earlier because the kernel PCI controller
support was so broken and limited, I think. If you run a new
kernel with the old QEMU it won't work even if you avoid the
irq-mapping issues.

Also I really don't want to get people into the habit of
using a QEMU-specific dts file. The result will be that
nobody will ever move on from that dts file to the one that
gets used with real hardware.

Plus, you guys make kernel changes that break running on
QEMU all the time, so I don't see that as a big deal really.
(Most recently, vexpress needed a pile of support for the
config registers that define the voltage regulators and clocks.)

-- PMM



reply via email to

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