On Fri, Apr 19, 2024 at 11:07:21AM +0100, Daniel P. Berrangé wrote:
> On Thu, Apr 18, 2024 at 04:02:49PM -0400, Peter Xu wrote:
> > On Thu, Apr 18, 2024 at 08:14:15PM +0200, Maciej S. Szmigiero wrote:
> > > I think one of the reasons for these results is that mixed (RAM +
is now about 1450 msec.
> I guess that's from all the extra overhead from switching between 100
> multifd channels.
100 threads are probably too much indeed.
However I agree with Dan's question raised, and I'd like to second that.
It so far looks better if the multifd channels can be managed just like a
pool of workers without assignments to specific jobs. It looks like this
series is already getting there, it's a pity we lose that genericity only
because some other side effects on the ram sync semantics.
>
> I think one of the reasons for these results is that mixed (RAM + device
> state) multifd channels participate in the RAM sync process
> (MULTIFD_FLAG_SYNC) whereas device state dedicated channels don't.
Firstly, I'm wondering whether we can have better names for these new
hooks. Currently (only comment on the async* stuff):
- complete_precopy_async
- complete_precopy
- complete_precopy_async_wait
But perhaps better:
- complete_precopy_begin
- complete_precopy
- complete_precopy_end
?
As I don't see why the device must do something with async in such hook.
To me it's more like you're splitting one process into multiple, then
begin/end sounds more generic.
Then, if with that in mind, IIUC we can already split ram_save_complete()
into >1 phases too. For example, I would be curious whether the performance
will go back to normal if we offloading multifd_send_sync_main() into the
complete_precopy_end(), because we really only need one shot of that, and I
am quite surprised it already greatly affects VFIO dumping its own things.
I would even ask one step further as what Dan was asking: have you thought
about dumping VFIO states via multifd even during iterations? Would that
help even more than this series (which IIUC only helps during the blackout
phase)?
It could mean that the "async*" hooks can be done differently, and I'm not
sure whether they're needed at all, e.g. when threads are created during
save_setup but cleaned up in save_cleanup.
Thanks,
>
> It is possible that there are other subtle performance interactions too,
> but I am not 100% sure about that.
>
> > With regards,
> > Daniel
>
> Best regards,
> Maciej
>
--
Peter Xu
eing equivalent to '-incoming defer' but without the
> > implicit exit.
> >
>
> Probably, that's the best variant. As I can check libvirt in some case, but
> not at all cases. And libvirt is not the only vm manager finally.
> And we can in the same time deprecate "-incoming defer" in favor of new
> behavior.
Or just make it a new migration parameter? Then we keep all existing
interfaces untouched, no risk of breaking anyone, and then it'll also apply
to anyone who uses things like -incoming tcp but still wants to keep the
qemu instance alive?
Thanks,
--
Peter Xu
at
> ../util/coroutine-ucontext.c:175
> #10 0x7fd2a5cf21c0 in () at /lib64/libc.so.6
>
> CC: Fabiano Rosas
> Closes: https://gitlab.com/qemu-project/qemu/-/issues/2277
> Fixes: 2b3912f135 ("block: Mark bdrv_first_blk() and bdrv_is_root_node()
> GRAPH_RDLOCK")
> Signed-off-by: Li Zhijian
queued (and cc stable), thanks.
--
Peter Xu
On Tue, Apr 16, 2024 at 03:28:41PM +0200, Jürgen Groß wrote:
> On 16.04.24 13:32, Edgar E. Iglesias wrote:
> > On Wed, Apr 10, 2024 at 8:56 PM Peter Xu wrote:
> > >
> > > On Wed, Apr 10, 2024 at 06:44:38PM +0200, Edgar E. Iglesias wrote:
> > > > On Tue,
On Fri, Apr 12, 2024 at 11:58:43AM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> > On Thu, Apr 11, 2024 at 04:41:16PM -0300, Fabiano Rosas wrote:
> >> Peter Xu writes:
> >>
> >> > On Thu, Apr 11, 2024 at 11:31:08PM +0530, Het Gala wrote:
On Thu, Apr 11, 2024 at 04:41:16PM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> > On Thu, Apr 11, 2024 at 11:31:08PM +0530, Het Gala wrote:
> >> I just wanted to highlight couple of pointers:
> >> 1. though we are using 'channels' in the precopy tes
. I think we need people
that understand these stuff well enough, have dedicated time and look after
it.
Thanks,
--
Peter Xu
> 2. Extend channels interface to migrate-incoming QAPI for precopy qtests
You can see whether Fabiano has anything to say, but what you proposed
looks good to me.
Thanks!
--
Peter Xu
On Thu, Apr 11, 2024 at 07:45:21PM +0530, Het Gala wrote:
>
> On 10/04/24 8:23 pm, Peter Xu wrote:
> > !---|
> >CAUTI
On Wed, Apr 10, 2024 at 09:49:15AM -0400, Peter Xu wrote:
> On Wed, Apr 10, 2024 at 02:28:59AM +, Zhijian Li (Fujitsu) via wrote:
> >
> >
> > on 4/10/2024 3:46 AM, Peter Xu wrote:
> >
> > >> Is there document/link about the unittest/CI for migration te
In that case, is there any option we implement it with direct access
mode (however with some extra dynamic permissions applied on top using
some mechanism)?
- perhaps sold old links would be great too so people can read about the
context when it's not obvious, without a need to copy-paste.
Thanks,
--
Peter Xu
then perhaps we don't need to test anywhere
else, as we got the code paths all covered.
We actually do the same already for all kinds of channels for postcopy,
where we stick with either tcp/unix but don't cover the rest.
--
Peter Xu
On Wed, Apr 10, 2024 at 02:28:59AM +, Zhijian Li (Fujitsu) via wrote:
>
>
> on 4/10/2024 3:46 AM, Peter Xu wrote:
>
> >> Is there document/link about the unittest/CI for migration tests, Why
> >> are those tests missing?
> >> Is it hard o
On Tue, Apr 09, 2024 at 09:32:46AM +0200, Jinpu Wang wrote:
> Hi Peter,
>
> On Mon, Apr 8, 2024 at 6:18 PM Peter Xu wrote:
> >
> > On Mon, Apr 08, 2024 at 04:07:20PM +0200, Jinpu Wang wrote:
> > > Hi Peter,
> >
> > Jinpu,
> >
> > Thanks for
t;
> Het Gala (3):
> fixup! tests/qtest/migration: Add negative tests to validate migration
> QAPIs
> fixup! tests/qtest/migration: Add migrate_set_ports into migrate_qmp
> to update migration port value
> fixup! tests/qtest/migration: Add multifd_tcp_plain test using list of
> channels instead of uri
queued, thanks.
--
Peter Xu
Het,
It's all fine, no worries! This is good enough. Let's finish the
discussion in the next patch before a repost.
Thanks,
On Mon, Apr 8, 2024, 2:35 p.m. Het Gala wrote:
>
> On 08/04/24 9:05 pm, Peter Xu
On Mon, Apr 08, 2024 at 04:07:20PM +0200, Jinpu Wang wrote:
> Hi Peter,
Jinpu,
Thanks for joining the discussion.
>
> On Tue, Apr 2, 2024 at 11:24 PM Peter Xu wrote:
> >
> > On Mon, Apr 01, 2024 at 11:26:25PM +0200, Yu Zhang wrote:
> > > Hello Peter und Zhjian,
-migrate_qmp(from, to, args->connect_uri, NULL, "{}");
> +migrate_qmp(from, to, args->connect_uri, args->connect_channels, "{}");
>
> if (args->result != MIG_TEST_SUCCEED) {
> bool allow_active = args->result == MIG_TEST_FAIL;
> --
> 2.22.3
>
--
Peter Xu
_QMP_ERROR) {
> -migrate_qmp_fail(from, args->connect_uri, args->connect_uri, "{}");
> +migrate_qmp_fail(from, args->connect_uri, args->connect_channels,
> "{}");
> goto finish;
> }
--
Peter Xu
53 ("docs/migration: Split 'dirty limit'")
> Signed-off-by: Avihai Horon
queued for rc3, thanks.
--
Peter Xu
gt; the main thread in the case that the channel create event hasn't been
> dispatched.
>
> Originally-by: Lei Wang
> Link:
> https://lore.kernel.org/all/9aa5d1be-7801-40dd-83fd-f7e041ced...@intel.com/T/
> Suggested-by: Peter Xu
The current version doesn't have any of my credits.
On Fri, Apr 05, 2024 at 01:38:31AM +, Wang, Wei W wrote:
> On Friday, April 5, 2024 4:57 AM, Peter Xu wrote:
> > On Fri, Apr 05, 2024 at 12:48:15AM +0800, Wang, Lei wrote:
> > > On 4/5/2024 0:25, Wang, Wei W wrote:> On Thursday, April 4, 2024 10:12
> > > PM, P
On Fri, Apr 05, 2024 at 12:48:15AM +0800, Wang, Lei wrote:
> On 4/5/2024 0:25, Wang, Wei W wrote:> On Thursday, April 4, 2024 10:12 PM,
> Peter
> Xu wrote:
> >> On Thu, Apr 04, 2024 at 06:05:50PM +0800, Wei Wang wrote:
> >>> Before loading the guest states, en
gt; the main thread in the case that the channel create event has been
> dispatched.
>
> Originally-by: Lei Wang
> Link:
> https://lore.kernel.org/all/9aa5d1be-7801-40dd-83fd-f7e041ced...@intel.com/T/
> Suggested-by: Peter Xu
> Signed-off-by: Lei Wang
> Signed-off-by: W
57,7 @@ struct RAMBlock {
off_t bitmap_offset;
uint64_t pages_offset;
-/* bitmap of already received pages in postcopy */
+/* Bitmap of already received pages. Only used on destination side. */
unsigned long *receivedmap;
/*
===8<===
--
Peter Xu
On Wed, Apr 03, 2024 at 04:04:21PM +, Wang, Wei W wrote:
> On Wednesday, April 3, 2024 10:42 PM, Peter Xu wrote:
> > On Wed, Apr 03, 2024 at 04:35:35PM +0800, Wang, Lei wrote:
> > > We should change the following line from
> > >
> > > while (!qemu_sem_t
it can catch it. It seems important if Wei can always reproduce it.
Thanks,
--
Peter Xu
rg/qemu-devel/20230326172540.2571110-1-pet...@redhat.com/
My memory was that we didn't have a good solution to fix it without
breaking the old protocol, so it can only be fixed on newer binaries.
Thanks,
--
Peter Xu
On Tue, Apr 02, 2024 at 05:28:36PM +0800, Wang, Lei wrote:
> On 4/2/2024 15:25, Wang, Wei W wrote:> On Tuesday, April 2, 2024 2:56 PM,
> Wang,
> Lei4 wrote:
> >> On 4/2/2024 0:13, Peter Xu wrote:> On Fri, Mar 29, 2024 at 08:54:07AM
> >> +,
> >> Wan
IC to outperform RDMAs, then it may make
little sense to maintain multiple protocols, considering RDMA migration
code is so special so that it has the most custom code comparing to other
protocols.
Thanks,
--
Peter Xu
On Mon, Apr 01, 2024 at 02:17:28PM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> > On Fri, Mar 29, 2024 at 08:54:07AM +, Wang, Wei W wrote:
> >> On Friday, March 29, 2024 11:32 AM, Wang, Lei4 wrote:
> >> > When using the post-copy preemption
to inform the end users of the RDMA migration status.
>
> [1] https://lore.kernel.org/r/20230920090412.726725-1-lizhij...@fujitsu.com
> [2]
> https://lore.kernel.org/r/cahecvy7hxswn4ow_kog+q+tn6f_kmeichevz1qgm-fbxbpp...@mail.gmail.com
>
> CC: Peter Xu
> CC: Philippe Mathieu-Daud
PY PostcopyTmpPage immediately.
@@ -1743,12 +1763,6 @@ void *postcopy_preempt_thread(void *opaque)
qemu_sem_post(>thread_sync_sem);
-/*
- * The preempt channel is established in asynchronous way. Wait
- * for its completion.
- */
-qemu_sem_wait(>postcopy_qemufile_dst_done);
-
/* Sending RAM_SAVE_FLAG_EOS to terminate this thread */
qemu_mutex_lock(>postcopy_prio_thread_mutex);
while (preempt_thread_should_run(mis)) {
--
2.44.0
--
Peter Xu
ly on top of :
> https://lore.kernel.org/qemu-devel/20240320064911.545001-1-...@redhat.com/
queued, thanks.
--
Peter Xu
igned-off-by: Marc-André Lureau
Acked-by: Peter Xu
--
Peter Xu
d uninitialized
> [-Werror=maybe-uninitialized]
> ../migration/migration.c:2273:5: error: ‘file’ may be used uninitialized
> [-Werror=maybe-uninitialized]
>
> Signed-off-by: Marc-André Lureau
Acked-by: Peter Xu
--
Peter Xu
BLOCK_SIZE, the previous
> loop is entered at least once, so 'ret' is assigned a value in all conditions.
>
> Signed-off-by: Marc-André Lureau
Acked-by: Peter Xu
--
Peter Xu
two more
releases. Hopefully that can ring a louder alarm to the current users with
such warnings, so that people can either stick with old binaries, or invest
developer/test resources to the community.
Thanks,
--
Peter Xu
gt; migration/postcopy: Ensure postcopy_start() sets errp if it fails
queued for 9.0-rc2, thanks.
--
Peter Xu
7657 198 654102221176
Thanks for the test results.
So I am guessing the migration overheads besides pushing the socket is high
enough to make it drop drastically, even if in this case zero detection
shouldn't play a major role considering most of guest mem is pre-filled.
--
Peter Xu
On Thu, Mar 28, 2024 at 02:32:37AM +, Liu, Yuan1 wrote:
> > -Original Message-
> > From: Peter Xu
> > Sent: Thursday, March 28, 2024 3:26 AM
> > To: Liu, Yuan1
> > Cc: Daniel P. Berrangé ; faro...@suse.de; qemu-
> > de...@nongnu.org; hao.xi...@byte
>
> Fix it by setting errp in all of postcopy_start() error paths.
>
> Fixes: 908927db28ea ("migration: Update error description whenever migration
> fails")
I think this should need:
Cc: qemu-stable
> Signed-off-by: Avihai Horon
Reviewed-by: Peter Xu
--
Peter Xu
quot;migration: Join the return path
> thread before releasing to_dst_file"), as shutdown() will not be issued
> for the return-path channel.
>
> Fix it by ensuring migration error is set in case of error in
> migration_completion().
>
> Signed-off-by: Avihai Horon
Review
t;
> > Remove:
> > - RDMA handling from migration
> > - dependencies on libibumad, libibverbs and librdmacm
> >
> > Keep the RAM_SAVE_FLAG_HOOK definition since it might appears
> > in old migration streams.
> >
> > Cc: Peter Xu
> > Cc:
on method.
> #
> +# @qpl: use qpl compression method. Query Processing Library(qpl) is based on
> +# the deflate compression algorithm and use the Intel In-Memory
> Analytics
> +# Accelerator(IAA) accelerated compression and decompression. (Since
> 9.0)
s/9.0/9.1/
> +#
> # Since: 5.0
> ##
> { 'enum': 'MultiFDCompression',
>'data': [ 'none', 'zlib',
> -{ 'name': 'zstd', 'if': 'CONFIG_ZSTD' } ] }
> +{ 'name': 'zstd', 'if': 'CONFIG_ZSTD' },
> +{ 'name': 'qpl', 'if': 'CONFIG_QPL' } ] }
>
> ##
> # @MigMode:
> --
> 2.39.3
>
Reviewed-by: Peter Xu
--
Peter Xu
On Fri, Mar 22, 2024 at 12:40:32PM -0400, Peter Xu wrote:
> > > void multifd_recv_zero_page_process(MultiFDRecvParams *p)
> > > {
> > > for (int i = 0; i < p->zero_num; i++) {
> > > void *page = p->host + p->zero[i];
>
er our
discussion in the other thread, the DMA fault latency cannot.
I think we can mention the possibility of IOTLB flush issue but that
shouldn't be the major cause of such suggestion. Again, I think it'll be
great to mention how slow a DMA page fault can be, it can be compared in
migration performance difference, or just describe an average DMA page
fault latency, v.s. a processor fault. That might explain why we suggest
prefault the pages (comparing to a generic setup where the pages are always
faulted by processors).
> +
> +Since the normal pages on the source side are all populated, ``IOTLB`` caused
> +by I/O page fault will not occur. On the destination side, a large number
> +of normal pages need to be loaded, so it is recommended to add
> ``-mem-prealloc``
> +parameter on the destination side.
> --
> 2.39.3
>
--
Peter Xu
On Fri, Mar 22, 2024 at 02:47:02PM +, Liu, Yuan1 wrote:
> > -Original Message-
> > From: Liu, Yuan1
> > Sent: Friday, March 22, 2024 10:07 AM
> > To: Peter Xu
> > Cc: Daniel P. Berrangé ; faro...@suse.de; qemu-
> > de...@nongnu.org; hao.xi...@byte
ogus documentation of query-migrationthreads
With Fabiano's fixup squashed:
Reviewed-by: Peter Xu
Thanks!
--
Peter Xu
On Thu, Mar 21, 2024 at 12:20:32PM -0400, Peter Xu wrote:
> On Wed, Mar 20, 2024 at 05:44:53PM -0400, pet...@redhat.com wrote:
> > From: Peter Xu
> >
> > On current code base I can observe extremely high sync count during
> > precopy, as long as one enables postco
gt; migration: Add Error** argument to xbzrle_init()
> migration: Modify ram_init_bitmaps() to report dirty tracking errors
>
> The VFIO changes depend on the above. They are simpler and have been
> reviewed already. I kept them for another series.
queued for 9.1, thanks.
--
Peter Xu
Yong. I think I'll go ahead and queue it then.
It should be in the 1st migration pull for 9.1. Thanks,
--
Peter Xu
(pages->block, pages->offset[i], true);
> }
>
> -for (int i = p->pages->num; i < zero_num; i++) {
> +for (int i = p->pages->normal_num; i < p->pages->num; i++) {
> ramblock_set_file_bmap_atomic(pages->block, pages->offset[i], false);
> }
> }
Hmm, a challenging one even if it reads obvious.. :)
queued for 9.0-rc1, thanks.
--
Peter Xu
On Wed, Mar 20, 2024 at 05:44:53PM -0400, pet...@redhat.com wrote:
> From: Peter Xu
>
> On current code base I can observe extremely high sync count during
> precopy, as long as one enables postcopy-ram=on before switchover to
> postcopy.
>
> To provide some context of
On Thu, Mar 21, 2024 at 01:37:36AM +, Liu, Yuan1 wrote:
> > -Original Message-
> > From: Peter Xu
> > Sent: Thursday, March 21, 2024 4:32 AM
> > To: Liu, Yuan1
> > Cc: Daniel P. Berrangé ; faro...@suse.de; qemu-
> > de...@nongnu.org; hao.xi...@byte
On Wed, Mar 20, 2024 at 03:46:44PM -0400, Peter Xu wrote:
> On Wed, Mar 20, 2024 at 08:21:30PM +0100, Nina Schoetterl-Glausch wrote:
> > On Wed, 2024-03-20 at 14:57 -0400, Peter Xu wrote:
> > > On Wed, Mar 20, 2024 at 06:51:26PM +0100, Nina Schoetterl-Glausch wrote:
> >
sh only
needed if a tear down happens?
>
> Due to the inability to quickly resolve a large number of IO page faults
> and IOTLB flushes, the decompression throughput of the IAA device will
> decrease significantly.
--
Peter Xu
On Wed, Mar 20, 2024 at 08:21:30PM +0100, Nina Schoetterl-Glausch wrote:
> On Wed, 2024-03-20 at 14:57 -0400, Peter Xu wrote:
> > On Wed, Mar 20, 2024 at 06:51:26PM +0100, Nina Schoetterl-Glausch wrote:
> > > On Wed, 2024-01-17 at 15:58 +0800, pet...@redhat.com wrote:
>
On Wed, Mar 20, 2024 at 06:51:26PM +0100, Nina Schoetterl-Glausch wrote:
> On Wed, 2024-01-17 at 15:58 +0800, pet...@redhat.com wrote:
> > From: Peter Xu
> >
> > When the migration frameworks fetches the exact pending sizes, it means
> > this check:
> >
> &g
On Wed, Mar 20, 2024 at 05:15:06PM +0100, Cédric Le Goater wrote:
> Sure, or I will in a v6. Markus had a comment on 8/14.
Yeah, I can handle both if they're the only ones. Thanks,
--
Peter Xu
recommend that
> customers need to add -mem-prealloc for destination boot parameters.
I'm not sure what issue you hit when testing it, but -mem-prealloc flag
should only control the guest memory backends not the buffers that QEMU
internally use, afaiu.
Thanks,
--
Peter Xu
ty log not ever
started.
For those bits, I'll wait and see whether Yong or Hailiang (cced) has any
comments. From generic migration/memory side, nothing I see wrong:
Acked-by: Peter Xu
Thanks,
--
Peter Xu
On Wed, Mar 20, 2024 at 07:49:06AM +0100, Cédric Le Goater wrote:
> We will use it in ram_init_bitmaps() to clear the allocated bitmaps when
> support for error reporting is added to memory_global_dirty_log_start().
>
> Signed-off-by: Cédric Le Goater
Reviewed-by: Peter Xu
--
Peter Xu
t; performed to stop dirty logging on all listeners where it was
> previously enabled.
>
> Cc: Stefano Stabellini
> Cc: Anthony Perard
> Cc: Paul Durrant
> Cc: "Michael S. Tsirkin"
> Cc: Paolo Bonzini
> Cc: David Hildenbrand
> Signed-off-by: Cédric Le Goater
osely to check that
> cleanups are still correctly done.
>
> Signed-off-by: Cédric Le Goater
Reviewed-by: Peter Xu
--
Peter Xu
Thanks,
--
Peter Xu
FileMigrationArgs::filename field of the new API with the
> "/dev/fdset/NN" syntax, both of which are already supported.
>
> Signed-off-by: Fabiano Rosas
queued for 9.0-rc1.
--
Peter Xu
ress
> *migrate_get_socket_address(QTestState *who)
> QObject *object;
>
> rsp = migrate_query(who);
> +
> +if (!qdict_haskey(rsp, "socket-address")) {
> +return NULL;
> +}
> object = qdict_get(rsp, "socket-address");
>
> iv = qobject_input_visitor_new(object);
> --
> 2.22.3
>
--
Peter Xu
;u.fd.str);
> case SOCKET_ADDRESS_TYPE_VSOCK:
> -return g_strdup_printf("tcp:%s:%s",
> +return g_strdup_printf("vsock:%s:%s",
> addr->u.vsock.cid,
> addr->u.vsock.port);
> default:
Queued for 9.1, thanks.
--
Peter Xu
On Tue, Mar 19, 2024 at 07:52:47PM +, Daniel P. Berrangé wrote:
> On Tue, Mar 19, 2024 at 03:25:18PM -0400, Peter Xu wrote:
> > On Tue, Mar 19, 2024 at 04:25:32PM +, Daniel P. Berrangé wrote:
> > > On Fri, Mar 15, 2024 at 04:54:27PM -0400, Peter Xu wrote:
> > > &
On Tue, Mar 19, 2024 at 04:25:32PM +, Daniel P. Berrangé wrote:
> On Fri, Mar 15, 2024 at 04:54:27PM -0400, Peter Xu wrote:
> > On Fri, Mar 15, 2024 at 03:01:09PM -0300, Fabiano Rosas wrote:
> > > Peter Xu writes:
> > >
> > > > [I queued patch 1-2 into
On Mon, Mar 18, 2024 at 08:08:29PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> On 08.03.24 06:47, Peter Xu wrote:
> > On Thu, Mar 07, 2024 at 12:06:59PM +0300, Maksim Davydov wrote:
> > >
> > > On 3/6/24 04:57, Peter Xu wrote:
> > > > On Tue, Mar 05, 2024
this can fail now, after all migration is
extra feature on top of VM's emulation functions, so it's optional.
Thanks,
--
Peter Xu
On Mon, Mar 18, 2024 at 03:54:28PM +0100, Cédric Le Goater wrote:
> On 3/15/24 12:18, Peter Xu wrote:
> > > @@ -3009,13 +3045,16 @@ static void
> > > listener_add_address_space(MemoryListener *listener,
> > > {
> > > FlatView *view;
> > >
ad on offset 0x2. IOW, I think it'll
also work if xhci_cap_ops can support impl.min_access_size=2, however I
don't know whether that can be more than that register, so that the memory
patch is still a more generic approach.
Thanks,
--
Peter Xu
(mr, current_addr, value, access_size, access_shift *
> 8,
> + access_mask, attrs);
> }
> if (mr->dev && reentrancy_guard_applied) {
> mr->dev->mem_reentrancy_guard.engaged_in_io = false;
> --
> 2.39.2
>
--
Peter Xu
On Fri, Mar 15, 2024 at 03:01:09PM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> > [I queued patch 1-2 into -stable, leaving this patch for further
> > discussions]
> >
> > On Fri, Mar 15, 2024 at 08:55:42AM +, Daniel P. Berrangé wrote:
> >>
y helpful if there can be a summary of how libvirt uses
fd for migration purpose.
Thanks,
--
Peter Xu
On Wed, Mar 06, 2024 at 02:34:37PM +0100, Cédric Le Goater wrote:
> Let the callers do the reporting. This will be useful in
> vfio_iommu_map_dirty_notify().
>
> Cc: "Michael S. Tsirkin"
> Cc: Paolo Bonzini
> Cc: David Hildenbrand
> Signed-off-by: Cédric Le
On Fri, Mar 15, 2024 at 03:31:28PM +0100, Cédric Le Goater wrote:
> On 3/15/24 14:11, Peter Xu wrote:
> > On Fri, Mar 15, 2024 at 01:20:49PM +0100, Cédric Le Goater wrote:
> > > +static void qemu_savevm_wait_unplug(MigrationState *s, int state)
> >
> > One more triv
On Fri, Mar 15, 2024 at 03:21:27PM +0100, Cédric Le Goater wrote:
> On 3/15/24 13:20, Cédric Le Goater wrote:
> > On 3/15/24 12:01, Peter Xu wrote:
> > > On Fri, Mar 15, 2024 at 11:17:45AM +0100, Cédric Le Goater wrote:
> > > > > migrate_set_state is also unint
e can
perhaps assert it instead of passing it over?
--
Peter Xu
On Fri, Mar 15, 2024 at 01:20:49PM +0100, Cédric Le Goater wrote:
> On 3/15/24 12:01, Peter Xu wrote:
> > On Fri, Mar 15, 2024 at 11:17:45AM +0100, Cédric Le Goater wrote:
> > > > migrate_set_state is also unintuitive because it ignores invalid state
> > > >
t; QIOChannel gets freed and the fd closed while outgoing_args.fd still
> has it available. This could lead to an fd-reuse bug.
>
> Duplicate the outgoing_args fd to avoid this issue.
>
> Suggested-by: Peter Xu
> Signed-off-by: Fabiano Rosas
Reviewed-by: Peter Xu
--
Peter Xu
gt;
> Add the missing verification and update the comment explaining this
> situation which is currently incorrect.
>
> Fixes: decdc76772 ("migration/multifd: Add mapped-ram support to fd: URI")
> Signed-off-by: Fabiano Rosas
Reviewed-by: Peter Xu
--
Peter Xu
ret = listener->log_global_start(listener, _err);
> +ret = listener->log_global_start(listener, errp);
> if (!ret) {
> break;
> }
> @@ -2969,14 +2968,14 @@ void memory_global_dirty_log_start(unsigned int flags)
> if (!ret) {
> memory_global_dirty_log_rollback(QTAILQ_PREV(listener, link),
> flags);
> -error_report_err(local_err);
> -return;
> +return false;
> }
>
> memory_region_transaction_begin();
> memory_region_update_pending = true;
> memory_region_transaction_commit();
> }
> +return true;
> }
>
> static void memory_global_dirty_log_do_stop(unsigned int flags)
> --
> 2.44.0
>
--
Peter Xu
le()) {
error_setg(errp, "device_add not allowed while migrating");
return NULL;
}
If it really happens it's a bug, as listener_add_address_space() will still
keep the rest things around even if the hook failed. It'll start to be a
total mess..
Thanks,
> }
> }
>
> --
> 2.44.0
>
--
Peter Xu
359afc4448c02f566a0e
Author: Laine Stump
Date: Wed Jan 15 16:38:57 2020 -0500
qemu: add wait-unplug to qemu migration status enum
Considering that qemu_savevm_wait_unplug() can be a noop if the device is
already unplugged, I think it means no upper layer app should rely on this
state to present.
Thanks,
--
Peter Xu
didn't.
The two issues are separate. I assume patch 2 will need a rework, but I
queued patch 1 first. Thanks.
--
Peter Xu
On Thu, Mar 14, 2024 at 01:50:07PM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> > On Thu, Mar 14, 2024 at 11:10:12AM -0400, Peter Xu wrote:
> >> On Wed, Mar 13, 2024 at 06:28:24PM -0300, Fabiano Rosas wrote:
> >> > When doing migration using the fd: U
On Thu, Mar 14, 2024 at 01:44:13PM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> > On Wed, Mar 13, 2024 at 06:28:24PM -0300, Fabiano Rosas wrote:
> >> When doing migration using the fd: URI, the incoming migration starts
> >> before the user has pass
On Thu, Mar 14, 2024 at 01:55:31PM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> > On Wed, Mar 13, 2024 at 06:28:22PM -0300, Fabiano Rosas wrote:
> >> Hi,
> >>
> >> In this v2:
> >>
> >> patch 1 - The fix for the ioc leaks,
On Thu, Mar 14, 2024 at 11:10:12AM -0400, Peter Xu wrote:
> On Wed, Mar 13, 2024 at 06:28:24PM -0300, Fabiano Rosas wrote:
> > When doing migration using the fd: URI, the incoming migration starts
> > before the user has passed the file descriptor to QEMU. This means
>
Ensure we're not given a socket for file migration
>
> migration/fd.c | 35 +++---
> migration/file.c | 65
> migration/file.h | 1 +
> 3 files changed, 60 insertions(+), 41 deletions(-)
>
> --
> 2.35.3
>
--
Peter Xu
ultifd: Add incoming QIOChannelFile support")
> Fixes: decdc76772 ("migration/multifd: Add mapped-ram support to fd: URI")
> Reported-by: Peter Xu
> Signed-off-by: Fabiano Rosas
Reviewed-by: Peter Xu
--
Peter Xu
t;
> #include "trace.h"
> @@ -58,6 +59,12 @@ bool file_send_channel_create(gpointer opaque, Error
> **errp)
> int fd = fd_args_get_fd();
>
> if (fd && fd != -1) {
> +if (fd_is_socket(fd)) {
> +error_setg(errp,
> + "Multifd migration to a socket FD is not supported");
> +goto out;
> +}
> +
> ioc = qio_channel_file_new_dupfd(fd, errp);
> } else {
> ioc = qio_channel_file_new_path(outgoing_args.fname, flags, 0, errp);
> --
> 2.35.3
>
--
Peter Xu
(qemu) info status
> + VM status: paused (suspended)
> + (qemu) system_wakeup
> + (qemu) info status
> + VM status: running
> +
> +Caveats
> +^^^
> +
> +cpr-reboot mode may not be used with postcopy, background-snapshot,
> +or COLO.
> diff --git a/docs/devel/migration/features.rst
> b/docs/devel/migration/features.rst
> index 9d1abd2..d5ca7b8 100644
> --- a/docs/devel/migration/features.rst
> +++ b/docs/devel/migration/features.rst
> @@ -11,3 +11,4 @@ Migration has plenty of features to support different use
> cases.
> vfio
> virtio
> mapped-ram
> + CPR
> --
> 1.8.3.1
>
--
Peter Xu
t;
> Fixes: 2dd7ee7a51 ("migration/multifd: Add incoming QIOChannelFile support")
> Fixes: decdc76772 ("migration/multifd: Add mapped-ram support to fd: URI")
> Reported-by: Peter Xu
> Signed-off-by: Fabiano Rosas
> ---
> based-on: https://gitlab.com/peterx/migratio
On Tue, Mar 12, 2024 at 05:34:26PM -0400, Stefan Hajnoczi wrote:
> I understand now. I missed that returning from init_blk_migration_it()
> did not abort iteration. Thank you!
I queued it, thanks both!
--
Peter Xu
1 - 100 of 7794 matches
Mail list logo
