From: "Eugenio Pérez" <eperezma@redhat.com>
To: qemu-devel@nongnu.org
Cc: Laurent Vivier <lvivier@redhat.com>,
Parav Pandit <parav@mellanox.com>, Cindy Lu <lulu@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Jason Wang <jasowang@redhat.com>,
Gautam Dawar <gdawar@xilinx.com>,
Harpreet Singh Anand <hanand@xilinx.com>,
Eli Cohen <eli@mellanox.com>,
Zhu Lingshan <lingshan.zhu@intel.com>
Subject: [RFC PATCH 0/9] Net Control VQ support in vDPA SVQ
Date: Mon, 14 Feb 2022 20:16:26 +0100 [thread overview]
Message-ID: <20220214191635.1604932-1-eperezma@redhat.com> (raw)
Control virtqueue is used by networking device for accepting various
commands from the driver. It's a must to support multiqueue and other
configurations.
Shadow VirtQueue (SVQ) [1] already makes possible migration of virtqueue
states, effectively intercepting them so qemu can track what regions of memory
are dirty because device action and needs migration. However, this does not
solve networking device state seen by the driver because CVQ messages, like
changes on MAC addresses from the driver.
To solve that, this series uses SVQ infraestructure proposed at SVQ [1] to
intercept networking control messages used by the device. This way, qemu is
able to update VirtIONet device model and to migrate it. This series needs to
be applied on top of [1].
Ideally, only the control VQ would be shadowed for all the run of qemu and the
rest of virtqueues would be passthrough unless it's migration time. However,
this requires the vDPA device to support address translations from more than
one address space, something that is not possible at the moment with the
current vhost-vDPA API. The API change has been proposed at [2], but use of it
is left for future series.
Sending this as a RFC so some details like error control is still not 100%
tested. Comments are welcomed on every aspect of the patch.
[1] https://lore.kernel.org/qemu-devel/20220121202733.404989-1-eperezma@redhat.com/
[2] https://lkml.org/lkml/2020/9/23/1243
Eugenio Pérez (9):
virtio-net: Expose ctrl virtqueue logic
vdpa: Extract get geatures part from vhost_vdpa_get_max_queue_pairs
virtio: Make virtqueue_alloc_element non-static
vhost: Add SVQElement
vhost: Add custom used buffer callback
vdpa: Add map/unmap operation callback to SVQ
vhost: Add vhost_svq_inject
vhost: Add vhost_svq_start_op
vdpa: control virtqueue support on shadow virtqueue
hw/virtio/vhost-shadow-virtqueue.h | 25 +++-
include/hw/virtio/vhost-vdpa.h | 2 +
include/hw/virtio/virtio-net.h | 3 +
include/hw/virtio/virtio.h | 1 +
hw/net/virtio-net.c | 83 ++++++-----
hw/virtio/vhost-shadow-virtqueue.c | 217 +++++++++++++++++++++++------
hw/virtio/vhost-vdpa.c | 22 ++-
hw/virtio/virtio.c | 2 +-
net/vhost-vdpa.c | 140 +++++++++++++++++--
9 files changed, 405 insertions(+), 90 deletions(-)
--
2.27.0
next reply other threads:[~2022-02-14 19:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-14 19:16 Eugenio Pérez [this message]
2022-02-14 19:16 ` [RFC PATCH 1/9] virtio-net: Expose ctrl virtqueue logic Eugenio Pérez
2022-02-14 19:16 ` [RFC PATCH 2/9] vdpa: Extract get geatures part from vhost_vdpa_get_max_queue_pairs Eugenio Pérez
2022-02-14 19:16 ` [RFC PATCH 3/9] virtio: Make virtqueue_alloc_element non-static Eugenio Pérez
2022-02-14 19:16 ` [RFC PATCH 4/9] vhost: Add SVQElement Eugenio Pérez
2022-02-14 19:16 ` [RFC PATCH 5/9] vhost: Add custom used buffer callback Eugenio Pérez
2022-02-14 19:16 ` [RFC PATCH 6/9] vdpa: Add map/unmap operation callback to SVQ Eugenio Pérez
2022-02-14 19:16 ` [RFC PATCH 7/9] vhost: Add vhost_svq_inject Eugenio Pérez
2022-02-15 9:46 ` Eugenio Perez Martin
2022-02-14 19:16 ` [RFC PATCH 8/9] vhost: Add vhost_svq_start_op Eugenio Pérez
2022-02-14 19:16 ` [RFC PATCH 9/9] vdpa: control virtqueue support on shadow virtqueue Eugenio Pérez
2022-02-15 15:51 ` [RFC PATCH 0/9] Net Control VQ support in vDPA SVQ Eugenio Perez Martin
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=20220214191635.1604932-1-eperezma@redhat.com \
--to=eperezma@redhat.com \
--cc=eli@mellanox.com \
--cc=gdawar@xilinx.com \
--cc=hanand@xilinx.com \
--cc=jasowang@redhat.com \
--cc=lingshan.zhu@intel.com \
--cc=lulu@redhat.com \
--cc=lvivier@redhat.com \
--cc=mst@redhat.com \
--cc=parav@mellanox.com \
--cc=qemu-devel@nongnu.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 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).