qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Philippe Mathieu-Daudé
Subject: Re: [PATCH 00/32] Consolidate PIIX south bridges
Date: Tue, 20 Dec 2022 16:08:57 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.6.0

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]