All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: virtio-comment@lists.oasis-open.org
Subject: Re: [virtio-comment] [PATCH V2 1/2] virtio: introduce virtqueue state as basic facility
Date: Thu, 25 Mar 2021 10:42:38 +0800	[thread overview]
Message-ID: <2274873f-68a3-0d4b-8bd4-0fca77dffcb1@redhat.com> (raw)
In-Reply-To: <YFsIrC6KigOjFxli@stefanha-x1.localdomain>

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


在 2021/3/24 下午5:38, Stefan Hajnoczi 写道:
> On Wed, Mar 24, 2021 at 04:15:55PM +0800, Jason Wang wrote:
>> 在 2021/3/23 下午6:27, Stefan Hajnoczi 写道:
>>> On Mon, Mar 22, 2021 at 11:47:16AM +0800, Jason Wang wrote:
>>>> +The \field{used_wrap_counter} field is the wrap counter that is used
>>>> +by the device.
>>>> +
>>>> +The used state is unnecessary when VIRTIO_RING_F_PACKED is not
>>>> +negotiated.
>>>> +
>>>> +See also \ref{sec:Packed Virtqueues / Driver and Device Ring Wrap Counters}.
>>>> +
>>>> +\drivernormative{\subsection}{Virtqueue State}{Basic Facilities of a Virtio Device / Virtqueue State}
>>>> +
>>>> +If VIRTIO_F_QUEUE_STATE has been negotiated, a driver MUST set the
>>>> +state of each virtqueue after setting the FEATURE_OK status bit but
>>>> +before setting the DRIVER_OK status bit.
>>>> +
>>>> +If VIRTIO_F_QUEUE_STATE has been negotiated. a driver MUST reset the
>>> s/negotiated./negotiated,/
>>>
>>>> +device before getting the virtqueue state.
>>> Interesting approach, but it makes sense that the device must be stopped
>>> before we mess with the queue state :).
>>>
>>> I wonder whether requiring the device to keep state across reset will
>>> cause issues in the future or for testing/fuzzing.
>>>
>>> Another approach would have been to add a new status register bit for
>>> pausing the device. That reminds me of vhost.
>>
>> That's the way I did here:
>> https://lists.oasis-open.org/archives/virtio-comment/202012/msg00027.html
> That design seems less risky. I think modifying the semantics of device
> reset might end up being a problem. Defining an explicit paused state
> for saving/loading state seems cleaner.
>
> Why did you end up switching approaches?


I try to seek some short-cut withut introducing new status bit but I end 
up realizing it might not work as expected.

Another reason is that, by using new status bit, we need to ability to 
resume the device by clearing the bit which is somehow conflict with 
what spec requries:

"

2.1.1 Driver Requirements: Device Status Field

The driver MUST NOT clear adevice statusbit.

"

Maybe we can have an exception for the device stop/pause in this case.

Thanks


>
> Stefan

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

  reply	other threads:[~2021-03-25  2:42 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 [this message]
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
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=2274873f-68a3-0d4b-8bd4-0fca77dffcb1@redhat.com \
    --to=jasowang@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.