On Fri, Mar 10, 2017 at 04:25:21PM +0100, Andrea Bolognani wrote: > 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.
That's a good point. I've put a fix into ppc-for-2.9, will send a pull request shortly. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature