On Fri, 2017-03-03 at 14:25 +1100, David Gibson wrote:
> The (paravirtual) PCI host bridge on the 'pseries' machine in most
> regards acts like a regular PCI bus, rather than a PCIe bus. Despite
> this, though, it does allow access to the PCIe extended config space.
>
> We already implemented the RTAS methods to allow this access.. but
> forgot to put the markers into the device tree so that guest's know it
> is there. This adds them in.
>
> With this, a pseries guest is able to view extended config space on
> (for example an e1000e device. This should be enough to allow guests
> to use at least some PCIe devices.
>
> Signed-off-by: David Gibson <da...@gibson.dropbear.id.au>
> ---
> hw/ppc/spapr_pci.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
> index 2a3499e..919d3c2 100644
> --- a/hw/ppc/spapr_pci.c
> +++ b/hw/ppc/spapr_pci.c
> @@ -1321,6 +1321,10 @@ static int spapr_populate_pci_child_dt(PCIDevice *dev,
> void *fdt, int offset,
> _FDT(fdt_setprop(fdt, offset, "assigned-addresses",
> (uint8_t *)rp.assigned, rp.assigned_len));
>
> + if (pci_is_express(dev)) {
> + _FDT(fdt_setprop_cell(fdt, offset, "ibm,pci-config-space-type",
> 0x1));
> + }
> +
> return 0;
> }
I've just realized that this is not tied to the pseries-2.9
machine type, which means existing guests will suddenly get
access to the Extended Config Space after upgrading QEMU.
I'm not sure this will cause any issue in practice, but it
seems like it would be safer to enable the Extended Config
Space only for pseries-2.9 and newer machine types.
--
Andrea Bolognani / Red Hat / Virtualization
