Michael S. Tsirkin
2021-Sep-06 06:37 UTC
[PATCH v13 05/13] vdpa: Add reset callback in vdpa_config_ops
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 <mst at redhat.com> wrote: > > > > On Tue, Aug 31, 2021 at 06:36:26PM +0800, Xie Yongji wrote: > > > 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 <xieyongji at bytedance.com> > > > > > > This does gloss over a significant change though: > > > > > > > --- > > > @@ -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, > YongjiHmm. 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