Re: [Qemu-devel] [PATCH 1/5] i8259: qdev-ify creation

["Andreas Färber" <andreas.faerber@web.de>]

Am 12.01.2012 09:09, schrieb Jan Kiszka:
> On 2012-01-12 09:05, Alexander Graf wrote:
>>
>> On 12.01.2012, at 09:00, Jan Kiszka wrote:
>>
>>> On 2012-01-12 08:58, Alexander Graf wrote:
>>>>
>>>> On 12.01.2012, at 08:35, Jan Kiszka wrote:
>>>>
>>>>> On 2012-01-12 01:04, Andreas Färber wrote:
>>>>>> Alex,
>>>>>>
>>>>>> I have this in my mailbox, but I'm still waiting for an SoB. Hervé?
>>>>>>
>>>>>> Regards,
>>>>>> Andreas
>>>>>>
>>>>>> -------- Original-Nachricht --------
>>>>>> Betreff: [PATCH 1/5] i8259: qdev-ify creation
>>>>>> Datum: Sun, 26 Jun 2011 14:47:09 +0200
>>>>>> Von: Hervé Poussineau <hpoussin@reactos.org>
>>>>>> An: andreas.faerber@web.de
>>>>>> Kopie (CC): Hervé Poussineau <hpoussin@reactos.org>
>>>>>>
>>>>>> ---
>>>>>> hw/i8259.c |   53 +++++++++++++++++++++++++++++++++++++++++++++++++----
>>>>>> 1 files changed, 49 insertions(+), 4 deletions(-)
[snip]
>>>>> This is obsolete. The i8259 has been significantly refactored (into two
>>>>> ISA devices) and qdev'ified some moons ago.
>>>>
>>>> The reason we were discussing this was a circular dependency on PREP.
>>>>
>>>> The PIC is sitting on the ISA bus.
>>>> The ISA bus is behind a PCI-ISA bridge
>>>> the PCI-ISA bridge is behind a PCI host controller
>>>> the PCI host controller needs interrupt lines in its initialization which are attached to the PIC
>>>>
>>>> Any good ideas on how to resolve this? :)
>>>
>>> As we do this always: Split up initialization and IRQ line wiring.
>>
>> Well, yes, the theory is obvious. How would this look like in practice? To create a PIC device I need a bus:
>>
>>     dev = isa_create(bus, "isa-i8259");
>>
>> But to create the bus, I need an interrupt line, which I only get after I created the PIC device.
> 
> ISA bus creation and IRQ assignment are split up IIRC.

So far I haven't found a really qdev'ified example though. mips_malta
uses qemu_irq_proxy() to pre-initialize 16 IRQ lines IIUC, but it does
everything in a flat, sequential way, creating the i8259 on the board
rather than on a chipset.

I'll send v2 of my series later, with the part that works today for
Anthony and the bridge that breaks. I'll cc you.

Maybe we can use a QOM property to access the i8259 on the i82378?

I'm aware we don't have PicState2 in upstream, so this patch doesn't
apply; the interesting part from my view was that it adds a SysBus
device as opposed to ISADevice, so doesn't need the ISABus.
Going down that route would require to split PicState into an
ISAPicState and SysBusPicState with shared core.

Andreas