From: Peter Xu <peterx@redhat.com>
To: Prasad Pandit <ppandit@redhat.com>
Cc: qemu-devel@nongnu.org, Fabiano Rosas <farosas@suse.de>,
Jason Wang <jasowang@redhat.com>,
"Michael S . Tsirkin" <mst@redhat.com>,
mcoqueli@redhat.com, Prasad Pandit <pjp@fedoraproject.org>
Subject: Re: [PATCH 0/2] Postcopy migration and vhost-user errors
Date: Mon, 15 Jul 2024 09:39:57 -0400 [thread overview]
Message-ID: <ZpUmrTrEnx0RcO2y@x1n> (raw)
In-Reply-To: <CAE8KmOzsGaPtTFsjcRkyd8n_fPzXeFd+c38Eb=aLG0_MdO+yKw@mail.gmail.com>
On Mon, Jul 15, 2024 at 03:44:06PM +0530, Prasad Pandit wrote:
> > I remember after you added the rwlock, there's still a hang issue.
> > Did you investigated that? Or do you mean this series will fix all the problems?
>
> * No, this series does not fix the guest hang issue. Root cause of
> that is still a mystery. If migration is ending abruptly before all of
> the guest state is migrated, the guest hang scenario seems possible.
> Adding vhost-user-rw-lock does not address the issue of end of
> migration.
IMHO it's better we debug and fix all the issues before merging this one,
otherwise we may overlook something. You could pass over the patch to
whoever going to debug this, so it will be included in the whole set to be
posted when the bug is completely fixed.
> * From the protocol page above, it is not clear if the front-end
> should allow/have multiple threads talking to the same vhost-user
> device.
The protocol should have no restriction on the thread model of a front-end.
It only describes the wire protocol.
IIUC the protocol was designed to be serialized by nature (where there's no
request ID, so we can't match reply to any of the previous response), then
the front-end can manage the threads well to serialize all the requests,
like using this rwlock.
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2024-07-15 13:40 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-11 13:14 [PATCH 0/2] Postcopy migration and vhost-user errors Prasad Pandit
2024-07-11 13:14 ` [PATCH 1/2] vhost-user: add a write-read lock Prasad Pandit
2024-07-11 14:39 ` Michael S. Tsirkin
2024-07-15 10:57 ` Prasad Pandit
2024-07-11 15:41 ` Peter Xu
2024-07-15 8:14 ` Prasad Pandit
2024-07-15 13:27 ` Peter Xu
2024-07-16 10:19 ` Prasad Pandit
2024-07-20 19:41 ` Michael S. Tsirkin
2024-07-23 4:58 ` Prasad Pandit
2024-07-11 13:14 ` [PATCH 2/2] vhost: fail device start if iotlb update fails Prasad Pandit
2024-07-11 15:38 ` [PATCH 0/2] Postcopy migration and vhost-user errors Peter Xu
2024-07-15 10:14 ` Prasad Pandit
2024-07-15 13:39 ` Peter Xu [this message]
2024-07-16 10:14 ` Prasad Pandit
2024-07-16 22:02 ` Peter Xu
2024-07-17 8:55 ` Michael S. Tsirkin
2024-07-17 13:33 ` Peter Xu
2024-07-17 13:40 ` Michael S. Tsirkin
2024-07-17 13:47 ` Peter Xu
2024-07-20 19:41 ` Michael S. Tsirkin
2024-07-23 5:03 ` Prasad Pandit
2024-07-23 17:52 ` Peter Xu
2024-07-23 17:57 ` Prasad Pandit
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=ZpUmrTrEnx0RcO2y@x1n \
--to=peterx@redhat.com \
--cc=farosas@suse.de \
--cc=jasowang@redhat.com \
--cc=mcoqueli@redhat.com \
--cc=mst@redhat.com \
--cc=pjp@fedoraproject.org \
--cc=ppandit@redhat.com \
--cc=qemu-devel@nongnu.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).