Re: [PATCH v5 00/31] Consolidate PIIX south bridges

[Bernhard Beschow]

Am 7. Januar 2023 23:57:32 UTC schrieb Mark Cave-Ayland 
<mark.cave-ayland@ilande.co.uk>:
>On 05/01/2023 14:31, 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. Note that 
>> the
>> first three patches are only included to avoid merge conflicts with mips-next
>> -- please ignore.
>> 
>> 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.
>> 
>> 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.
>> 
>> v5:
>> - Pick up Reviewed-by tags from 
>> https://lists.nongnu.org/archive/html/qemu-devel/2023-01/msg00116.html
>> - Add patch to make usage of the isa_pic global more type-safe
>> - Re-introduce isa-pic as PIC specific proxy (Mark)
>> Note that both patches are unreviewed -> Mark?
>> 
>> Furthermore, patch 'hw/i386/pc_piix: Associate pci_map_irq_fn as soon as PCI 
>> bus
>> is created' needs review and could be merged into
>> https://lists.nongnu.org/archive/html/qemu-devel/2022-11/msg03312.html .
>> 
>> Testing done:
>> * make check
>> * 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"`
>> 
>> Based-on: <20221120150550.63059-1-shentey@gmail.com>
>>            "[PATCH v2 0/3] Decouple INTx-to-LNKx routing from south bridges"
>> 
>> v4:
>> - Rebase onto "[PATCH v2 0/3] Decouple INTx-to-LNKx routing from south 
>> bridges"
>>    since it is already queued via mips-next. This eliminates patches
>>    'hw/isa/piix3: Prefix pci_slot_get_pirq() with "piix3_"' and 
>> 'hw/isa/piix4:
>>    Prefix pci_slot_get_pirq() with "piix4_"'.
>> - Squash 'hw/isa/piix: Drop the "3" from the PIIX base class' into
>>    'hw/isa/piix3: Rename typedef PIIX3State to PIIXState'. I originally only
>>    split these patches since I wasn't sure whether renaming a type was 
>> allowed.
>> - Add new patch 'hw/i386/pc_piix: Associate pci_map_irq_fn as soon as PCI 
>> bus is
>>    created' for forther cleanup of INTx-to-LNKx route decoupling.
>> 
>> 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.
>> 
>> v2:
>> - Introduce TYPE_ defines for IDE and USB device models (Mark)
>> - Omit unexporting of PIIXState (Mark)
>> - Improve commit message of patch 5 to mention reset triggering through PCI
>>    configuration space (Mark)
>> - Move reviewed patches w/o dependencies to the bottom of the series for 
>> early
>>    upstreaming
>> 
>> [1] https://lists.nongnu.org/archive/html/qemu-devel/2022-07/msg02348.html
>> [2] https://lists.nongnu.org/archive/html/qemu-devel/2022-11/msg03310.html
>> [3] https://lists.nongnu.org/archive/html/qemu-devel/2022-10/msg05367.html
>> 
>> Bernhard Beschow (28):
>>    hw/mips/Kconfig: Track Malta's PIIX dependencies via Kconfig
>>    hw/usb/hcd-uhci: Introduce TYPE_ defines for device models
>>    hw/i386/pc_piix: Associate pci_map_irq_fn as soon as PCI bus is
>>      created
>>    hw/i386/pc_piix: Allow for setting properties before realizing PIIX3
>>      south bridge
>>    hw/i386/pc: Create RTC controllers in south bridges
>>    hw/i386/pc: No need for rtc_state to be an out-parameter
>>    hw/isa/piix3: Create USB controller in host device
>>    hw/isa/piix3: Create power management controller in host device
>>    hw/intc/i8259: Make using the isa_pic singleton more type-safe
>>    hw/intc/i8259: Introduce i8259 proxy "isa-pic"
>>    hw/isa/piix3: Create ISA PIC in host device
>>    hw/isa/piix3: Create IDE controller in host device
>>    hw/isa/piix3: Wire up ACPI interrupt internally
>>    hw/isa/piix3: Resolve redundant PIIX_NUM_PIC_IRQS
>>    hw/isa/piix3: Rename pci_piix3_props for sharing with PIIX4
>>    hw/isa/piix3: Rename piix3_reset() for sharing with PIIX4
>>    hw/isa/piix3: Drop the "3" from PIIX base class
>>    hw/isa/piix4: Make PIIX4's ACPI and USB functions optional
>>    hw/isa/piix4: Remove unused inbound ISA interrupt lines
>>    hw/isa/piix4: Use ISA PIC device
>>    hw/isa/piix4: Reuse struct PIIXState from PIIX3
>>    hw/isa/piix4: Rename reset control operations to match PIIX3
>>    hw/isa/piix3: Merge hw/isa/piix4.c
>>    hw/isa/piix: Harmonize names of reset control memory regions
>>    hw/isa/piix: Reuse PIIX3 base class' realize method in PIIX4
>>    hw/isa/piix: Rename functions to be shared for interrupt triggering
>>    hw/isa/piix: Consolidate IRQ triggering
>>    hw/isa/piix: Share PIIX3's base class with PIIX4
>> 
>> Philippe Mathieu-Daudé (3):
>>    hw/mips/malta: Introduce PIIX4_PCI_DEVFN definition
>>    hw/mips/malta: Set PIIX4 IRQ routes in embedded bootloader
>>    hw/isa/piix4: Correct IRQRC[A:D] reset values
>> 
>>   configs/devices/mips-softmmu/common.mak |   2 -
>>   hw/usb/hcd-uhci.h                       |   4 +
>>   include/hw/i386/ich9.h                  |   2 +
>>   include/hw/i386/pc.h                    |   2 +-
>>   include/hw/intc/i8259.h                 |  25 +-
>>   include/hw/southbridge/piix.h           |  30 ++-
>>   include/qemu/typedefs.h                 |   1 +
>>   hw/i386/pc.c                            |  16 +-
>>   hw/i386/pc_piix.c                       |  77 +++---
>>   hw/i386/pc_q35.c                        |  16 +-
>>   hw/intc/i8259.c                         |  38 ++-
>>   hw/isa/lpc_ich9.c                       |   8 +
>>   hw/isa/{piix3.c => piix.c}              | 274 ++++++++++++++++-----
>>   hw/isa/piix4.c                          | 302 ------------------------
>>   hw/mips/malta.c                         |  38 ++-
>>   hw/usb/hcd-uhci.c                       |  16 +-
>>   MAINTAINERS                             |   6 +-
>>   hw/i386/Kconfig                         |   4 +-
>>   hw/isa/Kconfig                          |   8 +-
>>   hw/isa/meson.build                      |   3 +-
>>   hw/mips/Kconfig                         |   2 +
>>   21 files changed, 419 insertions(+), 455 deletions(-)
>>   rename hw/isa/{piix3.c => piix.c} (57%)
>>   delete mode 100644 hw/isa/piix4.c
>
>I've made a few comments on minor things I spotted reading through the series, 
>but in general I'm happy with this series as it does a lot of good tidy-up 
>work (and even if any problems do occur later, it's early enough in the 
>development cycle to catch them in plenty of time).

Thanks!

>Phil - over to you!

Shall I respin? I could integrate my PCI series into this one in order to avoid 
the outdated MIPS patches while still delivering a working series. Yes/No?

Best regards,
Bernhard

>
>
>ATB,
>
>Mark.