Message ID | 20221204190553.3274-1-shentey@gmail.com |
---|---|
Headers | show |
Series | Consolidate PIIX south bridges | expand |
Sorry, the titles should have contained a "v3"... Am 4. Dezember 2022 19:05:21 UTC schrieb Bernhard Beschow <shentey@gmail.com>: >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] - Use OBJECT_DECLARE_SIMPLE_TYPE() for PIIXState (Mark in v1) Best regards, Bernhard > >- 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 (29): > > hw/mips/Kconfig: Track Malta's PIIX dependencies via Kconfig > > hw/i386/pc_piix: Allow for setting properties before realizing PIIX3 > > south bridge > > hw/usb/hcd-uhci: Introduce TYPE_ defines for device models > > 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/core: Introduce proxy-pic > > hw/isa/piix3: Create Proxy 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: Prefix pci_slot_get_pirq() with "piix3_" > > hw/isa/piix3: Rename typedef PIIX3State to PIIXState > > hw/isa/piix4: Make PIIX4's ACPI and USB functions optional > > hw/isa/piix4: Remove unused code > > hw/isa/piix4: Use Proxy PIC device > > hw/isa/piix4: Reuse struct PIIXState from PIIX3 > > hw/isa/piix4: Rename reset control operations to match PIIX3 > > hw/isa/piix4: Prefix pci_slot_get_pirq() with "piix4_" > > 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 base class with PIIX4 > > hw/isa/piix: Drop the "3" from the PIIX base class > > > >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 > > > > MAINTAINERS | 8 +- > > configs/devices/mips-softmmu/common.mak | 2 - > > hw/core/Kconfig | 3 + > > hw/core/meson.build | 1 + > > hw/core/proxy-pic.c | 70 +++++ > > hw/i386/Kconfig | 4 +- > > hw/i386/pc.c | 16 +- > > hw/i386/pc_piix.c | 71 ++--- > > hw/i386/pc_q35.c | 16 +- > > hw/isa/Kconfig | 10 +- > > hw/isa/lpc_ich9.c | 8 + > > hw/isa/meson.build | 3 +- > > hw/isa/{piix3.c => piix.c} | 302 +++++++++++++++++----- > > hw/isa/piix4.c | 327 ------------------------ > > hw/mips/Kconfig | 2 + > > hw/mips/malta.c | 38 ++- > > hw/usb/hcd-uhci.c | 16 +- > > hw/usb/hcd-uhci.h | 4 + > > include/hw/core/proxy-pic.h | 54 ++++ > > include/hw/i386/ich9.h | 2 + > > include/hw/i386/pc.h | 2 +- > > include/hw/southbridge/piix.h | 30 ++- > > 22 files changed, 520 insertions(+), 469 deletions(-) > > create mode 100644 hw/core/proxy-pic.c > > rename hw/isa/{piix3.c => piix.c} (56%) > > delete mode 100644 hw/isa/piix4.c > > create mode 100644 include/hw/core/proxy-pic.h > > > >-- > >2.38.1 > > >
Am 4. Dezember 2022 19:05:21 UTC schrieb Bernhard Beschow <shentey@gmail.com>: >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. > Ping > > >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 (29): > > hw/mips/Kconfig: Track Malta's PIIX dependencies via Kconfig > > hw/i386/pc_piix: Allow for setting properties before realizing PIIX3 > > south bridge > > hw/usb/hcd-uhci: Introduce TYPE_ defines for device models > > 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/core: Introduce proxy-pic > > hw/isa/piix3: Create Proxy 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: Prefix pci_slot_get_pirq() with "piix3_" > > hw/isa/piix3: Rename typedef PIIX3State to PIIXState > > hw/isa/piix4: Make PIIX4's ACPI and USB functions optional > > hw/isa/piix4: Remove unused code > > hw/isa/piix4: Use Proxy PIC device > > hw/isa/piix4: Reuse struct PIIXState from PIIX3 > > hw/isa/piix4: Rename reset control operations to match PIIX3 > > hw/isa/piix4: Prefix pci_slot_get_pirq() with "piix4_" > > 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 base class with PIIX4 > > hw/isa/piix: Drop the "3" from the PIIX base class > > > >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 > > > > MAINTAINERS | 8 +- > > configs/devices/mips-softmmu/common.mak | 2 - > > hw/core/Kconfig | 3 + > > hw/core/meson.build | 1 + > > hw/core/proxy-pic.c | 70 +++++ > > hw/i386/Kconfig | 4 +- > > hw/i386/pc.c | 16 +- > > hw/i386/pc_piix.c | 71 ++--- > > hw/i386/pc_q35.c | 16 +- > > hw/isa/Kconfig | 10 +- > > hw/isa/lpc_ich9.c | 8 + > > hw/isa/meson.build | 3 +- > > hw/isa/{piix3.c => piix.c} | 302 +++++++++++++++++----- > > hw/isa/piix4.c | 327 ------------------------ > > hw/mips/Kconfig | 2 + > > hw/mips/malta.c | 38 ++- > > hw/usb/hcd-uhci.c | 16 +- > > hw/usb/hcd-uhci.h | 4 + > > include/hw/core/proxy-pic.h | 54 ++++ > > include/hw/i386/ich9.h | 2 + > > include/hw/i386/pc.h | 2 +- > > include/hw/southbridge/piix.h | 30 ++- > > 22 files changed, 520 insertions(+), 469 deletions(-) > > create mode 100644 hw/core/proxy-pic.c > > rename hw/isa/{piix3.c => piix.c} (56%) > > delete mode 100644 hw/isa/piix4.c > > create mode 100644 include/hw/core/proxy-pic.h > > > >-- > >2.38.1 > > >
On 18/12/22 11:33, Bernhard Beschow wrote: > > > Am 4. Dezember 2022 19:05:21 UTC schrieb Bernhard Beschow <shentey@gmail.com>: >> 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. >> > > Ping Could you review patches 1-3?
Am 18. Dezember 2022 14:17:48 UTC schrieb "Philippe Mathieu-Daudé" <philmd@linaro.org>: >On 18/12/22 11:33, Bernhard Beschow wrote: >> >> >> Am 4. Dezember 2022 19:05:21 UTC schrieb Bernhard Beschow <shentey@gmail.com>: >>> 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. >>> >> >> Ping > >Could you review patches 1-3? I reviewed patches 1 & 3. Patch 2 still has the todo [1]. Could you respin v2? [1] https://lists.nongnu.org/archive/html/qemu-devel/2022-10/msg05367.html ?
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? > 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 (29): > hw/mips/Kconfig: Track Malta's PIIX dependencies via Kconfig > hw/i386/pc_piix: Allow for setting properties before realizing PIIX3 > south bridge > hw/usb/hcd-uhci: Introduce TYPE_ defines for device models > 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/core: Introduce proxy-pic > hw/isa/piix3: Create Proxy 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: Prefix pci_slot_get_pirq() with "piix3_" > hw/isa/piix3: Rename typedef PIIX3State to PIIXState > hw/isa/piix4: Make PIIX4's ACPI and USB functions optional > hw/isa/piix4: Remove unused code > hw/isa/piix4: Use Proxy PIC device > hw/isa/piix4: Reuse struct PIIXState from PIIX3 > hw/isa/piix4: Rename reset control operations to match PIIX3 > hw/isa/piix4: Prefix pci_slot_get_pirq() with "piix4_" > 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 base class with PIIX4 > hw/isa/piix: Drop the "3" from the PIIX base class > > 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 > > MAINTAINERS | 8 +- > configs/devices/mips-softmmu/common.mak | 2 - > hw/core/Kconfig | 3 + > hw/core/meson.build | 1 + > hw/core/proxy-pic.c | 70 +++++ > hw/i386/Kconfig | 4 +- > hw/i386/pc.c | 16 +- > hw/i386/pc_piix.c | 71 ++--- > hw/i386/pc_q35.c | 16 +- > hw/isa/Kconfig | 10 +- > hw/isa/lpc_ich9.c | 8 + > hw/isa/meson.build | 3 +- > hw/isa/{piix3.c => piix.c} | 302 +++++++++++++++++----- > hw/isa/piix4.c | 327 ------------------------ > hw/mips/Kconfig | 2 + > hw/mips/malta.c | 38 ++- > hw/usb/hcd-uhci.c | 16 +- > hw/usb/hcd-uhci.h | 4 + > include/hw/core/proxy-pic.h | 54 ++++ > include/hw/i386/ich9.h | 2 + > include/hw/i386/pc.h | 2 +- > include/hw/southbridge/piix.h | 30 ++- > 22 files changed, 520 insertions(+), 469 deletions(-) > create mode 100644 hw/core/proxy-pic.c > rename hw/isa/{piix3.c => piix.c} (56%) > delete mode 100644 hw/isa/piix4.c > create mode 100644 include/hw/core/proxy-pic.h > > -- > 2.38.1 >
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). Regards. Phil.
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. Series Reviewed-by: Michael S. Tsirkin <mst@redhat.com> ok to be merged through mips tree. > 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. > > 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 (29): > hw/mips/Kconfig: Track Malta's PIIX dependencies via Kconfig > hw/i386/pc_piix: Allow for setting properties before realizing PIIX3 > south bridge > hw/usb/hcd-uhci: Introduce TYPE_ defines for device models > 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/core: Introduce proxy-pic > hw/isa/piix3: Create Proxy 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: Prefix pci_slot_get_pirq() with "piix3_" > hw/isa/piix3: Rename typedef PIIX3State to PIIXState > hw/isa/piix4: Make PIIX4's ACPI and USB functions optional > hw/isa/piix4: Remove unused code > hw/isa/piix4: Use Proxy PIC device > hw/isa/piix4: Reuse struct PIIXState from PIIX3 > hw/isa/piix4: Rename reset control operations to match PIIX3 > hw/isa/piix4: Prefix pci_slot_get_pirq() with "piix4_" > 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 base class with PIIX4 > hw/isa/piix: Drop the "3" from the PIIX base class > > 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 > > MAINTAINERS | 8 +- > configs/devices/mips-softmmu/common.mak | 2 - > hw/core/Kconfig | 3 + > hw/core/meson.build | 1 + > hw/core/proxy-pic.c | 70 +++++ > hw/i386/Kconfig | 4 +- > hw/i386/pc.c | 16 +- > hw/i386/pc_piix.c | 71 ++--- > hw/i386/pc_q35.c | 16 +- > hw/isa/Kconfig | 10 +- > hw/isa/lpc_ich9.c | 8 + > hw/isa/meson.build | 3 +- > hw/isa/{piix3.c => piix.c} | 302 +++++++++++++++++----- > hw/isa/piix4.c | 327 ------------------------ > hw/mips/Kconfig | 2 + > hw/mips/malta.c | 38 ++- > hw/usb/hcd-uhci.c | 16 +- > hw/usb/hcd-uhci.h | 4 + > include/hw/core/proxy-pic.h | 54 ++++ > include/hw/i386/ich9.h | 2 + > include/hw/i386/pc.h | 2 +- > include/hw/southbridge/piix.h | 30 ++- > 22 files changed, 520 insertions(+), 469 deletions(-) > create mode 100644 hw/core/proxy-pic.c > rename hw/isa/{piix3.c => piix.c} (56%) > delete mode 100644 hw/isa/piix4.c > create mode 100644 include/hw/core/proxy-pic.h > > -- > 2.38.1 >
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] https://lists.nongnu.org/archive/html/qemu-devel/2022-11/msg03310.html > >Regards. > >Phil.
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.
Am 20. Dezember 2022 15:30:00 UTC schrieb "Michael S. Tsirkin" <mst@redhat.com>: >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. > >Series > >Reviewed-by: Michael S. Tsirkin <mst@redhat.com> > >ok to be merged through mips tree. Thanks! > >> 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. >> >> 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 (29): >> hw/mips/Kconfig: Track Malta's PIIX dependencies via Kconfig >> hw/i386/pc_piix: Allow for setting properties before realizing PIIX3 >> south bridge >> hw/usb/hcd-uhci: Introduce TYPE_ defines for device models >> 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/core: Introduce proxy-pic >> hw/isa/piix3: Create Proxy 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: Prefix pci_slot_get_pirq() with "piix3_" >> hw/isa/piix3: Rename typedef PIIX3State to PIIXState >> hw/isa/piix4: Make PIIX4's ACPI and USB functions optional >> hw/isa/piix4: Remove unused code >> hw/isa/piix4: Use Proxy PIC device >> hw/isa/piix4: Reuse struct PIIXState from PIIX3 >> hw/isa/piix4: Rename reset control operations to match PIIX3 >> hw/isa/piix4: Prefix pci_slot_get_pirq() with "piix4_" >> 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 base class with PIIX4 >> hw/isa/piix: Drop the "3" from the PIIX base class >> >> 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 >> >> MAINTAINERS | 8 +- >> configs/devices/mips-softmmu/common.mak | 2 - >> hw/core/Kconfig | 3 + >> hw/core/meson.build | 1 + >> hw/core/proxy-pic.c | 70 +++++ >> hw/i386/Kconfig | 4 +- >> hw/i386/pc.c | 16 +- >> hw/i386/pc_piix.c | 71 ++--- >> hw/i386/pc_q35.c | 16 +- >> hw/isa/Kconfig | 10 +- >> hw/isa/lpc_ich9.c | 8 + >> hw/isa/meson.build | 3 +- >> hw/isa/{piix3.c => piix.c} | 302 +++++++++++++++++----- >> hw/isa/piix4.c | 327 ------------------------ >> hw/mips/Kconfig | 2 + >> hw/mips/malta.c | 38 ++- >> hw/usb/hcd-uhci.c | 16 +- >> hw/usb/hcd-uhci.h | 4 + >> include/hw/core/proxy-pic.h | 54 ++++ >> include/hw/i386/ich9.h | 2 + >> include/hw/i386/pc.h | 2 +- >> include/hw/southbridge/piix.h | 30 ++- >> 22 files changed, 520 insertions(+), 469 deletions(-) >> create mode 100644 hw/core/proxy-pic.c >> rename hw/isa/{piix3.c => piix.c} (56%) >> delete mode 100644 hw/isa/piix4.c >> create mode 100644 include/hw/core/proxy-pic.h >> >> -- >> 2.38.1 >> >
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.
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.