Am 18. Dezember 2022 14:17:48 UTC schrieb "Philippe Mathieu-Daudé"
<phi...@linaro.org>:
>On 18/12/22 11:33, Bernhard Beschow wrote:
>>
>>
>> Am 4. Dezember 2022 19:05:21 UTC schrieb Bernhard Beschow
>> <shen...@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 ?
