From: Peter Xu <peterx@redhat.com>
To: Eugenio Perez Martin <eperezma@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>,
qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>,
si-wei.liu@oracle.com, Lei Yang <leiyang@redhat.com>,
Dragos Tatulea <dtatulea@nvidia.com>,
Zhu Lingshan <lingshan.zhu@intel.com>,
Parav Pandit <parav@mellanox.com>,
Stefano Garzarella <sgarzare@redhat.com>,
Laurent Vivier <lvivier@redhat.com>
Subject: Re: [PATCH for 9.0 08/12] vdpa: add vhost_vdpa_load_setup
Date: Tue, 2 Jan 2024 13:33:14 +0800 [thread overview]
Message-ID: <ZZOgGmpNT_zi2eat@x1n> (raw)
In-Reply-To: <CAJaqyWfGkboB4sN0PSukKx1kAV-QQ_YSWXWvksPScBD9OgHRsQ@mail.gmail.com>
Jason, Eugenio,
Apologies for a late reply; just back from the long holiday.
On Thu, Dec 21, 2023 at 09:20:40AM +0100, Eugenio Perez Martin wrote:
> Si-Wei did the actual profiling as he is the one with the 128G guests,
> but most of the time was spent in the memory pinning. Si-Wei, please
> correct me if I'm wrong.
IIUC we're talking about no-vIOMMU use case. The pinning should indeed
take a lot of time if it's similar to what VFIO does.
>
> I didn't check VFIO, but I think it just maps at realize phase with
> vfio_realize -> vfio_attach_device -> vfio_connect_container(). In
> previous testings, this delayed the VM initialization by a lot, as
> we're moving that 20s of blocking to every VM start.
>
> Investigating a way to do it only in the case of being the destination
> of a live migration, I think the right place is .load_setup migration
> handler. But I'm ok to move it for sure.
If it's destined to map the 128G, it does sound sensible to me to do it
when VM starts, rather than anytime afterwards.
Could anyone help to explain what's the problem if vDPA maps 128G at VM
init just like what VFIO does?
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2024-01-02 5:34 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-15 17:28 [PATCH for 9.0 00/12] Map memory at destination .load_setup in vDPA-net migration Eugenio Pérez
2023-12-15 17:28 ` [PATCH for 9.0 01/12] vdpa: do not set virtio status bits if unneeded Eugenio Pérez
2023-12-20 4:25 ` Jason Wang
2023-12-15 17:28 ` [PATCH for 9.0 02/12] vdpa: make batch_begin_once early return Eugenio Pérez
2023-12-20 4:27 ` Jason Wang
2023-12-15 17:28 ` [PATCH for 9.0 03/12] vdpa: merge _begin_batch into _batch_begin_once Eugenio Pérez
2023-12-20 4:30 ` Jason Wang
2023-12-15 17:28 ` [PATCH for 9.0 04/12] vdpa: extract out _dma_end_batch from _listener_commit Eugenio Pérez
2023-12-20 4:31 ` Jason Wang
2023-12-15 17:28 ` [PATCH for 9.0 05/12] vdpa: factor out stop path of vhost_vdpa_dev_start Eugenio Pérez
2023-12-20 4:31 ` Jason Wang
2023-12-15 17:28 ` [PATCH for 9.0 06/12] vdpa: check for iova tree initialized at net_client_start Eugenio Pérez
2023-12-15 17:28 ` [PATCH for 9.0 07/12] vdpa: set backend capabilities at vhost_vdpa_init Eugenio Pérez
2023-12-20 4:34 ` Jason Wang
2023-12-20 7:07 ` Eugenio Perez Martin
2023-12-21 3:39 ` Jason Wang
2023-12-15 17:28 ` [PATCH for 9.0 08/12] vdpa: add vhost_vdpa_load_setup Eugenio Pérez
2023-12-20 5:21 ` Jason Wang
2023-12-20 7:06 ` Eugenio Perez Martin
2023-12-21 2:17 ` Jason Wang
2023-12-21 8:20 ` Eugenio Perez Martin
2024-01-02 5:33 ` Peter Xu [this message]
2024-01-02 11:28 ` Eugenio Perez Martin
2024-01-03 6:16 ` Peter Xu
2024-01-03 11:11 ` Eugenio Perez Martin
2024-01-04 6:46 ` Peter Xu
2023-12-15 17:28 ` [PATCH for 9.0 09/12] vdpa: approve switchover after memory map in the migration destination Eugenio Pérez
2023-12-15 17:28 ` [PATCH for 9.0 10/12] vdpa: add vhost_vdpa_net_load_setup NetClient callback Eugenio Pérez
2023-12-15 17:28 ` [PATCH for 9.0 11/12] vdpa: add vhost_vdpa_net_switchover_ack_needed Eugenio Pérez
2023-12-15 17:28 ` [PATCH for 9.0 12/12] virtio_net: register incremental migration handlers Eugenio Pérez
2023-12-25 1:41 ` [PATCH for 9.0 00/12] Map memory at destination .load_setup in vDPA-net migration Lei Yang
2023-12-25 16:30 ` Michael S. Tsirkin
2024-01-02 14:38 ` 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=ZZOgGmpNT_zi2eat@x1n \
--to=peterx@redhat.com \
--cc=dtatulea@nvidia.com \
--cc=eperezma@redhat.com \
--cc=jasowang@redhat.com \
--cc=leiyang@redhat.com \
--cc=lingshan.zhu@intel.com \
--cc=lvivier@redhat.com \
--cc=mst@redhat.com \
--cc=parav@mellanox.com \
--cc=qemu-devel@nongnu.org \
--cc=sgarzare@redhat.com \
--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).