On Tue, Dec 20, 2022 at 10:35:23PM +0000, Bernhard Beschow wrote: > > > Am 20. Dezember 2022 15:08:57 UTC schrieb "Philippe Mathieu-Daudé" > <phi...@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.
OK I'll drop it from my tree. > 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] https://lists.nongnu.org/archive/html/qemu-devel/2022-11/msg03310.html > > > > >Regards. > > > >Phil.