diff options
author | David Gibson <david@gibson.dropbear.id.au> | 2016-02-29 17:19:42 +1100 |
---|---|---|
committer | David Gibson <david@gibson.dropbear.id.au> | 2016-03-16 09:55:11 +1100 |
commit | c1fa017c7e9b017ec0a75f8added7f9c4864fe8a (patch) | |
tree | 90110a0e12acc9b90b0d4961640e24cb588a9181 /target-unicore32 | |
parent | fbb4e983415dc5a15e167dd00bc4564c57121915 (diff) | |
download | qemu-c1fa017c7e9b017ec0a75f8added7f9c4864fe8a.tar.gz qemu-c1fa017c7e9b017ec0a75f8added7f9c4864fe8a.tar.bz2 qemu-c1fa017c7e9b017ec0a75f8added7f9c4864fe8a.zip |
spapr_pci: Allow EEH on spapr-pci-host-bridge
Now that the EEH code is independent of the special
spapr-vfio-pci-host-bridge device, we can allow it on all spapr PCI
host bridges instead. We do this by changing spapr_phb_eeh_available()
to be based on the vfio_eeh_as_ok() call instead of the host bridge class.
Because the value of vfio_eeh_as_ok() can change with devices being
hotplugged or unplugged, this can potentially lead to some strange edge
cases where the guest starts using EEH, then it starts failing because
of a change in status.
However, it's not really any worse than the current situation. Cases that
would have worked previously will still work (i.e. VFIO devices from at
most one VFIO IOMMU group per vPHB), it's just that it's no longer
necessary to use spapr-vfio-pci-host-bridge with the groupid pre-specified.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Diffstat (limited to 'target-unicore32')
0 files changed, 0 insertions, 0 deletions