Re: [PATCH v4 12/30] hw/core: Introduce proxy-pic

[Bernhard Beschow]

Am 4. Januar 2023 20:31:15 UTC schrieb "Philippe Mathieu-Daudé" 
<philmd@linaro.org>:
>On 4/1/23 21:12, Bernhard Beschow wrote:
>> 
>> 
>> Am 4. Januar 2023 16:35:57 UTC schrieb "Philippe Mathieu-Daudé" 
>> <philmd@linaro.org>:
>>> On 4/1/23 17:01, Bernhard Beschow wrote:
>>>> Am 4. Januar 2023 14:37:29 UTC schrieb "Philippe Mathieu-Daudé" 
>>>> <philmd@linaro.org>:
>>>>> On 21/12/22 17:59, Bernhard Beschow wrote:
>>>>>> Having a proxy PIC allows for ISA PICs to be created and wired up in
>>>>>> southbridges. This is especially useful for PIIX3 for two reasons:
>>>>>> First, the southbridge doesn't need to care about the virtualization
>>>>>> technology used (KVM, TCG, Xen) due to in-IRQs (where devices get
>>>>>> attached) and out-IRQs (which will trigger the IRQs of the respective
>>>>>> virtzalization technology) are separated. Second, since the in-IRQs are
>>> 
>>> Typo "virtualization".
>> 
>> Fixed...
>
>
>>>>> Why restrict to 16 and not use a class property and allocate
>>>>> on the heap? See TYPE_SPLIT_IRQ for example.
>>>> 
>>>> TYPE_SPLIT_IRQ doesn't allocate on the heap and instead has a hardcoded 
>>>> limit of MAX_SPLIT_LINES which equals 16 ;)
>>>> 
>>>> I was unsure on when to free the memory and how to dispose the elements so 
>>>> I went with this solution for simplicity. I'll look for inspitation in 
>>>> other device models and respin.
>>> 
>>> Oh indeed. Well this model as is is OK, but it could be more useful
>>> if able to proxy any range of IRQs.
>> 
>> I've responded with a new, single patch to this patch. Is that okay or shall 
>> I respin the whole series? Is anything missing? IIUC we can make the 
>> proxy-pic dynamic in a follow-up?
>
>I think we are good :) If you can point me to a branch with all your patches, 
>I could verify everything is properly applied locally.

Sure, here we go: https://github.com/shentok/qemu/commits/piix-consolidate

Thanks for your help and for picking up this beast ;)

>
>>> I have the feeling we are cycling around this IRQ proxy:
>>> 
>>> 22ec3283ef ("irq: introduce qemu_irq_proxy()")
>>> 078778c5a5 ("piix4: Add an i8259 Interrupt Controller as specified in 
>>> datasheet")
>>> fc531e7cab ("Revert "irq: introduce qemu_irq_proxy()"")
>>> 
>>> What is our problem? IRQ lines connect 2 devices in a fixed direction.
>>> Current model expects one edge to be wired to a device before wiring
>>> the other device, so device composition with IRQs in middle is
>>> impossible? If so, this doesn't scale with dynamic machine creation.
>> 
>> My PIIX consolidation series and even more so my effort to make the VT82xx 
>> south bridges work with the PC machine are indeed bottom-up explorations of 
>> dynamic/flexible machine creation.
>
>Yeah (I have been there too...).

I've seen it. Eventually I'll also pick up your work of eliminating the isabus 
global...

Best regards,
Bernhard

> Also Mark Cave-Ayland confirmed
>elsewhere in this thread that yourv effort points toward the right
>direction :)
>
>Regards,
>
>Phil.