qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH for-4.0 0/2] spapr: Fix extended config space ac


From: Alex Williamson
Subject: Re: [Qemu-devel] [PATCH for-4.0 0/2] spapr: Fix extended config space accesses
Date: Mon, 1 Apr 2019 13:25:12 -0600

On Mon, 01 Apr 2019 19:54:57 +0200
Greg Kurz <address@hidden> wrote:

> Recent commit c2077e2ca0da7 added stricter checks that now prevent
> a guest to access the extended config space of a PCIe device connected
> attached to a PHB on a pseries machine.
> 
> PAPR compatible PHBs act like legacy PCI busses, but they do allow access
> to the full 4k config space of PCIe devices. As discussed several times on
> the list ([1] and [2]), we cannot really change PAPR PHB to have a true
> PCIe root bus since it would call for massive and unwanted changes in
> libvirt.
> 
> This series tries to address the issue with a new PCI bus class method
> that tells if the PCI bus supports extended config space accesses,
> instead of relying on pci_bus_is_express() which wants a PCIe root bus.
> A new legacy PCI bus type is added to implement the PAPR behaviour.
> 
> Note that this fixes a potential 4.0 regression, hence the for-4.0 tag.

Post-4.0, please also evaluate:

https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg07164.html

Seems that PAPR only has one IOMMU AddressSpace per bus to return
through the iommu_fn so there should be no harm in aliasing the guest
view of devices, but if anything this series warns never to assume that
PAPR behaves normally.

FWIW, this series might make it easier to create a PCI-X Mode 2 bus,
which would otherwise be similar to conventional PCI for
inter-connectivity, but does support extended config space.  Though a
new bus type would be the more obvious way to do it, which clearly has
been a problem here.  Thanks,

Alex



reply via email to

[Prev in Thread] Current Thread [Next in Thread]