qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Steve Sistare <steven.sistare@oracle.com>
To: qemu-devel@nongnu.org
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	Philippe Mathieu-Daude <philmd@linaro.org>,
	Eugenio Perez Martin <eperezma@redhat.com>,
	Peter Xu <peterx@redhat.com>, Fabiano Rosas <farosas@suse.de>,
	Si-Wei Liu <si-wei.liu@oracle.com>,
	Steve Sistare <steven.sistare@oracle.com>
Subject: [RFC V1 0/7] Live update: vdpa
Date: Fri, 12 Jul 2024 07:02:04 -0700	[thread overview]
Message-ID: <1720792931-456433-1-git-send-email-steven.sistare@oracle.com> (raw)

Support vdpa devices with the cpr-exec live migration mode.  
This series depends on the QEMU series 
  Live update: cpr-exec
  https://lore.kernel.org/qemu-devel/1719776434-435013-1-git-send-email-steven.sistare@oracle.com/

and depends on the kernel series:
  vdpa live update
  https://lore.kernel.org/virtualization/1720790333-456232-1-git-send-email-steven.sistare@oracle.com/

Preserve the device descriptor across exec, which in turn preserves the
locks on pages which are pinned in memory for DMA.  Suppress the DMA
unmap calls which are normally triggerred when a vdpa device is suspended.
After exec, call VHOST_NEW_OWNER to inform the device that a new process
is in charge.

If the device advertises the VHOST_BACKEND_F_IOTLB_REMAP capability, then
send VHOST_IOTLB_REMAP messages to update the userland address for each
DMA mapping.  Devices that do not advertise this cap have already translated
the userland addresses to physical when the DMA was initially mapped,
and do not require any update.

The cpr-exec mode leverages the vdpa live migration code path for the rest 
of the update, but is faster than live migration because it does not unlock
and relock pages in memory for DMA.

This series does not add any user-visible interfaces.

Steve Sistare (7):
  migration: cpr_needed_for_reuse
  migration: skip dirty memory tracking for cpr
  vdpa/cpr: preserve device fd
  vdpa/cpr: kernel interfaces
  vdpa/cpr: use VHOST_NEW_OWNER
  vdpa/cpr: pass shadow parameter to dma functions
  vdpa/cpr: preserve dma mappings

 hw/virtio/trace-events                       |  5 +-
 hw/virtio/vhost-vdpa.c                       | 71 +++++++++++++++-----
 include/hw/virtio/vhost-vdpa.h               |  7 +-
 include/hw/virtio/vhost.h                    |  1 +
 include/migration/cpr.h                      |  1 +
 include/standard-headers/linux/vhost_types.h |  7 ++
 linux-headers/linux/vhost.h                  |  9 +++
 migration/cpr.c                              |  5 ++
 net/vhost-vdpa.c                             | 29 +++++---
 scripts/tracetool/__init__.py                |  2 +-
 system/memory.c                              | 11 +++
 11 files changed, 120 insertions(+), 28 deletions(-)

-- 
2.39.3



             reply	other threads:[~2024-07-12 14:03 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-12 14:02 Steve Sistare [this message]
2024-07-12 14:02 ` [RFC V1 1/7] migration: cpr_needed_for_reuse Steve Sistare
2024-07-12 14:02 ` [RFC V1 2/7] migration: skip dirty memory tracking for cpr Steve Sistare
2024-08-12 18:57   ` Fabiano Rosas
2024-08-14 19:54     ` Steven Sistare
2024-07-12 14:02 ` [RFC V1 3/7] vdpa/cpr: preserve device fd Steve Sistare
2024-07-12 14:02 ` [RFC V1 4/7] vdpa/cpr: kernel interfaces Steve Sistare
2024-07-12 14:02 ` [RFC V1 5/7] vdpa/cpr: use VHOST_NEW_OWNER Steve Sistare
2024-07-12 14:02 ` [RFC V1 6/7] vdpa/cpr: pass shadow parameter to dma functions Steve Sistare
2024-07-12 14:02 ` [RFC V1 7/7] vdpa/cpr: preserve dma mappings Steve Sistare

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=1720792931-456433-1-git-send-email-steven.sistare@oracle.com \
    --to=steven.sistare@oracle.com \
    --cc=eperezma@redhat.com \
    --cc=farosas@suse.de \
    --cc=jasowang@redhat.com \
    --cc=mst@redhat.com \
    --cc=peterx@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=si-wei.liu@oracle.com \
    /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).