[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 00/32] Consolidate PIIX south bridges
From: |
Michael S. Tsirkin |
Subject: |
Re: [PATCH 00/32] Consolidate PIIX south bridges |
Date: |
Tue, 20 Dec 2022 18:03:40 -0500 |
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é"
> <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.
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.
- [PATCH 30/32] hw/isa/piix: Consolidate IRQ triggering, (continued)
- [PATCH 30/32] hw/isa/piix: Consolidate IRQ triggering, Bernhard Beschow, 2022/12/04
- [PATCH 32/32] hw/isa/piix: Drop the "3" from the PIIX base class, Bernhard Beschow, 2022/12/04
- Re: [PATCH 00/32] Consolidate PIIX south bridges, Bernhard Beschow, 2022/12/04
- Re: [PATCH 00/32] Consolidate PIIX south bridges, Bernhard Beschow, 2022/12/18
- Re: [PATCH 00/32] Consolidate PIIX south bridges, Michael S. Tsirkin, 2022/12/20
- Re: [PATCH 00/32] Consolidate PIIX south bridges, Michael S. Tsirkin, 2022/12/20