summaryrefslogtreecommitdiff
path: root/target-unicore32
diff options
context:
space:
mode:
authorDavid Gibson <david@gibson.dropbear.id.au>2016-02-29 17:19:42 +1100
committerDavid Gibson <david@gibson.dropbear.id.au>2016-03-16 09:55:11 +1100
commitc1fa017c7e9b017ec0a75f8added7f9c4864fe8a (patch)
tree90110a0e12acc9b90b0d4961640e24cb588a9181 /target-unicore32
parentfbb4e983415dc5a15e167dd00bc4564c57121915 (diff)
downloadqemu-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