From: Jason Wang <jasowang@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: mst@redhat.com, virtio-comment@lists.oasis-open.org,
eperezma@redhat.com, lulu@redhat.com, rob.miller@broadcom.com,
pasic@linux.ibm.com, sgarzare@redhat.com, cohuck@redhat.com,
jim.harford@broadcom.com
Subject: Re: [virtio-comment] [PATCH V2 0/2] Introduce VIRTIO_F_QUEUE_STATE
Date: Wed, 24 Mar 2021 15:05:30 +0800 [thread overview]
Message-ID: <48f5695e-9a34-88cd-44a4-a9d31426e6eb@redhat.com> (raw)
In-Reply-To: <YFnFpcaAg0atjwTt@stefanha-x1.localdomain>
在 2021/3/23 下午6:40, Stefan Hajnoczi 写道:
> On Mon, Mar 22, 2021 at 11:47:15AM +0800, Jason Wang wrote:
>> This is a new version to support VIRTIO_F_QUEUE_STATE. The feautre
>> extends the basic facility to allow the driver to set and get device
>> internal virtqueue state. This main motivation is to support live
>> migration of virtio devices.
> Can you describe the use cases that this interface covers as well as the
> steps involved in migrating a device?
Yes. I can describe the steps for live migrating virtio-net device. For
other devices, we probably need other state.
> Traditionally live migration was
> transparent to the VIRTIO driver because it was performed by the
> hypervisor.
Right, but it could be possible that we may want live migrate between
hardware virtio-pci devices. So it's up to the hypversior to save and
restore states silently without the notice of guest driver as what we
did for vhost.
>
> I know you're aware but I think it's worth mentioning that this only
> supports stateless devices.
Yes, that's why it's a queue state not a device state.
> Even the simple virtio-blk device has state
> in QEMU's implementation. If an I/O request fails it can be held by the
> device and resumed after live migration instead of failing the request
> immediately. The list of held requests needs to be migrated with the
> device and is not part of the virtqueue state.
Yes, I think we need to extend virtio spec to support save and restore
device state. But anyway the virtqueue state is the infrastructure which
should be introdouced first.
>
> I'm concerned that using device reset will not work once this interface
> is extended to support device-specific state (e.g. the virtio-blk failed
> request list). There could be situations where reset really needs to
> reset (e.g. freeing I/O resources) and the device therefore cannot hold
> on to state across reset.
Good point. So here're some ways:
1) reuse device reset that is done in this patch
2) intorduce a new device status like what has been done in [1]
3) using queue_enable (as what has been done in the virtio-mmio, pci
forbids to stop a queue currently, we may need to extend that)
4) use device specific way to stop the datapath
Reusing device reset looks like a shortcut that might not be easy for
stateful device as you said. 2) looks more general. 3) have the issues
that it doesn't forbid the config changed. And 4) is also proposed by
you and Michael.
My understanding is that there should be no fundamental differences
between 2) and 4). So I tend to respin [1], do you have any other ideas?
Thanks
[1]
https://lists.oasis-open.org/archives/virtio-comment/202012/msg00027.html
>
> Stefan
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
next prev parent reply other threads:[~2021-03-24 7:05 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-22 3:47 [virtio-comment] [PATCH V2 0/2] Introduce VIRTIO_F_QUEUE_STATE Jason Wang
2021-03-22 3:47 ` [virtio-comment] [PATCH V2 1/2] virtio: introduce virtqueue state as basic facility Jason Wang
2021-03-22 8:19 ` [virtio-comment] " Eugenio Perez Martin
2021-03-23 2:54 ` Jason Wang
2021-03-23 9:27 ` Eugenio Perez Martin
2021-03-23 10:27 ` [virtio-comment] " Stefan Hajnoczi
2021-03-24 8:15 ` Jason Wang
2021-03-24 9:35 ` Stefan Hajnoczi
2021-03-25 2:38 ` Jason Wang
2021-03-24 9:38 ` Stefan Hajnoczi
2021-03-25 2:42 ` Jason Wang
2021-03-25 9:59 ` Stefan Hajnoczi
2021-03-22 3:47 ` [virtio-comment] [PATCH V2 2/2] virtio-pci: implement VIRTIO_F_QUEUE_STATE Jason Wang
2021-03-23 10:02 ` Stefan Hajnoczi
2021-03-23 10:40 ` [virtio-comment] [PATCH V2 0/2] Introduce VIRTIO_F_QUEUE_STATE Stefan Hajnoczi
2021-03-24 7:05 ` Jason Wang [this message]
2021-03-24 10:05 ` Stefan Hajnoczi
2021-03-25 2:57 ` Jason Wang
2021-03-25 10:03 ` [virtio-comment] [PATCH V2 0/2] Introduce VIRTIO_F_QUEUE_STATE\\ 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=48f5695e-9a34-88cd-44a4-a9d31426e6eb@redhat.com \
--to=jasowang@redhat.com \
--cc=cohuck@redhat.com \
--cc=eperezma@redhat.com \
--cc=jim.harford@broadcom.com \
--cc=lulu@redhat.com \
--cc=mst@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=rob.miller@broadcom.com \
--cc=sgarzare@redhat.com \
--cc=stefanha@redhat.com \
--cc=virtio-comment@lists.oasis-open.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 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.