All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hanna Czenczek <hreitz@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
	"Michael S . Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH] virtio: Always reset vhost devices
Date: Thu, 11 Jul 2024 13:46:33 +0200	[thread overview]
Message-ID: <b45513dd-d200-4a10-bd9d-d129bc8b8528@redhat.com> (raw)
In-Reply-To: <CAJSP0QWMKZxQTKuhQ1dASm9xqfWiumLz7ciVZy2APjPhT4VuFw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2948 bytes --]

On 10.07.24 18:28, Stefan Hajnoczi wrote:
> On Wed, 10 Jul 2024 at 13:25, Hanna Czenczek<hreitz@redhat.com>  wrote:
>> Requiring `vhost_started` to be true for resetting vhost devices in
>> `virtio_reset()` seems like the wrong condition: Most importantly, the
>> preceding `virtio_set_status(vdev, 0)` call will (for vhost devices) end
>> up in `vhost_dev_stop()` (through vhost devices' `.set_status`
>> implementations), setting `vdev->vhost_started = false`.  Therefore, the
>> gated `vhost_reset_device()` call is unreachable.
>>
>> `vhost_started` is not documented, so it is hard to say what exactly it
>> is supposed to mean, but judging from the fact that `vhost_dev_start()`
>> sets it and `vhost_dev_stop()` clears it, it seems like it indicates
>> whether there is a vhost back-end, and whether that back-end is
>> currently running and processing virtio requests.
>>
>> Making a reset conditional on whether the vhost back-end is processing
>> virtio requests seems wrong; in fact, it is probably better to reset it
>> only when it is not currently processing requests, which is exactly the
>> current order of operations in `virtio_reset()`: First, the back-end is
>> stopped through `virtio_set_status(vdev, 0)`, then we want to send a
>> reset.
>>
>> Therefore, we should drop the `vhost_started` condition, but in its
>> stead we then have to verify that we can indeed send a reset to this
>> vhost device, by not just checking `k->get_vhost != NULL` (introduced by
>> commit 95e1019a4a9), but also that the vhost back-end is connected
>> (`hdev = k->get_vhost(); hdev != NULL && hdev->vhost_ops != NULL`).
>>
>> Signed-off-by: Hanna Czenczek<hreitz@redhat.com>
> I think an additional SET_STATUS 0 call is made to the vDPA vhost
> backend after this patch, but that seems fine.
>
> Reviewed-by: Stefan Hajnoczi<stefanha@redhat.com>

Thanks!  I agree that double-sending SET_STATUS with the same value 
should be fine.The virtio specification states: “The device status field 
starts out as 0, and is reinitialized to 0 by the device during reset.” 
– I interpret that to mean that (re-)setting the field to 0 is always 
OK. Hanna
>> ---
>>   hw/virtio/virtio.c | 8 ++++++--
>>   1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
>> index 893a072c9d..4410d62126 100644
>> --- a/hw/virtio/virtio.c
>> +++ b/hw/virtio/virtio.c
>> @@ -2146,8 +2146,12 @@ void virtio_reset(void *opaque)
>>           vdev->device_endian = virtio_default_endian();
>>       }
>>
>> -    if (vdev->vhost_started && k->get_vhost) {
>> -        vhost_reset_device(k->get_vhost(vdev));
>> +    if (k->get_vhost) {
>> +        struct vhost_dev *hdev = k->get_vhost(vdev);
>> +        /* Only reset when vhost back-end is connected */
>> +        if (hdev && hdev->vhost_ops) {
>> +            vhost_reset_device(hdev);
>> +        }
>>       }
>>
>>       if (k->reset) {
>> --
>> 2.45.2
>>
>>

[-- Attachment #2: Type: text/html, Size: 3932 bytes --]

      reply	other threads:[~2024-07-11 11:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-10 11:23 [PATCH] virtio: Always reset vhost devices Hanna Czenczek
2024-07-10 13:39 ` Matias Ezequiel Vara Larsen
2024-07-11 11:43   ` Hanna Czenczek
2024-07-10 16:28 ` Stefan Hajnoczi
2024-07-11 11:46   ` Hanna Czenczek [this message]

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=b45513dd-d200-4a10-bd9d-d129bc8b8528@redhat.com \
    --to=hreitz@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=stefanha@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.