| Message ID | 20170303032507.16142-16-david@gibson.dropbear.id.au |
|---|---|
| State | New |
| Headers | show |
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 <david@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
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 <david@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.
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; }
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 <david@gibson.dropbear.id.au> --- hw/ppc/spapr_pci.c | 4 ++++ 1 file changed, 4 insertions(+)