Re: [PATCH v8 00/29] Consolidate PIIX south bridges
Am 11. Oktober 2023 20:18:00 UTC schrieb "Michael S. Tsirkin" : >On Wed, Oct 11, 2023 at 06:57:07PM +, Bernhard Beschow wrote: >> >> >> Am 8. Oktober 2023 17:56:48 UTC schrieb Chuck Zmudzinski : >> >On 10/7/23 8:38 AM, Bernhard Beschow wrote: >> >> This series consolidates the implementations of the PIIX3 and PIIX4 south >> >> bridges and makes PIIX4 usable in the PC machine via an experimental >> >> command >> >> line parameter. The motivation is to resolve duplicate code between the >> >> device >> >> models as well as resolving the "Frankenstein" PIIX4-PM problem in PIIX3 >> >> discussed on this list before. >> >> >> >> The series is structured as follows: >> >> >> >> Patches 1-8 are preparational patches necessary for moving all sub >> >> devices into >> >> PIIX3, like was done for PIIX4. In isolation these patches can also be >> >> seen as >> >> general x86 machine cleanup sub series which has merit in its own right >> >> -- and >> >> could be applied to master if the remainder of the series takes longer to >> >> review. >> >> >> >> Patches 9-13 move PIIX3 sub devices into one device model like already >> >> done for PIIX4. Together with the previous sub series these patches form a >> >> bigger sub series which also has merit in its own right, and could be >> >> applied >> >> independent of the remainder of this series as well. >> >> >> >> The remainder of this series consolidates the PIIX3 and PIIX4 device >> >> models. >> >> The culmination point is the last commit which makes PIIX4 usable in the >> >> PC >> >> machine. >> >> >> >> One challenge was dealing with optional devices where Peter already gave >> >> advice >> >> in [1] which this series implements. Although PIIX4 is now usable in the >> >> PC >> >> machine it still has a different binary layout in its VM state. >> >> >> >> Testing done: >> >> * `make check` >> >> * `qemu-system-x86_64 -M pc -m 2G -accel kvm -cdrom >> >> manjaro-kde-21.3.2-220704-linux515.iso` >> >> * `qemu-system-x86_64 -M pc,x-south-bridge=piix4-isa -m 2G -accel kvm >> >> -cdrom >> >> manjaro-kde-21.3.2-220704-linux515.iso` >> >> * `qemu-system-x86_64 -M q35 -m 2G -accel kvm -cdrom >> >> manjaro-kde-21.3.2-220704-linux515.iso` >> >> * `qemu-system-mips64el -M malta -cpu 5KEc -m 1G -kernel kernel -initrd >> >> initrd >> >> -append "root=LABEL=rootfs console=ttyS0" -drive file=image.qcow2` >> >> * `qemu-system-mips64el -M malta -bios yamon-02.22.bin` >> >> * Run HVM domU guest under Xen with >> >> manjaro-kde-21.3.2-220704-linux515.iso image >> > >> >I did some preliminary tests of this patch series on some Xen HVM domU >> >guests I have >> >that use the xenfv / pc machine and depend on the current PIIX3 >> >implementation. >> >So far there are no regressions in my tests. I use libxl or libvirt to >> >manage the >> >Xen guests. >> >> Thanks, nice to read! >> >> > >> >I have not (yet) tested the experimental option that makes PIIX4 useable in >> >the xenfv / pc >> >machines. IIUC, that would require a patch to hvmloader/pci.c in Xen tools >> >so Xen's >> >hvmloader recognizes the PIIX4 pci device id [1], and a patch to libxl so >> >libxl can >> >optionally launch qemu with the new experimental option enabled. >> > >> >Since this patch series affects the xenfv machine, I added the Xen x86 >> >maintainers to >> >the Cc list and Jason Andryuk who is credited with discovering the >> >necessary patch to >> >hvmloader/pci.c. >> >> Good idea. In the next iteration, I'll cc the respective email addresses >> from the MAINTAINERS file which hopefully reaches all relevant people. > >there will be a next version then? No, unless review comments will require it. > >> Best regards, >> Bernhard >> >> > >> >[1] >> >https://lore.kernel.org/qemu-devel/b0ff78f4-1193-495b-919c-84a1ff8ad...@gmail.com/ >> > >> >> >> >> v8: >> >> - Wire ISA interrupts before device realization >> >> - Optionally allow a PIC and PIT to be instantiated in PIIX3 for >> >> compatiblity >> >> with PIIX4 >> >> - Touch ICH9 LPC as far as required for PIIX consolidation >> >> - Make PIIX4 usable in the PC machine via an experimental option >> >> - Review and rework history, touching every commit and drop R-b tags when >> >> changes became too large >> >> >> >> v7: >> >> - Rebase onto master >> >> - Avoid the PIC proxy (Phil) >> >> The motivation for the PIC proxy was to allow for wiring up ISA >> >> interrupts in >> >> the south bridges. ISA interrupt wiring requires the GPIO lines to be >> >> populated already but pc_piix assigned the interrupts only after >> >> realizing >> >> PIIX3. By shifting interrupt assignment before realizing, the ISA >> >> interrupts >> >> are already populated during PIIX3's realize phase where the ISA >> >> interrupts >> >> are wired up. >> >> - New patches: >> >> * hw/isa/piix4: Reuse struct PIIXState from PIIX3 >> >> * hw/isa/piix4: Create the "intr" property during init() already >> >> - Patches
Re: [PATCH v8 00/29] Consolidate PIIX south bridges
On Wed, Oct 11, 2023 at 06:57:07PM +, Bernhard Beschow wrote: > > > Am 8. Oktober 2023 17:56:48 UTC schrieb Chuck Zmudzinski : > >On 10/7/23 8:38 AM, Bernhard Beschow wrote: > >> This series consolidates the implementations of the PIIX3 and PIIX4 south > >> bridges and makes PIIX4 usable in the PC machine via an experimental > >> command > >> line parameter. The motivation is to resolve duplicate code between the > >> device > >> models as well as resolving the "Frankenstein" PIIX4-PM problem in PIIX3 > >> discussed on this list before. > >> > >> The series is structured as follows: > >> > >> Patches 1-8 are preparational patches necessary for moving all sub devices > >> into > >> PIIX3, like was done for PIIX4. In isolation these patches can also be > >> seen as > >> general x86 machine cleanup sub series which has merit in its own right -- > >> and > >> could be applied to master if the remainder of the series takes longer to > >> review. > >> > >> Patches 9-13 move PIIX3 sub devices into one device model like already > >> done for PIIX4. Together with the previous sub series these patches form a > >> bigger sub series which also has merit in its own right, and could be > >> applied > >> independent of the remainder of this series as well. > >> > >> The remainder of this series consolidates the PIIX3 and PIIX4 device > >> models. > >> The culmination point is the last commit which makes PIIX4 usable in the PC > >> machine. > >> > >> One challenge was dealing with optional devices where Peter already gave > >> advice > >> in [1] which this series implements. Although PIIX4 is now usable in the PC > >> machine it still has a different binary layout in its VM state. > >> > >> Testing done: > >> * `make check` > >> * `qemu-system-x86_64 -M pc -m 2G -accel kvm -cdrom > >> manjaro-kde-21.3.2-220704-linux515.iso` > >> * `qemu-system-x86_64 -M pc,x-south-bridge=piix4-isa -m 2G -accel kvm > >> -cdrom > >> manjaro-kde-21.3.2-220704-linux515.iso` > >> * `qemu-system-x86_64 -M q35 -m 2G -accel kvm -cdrom > >> manjaro-kde-21.3.2-220704-linux515.iso` > >> * `qemu-system-mips64el -M malta -cpu 5KEc -m 1G -kernel kernel -initrd > >> initrd > >> -append "root=LABEL=rootfs console=ttyS0" -drive file=image.qcow2` > >> * `qemu-system-mips64el -M malta -bios yamon-02.22.bin` > >> * Run HVM domU guest under Xen with manjaro-kde-21.3.2-220704-linux515.iso > >> image > > > >I did some preliminary tests of this patch series on some Xen HVM domU > >guests I have > >that use the xenfv / pc machine and depend on the current PIIX3 > >implementation. > >So far there are no regressions in my tests. I use libxl or libvirt to > >manage the > >Xen guests. > > Thanks, nice to read! > > > > >I have not (yet) tested the experimental option that makes PIIX4 useable in > >the xenfv / pc > >machines. IIUC, that would require a patch to hvmloader/pci.c in Xen tools > >so Xen's > >hvmloader recognizes the PIIX4 pci device id [1], and a patch to libxl so > >libxl can > >optionally launch qemu with the new experimental option enabled. > > > >Since this patch series affects the xenfv machine, I added the Xen x86 > >maintainers to > >the Cc list and Jason Andryuk who is credited with discovering the necessary > >patch to > >hvmloader/pci.c. > > Good idea. In the next iteration, I'll cc the respective email addresses from > the MAINTAINERS file which hopefully reaches all relevant people. there will be a next version then? > Best regards, > Bernhard > > > > >[1] > >https://lore.kernel.org/qemu-devel/b0ff78f4-1193-495b-919c-84a1ff8ad...@gmail.com/ > > > >> > >> v8: > >> - Wire ISA interrupts before device realization > >> - Optionally allow a PIC and PIT to be instantiated in PIIX3 for > >> compatiblity > >> with PIIX4 > >> - Touch ICH9 LPC as far as required for PIIX consolidation > >> - Make PIIX4 usable in the PC machine via an experimental option > >> - Review and rework history, touching every commit and drop R-b tags when > >> changes became too large > >> > >> v7: > >> - Rebase onto master > >> - Avoid the PIC proxy (Phil) > >> The motivation for the PIC proxy was to allow for wiring up ISA > >> interrupts in > >> the south bridges. ISA interrupt wiring requires the GPIO lines to be > >> populated already but pc_piix assigned the interrupts only after > >> realizing > >> PIIX3. By shifting interrupt assignment before realizing, the ISA > >> interrupts > >> are already populated during PIIX3's realize phase where the ISA > >> interrupts > >> are wired up. > >> - New patches: > >> * hw/isa/piix4: Reuse struct PIIXState from PIIX3 > >> * hw/isa/piix4: Create the "intr" property during init() already > >> - Patches with substantial changes (Reviewed-by dropped): > >> * hw/isa/piix3: Move ISA bus IRQ assignments into host device > >> > >> v6: > >> - Fix some comments about TYPE_ISA_PIC (Mark) ... and use it consistently > >> within the patch series. > >>
Re: [PATCH v8 00/29] Consolidate PIIX south bridges
Am 8. Oktober 2023 17:56:48 UTC schrieb Chuck Zmudzinski : >On 10/7/23 8:38 AM, Bernhard Beschow wrote: >> This series consolidates the implementations of the PIIX3 and PIIX4 south >> bridges and makes PIIX4 usable in the PC machine via an experimental command >> line parameter. The motivation is to resolve duplicate code between the >> device >> models as well as resolving the "Frankenstein" PIIX4-PM problem in PIIX3 >> discussed on this list before. >> >> The series is structured as follows: >> >> Patches 1-8 are preparational patches necessary for moving all sub devices >> into >> PIIX3, like was done for PIIX4. In isolation these patches can also be seen >> as >> general x86 machine cleanup sub series which has merit in its own right -- >> and >> could be applied to master if the remainder of the series takes longer to >> review. >> >> Patches 9-13 move PIIX3 sub devices into one device model like already >> done for PIIX4. Together with the previous sub series these patches form a >> bigger sub series which also has merit in its own right, and could be applied >> independent of the remainder of this series as well. >> >> The remainder of this series consolidates the PIIX3 and PIIX4 device models. >> The culmination point is the last commit which makes PIIX4 usable in the PC >> machine. >> >> One challenge was dealing with optional devices where Peter already gave >> advice >> in [1] which this series implements. Although PIIX4 is now usable in the PC >> machine it still has a different binary layout in its VM state. >> >> Testing done: >> * `make check` >> * `qemu-system-x86_64 -M pc -m 2G -accel kvm -cdrom >> manjaro-kde-21.3.2-220704-linux515.iso` >> * `qemu-system-x86_64 -M pc,x-south-bridge=piix4-isa -m 2G -accel kvm -cdrom >> manjaro-kde-21.3.2-220704-linux515.iso` >> * `qemu-system-x86_64 -M q35 -m 2G -accel kvm -cdrom >> manjaro-kde-21.3.2-220704-linux515.iso` >> * `qemu-system-mips64el -M malta -cpu 5KEc -m 1G -kernel kernel -initrd >> initrd >> -append "root=LABEL=rootfs console=ttyS0" -drive file=image.qcow2` >> * `qemu-system-mips64el -M malta -bios yamon-02.22.bin` >> * Run HVM domU guest under Xen with manjaro-kde-21.3.2-220704-linux515.iso >> image > >I did some preliminary tests of this patch series on some Xen HVM domU guests >I have >that use the xenfv / pc machine and depend on the current PIIX3 implementation. >So far there are no regressions in my tests. I use libxl or libvirt to manage >the >Xen guests. Thanks, nice to read! > >I have not (yet) tested the experimental option that makes PIIX4 useable in >the xenfv / pc >machines. IIUC, that would require a patch to hvmloader/pci.c in Xen tools so >Xen's >hvmloader recognizes the PIIX4 pci device id [1], and a patch to libxl so >libxl can >optionally launch qemu with the new experimental option enabled. > >Since this patch series affects the xenfv machine, I added the Xen x86 >maintainers to >the Cc list and Jason Andryuk who is credited with discovering the necessary >patch to >hvmloader/pci.c. Good idea. In the next iteration, I'll cc the respective email addresses from the MAINTAINERS file which hopefully reaches all relevant people. Best regards, Bernhard > >[1] >https://lore.kernel.org/qemu-devel/b0ff78f4-1193-495b-919c-84a1ff8ad...@gmail.com/ > >> >> v8: >> - Wire ISA interrupts before device realization >> - Optionally allow a PIC and PIT to be instantiated in PIIX3 for compatiblity >> with PIIX4 >> - Touch ICH9 LPC as far as required for PIIX consolidation >> - Make PIIX4 usable in the PC machine via an experimental option >> - Review and rework history, touching every commit and drop R-b tags when >> changes became too large >> >> v7: >> - Rebase onto master >> - Avoid the PIC proxy (Phil) >> The motivation for the PIC proxy was to allow for wiring up ISA interrupts >> in >> the south bridges. ISA interrupt wiring requires the GPIO lines to be >> populated already but pc_piix assigned the interrupts only after realizing >> PIIX3. By shifting interrupt assignment before realizing, the ISA >> interrupts >> are already populated during PIIX3's realize phase where the ISA interrupts >> are wired up. >> - New patches: >> * hw/isa/piix4: Reuse struct PIIXState from PIIX3 >> * hw/isa/piix4: Create the "intr" property during init() already >> - Patches with substantial changes (Reviewed-by dropped): >> * hw/isa/piix3: Move ISA bus IRQ assignments into host device >> >> v6: >> - Fix some comments about TYPE_ISA_PIC (Mark) ... and use it consistently >> within the patch series. >> - Incorporate series "[PATCH v2 0/3] Decouple INTx-to-LNKx routing from south >> bridges" [2] for maintainer convenience. >> - Merge v5's 'hw/i386/pc_piix: Associate pci_map_irq_fn as soon as PCI bus is >> created' into >> https://lists.nongnu.org/archive/html/qemu-devel/2022-11/msg03312.html . Do >> similar for Malta. >> - Rebase onto latest master (d6271b657286
Re: [PATCH v8 00/29] Consolidate PIIX south bridges
On 10/7/23 8:38 AM, Bernhard Beschow wrote: > This series consolidates the implementations of the PIIX3 and PIIX4 south > bridges and makes PIIX4 usable in the PC machine via an experimental command > line parameter. The motivation is to resolve duplicate code between the device > models as well as resolving the "Frankenstein" PIIX4-PM problem in PIIX3 > discussed on this list before. > > The series is structured as follows: > > Patches 1-8 are preparational patches necessary for moving all sub devices > into > PIIX3, like was done for PIIX4. In isolation these patches can also be seen as > general x86 machine cleanup sub series which has merit in its own right -- and > could be applied to master if the remainder of the series takes longer to > review. > > Patches 9-13 move PIIX3 sub devices into one device model like already > done for PIIX4. Together with the previous sub series these patches form a > bigger sub series which also has merit in its own right, and could be applied > independent of the remainder of this series as well. > > The remainder of this series consolidates the PIIX3 and PIIX4 device models. > The culmination point is the last commit which makes PIIX4 usable in the PC > machine. > > One challenge was dealing with optional devices where Peter already gave > advice > in [1] which this series implements. Although PIIX4 is now usable in the PC > machine it still has a different binary layout in its VM state. > > Testing done: > * `make check` > * `qemu-system-x86_64 -M pc -m 2G -accel kvm -cdrom > manjaro-kde-21.3.2-220704-linux515.iso` > * `qemu-system-x86_64 -M pc,x-south-bridge=piix4-isa -m 2G -accel kvm -cdrom > manjaro-kde-21.3.2-220704-linux515.iso` > * `qemu-system-x86_64 -M q35 -m 2G -accel kvm -cdrom > manjaro-kde-21.3.2-220704-linux515.iso` > * `qemu-system-mips64el -M malta -cpu 5KEc -m 1G -kernel kernel -initrd initrd > -append "root=LABEL=rootfs console=ttyS0" -drive file=image.qcow2` > * `qemu-system-mips64el -M malta -bios yamon-02.22.bin` > * Run HVM domU guest under Xen with manjaro-kde-21.3.2-220704-linux515.iso > image I did some preliminary tests of this patch series on some Xen HVM domU guests I have that use the xenfv / pc machine and depend on the current PIIX3 implementation. So far there are no regressions in my tests. I use libxl or libvirt to manage the Xen guests. I have not (yet) tested the experimental option that makes PIIX4 useable in the xenfv / pc machines. IIUC, that would require a patch to hvmloader/pci.c in Xen tools so Xen's hvmloader recognizes the PIIX4 pci device id [1], and a patch to libxl so libxl can optionally launch qemu with the new experimental option enabled. Since this patch series affects the xenfv machine, I added the Xen x86 maintainers to the Cc list and Jason Andryuk who is credited with discovering the necessary patch to hvmloader/pci.c. [1] https://lore.kernel.org/qemu-devel/b0ff78f4-1193-495b-919c-84a1ff8ad...@gmail.com/ > > v8: > - Wire ISA interrupts before device realization > - Optionally allow a PIC and PIT to be instantiated in PIIX3 for compatiblity > with PIIX4 > - Touch ICH9 LPC as far as required for PIIX consolidation > - Make PIIX4 usable in the PC machine via an experimental option > - Review and rework history, touching every commit and drop R-b tags when > changes became too large > > v7: > - Rebase onto master > - Avoid the PIC proxy (Phil) > The motivation for the PIC proxy was to allow for wiring up ISA interrupts > in > the south bridges. ISA interrupt wiring requires the GPIO lines to be > populated already but pc_piix assigned the interrupts only after realizing > PIIX3. By shifting interrupt assignment before realizing, the ISA interrupts > are already populated during PIIX3's realize phase where the ISA interrupts > are wired up. > - New patches: > * hw/isa/piix4: Reuse struct PIIXState from PIIX3 > * hw/isa/piix4: Create the "intr" property during init() already > - Patches with substantial changes (Reviewed-by dropped): > * hw/isa/piix3: Move ISA bus IRQ assignments into host device > > v6: > - Fix some comments about TYPE_ISA_PIC (Mark) ... and use it consistently > within the patch series. > - Incorporate series "[PATCH v2 0/3] Decouple INTx-to-LNKx routing from south > bridges" [2] for maintainer convenience. > - Merge v5's 'hw/i386/pc_piix: Associate pci_map_irq_fn as soon as PCI bus is > created' into > https://lists.nongnu.org/archive/html/qemu-devel/2022-11/msg03312.html . Do > similar for Malta. > - Rebase onto latest master (d6271b657286 "Merge tag 'for_upstream' of > https://git.kernel.org/pub/scm/virt/kvm/mst/qemu into staging") > > 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) > > v4: > - Rebase onto "[PATCH v2 0/3] Decouple
[PATCH v8 00/29] Consolidate PIIX south bridges
This series consolidates the implementations of the PIIX3 and PIIX4 south bridges and makes PIIX4 usable in the PC machine via an experimental command line parameter. The motivation is to resolve duplicate code between the device models as well as resolving the "Frankenstein" PIIX4-PM problem in PIIX3 discussed on this list before. The series is structured as follows: Patches 1-8 are preparational patches necessary for moving all sub devices into PIIX3, like was done for PIIX4. In isolation these patches can also be seen as general x86 machine cleanup sub series which has merit in its own right -- and could be applied to master if the remainder of the series takes longer to review. Patches 9-13 move PIIX3 sub devices into one device model like already done for PIIX4. Together with the previous sub series these patches form a bigger sub series which also has merit in its own right, and could be applied independent of the remainder of this series as well. The remainder of this series consolidates the PIIX3 and PIIX4 device models. The culmination point is the last commit which makes PIIX4 usable in the PC machine. One challenge was dealing with optional devices where Peter already gave advice in [1] which this series implements. Although PIIX4 is now usable in the PC machine it still has a different binary layout in its VM state. Testing done: * `make check` * `qemu-system-x86_64 -M pc -m 2G -accel kvm -cdrom manjaro-kde-21.3.2-220704-linux515.iso` * `qemu-system-x86_64 -M pc,x-south-bridge=piix4-isa -m 2G -accel kvm -cdrom manjaro-kde-21.3.2-220704-linux515.iso` * `qemu-system-x86_64 -M q35 -m 2G -accel kvm -cdrom manjaro-kde-21.3.2-220704-linux515.iso` * `qemu-system-mips64el -M malta -cpu 5KEc -m 1G -kernel kernel -initrd initrd -append "root=LABEL=rootfs console=ttyS0" -drive file=image.qcow2` * `qemu-system-mips64el -M malta -bios yamon-02.22.bin` * Run HVM domU guest under Xen with manjaro-kde-21.3.2-220704-linux515.iso image v8: - Wire ISA interrupts before device realization - Optionally allow a PIC and PIT to be instantiated in PIIX3 for compatiblity with PIIX4 - Touch ICH9 LPC as far as required for PIIX consolidation - Make PIIX4 usable in the PC machine via an experimental option - Review and rework history, touching every commit and drop R-b tags when changes became too large v7: - Rebase onto master - Avoid the PIC proxy (Phil) The motivation for the PIC proxy was to allow for wiring up ISA interrupts in the south bridges. ISA interrupt wiring requires the GPIO lines to be populated already but pc_piix assigned the interrupts only after realizing PIIX3. By shifting interrupt assignment before realizing, the ISA interrupts are already populated during PIIX3's realize phase where the ISA interrupts are wired up. - New patches: * hw/isa/piix4: Reuse struct PIIXState from PIIX3 * hw/isa/piix4: Create the "intr" property during init() already - Patches with substantial changes (Reviewed-by dropped): * hw/isa/piix3: Move ISA bus IRQ assignments into host device v6: - Fix some comments about TYPE_ISA_PIC (Mark) ... and use it consistently within the patch series. - Incorporate series "[PATCH v2 0/3] Decouple INTx-to-LNKx routing from south bridges" [2] for maintainer convenience. - Merge v5's 'hw/i386/pc_piix: Associate pci_map_irq_fn as soon as PCI bus is created' into https://lists.nongnu.org/archive/html/qemu-devel/2022-11/msg03312.html . Do similar for Malta. - Rebase onto latest master (d6271b657286 "Merge tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu into staging") 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) 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
