On Mon, Sep 06, 2021 at 02:09:25PM +0800, Yongji Xie wrote:

On Mon, Sep 6, 2021 at 1:56 PM Michael S. Tsirkin [off-list ref] wrote:

quoted

On Tue, Aug 31, 2021 at 06:36:26PM +0800, Xie Yongji wrote:

quoted

This adds a new callback to support device specific reset
behavior. The vdpa bus driver will call the reset function
instead of setting status to zero during resetting.

Signed-off-by: Xie Yongji <redacted>

This does gloss over a significant change though:

quoted

---

@@ -348,12 +352,12 @@ static inline struct device *vdpa_get_dma_dev(struct vdpa_device *vdev)
      return vdev->dma_dev;
 }

-static inline void vdpa_reset(struct vdpa_device *vdev)
+static inline int vdpa_reset(struct vdpa_device *vdev)
 {
      const struct vdpa_config_ops *ops = vdev->config;

      vdev->features_valid = false;
-     ops->set_status(vdev, 0);
+     return ops->reset(vdev);
 }

 static inline int vdpa_set_features(struct vdpa_device *vdev, u64 features)

Unfortunately this breaks virtio_vdpa:


static void virtio_vdpa_reset(struct virtio_device *vdev)
{
        struct vdpa_device *vdpa = vd_get_vdpa(vdev);

        vdpa_reset(vdpa);
}


and there's no easy way to fix this, kernel can't recover
from a reset failure e.g. during driver unbind.

Yes, but it should be safe with the protection of software IOTLB even
if the reset() fails during driver unbind.

Thanks,
Yongji

Hmm. I don't see it.
What exactly will happen? What prevents device from poking at
memory after reset? Note that dma unmap in e.g. del_vqs happens
too late.  And what about e.g. interrupts?
E.g. we have this:

        /* Virtqueues are stopped, nothing can use vblk->vdev anymore. */
        vblk->vdev = NULL;

and this is no longer true at this point.


-- 
MST