From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: Halil Pasic <pasic@linux.ibm.com>,
Cornelia Huck <cohuck@redhat.com>,
stefanha@redhat.com, virtio-comment@lists.oasis-open.org,
eperezma@redhat.com, sgarzare@redhat.com
Subject: Re: [virtio-comment] [PATCH RFC] virtio: introduce VIRTIO_F_DEVICE_STOP
Date: Tue, 12 Jan 2021 05:54:56 -0500 [thread overview]
Message-ID: <20210112054859-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <661905925.40710498.1609232667286.JavaMail.zimbra@redhat.com>
On Tue, Dec 29, 2020 at 04:04:27AM -0500, Jason Wang wrote:
> > > > > However wouldn't it be possible for device to just cancel
> > > > > processing available buffers even if it started processing
> > > > > them? Some buffers could be in indeterminate state
> > > > > (e.g. we might not have a way to know how much data did
> > > > > device have time to write into a buffer).
> > > > >
> > > > Maybe Jason can answer this one.
> > >
> > >
> > > For networking device, it should be possible (packet could be dropped or
> > > duplicated). But I'm not sure it works for other device. E.g for the block
> > > devices that needs to communicate with a remote backend. Waat's more
> > > important, my understadning is that the intermediate state is something
> > > that
> > > we need to avoid (hard to be migrated anyhow).
> >
> > The difficulty is on the device side though, so why not say: if it wants to
> > flush IO that's up to it.
>
> Do you mean to introduce a device specific way to flush IO? If yes, it
> actually introduces a new intermediate state implicitly:
>
> 1) device is stopped
> 2) device is stopped and IO is flushed
>
> This looks more complicated than a single new state:
>
> 1) device is stopped and IO is flushed
>
> Thanks
I thought some more about it, if we call a buffer which was
made available by driver but not yet used by device,
a cancelled buffer, then maybe we can specify
the behaviour by explaining that it should be possible to
retry any cancelled buffer, that is make it available again,
and achieve the same effect as if it was used.
For example, any reads without side effects can be just
ignored even if they might have modified guest memory.
--
MST
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-01-12 10:55 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-18 4:23 [virtio-comment] [PATCH RFC] virtio: introduce VIRTIO_F_DEVICE_STOP Jason Wang
2020-12-18 10:15 ` [virtio-comment] " Stefano Garzarella
2020-12-21 3:08 ` Jason Wang
2020-12-21 11:06 ` Stefano Garzarella
2020-12-22 2:38 ` Jason Wang
2020-12-21 21:33 ` [virtio-comment] " Halil Pasic
2020-12-22 2:36 ` Jason Wang
2020-12-22 6:50 ` Halil Pasic
2020-12-22 7:30 ` Jason Wang
2020-12-22 12:14 ` Cornelia Huck
2020-12-22 12:51 ` Jason Wang
2020-12-22 15:54 ` Cornelia Huck
2020-12-23 2:48 ` Jason Wang
2020-12-25 7:38 ` Halil Pasic
2020-12-27 10:00 ` Michael S. Tsirkin
2020-12-28 6:21 ` Halil Pasic
2020-12-28 7:01 ` Jason Wang
2020-12-28 12:30 ` Michael S. Tsirkin
2020-12-29 9:04 ` Jason Wang
2021-01-12 10:54 ` Michael S. Tsirkin [this message]
2021-01-13 3:35 ` Jason Wang
2020-12-29 13:35 ` Halil Pasic
2020-12-30 8:15 ` Jason Wang
2021-01-11 18:16 ` Cornelia Huck
2021-01-12 3:27 ` Jason Wang
2021-01-12 12:13 ` Cornelia Huck
2021-01-13 2:52 ` Jason Wang
2021-01-14 12:00 ` Cornelia Huck
2020-12-28 6:47 ` Jason Wang
2020-12-29 13:20 ` Halil Pasic
2020-12-30 8:03 ` Jason Wang
2020-12-24 4:52 ` Halil Pasic
2020-12-24 5:51 ` Jason Wang
2020-12-25 3:18 ` Halil Pasic
2020-12-25 6:45 ` Jason Wang
2020-12-27 11:12 ` Michael S. Tsirkin
2020-12-28 7:05 ` Jason Wang
2020-12-28 12:27 ` Michael S. Tsirkin
2020-12-29 8:57 ` Jason Wang
2021-05-03 9:02 ` [virtio-comment] " Eugenio Perez Martin
2021-05-06 2:51 ` Jason Wang
2021-05-05 13:16 ` Michael S. Tsirkin
2021-05-06 7:26 ` Jason Wang
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=20210112054859-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=cohuck@redhat.com \
--cc=eperezma@redhat.com \
--cc=jasowang@redhat.com \
--cc=pasic@linux.ibm.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.