From: "Michael S. Tsirkin" <mst@redhat.com>
To: Max Gurtovoy <mgurtovoy@nvidia.com>
Cc: Jason Wang <jasowang@redhat.com>,
kvm@vger.kernel.org, virtualization@lists.linux-foundation.org,
oren@nvidia.com, nitzanc@nvidia.com, cohuck@redhat.com
Subject: Re: [PATCH v2 1/3] virtio: update reset callback to return status
Date: Mon, 12 Apr 2021 17:29:49 -0400 [thread overview]
Message-ID: <20210412172333-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <e1e4a42c-2e87-adc1-9089-1c722f02b810@nvidia.com>
On Mon, Apr 12, 2021 at 03:17:02PM +0300, Max Gurtovoy wrote:
>
> On 4/12/2021 12:07 PM, Michael S. Tsirkin wrote:
> > On Sun, Apr 11, 2021 at 12:50:22PM +0300, Max Gurtovoy wrote:
> > > On 4/9/2021 8:22 AM, Jason Wang wrote:
> > > > 在 2021/4/8 下午10:24, Max Gurtovoy 写道:
> > > > > On 4/8/2021 4:14 PM, Jason Wang wrote:
> > > > > > 在 2021/4/8 下午5:56, Max Gurtovoy 写道:
> > > > > > > On 4/8/2021 11:58 AM, Jason Wang wrote:
> > > > > > > > 在 2021/4/8 下午4:11, Max Gurtovoy 写道:
> > > > > > > > > The reset device operation, usually is an operation
> > > > > > > > > that might fail from
> > > > > > > > > various reasons. For example, the controller might
> > > > > > > > > be in a bad state and
> > > > > > > > > can't answer to any request. Usually, the paravirt SW based virtio
> > > > > > > > > devices always succeed in reset operation but this
> > > > > > > > > is not the case for
> > > > > > > > > HW based virtio devices.
> > > > > > > >
> > > > > > > > I would like to know under what condition that the reset
> > > > > > > > operation may fail (except for the case of a bugg
> > > > > > > > guest).
> > > > > > > The controller might not be ready or stuck. This is a real
> > > > > > > use case for many PCI devices.
> > > > > > >
> > > > > > > For real devices the FW might be in a bad state and it can
> > > > > > > happen also for paravirt device if you have a bug in the
> > > > > > > controller code or if you entered some error flow (Out of
> > > > > > > memory).
> > > > > > >
> > > > > > > You don't want to be stuck because of one bad device.
> > > > > >
> > > > > > So the buggy driver can damage the host through various ways,
> > > > > > I'm not sure doing such workaround is worthwhile.
> > > > > do you mean device ?
> > > >
> > > > Yes.
> > > >
> > > >
> > > > > sometimes you need to replace device FW and it will work.
> > > > >
> > > > > I don't think it's a workaround. Other protocols, such as NVMe,
> > > > > solved this in the specification.
> > > > >
> > > > > PCI config space and PCI controller are sometimes 2 different
> > > > > components and sometimes the controller is not active, although the
> > > > > device is plugged and seen by the PCI subsystem.
> > > >
> > > > So I think we need patch to spec to see if it works first.
> > > We can't leave the driver to loop forever without allowing next "good"
> > > virtio devices to probe.
> > >
> > > We can in parallel look for spec fixes but for now we must fix the driver.
> > I'd like to narrow the case though. the proper thing
> > would probably be for device to clear the status.
> > Provided it entered some state where it can not do it -
> > is there anything special about
> > the device state that *can* be detected?
> > If yes what is it?
>
> We don't have anything in the spec to detect it.
>
> Different devices can have different behavior.
I mean ... is this trying to address a practical or a theoretical
problem?
> The only thing we can count on is that the device didn't present a 0 in
> device_status once that was requested.
So for example, it's quite easy for a hypervisor to present 0 if it
wants to even if device isn't fully reset yet ... the fact it doesn't
seems to indicate it does not want the driver to be deleted yet.
I don't yet understand why overriding that from guest is a good idea.
What does guest know that hypervisor doesn't?
>
> >
> > > The fix can be using the mechanism introduced in this series or adding an
> > > async probing mechanism.
> > What would that be?
>
> just schedule some work using queue_work/schedule_work.
>
> And wait for it in the virtio_pci_remove
>
> > > In both solutions, we can't allow looping forever.
> > Multiple minute downtime isn't much better either. I'd like a
> > much shorter timer or even no timer at all, instead
> > verifying that device is alive every X iterations.
>
> I added an option to configure the module parameter.
>
> I think 2-3 minutes to wait is not so bad and one can configure it for any
> value that fits.
What motivates all this work though? Figuring out the real usecase will help
us converge on a solution. Given you work for a hardware vendor I'm
guessing there's something that triggers it with a specific card
you are trying to support better.
>
> >
> > > >
> > > > >
> > > > > > Note that this driver has been used for real hardware PCI
> > > > > > devices for many years. We don't receive any report of this
> > > > > > before.
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > > This commit is also a preparation for adding a timeout mechanism for
> > > > > > > > > resetting virtio devices.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Max Gurtovoy <mgurtovoy@nvidia.com>
> > > > > > > > > ---
> > > > > > > > >
> > > > > > > > > changes from v1:
> > > > > > > > > - update virtio_ccw.c (Cornelia)
> > > > > > > > > - update virtio_uml.c
> > > > > > > > > - update mlxbf-tmfifo.c
> > > > > > > >
> > > > > > > > Note that virtio driver may call reset, so you probably
> > > > > > > > need to convert them.
> > > > > > > I'm sure I understand.
> > > > > > >
> > > > > > > Convert to what ?
> > > > > >
> > > > > > Convert to deal with the possible rest failure. E.g in
> > > > > > virtblk_freeze() we had:
> > > > > >
> > > > > > static int virtblk_freeze(struct virtio_device *vdev)
> > > > > > {
> > > > > > struct virtio_blk *vblk = vdev->priv;
> > > > > >
> > > > > > /* Ensure we don't receive any more interrupts */
> > > > > > vdev->config->reset(vdev);
> > > > > > ...
> > > > > >
> > > > > > We need fail the freeze here.
> > > > >
> > > > > Agree.
> > > > >
> > > > >
> > > > > > Another example is the driver remove which is not expected to be
> > > > > > fail. A lot of virtio drivers tries to call reset there. I'm not
> > > > > > sure how hard to deal with the failure in the path of remove
> > > > > > (e.g __device_release_driver tends to ignore the return value of
> > > > > > bus->remove().)
> > > > > I think it can stay as-is and ignore the ->reset return value and
> > > > > continue free the other resources to avoid leakage.
> > > >
> > > > The problem is that it's unclear that what kind of behaviour would the
> > > > device do, e.g can it still send interrupts?
> > > >
> > > > That's why we need to formalize the bahviour first if necessary.
> > > >
> > > > Thanks
> > > >
> > > >
> > > > >
> > > > > > Thanks
> > > > > >
> > > > > >
> > > > > > > Thanks.
> > > > > > >
> > > > > > > > Thanks
> > > > > > > >
> > > > > > > >
> > > > > > > > > ---
> > > > > > > > > arch/um/drivers/virtio_uml.c | 4 +++-
> > > > > > > > > drivers/platform/mellanox/mlxbf-tmfifo.c | 4 +++-
> > > > > > > > > drivers/remoteproc/remoteproc_virtio.c | 4 +++-
> > > > > > > > > drivers/s390/virtio/virtio_ccw.c | 9 ++++++---
> > > > > > > > > drivers/virtio/virtio.c | 22
> > > > > > > > > +++++++++++++++-------
> > > > > > > > > drivers/virtio/virtio_mmio.c | 3 ++-
> > > > > > > > > drivers/virtio/virtio_pci_legacy.c | 4 +++-
> > > > > > > > > drivers/virtio/virtio_pci_modern.c | 3 ++-
> > > > > > > > > drivers/virtio/virtio_vdpa.c | 4 +++-
> > > > > > > > > include/linux/virtio_config.h | 5 +++--
> > > > > > > > > 10 files changed, 43 insertions(+), 19 deletions(-)
> > > > > > > > >
> > > > > > > > > diff --git a/arch/um/drivers/virtio_uml.c
> > > > > > > > > b/arch/um/drivers/virtio_uml.c
> > > > > > > > > index 91ddf74ca888..b6e66265ed32 100644
> > > > > > > > > --- a/arch/um/drivers/virtio_uml.c
> > > > > > > > > +++ b/arch/um/drivers/virtio_uml.c
> > > > > > > > > @@ -827,11 +827,13 @@ static void
> > > > > > > > > vu_set_status(struct virtio_device *vdev, u8 status)
> > > > > > > > > vu_dev->status = status;
> > > > > > > > > }
> > > > > > > > > -static void vu_reset(struct virtio_device *vdev)
> > > > > > > > > +static int vu_reset(struct virtio_device *vdev)
> > > > > > > > > {
> > > > > > > > > struct virtio_uml_device *vu_dev = to_virtio_uml_device(vdev);
> > > > > > > > > vu_dev->status = 0;
> > > > > > > > > +
> > > > > > > > > + return 0;
> > > > > > > > > }
> > > > > > > > > static void vu_del_vq(struct virtqueue *vq)
> > > > > > > > > diff --git
> > > > > > > > > a/drivers/platform/mellanox/mlxbf-tmfifo.c
> > > > > > > > > b/drivers/platform/mellanox/mlxbf-tmfifo.c
> > > > > > > > > index bbc4e71a16ff..c192b8ac5d9e 100644
> > > > > > > > > --- a/drivers/platform/mellanox/mlxbf-tmfifo.c
> > > > > > > > > +++ b/drivers/platform/mellanox/mlxbf-tmfifo.c
> > > > > > > > > @@ -980,11 +980,13 @@ static void
> > > > > > > > > mlxbf_tmfifo_virtio_set_status(struct virtio_device
> > > > > > > > > *vdev,
> > > > > > > > > }
> > > > > > > > > /* Reset the device. Not much here for now. */
> > > > > > > > > -static void mlxbf_tmfifo_virtio_reset(struct virtio_device *vdev)
> > > > > > > > > +static int mlxbf_tmfifo_virtio_reset(struct virtio_device *vdev)
> > > > > > > > > {
> > > > > > > > > struct mlxbf_tmfifo_vdev *tm_vdev =
> > > > > > > > > mlxbf_vdev_to_tmfifo(vdev);
> > > > > > > > > tm_vdev->status = 0;
> > > > > > > > > +
> > > > > > > > > + return 0;
> > > > > > > > > }
> > > > > > > > > /* Read the value of a configuration field. */
> > > > > > > > > diff --git a/drivers/remoteproc/remoteproc_virtio.c
> > > > > > > > > b/drivers/remoteproc/remoteproc_virtio.c
> > > > > > > > > index 0cc617f76068..ca9573c62c3d 100644
> > > > > > > > > --- a/drivers/remoteproc/remoteproc_virtio.c
> > > > > > > > > +++ b/drivers/remoteproc/remoteproc_virtio.c
> > > > > > > > > @@ -191,7 +191,7 @@ static void
> > > > > > > > > rproc_virtio_set_status(struct virtio_device *vdev,
> > > > > > > > > u8 status)
> > > > > > > > > dev_dbg(&vdev->dev, "status: %d\n", status);
> > > > > > > > > }
> > > > > > > > > -static void rproc_virtio_reset(struct virtio_device *vdev)
> > > > > > > > > +static int rproc_virtio_reset(struct virtio_device *vdev)
> > > > > > > > > {
> > > > > > > > > struct rproc_vdev *rvdev = vdev_to_rvdev(vdev);
> > > > > > > > > struct fw_rsc_vdev *rsc;
> > > > > > > > > @@ -200,6 +200,8 @@ static void
> > > > > > > > > rproc_virtio_reset(struct virtio_device *vdev)
> > > > > > > > > rsc->status = 0;
> > > > > > > > > dev_dbg(&vdev->dev, "reset !\n");
> > > > > > > > > +
> > > > > > > > > + return 0;
> > > > > > > > > }
> > > > > > > > > /* provide the vdev features as retrieved from the firmware */
> > > > > > > > > diff --git a/drivers/s390/virtio/virtio_ccw.c
> > > > > > > > > b/drivers/s390/virtio/virtio_ccw.c
> > > > > > > > > index 54e686dca6de..52b32555e746 100644
> > > > > > > > > --- a/drivers/s390/virtio/virtio_ccw.c
> > > > > > > > > +++ b/drivers/s390/virtio/virtio_ccw.c
> > > > > > > > > @@ -732,14 +732,15 @@ static int
> > > > > > > > > virtio_ccw_find_vqs(struct virtio_device *vdev,
> > > > > > > > > unsigned nvqs,
> > > > > > > > > return ret;
> > > > > > > > > }
> > > > > > > > > -static void virtio_ccw_reset(struct virtio_device *vdev)
> > > > > > > > > +static int virtio_ccw_reset(struct virtio_device *vdev)
> > > > > > > > > {
> > > > > > > > > struct virtio_ccw_device *vcdev = to_vc_device(vdev);
> > > > > > > > > struct ccw1 *ccw;
> > > > > > > > > + int ret;
> > > > > > > > > ccw = ccw_device_dma_zalloc(vcdev->cdev, sizeof(*ccw));
> > > > > > > > > if (!ccw)
> > > > > > > > > - return;
> > > > > > > > > + return -ENOMEM;
> > > > > > > > > /* Zero status bits. */
> > > > > > > > > vcdev->dma_area->status = 0;
> > > > > > > > > @@ -749,8 +750,10 @@ static void
> > > > > > > > > virtio_ccw_reset(struct virtio_device *vdev)
> > > > > > > > > ccw->flags = 0;
> > > > > > > > > ccw->count = 0;
> > > > > > > > > ccw->cda = 0;
> > > > > > > > > - ccw_io_helper(vcdev, ccw, VIRTIO_CCW_DOING_RESET);
> > > > > > > > > + ret = ccw_io_helper(vcdev, ccw, VIRTIO_CCW_DOING_RESET);
> > > > > > > > > ccw_device_dma_free(vcdev->cdev, ccw, sizeof(*ccw));
> > > > > > > > > +
> > > > > > > > > + return ret;
> > > > > > > > > }
> > > > > > > > > static u64 virtio_ccw_get_features(struct virtio_device *vdev)
> > > > > > > > > diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
> > > > > > > > > index 4b15c00c0a0a..ddbfd5b5f3bd 100644
> > > > > > > > > --- a/drivers/virtio/virtio.c
> > > > > > > > > +++ b/drivers/virtio/virtio.c
> > > > > > > > > @@ -338,7 +338,7 @@ int
> > > > > > > > > register_virtio_device(struct virtio_device *dev)
> > > > > > > > > /* Assign a unique device index and hence name. */
> > > > > > > > > err = ida_simple_get(&virtio_index_ida, 0, 0, GFP_KERNEL);
> > > > > > > > > if (err < 0)
> > > > > > > > > - goto out;
> > > > > > > > > + goto out_err;
> > > > > > > > > dev->index = err;
> > > > > > > > > dev_set_name(&dev->dev, "virtio%u", dev->index);
> > > > > > > > > @@ -349,7 +349,9 @@ int
> > > > > > > > > register_virtio_device(struct virtio_device *dev)
> > > > > > > > > /* We always start by resetting the device,
> > > > > > > > > in case a previous
> > > > > > > > > * driver messed it up. This also tests that
> > > > > > > > > code path a little. */
> > > > > > > > > - dev->config->reset(dev);
> > > > > > > > > + err = dev->config->reset(dev);
> > > > > > > > > + if (err)
> > > > > > > > > + goto out_ida;
> > > > > > > > > /* Acknowledge that we've seen the device. */
> > > > > > > > > virtio_add_status(dev, VIRTIO_CONFIG_S_ACKNOWLEDGE);
> > > > > > > > > @@ -362,10 +364,14 @@ int
> > > > > > > > > register_virtio_device(struct virtio_device *dev)
> > > > > > > > > */
> > > > > > > > > err = device_add(&dev->dev);
> > > > > > > > > if (err)
> > > > > > > > > - ida_simple_remove(&virtio_index_ida, dev->index);
> > > > > > > > > -out:
> > > > > > > > > - if (err)
> > > > > > > > > - virtio_add_status(dev, VIRTIO_CONFIG_S_FAILED);
> > > > > > > > > + goto out_ida;
> > > > > > > > > +
> > > > > > > > > + return 0;
> > > > > > > > > +
> > > > > > > > > +out_ida:
> > > > > > > > > + ida_simple_remove(&virtio_index_ida, dev->index);
> > > > > > > > > +out_err:
> > > > > > > > > + virtio_add_status(dev, VIRTIO_CONFIG_S_FAILED);
> > > > > > > > > return err;
> > > > > > > > > }
> > > > > > > > > EXPORT_SYMBOL_GPL(register_virtio_device);
> > > > > > > > > @@ -408,7 +414,9 @@ int virtio_device_restore(struct
> > > > > > > > > virtio_device *dev)
> > > > > > > > > /* We always start by resetting the device,
> > > > > > > > > in case a previous
> > > > > > > > > * driver messed it up. */
> > > > > > > > > - dev->config->reset(dev);
> > > > > > > > > + ret = dev->config->reset(dev);
> > > > > > > > > + if (ret)
> > > > > > > > > + goto err;
> > > > > > > > > /* Acknowledge that we've seen the device. */
> > > > > > > > > virtio_add_status(dev, VIRTIO_CONFIG_S_ACKNOWLEDGE);
> > > > > > > > > diff --git a/drivers/virtio/virtio_mmio.c
> > > > > > > > > b/drivers/virtio/virtio_mmio.c
> > > > > > > > > index 56128b9c46eb..12b8f048c48d 100644
> > > > > > > > > --- a/drivers/virtio/virtio_mmio.c
> > > > > > > > > +++ b/drivers/virtio/virtio_mmio.c
> > > > > > > > > @@ -256,12 +256,13 @@ static void
> > > > > > > > > vm_set_status(struct virtio_device *vdev, u8 status)
> > > > > > > > > writel(status, vm_dev->base + VIRTIO_MMIO_STATUS);
> > > > > > > > > }
> > > > > > > > > -static void vm_reset(struct virtio_device *vdev)
> > > > > > > > > +static int vm_reset(struct virtio_device *vdev)
> > > > > > > > > {
> > > > > > > > > struct virtio_mmio_device *vm_dev =
> > > > > > > > > to_virtio_mmio_device(vdev);
> > > > > > > > > /* 0 status means a reset. */
> > > > > > > > > writel(0, vm_dev->base + VIRTIO_MMIO_STATUS);
> > > > > > > > > + return 0;
> > > > > > > > > }
> > > > > > > > > diff --git a/drivers/virtio/virtio_pci_legacy.c
> > > > > > > > > b/drivers/virtio/virtio_pci_legacy.c
> > > > > > > > > index d62e9835aeec..0b5d95e3efa1 100644
> > > > > > > > > --- a/drivers/virtio/virtio_pci_legacy.c
> > > > > > > > > +++ b/drivers/virtio/virtio_pci_legacy.c
> > > > > > > > > @@ -89,7 +89,7 @@ static void vp_set_status(struct
> > > > > > > > > virtio_device *vdev, u8 status)
> > > > > > > > > iowrite8(status, vp_dev->ioaddr + VIRTIO_PCI_STATUS);
> > > > > > > > > }
> > > > > > > > > -static void vp_reset(struct virtio_device *vdev)
> > > > > > > > > +static int vp_reset(struct virtio_device *vdev)
> > > > > > > > > {
> > > > > > > > > struct virtio_pci_device *vp_dev = to_vp_device(vdev);
> > > > > > > > > /* 0 status means a reset. */
> > > > > > > > > @@ -99,6 +99,8 @@ static void vp_reset(struct virtio_device *vdev)
> > > > > > > > > ioread8(vp_dev->ioaddr + VIRTIO_PCI_STATUS);
> > > > > > > > > /* Flush pending VQ/configuration callbacks. */
> > > > > > > > > vp_synchronize_vectors(vdev);
> > > > > > > > > +
> > > > > > > > > + return 0;
> > > > > > > > > }
> > > > > > > > > static u16 vp_config_vector(struct
> > > > > > > > > virtio_pci_device *vp_dev, u16 vector)
> > > > > > > > > diff --git a/drivers/virtio/virtio_pci_modern.c
> > > > > > > > > b/drivers/virtio/virtio_pci_modern.c
> > > > > > > > > index fbd4ebc00eb6..cc3412a96a17 100644
> > > > > > > > > --- a/drivers/virtio/virtio_pci_modern.c
> > > > > > > > > +++ b/drivers/virtio/virtio_pci_modern.c
> > > > > > > > > @@ -158,7 +158,7 @@ static void vp_set_status(struct
> > > > > > > > > virtio_device *vdev, u8 status)
> > > > > > > > > vp_modern_set_status(&vp_dev->mdev, status);
> > > > > > > > > }
> > > > > > > > > -static void vp_reset(struct virtio_device *vdev)
> > > > > > > > > +static int vp_reset(struct virtio_device *vdev)
> > > > > > > > > {
> > > > > > > > > struct virtio_pci_device *vp_dev = to_vp_device(vdev);
> > > > > > > > > struct virtio_pci_modern_device *mdev = &vp_dev->mdev;
> > > > > > > > > @@ -174,6 +174,7 @@ static void vp_reset(struct virtio_device *vdev)
> > > > > > > > > msleep(1);
> > > > > > > > > /* Flush pending VQ/configuration callbacks. */
> > > > > > > > > vp_synchronize_vectors(vdev);
> > > > > > > > > + return 0;
> > > > > > > > > }
> > > > > > > > > static u16 vp_config_vector(struct
> > > > > > > > > virtio_pci_device *vp_dev, u16 vector)
> > > > > > > > > diff --git a/drivers/virtio/virtio_vdpa.c
> > > > > > > > > b/drivers/virtio/virtio_vdpa.c
> > > > > > > > > index e28acf482e0c..5fd4e627a9b0 100644
> > > > > > > > > --- a/drivers/virtio/virtio_vdpa.c
> > > > > > > > > +++ b/drivers/virtio/virtio_vdpa.c
> > > > > > > > > @@ -97,11 +97,13 @@ static void
> > > > > > > > > virtio_vdpa_set_status(struct virtio_device *vdev,
> > > > > > > > > u8 status)
> > > > > > > > > return ops->set_status(vdpa, status);
> > > > > > > > > }
> > > > > > > > > -static void virtio_vdpa_reset(struct virtio_device *vdev)
> > > > > > > > > +static int virtio_vdpa_reset(struct virtio_device *vdev)
> > > > > > > > > {
> > > > > > > > > struct vdpa_device *vdpa = vd_get_vdpa(vdev);
> > > > > > > > > vdpa_reset(vdpa);
> > > > > > > > > +
> > > > > > > > > + return 0;
> > > > > > > > > }
> > > > > > > > > static bool virtio_vdpa_notify(struct virtqueue *vq)
> > > > > > > > > diff --git a/include/linux/virtio_config.h
> > > > > > > > > b/include/linux/virtio_config.h
> > > > > > > > > index 8519b3ae5d52..d2b0f1699a75 100644
> > > > > > > > > --- a/include/linux/virtio_config.h
> > > > > > > > > +++ b/include/linux/virtio_config.h
> > > > > > > > > @@ -44,9 +44,10 @@ struct virtio_shm_region {
> > > > > > > > > * status: the new status byte
> > > > > > > > > * @reset: reset the device
> > > > > > > > > * vdev: the virtio device
> > > > > > > > > - * After this, status and feature negotiation must be done again
> > > > > > > > > + * Upon success, status and feature negotiation
> > > > > > > > > must be done again
> > > > > > > > > * Device must not be reset from its vq/config callbacks, or in
> > > > > > > > > * parallel with being added/removed.
> > > > > > > > > + * Returns 0 on success or error status.
> > > > > > > > > * @find_vqs: find virtqueues and instantiate them.
> > > > > > > > > * vdev: the virtio_device
> > > > > > > > > * nvqs: the number of virtqueues to find
> > > > > > > > > @@ -82,7 +83,7 @@ struct virtio_config_ops {
> > > > > > > > > u32 (*generation)(struct virtio_device *vdev);
> > > > > > > > > u8 (*get_status)(struct virtio_device *vdev);
> > > > > > > > > void (*set_status)(struct virtio_device *vdev, u8 status);
> > > > > > > > > - void (*reset)(struct virtio_device *vdev);
> > > > > > > > > + int (*reset)(struct virtio_device *vdev);
> > > > > > > > > int (*find_vqs)(struct virtio_device *, unsigned nvqs,
> > > > > > > > > struct virtqueue *vqs[], vq_callback_t *callbacks[],
> > > > > > > > > const char * const names[], const bool *ctx,
next prev parent reply other threads:[~2021-04-12 21:30 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-08 8:11 [PATCH v2 1/3] virtio: update reset callback to return status Max Gurtovoy
2021-04-08 8:11 ` [PATCH v2 2/3] virito_pci: add timeout to reset device operation Max Gurtovoy
2021-04-08 9:01 ` Jason Wang
2021-04-08 9:44 ` Max Gurtovoy
2021-04-08 12:45 ` Jason Wang
2021-04-08 12:57 ` Max Gurtovoy
2021-04-08 13:18 ` Jason Wang
2021-04-08 8:11 ` [PATCH v2 3/3] virtio_pci: add module param for reset_timeout Max Gurtovoy
2021-04-08 8:58 ` [PATCH v2 1/3] virtio: update reset callback to return status Jason Wang
2021-04-08 9:56 ` Max Gurtovoy
2021-04-08 13:14 ` Jason Wang
2021-04-08 14:24 ` Max Gurtovoy
2021-04-09 5:22 ` Jason Wang
2021-04-11 9:50 ` Max Gurtovoy
2021-04-12 9:07 ` Michael S. Tsirkin
2021-04-12 12:17 ` Max Gurtovoy
2021-04-12 21:29 ` Michael S. Tsirkin [this message]
2021-04-08 15:56 ` Michael S. Tsirkin
2021-04-12 11:55 ` Max Gurtovoy
2021-04-12 12:04 ` Michael S. Tsirkin
2021-04-12 13:03 ` Max Gurtovoy
2021-04-12 21:23 ` Michael S. Tsirkin
2021-04-12 22:53 ` Max Gurtovoy
2021-04-13 2:42 ` Jason Wang
2021-04-13 4:52 ` Michael S. Tsirkin
2021-04-13 4:42 ` Michael S. Tsirkin
2021-04-13 10:56 ` Max Gurtovoy
2021-04-08 16:18 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210412172333-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=cohuck@redhat.com \
--cc=jasowang@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mgurtovoy@nvidia.com \
--cc=nitzanc@nvidia.com \
--cc=oren@nvidia.com \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).