bwlp/qemu.git/include/hw/pci-host, branch spice_video_codecs

hw/loongarch: Improve fdt for LoongArch virt machine

2022-11-04T09:07:40+00:00

Add new items into LoongArch FDT, including rtc and uart info. Signed-off-by: Xiaojuan Yang Reviewed-by: Song Gao Message-Id: <20221028014007.2718352-3-yangxiaojuan@loongson.cn> Signed-off-by: Song Gao

hw/ppc/mac.h: Move grackle-pcihost type declaration out to a header

2022-10-31T18:48:23+00:00

Signed-off-by: BALATON Zoltan Reviewed-by: Mark Cave-Ayland Message-Id: Signed-off-by: Mark Cave-Ayland

hw/loongarch: Add platform bus support

2022-09-20T07:44:24+00:00

Add platform bus support and add the bus information such as address, size, irq number to FDT table. Signed-off-by: Xiaojuan Yang Acked-by: Song Gao Message-Id: <20220908094623.73051-5-yangxiaojuan@loongson.cn> Signed-off-by: Song Gao

ppc/pnv: add phb-id/chip-id PnvPHB4RootBus properties

2022-08-31T17:08:05+00:00

The same rationale provided in the PHB3 bus case applies here. Note: we could have merged both buses in a single object, like we did with the root ports, and spare some boilerplate. The reason we opted to preserve both buses objects is twofold: - there's not user side advantage in doing so. Unifying the root ports presents a clear user QOL change when we enable user created devices back. The buses objects, aside from having a different QOM name, is transparent to the user; - we leave a door opened in case we want to increase the root port limit for phb4/5 later on without having to deal with phb3 code. Reviewed-by: Cédric Le Goater Signed-off-by: Daniel Henrique Barboza Reviewed-by: Frederic Barrat Message-Id: <20220811163950.578927-3-danielhb413@gmail.com>

ppc/pnv: add phb-id/chip-id PnvPHB3RootBus properties

2022-08-31T17:08:05+00:00

We rely on the phb-id and chip-id, which are PHB properties, to assign chassis and slot to the root port. For default devices this is no big deal: the root port is being created under pnv_phb_realize() and the values are being passed on via the 'index' and 'chip-id' of the pnv_phb_attach_root_port() helper. If we want to implement user created root ports we have a problem. The user created root port will not be aware of which PHB it belongs to, unless we're willing to violate QOM best practices and access the PHB via dev->parent_bus->parent. What we can do is to access the root bus parent bus. Since we're already assigning the root port as QOM child of the bus, and the bus is initiated using PHB properties, let's add phb-id and chip-id as properties of the bus. This will allow us trivial access to them, for both user-created and default root ports, without doing anything too shady with QOM. Reviewed-by: Cédric Le Goater Signed-off-by: Daniel Henrique Barboza Reviewed-by: Frederic Barrat Message-Id: <20220811163950.578927-2-danielhb413@gmail.com>

ppc/pnv: remove PnvPHB4.version

2022-08-31T17:08:05+00:00

It's unused. Signed-off-by: Daniel Henrique Barboza Reviewed-by: Frederic Barrat Message-Id: <20220624084921.399219-12-danielhb413@gmail.com>

ppc/pnv: remove pecc->rp_model

2022-08-31T17:08:05+00:00

The attribute is unused. Signed-off-by: Daniel Henrique Barboza Reviewed-by: Frederic Barrat Message-Id: <20220624084921.399219-11-danielhb413@gmail.com>

ppc/pnv: remove pnv-phb4-root-port

2022-08-31T17:08:05+00:00

The unified pnv-phb-root-port can be used instead. The phb4-root-port device isn't exposed to the user in any official QEMU release so there's no ABI breakage in removing it. Signed-off-by: Daniel Henrique Barboza Reviewed-by: Frederic Barrat Message-Id: <20220624084921.399219-9-danielhb413@gmail.com>

ppc/pnv: remove pnv-phb3-root-port

2022-08-31T17:08:05+00:00

The unified pnv-phb-root-port can be used in its place. There is no ABI breakage in doing so because no official QEMU release introduced user creatable pnv-phb3-root-port devices. Signed-off-by: Daniel Henrique Barboza Reviewed-by: Frederic Barrat Message-Id: <20220624084921.399219-8-danielhb413@gmail.com>

ppc/pnv: turn PnvPHB4 into a PnvPHB backend

2022-08-31T17:08:05+00:00

Change the parent type of the PnvPHB4 device to TYPE_PARENT since the PCI bus is going to be initialized by the PnvPHB parent. Functions that needs to access the bus via a PnvPHB4 object can do so via the phb4->phb_base pointer. pnv_phb4_pec now creates a PnvPHB object. The powernv9 machine class will create PnvPHB devices with version '4'. powernv10 will create using version '5'. Both are using global machine properties in their class_init() to do that. These changes will benefit us when adding PnvPHB user creatable devices for powernv9 and powernv10. Signed-off-by: Daniel Henrique Barboza Reviewed-by: Frederic Barrat Message-Id: <20220624084921.399219-6-danielhb413@gmail.com>