On 11/28/2016 11:00 AM, Michael S. Tsirkin wrote:
On Sun, Nov 27, 2016 at 07:34:17PM +0800, Cao jin wrote:
It is user space driver's or device-specific driver's(in guest) responsbility
to do a serious recovery when error happened. Link-reset is one part of
recovery, when pci device is assigned to VM via vfio, link-reset will do
twice in host & guest separately, which will cause many trouble for a
successful recovery, so, disable the vfio-pci's link-reset in aer driver
in host, this is a keypoint for guest to do error recovery successfully.
CC: alex.williamson@xxxxxxxxxx
CC: mst@xxxxxxxxxx
Signed-off-by: Cao jin <caoj.fnst@xxxxxxxxxxxxxx>
---
This is actually a RFC version(has debug lines left), and has minor changes in
aer driver, so I think maybe it is better not to CC pci guys in this round.
Later will do.
drivers/pci/pcie/aer/aerdrv_core.c | 12 ++++++-
drivers/vfio/pci/vfio_pci.c | 63 +++++++++++++++++++++++++++++++++++--
drivers/vfio/pci/vfio_pci_private.h | 2 ++
3 files changed, 74 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/pcie/aer/aerdrv_core.c b/drivers/pci/pcie/aer/aerdrv_core.c
index 521e39c..289fb8e 100644
--- a/drivers/pci/pcie/aer/aerdrv_core.c
+++ b/drivers/pci/pcie/aer/aerdrv_core.c
@@ -496,7 +496,17 @@ static void do_recovery(struct pci_dev *dev, int severity)
"error_detected",
report_error_detected);
- if (severity == AER_FATAL) {
+ /* vfio-pci as a general meta driver, it actually couldn't do any real
+ * recovery for device. It is user space driver, or device-specific
+ * driver in guest who should take care of the serious error recovery,
+ * link reset actually is one part of whole recovery. Doing reset_link
+ * in aer driver of host kernel for vfio-pci devices will cause many
+ * trouble for user space driver or guest's device-specific driver,
+ * for example: the serious recovery often need to read register in
+ * config space, but if register reading happens during link-resetting,
+ * it is quite possible to return invalid value like all F's, which
+ * will result in unpredictable error. */
Fix multi-comment style please.
+ if (severity == AER_FATAL && strcmp(dev->driver->name, "vfio-pci")) {
You really want some flag in the device, or something similar.
Also, how do we know driver is not going away at this point?
I didn't think of this condition, and I don't quite follow how would
driver go away?(device has error happened, then is removed?)
result = reset_link(dev);
if (result != PCI_ERS_RESULT_RECOVERED)
goto failed;
@@ -1187,10 +1200,30 @@ static pci_ers_result_t vfio_pci_aer_err_detected(struct pci_dev *pdev,
return PCI_ERS_RESULT_DISCONNECT;
}
+ /* get device's uncorrectable error status as soon as possible,
+ * and signal it to user space. The later we read it, the possibility
+ * the register value is mangled grows. */
+ aer_cap_offset = pci_find_ext_capability(vdev->pdev, PCI_EXT_CAP_ID_ERR);
+ ret = pci_read_config_dword(vdev->pdev, aer_cap_offset +
+ PCI_ERR_UNCOR_STATUS, &uncor_status);
+ if (ret)
+ return PCI_ERS_RESULT_DISCONNECT;
+
+ pr_err("device %d got AER detect notification. uncorrectable error status = 0x%x\n", pdev->devfn, uncor_status);//to be removed
mutex_lock(&vdev->igate);
+
+ vdev->aer_recovering = true;
+ reinit_completion(&vdev->aer_error_completion);
+
+ /* suspend config space access from user space,
+ * when vfio-pci's error recovery process is on */
what about access to memory etc? Do you need to suspend this as well?
Yes, this question came into my mind a little bit, but I didn't see some
existing APIs like pci_cfg_access_xxx which can help to do this.(I am
still not familiar with kernel)
+ pci_cfg_access_trylock(vdev->pdev);
If you trylock, you need to handle failure.
try lock returns 0 if access is already locked, 1 otherwise. Is it
necessary to check its return value?
--
Sincerely,
Cao jin
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
