Re: [PATCH 00/32] Consolidate PIIX south bridges

[Bernhard Beschow]

Am 20. Dezember 2022 15:08:57 UTC schrieb "Philippe Mathieu-Daudé" 
<philmd@linaro.org>:
>On 20/12/22 15:48, Michael S. Tsirkin wrote:
>> On Sun, Dec 04, 2022 at 08:05:21PM +0100, Bernhard Beschow wrote:
>>> This series consolidates the implementations of the PIIX3 and PIIX4 south
>>> bridges and is an extended version of [1]. The motivation is to share as 
>>> much
>>> code as possible and to bring both device models to feature parity such that
>>> perhaps PIIX4 can become a drop-in-replacement for PIIX3 in the pc machine. 
>>> This
>>> could resolve the "Frankenstein" PIIX4-PM problem in PIIX3 discussed on this
>>> list before.
>>> 
>>> The series is structured as follows: First, PIIX3 is changed to instantiate
>>> internal devices itself, like PIIX4 does already. Second, PIIX3 gets 
>>> prepared
>>> for the merge with PIIX4 which includes some fixes, cleanups, and renamings.
>>> Third, the same is done for PIIX4. In step four the implementations are 
>>> merged.
>>> Since some consolidations could be done easier with merged implementations, 
>>> the
>>> consolidation continues in step five which concludes the series.
>>> 
>>> One particular challenge in this series was that the PIC of PIIX3 used to be
>>> instantiated outside of the south bridge while some sub functions require a 
>>> PIC
>>> with populated qemu_irqs. This has been solved by introducing a proxy PIC 
>>> which
>>> furthermore allows PIIX3 to be agnostic towards the virtualization 
>>> technology
>>> used (KVM, TCG, Xen). Due to consolidation PIIX4 gained the proxy PIC as 
>>> well.
>>> 
>>> Another challenge was dealing with optional devices where Peter already gave
>>> advice in [1] which this series implements.
>>> 
>>> A challenge still remains with consolidating PCI interrupt handling. There 
>>> are
>>> still board-specific piix3_pci_slot_get_pirq() and piix4_pci_slot_get_pirq()
>>> which are implemented in isa/piix.c. Any advice how to resolve these would 
>>> be
>>> highly appreaciated. See [2] for details.
>>> 
>>> Last but not least there might be some opportunity to consolidate VM state
>>> handling, probably by reusing the one from PIIX3. Since I'm not very 
>>> familiar
>>> with the requirements I didn't touch it so far.
>>> 
>>> Testing done:
>>> * make check
>>> * make check-avocado
>>> * Boot live CD:
>>>    * `qemu-system-x86_64 -M pc -m 2G -accel kvm -cpu host -cdrom 
>>> manjaro-kde-21.3.2-220704-linux515.iso`
>>>    * `qemu-system-x86_64 -M q35 -m 2G -accel kvm -cpu host -cdrom 
>>> manjaro-kde-21.3.2-220704-linux515.iso`
>>> * 'qemu-system-mips64el -M malta -kernel vmlinux-3.2.0-4-5kc-malta -hda 
>>> debian_wheezy_mipsel_standard.qcow2 -append "root=/dev/sda1 console=ttyS0"`
>>> 
>>> v3:
>>> - Introduce one TYPE_ICH9_USB_UHCI(fn) rather than several 
>>> TYPE_ICH9_USB_UHCIx (Philippe)
>>> - Make proxy PIC generic (Philippe)
>>> - Track Malta's PIIX dependencies through KConfig
>>> - Rebase onto Philippe's 'hw/isa/piix4: Remove MIPS Malta specific bits' 
>>> series [3]
>>> - Also rebase onto latest master to resolve merge conflicts. This required 
>>> copying
>>>    Philippe's series as first three patches - please ignore.
>> 
>> So IIUC, you are waiting for Philippe to respin his series then
>> you can include it all in v4, right?
>Correct. And mine is waiting for few more R-b tags.

I've reviewed patches 1 & 3 and patch 2 still has a nanoMIPS TODO. So I think 
we need a v3 there, no? What else is missing?

Best regards,
Bernhard

> If you can Ack
>this series, no need for v4 and I can pick it via mips-next once the
>rest is ready (before Xmas I hope).
>
>Regards.
>
>Phil.