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

[Bernhard Beschow]

Am 20. Dezember 2022 22:35:23 UTC schrieb Bernhard Beschow <shentey@gmail.com>:
>
>
>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. 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).
>
>Nice!
>
>Shall we integrate [1] 'Decouple INTx-to-LNKx routing from south bridges' via 
>mips-next rather than x86 as well? This would 1/ make the consolidation more 
>complete and 2/ simplify the process since these series conflict with one 
>another.
>
>I could rebase [1] onto this series (perhaps simpler to review) or the other 
>way around (less code movement). Please let me know what you'd prefer.

[1] is now queued to mips-next, so I've respun a v4 of this series.

Thanks,
Bernhard

>
>[1] https://lists.nongnu.org/archive/html/qemu-devel/2022-11/msg03310.html
>
>>
>>Regards.
>>
>>Phil.