[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] [PATCH 0/5] virtio: introduce SUSPEND bit and vq state
On Wed, Sep 6, 2023 at 3:49âPM Michael S. Tsirkin <mst@redhat.com> wrote: > > On Wed, Sep 06, 2023 at 04:38:44PM +0800, Zhu, Lingshan wrote: > > > > > > On 9/6/2023 4:29 PM, Michael S. Tsirkin wrote: > > > On Wed, Sep 06, 2023 at 04:16:32PM +0800, Zhu Lingshan wrote: > > > > This series introduces > > > > 1)a new SUSPEND bit in the device status > > > > Which is used to suspend the device, so that the device states > > > > and virtqueue states are stabilized. > > > > > > > > 2)virtqueue state and its accessor, to get and set last_avail_idx > > > > and last_used_idx of virtqueues. > > > > > > > > The main usecase of these new facilities is Live Migration. > > > > > > > > Future work: dirty page tracking and in-flight descriptors. > > > oh that answers my question - it's not covered. > > > I don't think we can merge this without in-flight descriptor > > > support. > > When SUSPEND, we require the device wait until all descriptors that > > being processed to finish and mark them as used.(In patch 2) > > at this point there may be no in-flight descriptors, so this is still > > self-consistent. The tracker for in-flight descriptors is excluded to > > make this series small and focus. > > Does not work generally. > Imagine RX ring of a network device for example. You can wait > as long as you can but if there's no incoming network traffic > buffers will not be used. > The patch should word it differently, yes. QEMU's vhost-kernel net handler currently assumes the device will use the descriptors sequentially from avail_idx. In that case, it is possible to simply finish receiving in-flight packets (not buffers) and just stop receiving new packets. As all packets has been received, we have a valid used-idx, and the device at resume (or the destination device at migration) can just fetch all buffers from there. I may have a better wording of this in other mails. Would it work to use this solution with in_order, and defer the inflight buffers handling for the future? It would allow to keep this series small. Thanks! > Also please, keep to the spec terminology. buffers are used not > descriptors. Best to keep it straight errors will not leak into > spec. > > > > > > > > > > > > > > > This series addresses many comments from Jason, Stefan and Eugenio > > > > from RFC series. > > > > > > > > Zhu Lingshan (5): > > > > virtio: introduce vq state as basic facility > > > > virtio: introduce SUSPEND bit in device status > > > > virtqueue: constraints for virtqueue state > > > > virtqueue: ignore resetting vqs when SUSPEND > > > > virtio-pci: implement VIRTIO_F_QUEUE_STATE > > > > > > > > content.tex | 118 ++++++++++++++++++++++++++++++++++++++++++++++ > > > > transport-pci.tex | 18 +++++++ > > > > 2 files changed, 136 insertions(+) > > > > > > > > -- > > > > 2.35.3 > > > > > > > > > > > > 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/ > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]