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

[Philippe Mathieu-Daudé]

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.

> > 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...). Also Mark Cave-Ayland confirmed
elsewhere in this thread that yourv effort points toward the right
direction :)

Regards,

Phil.