From: Juan Quintela <quintela@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: "Hanna Czenczek" <hreitz@redhat.com>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
virtio-fs-list <virtio-fs@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Eugenio Pérez" <eperezma@redhat.com>,
"Jason Wang" <jasowang@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Dave Gilbert" <dgilbert@redhat.com>
Subject: Re: vhost-user (virtio-fs) migration: back end state
Date: Tue, 07 Feb 2023 00:58:27 +0100 [thread overview]
Message-ID: <87ilgeuz18.fsf@secure.mitica> (raw)
In-Reply-To: <CAJSP0QUO3i+tLfDE0sdNRePnoaqJ7TL29izmk5sDzRt83Ds8tQ@mail.gmail.com> (Stefan Hajnoczi's message of "Mon, 6 Feb 2023 16:16:22 -0500")
Stefan Hajnoczi <stefanha@gmail.com> wrote:
> On Mon, 6 Feb 2023 at 16:02, Juan Quintela <quintela@redhat.com> wrote:
>> The last two bits are on my ToDo list for the near future, but not done.
>>
>> If we ended having lots of so big devices, we are going to have to think
>> about downtimes in the order of dozens of seconds, not subsecond.
>>
>> So, if you are planning doing this in the near future, this is a good
>> time to discuss this.
>
> Can you explain the dirty bitmap requirement you mentioned further, given that:
> 1. vhost-user has dirty memory logging already, so DMA is covered.
> 2. An iterative interface allows the device to keep generating more
> state, so does QEMU really need to know if parts of the previously
> emitted binary blob have become dirty? It might allow QEMU to minimize
> the size of the savevm file, but only if the overwritten data has the
> same size.
>
> Is a dirty bitmap for the device state necessary?
Not for that. My fault. I was talking about a dirty bitmap because
that is how it is implemented in vfio. Notice that qemu don't see that
bitmap. But the device can enter the iterative stage.
The reason that I ask is if you can enter the iterative stage to send
stuff before the last stage.
If you don't have something similar to that, you need to send that in
one go, and that is going to take really a lot of time.
When we are talking about NVidia GPU's, they have two kinds of state:
- Frame buffer: they can (or at some point would have) a dirty bitmap
and they can enter the iterative stage.
- They have internal state that is not visible to the user, that state
is big (around 1GB) and they can't enter the iterative stage, because
they can't know if the guest, the card, or whoever has changed that.
For vhost device:
- what is the "typical" amount of state.
- if it is more than a few megabytes, is there a way to send parts of it
before the ending stage? That is what I asked for a dirty bitmap for
it, but it can be anything else. Just that vhost-user keep track of
what has sent to the other side and then have less state for the last
stage?
Later, Juan.
next prev parent reply other threads:[~2023-02-06 23:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-06 12:35 vhost-user (virtio-fs) migration: back end state Hanna Czenczek
2023-02-06 16:27 ` Stefan Hajnoczi
2023-02-06 21:02 ` Juan Quintela
2023-02-06 21:16 ` Stefan Hajnoczi
2023-02-06 23:58 ` Juan Quintela [this message]
2023-02-07 9:35 ` Hanna Czenczek
2023-02-07 15:13 ` Juan Quintela
2023-02-07 9:08 ` Hanna Czenczek
2023-02-07 12:29 ` Stefan Hajnoczi
2023-02-08 14:32 ` Stefan Hajnoczi
2023-02-08 14:34 ` Michael S. Tsirkin
2023-02-08 15:58 ` Hanna Czenczek
2023-02-08 16:32 ` Stefan Hajnoczi
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=87ilgeuz18.fsf@secure.mitica \
--to=quintela@redhat.com \
--cc=dgilbert@redhat.com \
--cc=eperezma@redhat.com \
--cc=hreitz@redhat.com \
--cc=jasowang@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=stefanha@redhat.com \
--cc=virtio-fs@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 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).