From: "Maciej S. Szmigiero"
Allow capping the maximum total size of in-flight VFIO device state buffers
queued at the destination, otherwise a malicious QEMU source could
theoretically cause the target QEMU to allocate unlimited amounts of memory
for buffers-in-flight.
Since t
From: "Maciej S. Szmigiero"
This is an updated v2 patch series of the v1 series located at [1] of the
leftover patches of VFIO multifd migration patch set that was merged in
QEMU 10.0.
Changes from v1:
* Drop the in-flight VFIO device state buffer *count* limit, leave
the *size*
From: "Maciej S. Szmigiero"
This property allows configuring whether to start the config load only
after all iterables were loaded, during non-iterables loading phase.
Such interlocking is required for ARM64 due to this platform VFIO
dependency on interrupt controller being loaded f
On 24.06.2025 19:51, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
When VFIO multifd device state transfer support was merged in QEMU 10.0
some of patches were separated for the future QEMU release after the
spring cleanup.
Since QEMU 10.1 code freeze is getting closer
On 7.07.2025 11:29, Avihai Horon wrote:
On 24/06/2025 20:51, Maciej S. Szmigiero wrote:
External email: Use caution opening links or attachments
From: "Maciej S. Szmigiero"
Allow capping the maximum count of in-flight VFIO device state buffers
queued at the destination, o
On 2.07.2025 08:27, Cédric Le Goater wrote:
Adding more maintainers,
+Eric (ARM smmu),
+Peter (ARM, GIC, virt),
On 6/24/25 19:51, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
This property allows configuring whether to start the config load only
after all iterables w
On 1.07.2025 10:23, Xiaoyao Li wrote:
On 6/30/2025 9:30 PM, Alexandre Chartre wrote:
KVM emulates the ARCH_CAPABILITIES on x86 for both Intel and AMD
cpus, although the IA32_ARCH_CAPABILITIES MSR is an Intel-specific
MSR and it makes no sense to emulate it on AMD.
As a consequence, VMs created
From: "Maciej S. Szmigiero"
Allow capping the maximum count of in-flight VFIO device state buffers
queued at the destination, otherwise a malicious QEMU source could
theoretically cause the target QEMU to allocate unlimited amounts of memory
for buffers-in-flight.
Since this is not e
From: "Maciej S. Szmigiero"
When VFIO multifd device state transfer support was merged in QEMU 10.0
some of patches were separated for the future QEMU release after the
spring cleanup.
Since QEMU 10.1 code freeze is getting closer let's have them reviewed
now.
The most impor
From: "Maciej S. Szmigiero"
There's already a max in-flight VFIO device state buffers *count* limit,
add also max queued buffers *size* limit.
Signed-off-by: Maciej S. Szmigiero
---
docs/devel/migration/vfio.rst | 8 +---
hw/vfio/migration-multifd.c | 21 +++
From: "Maciej S. Szmigiero"
This property allows configuring whether to start the config load only
after all iterables were loaded.
Such interlocking is required for ARM64 due to this platform VFIO
dependency on interrupt controller being loaded first.
The property defaults to AUTO, w
On 14.05.2025 10:49, Zhao Liu wrote:
The QOM type of HvBalloon is declared by OBJECT_DECLARE_SIMPLE_TYPE,
which means it doesn't need the class!
Therefore, use OBJECT_DEFINE_SIMPLE_TYPE_WITH_INTERFACES to implement
the type, then there's no need for class definition.
Cc: "Maci
From: "Maciej S. Szmigiero"
If zerocopy is enabled for multifd then QIO_CHANNEL_WRITE_FLAG_ZERO_COPY
flag is forced into all multifd channel write calls via p->write_flags
that was setup in multifd_nocomp_send_setup().
However, device state packets aren't compatible with z
++-
6 files changed, 21 insertions(+), 15 deletions(-)
@Maciej, this is now ready to be tested :)
Tested this patch set on a Windows VM with hv-balloon QEMU device
(which uses VMBus, which in turn uses basic Hyper-V host support).
No problems encountered, so:
Tested-by: Maciej S
On 25.04.2025 01:28, Pierrick Bouvier wrote:
Signed-off-by: Pierrick Bouvier
---
include/system/kvm.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
It looks like this patch was already merged outside of this patch set.
Thanks,
Maciej
On 27.03.2025 19:24, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
Commit 3f2a05b31ee9 ("target/i386: Reset TSCs of parked vCPUs too on VM
reset") introduced a way to reset TSCs of parked vCPUs during VM reset to
prevent them getting desynchronized with the online
On 2.04.2025 11:51, Cédric Le Goater wrote:
Hello Maciej,
On 4/1/25 14:26, Maciej S. Szmigiero wrote:
On 11.03.2025 14:04, Cédric Le Goater wrote:
On 3/7/25 14:45, Maciej S. Szmigiero wrote:
On 7.03.2025 13:03, Cédric Le Goater wrote:
On 3/7/25 11:57, Maciej S. Szmigiero wrote:
From
On 11.03.2025 14:04, Cédric Le Goater wrote:
On 3/7/25 14:45, Maciej S. Szmigiero wrote:
On 7.03.2025 13:03, Cédric Le Goater wrote:
On 3/7/25 11:57, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
There's already a max in-flight VFIO device state buffers *count* lim
From: "Maciej S. Szmigiero"
Commit 3f2a05b31ee9 ("target/i386: Reset TSCs of parked vCPUs too on VM
reset") introduced a way to reset TSCs of parked vCPUs during VM reset to
prevent them getting desynchronized with the online vCPUs and therefore
causing the
On 10.03.2025 10:23, Cédric Le Goater wrote:
On 3/10/25 09:17, Avihai Horon wrote:
On 07/03/2025 12:57, Maciej S. Szmigiero wrote:
External email: Use caution opening links or attachments
From: "Maciej S. Szmigiero"
Wire data commonly use BE byte order (including in the existing
On 11.03.2025 16:00, Philippe Mathieu-Daudé wrote:
Hi Maciej,
On 6/11/23 15:20, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
This driver is like virtio-balloon on steroids: it allows both changing the
guest memory allocation via ballooning and (in the next patch) insert
From: "Maciej S. Szmigiero"
Wire data commonly use BE byte order (including in the existing migration
protocol), use it also for for VFIO device state packets.
This will allow VFIO multifd device state transfer between hosts with
different endianness.
Although currently there is n
On 10.03.2025 09:17, Avihai Horon wrote:
On 07/03/2025 12:57, Maciej S. Szmigiero wrote:
External email: Use caution opening links or attachments
From: "Maciej S. Szmigiero"
Wire data commonly use BE byte order (including in the existing migration
protocol), use it also for for V
On 10.03.2025 01:14, Philippe Mathieu-Daudé wrote:
On 10/3/25 00:33, Pierrick Bouvier wrote:
Hi Maciej,
On 3/7/25 14:31, Maciej S. Szmigiero wrote:
Hi Philippe,
On 7.03.2025 23:25, Philippe Mathieu-Daudé wrote:
Hi Maciej,
On 7/3/25 22:56, Pierrick Bouvier wrote:
Work towards having a
On 10.03.2025 00:33, Pierrick Bouvier wrote:
Hi Maciej,
On 3/7/25 14:31, Maciej S. Szmigiero wrote:
Hi Philippe,
On 7.03.2025 23:25, Philippe Mathieu-Daudé wrote:
Hi Maciej,
On 7/3/25 22:56, Pierrick Bouvier wrote:
Work towards having a single binary, by removing duplicated object files
Hi Philippe,
On 7.03.2025 23:25, Philippe Mathieu-Daudé wrote:
Hi Maciej,
On 7/3/25 22:56, Pierrick Bouvier wrote:
Work towards having a single binary, by removing duplicated object files.
Pierrick Bouvier (7):
hw/hyperv/hv-balloon-stub: common compilation unit
hw/hyperv/hyperv.h: hea
On 7.03.2025 15:50, Alex Bennée wrote:
"Maciej S. Szmigiero" writes:
On 6.03.2025 23:56, Pierrick Bouvier wrote:
On 3/6/25 09:58, Philippe Mathieu-Daudé wrote:
On 6/3/25 17:23, Pierrick Bouvier wrote:
On 3/6/25 08:19, Richard Henderson wrote:
On 3/5/25 22:41, Pierrick Bou
On 7.03.2025 13:03, Cédric Le Goater wrote:
On 3/7/25 11:57, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
There's already a max in-flight VFIO device state buffers *count* limit,
no. there isn't. Do we need both ?
This is on a top of the remaining patch
On 6.03.2025 07:47, Avihai Horon wrote:
On 05/03/2025 0:03, Maciej S. Szmigiero wrote:
External email: Use caution opening links or attachments
From: "Maciej S. Szmigiero"
Implement the multifd device state transfer via additional per-device
thread inside save_live_complete_prec
On 6.03.2025 23:56, Pierrick Bouvier wrote:
On 3/6/25 09:58, Philippe Mathieu-Daudé wrote:
On 6/3/25 17:23, Pierrick Bouvier wrote:
On 3/6/25 08:19, Richard Henderson wrote:
On 3/5/25 22:41, Pierrick Bouvier wrote:
Replace TARGET_PAGE.* by runtime calls
Signed-off-by: Pierrick Bouvier
---
at the first opportunity?
Is it more clear for you?
Thanks,
Maciej
On 3/6/25 12:29, Maciej S. Szmigiero wrote:
On 6.03.2025 07:41, Pierrick Bouvier wrote:
Replace TARGET_PAGE.* by runtime calls.
Seems like this patch subject/title is not aligned
well with its content, or a least
On 6.03.2025 15:26, Cédric Le Goater wrote:
On 3/6/25 15:23, Avihai Horon wrote:
On 06/03/2025 16:13, Maciej S. Szmigiero wrote:
External email: Use caution opening links or attachments
On 6.03.2025 14:37, Avihai Horon wrote:
On 06/03/2025 12:32, Cédric Le Goater wrote:
External email
From: "Maciej S. Szmigiero"
Wire data commonly use BE byte order (including in the existing migration
protocol), use it also for for VFIO device state packets.
Fixes: 3228d311ab18 ("vfio/migration: Multifd device state transfer support -
received buffers queuing")
Fixes:
From: "Maciej S. Szmigiero"
There's already a max in-flight VFIO device state buffers *count* limit,
add also max queued buffers *size* limit.
Signed-off-by: Maciej S. Szmigiero
---
docs/devel/migration/vfio.rst | 8 +---
hw/vfio/migration-multifd.c | 21 +++
On 6.03.2025 07:41, Pierrick Bouvier wrote:
Replace TARGET_PAGE.* by runtime calls.
Seems like this patch subject/title is not aligned
well with its content, or a least incomplete.
Also, could you provide more detailed information
why TARGET_PAGE_SIZE is getting replaced by
qemu_target_page_si
On 6.03.2025 14:37, Avihai Horon wrote:
On 06/03/2025 12:32, Cédric Le Goater wrote:
External email: Use caution opening links or attachments
On 3/6/25 11:15, Maciej S. Szmigiero wrote:
On 6.03.2025 07:47, Avihai Horon wrote:
On 05/03/2025 0:03, Maciej S. Szmigiero wrote:
External email
On 5.03.2025 17:39, Cédric Le Goater wrote:
On 3/5/25 16:11, Maciej S. Szmigiero wrote:
On 5.03.2025 10:19, Cédric Le Goater wrote:
On 3/4/25 23:04, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
Allow capping the maximum count of in-flight VFIO device state buffers
que
On 5.03.2025 17:53, Cédric Le Goater wrote:
So that's PATCH 7 replacement.
Yes, that the replacement for "[PATCH v6 07/36] migration:
postcopy_ram_listen_thread() should take BQL for some calls".
Thanks,
C.
Thanks,
Maciej
On 3/5/25 17:49, Maciej S. Szmigiero wrote:
On 5.03.2025 17:37, Cédric Le Goater wrote:
On 3/5/25 17:15, Peter Xu wrote:
On Wed, Mar 05, 2025 at 04:11:30PM +0100, Maciej S. Szmigiero wrote:
On 5.03.2025 13:34, Peter Xu wrote:
On Tue, Mar 04, 2025 at 11:03:34PM +0100, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
A
From: "Maciej S. Szmigiero"
All callers to migration_incoming_state_destroy() other than
postcopy_ram_listen_thread() do this call with BQL held.
Since migration_incoming_state_destroy() ultimately calls "load_cleanup"
SaveVMHandlers and it will soon call BQL-sensitive co
On 5.03.2025 17:22, Peter Xu wrote:
On Tue, Mar 04, 2025 at 11:03:52PM +0100, Maciej S. Szmigiero wrote:
@@ -509,6 +513,9 @@ static void vfio_save_cleanup(void *opaque)
Error *local_err = NULL;
int ret;
+/* Currently a NOP, done for symmetry with load_cleanup
On 5.03.2025 10:19, Cédric Le Goater wrote:
On 3/4/25 23:04, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
Allow capping the maximum count of in-flight VFIO device state buffers
queued at the destination, otherwise a malicious QEMU source could
theoretically cause the targ
On 5.03.2025 13:34, Peter Xu wrote:
On Tue, Mar 04, 2025 at 11:03:34PM +0100, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
All callers to migration_incoming_state_destroy() other than
postcopy_ram_listen_thread() do this call with BQL held.
Since migration_incoming_sta
From: "Maciej S. Szmigiero"
Some drivers might want to make use of auxiliary helper threads during VM
state loading, for example to make sure that their blocking (sync) I/O
operations don't block the rest of the migration process.
Add a migration core managed thread pool to faci
From: "Maciej S. Szmigiero"
Add vfio_multifd_transfer_supported() function that tells whether the
multifd device state transfer is supported.
Reviewed-by: Cédric Le Goater
Signed-off-by: Maciej S. Szmigiero
---
hw/vfio/migration-multifd.c | 6 ++
hw/vfio/migration-multifd.h
From: "Maciej S. Szmigiero"
The multifd received data needs to be reassembled since device state
packets sent via different multifd channels can arrive out-of-order.
Therefore, each VFIO device state packet carries a header indicating its
position in the stream.
The raw device sta
From: "Maciej S. Szmigiero"
Implement the multifd device state transfer via additional per-device
thread inside save_live_complete_precopy_thread handler.
Switch between doing the data transfer in the new handler and doing it
in the old save_state handler depending if VFIO multifd t
From: "Maciej S. Szmigiero"
Add a thread which loads the VFIO device state buffers that were received
via multifd.
Each VFIO device that has multifd device state transfer enabled has one
such thread, which is created using migration core API
qemu_loadvm_start_load_thread().
From: "Maciej S. Szmigiero"
This property allows configuring whether to start the config load only
after all iterables were loaded.
Such interlocking is required for ARM64 due to this platform VFIO
dependency on interrupt controller being loaded first.
The property defaults to AUTO, w
From: "Maciej S. Szmigiero"
multifd_send() function is currently not thread safe, make it thread safe
by holding a lock during its execution.
This way it will be possible to safely call it concurrently from multiple
threads.
Reviewed-by: Peter Xu
Signed-off-by: Maciej S.
From: "Maciej S. Szmigiero"
Automatic memory management helps avoid memory safety issues.
Reviewed-by: Peter Xu
Signed-off-by: Maciej S. Szmigiero
---
include/qapi/error.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/qapi/error.h b/include/qapi/error.h
index f5
From: "Maciej S. Szmigiero"
Load device config received via multifd using the existing machinery
behind vfio_load_device_config_state().
Also, make sure to process the relevant main migration channel flags.
Signed-off-by: Maciej S. Szmigiero
---
hw/vfio/migration-multif
From: "Maciej S. Szmigiero"
This property allows configuring whether to transfer the particular device
state via multifd channels when live migrating that device.
It defaults to AUTO, which means that VFIO device state transfer via
multifd channels is attempted in configurations that
From: "Maciej S. Szmigiero"
Add basic types and flags used by VFIO multifd device state transfer
support.
Since we'll be introducing a lot of multifd transfer specific code,
add a new file migration-multifd.c to home it, wired into main VFIO
migration code (migration.c) via migr
From: "Maciej S. Szmigiero"
Add multifd setup/cleanup functions and an associated VFIOMultifd data
structure that will contain most of the receive-side data together
with its init/cleanup methods.
Signed-off-by: Maciej S. Szmigiero
---
hw/vfio/migration-multif
From: "Maciej S. Szmigiero"
Automatic memory management helps avoid memory safety issues.
Reviewed-by: Fabiano Rosas
Reviewed-by: Peter Xu
Signed-off-by: Maciej S. Szmigiero
---
migration/qemu-file.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/migration/qemu-file.h b
From: "Maciej S. Szmigiero"
Update the VFIO documentation at docs/devel/migration describing the
changes brought by the multifd device state transfer.
Signed-off-by: Maciej S. Szmigiero
---
docs/devel/migration/vfio.rst | 79 +++
1 file changed, 72
From: "Maciej S. Szmigiero"
This way they can also be referenced in other translation
units than migration.c.
Reviewed-by: Cédric Le Goater
Signed-off-by: Maciej S. Szmigiero
---
hw/vfio/migration.c | 17 -
include/hw/vfio/vfio-common.h | 17 ++
From: "Maciej S. Szmigiero"
DEFINE_PROP_ON_OFF_AUTO() property isn't runtime-mutable so using it
would mean that the source VM would need to decide upfront at startup
time whether it wants to do a multifd device state transfer at some
point.
Source VM can run for a long ti
From: "Maciej S. Szmigiero"
Wire VFIO multifd transfer specific setup and cleanup functions into
general VFIO load/save setup and cleanup methods.
Signed-off-by: Maciej S. Szmigiero
---
hw/vfio/migration.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletion
From: "Maciej S. Szmigiero"
Add a hw_compat entry for recently added x-migration-multifd-transfer VFIO
property.
Reviewed-by: Cédric Le Goater
Signed-off-by: Maciej S. Szmigiero
---
hw/core/machine.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/core/machine.c b/hw/core
From: "Maciej S. Szmigiero"
Add a basic support for receiving device state via multifd channels -
channels that are shared with RAM transfers.
Depending whether MULTIFD_FLAG_DEVICE_STATE flag is present or not in the
packet header either device state (MultiFDPacketDeviceState_t) o
From: "Maciej S. Szmigiero"
Allow capping the maximum count of in-flight VFIO device state buffers
queued at the destination, otherwise a malicious QEMU source could
theoretically cause the target QEMU to allocate unlimited amounts of memory
for buffers-in-flight.
Since this is not e
From: "Maciej S. Szmigiero"
This function name conflicts with one used by a future generic thread pool
function and it was only used by one test anyway.
Update the trace event name in thread_pool_submit_aio() accordingly.
Acked-by: Fabiano Rosas
Reviewed-by: Cédric Le Goater
R
From: "Maciej S. Szmigiero"
Since device state transfer via multifd channels requires multifd
channels with packets and is currently not compatible with multifd
compression add an appropriate query function so device can learn
whether it can actually make use of it.
Reviewed-by: Fab
From: "Maciej S. Szmigiero"
And rename existing load_device_config_state trace event to
load_device_config_state_end for consistency since it is triggered at the
end of loading of the VFIO device config state.
This way both the start and end points of particular device config
loading
properly free it when the SendData is freed.
Signed-off-by: Peter Xu
[MSS: Make sure to clear possible device state payload before freeing
MultiFDSendData, remove placeholders for other patches not included]
Signed-off-by: Maciej S. Szmigiero
---
migration/multifd-device-state.c | 5 -
migration/mu
From: "Maciej S. Szmigiero"
All callers to migration_incoming_state_destroy() other than
postcopy_ram_listen_thread() do this call with BQL held.
Since migration_incoming_state_destroy() ultimately calls "load_cleanup"
SaveVMHandlers and it will soon call BQL-sensitive co
From: "Maciej S. Szmigiero"
A new function multifd_queue_device_state() is provided for device to queue
its state for transmission via a multifd channel.
Reviewed-by: Peter Xu
Signed-off-by: Maciej S. Szmigiero
---
include/migration/misc.h | 4 ++
migration/m
From: "Maciej S. Szmigiero"
So it can be safety accessed from multiple threads.
This variable type needs to be changed to unsigned long since
32-bit host platforms lack the necessary addition atomics on 64-bit
variables.
Using 32-bit counters on 32-bit host platforms should not be a
From: "Maciej S. Szmigiero"
This way bytes_transferred can also be incremented in other translation
units than migration.c.
Signed-off-by: Maciej S. Szmigiero
---
hw/vfio/migration.c | 7 ++-
include/hw/vfio/vfio-common.h | 1 +
2 files changed, 7 insertions(+),
From: "Maciej S. Szmigiero"
This SaveVMHandler helps device provide its own asynchronous transmission
of the remaining data at the end of a precopy phase via multifd channels,
in parallel with the transfer done by save_live_complete_precopy handlers.
These threads are launched only wh
From: "Maciej S. Szmigiero"
qemu_loadvm_load_state_buffer() and its load_state_buffer
SaveVMHandler allow providing device state buffer to explicitly
specified device via its idstr and instance id.
Reviewed-by: Fabiano Rosas
Reviewed-by: Peter Xu
Signed-off-by: Maciej S.
From: "Maciej S. Szmigiero"
Read packet header first so in the future we will be able to
differentiate between a RAM multifd packet and a device state multifd
packet.
Since these two are of different size we can't read the packet body until
we know which packet type it is.
Revie
From: "Maciej S. Szmigiero"
This way if there are fields there that needs explicit disposal (like, for
example, some attached buffers) they will be handled appropriately.
Add a related assert to multifd_set_payload_type() in order to make sure
that this function is only used
From: "Maciej S. Szmigiero"
This QEMU_VM_COMMAND sub-command and its switchover_start SaveVMHandler is
used to mark the switchover point in main migration stream.
It can be used to inform the destination that all pre-switchover main
migration stream data has been sent/received so it
From: "Maciej S. Szmigiero"
It's possible for {load,save}_cleanup SaveVMHandlers to get called without
the corresponding {load,save}_setup handler being called first.
One such example is if {load,save}_setup handler of a proceeding device
returns error.
In this case the migrati
From: "Maciej S. Szmigiero"
This is an updated v6 patch series of the v5 series located here:
https://lore.kernel.org/qemu-devel/cover.1739994627.git.maciej.szmigi...@oracle.com/
What this patch set is about?
Current live migration device state transfer is done via the main (single)
From: "Maciej S. Szmigiero"
Migration code wants to manage device data sending threads in one place.
QEMU has an existing thread pool implementation, however it is limited
to queuing AIO operations only and essentially has a 1:1 mapping between
the current AioContext and the AIO Thr
From: "Maciej S. Szmigiero"
These names conflict with ones used by future generic thread pool
equivalents.
Generic names should belong to the generic pool type, not specific (AIO)
type.
Acked-by: Fabiano Rosas
Reviewed-by: Cédric Le Goater
Reviewed-by: Peter Xu
Signed-off-by
On 26.02.2025 17:43, Peter Xu wrote:
On Wed, Feb 19, 2025 at 09:33:59PM +0100, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
This SaveVMHandler helps device provide its own asynchronous transmission
of the remaining data at the end of a precopy phase via multifd channels,
i
On 4.03.2025 12:29, Avihai Horon wrote:
On 04/03/2025 0:17, Maciej S. Szmigiero wrote:
External email: Use caution opening links or attachments
On 2.03.2025 15:48, Avihai Horon wrote:
On 19/02/2025 22:34, Maciej S. Szmigiero wrote:
External email: Use caution opening links or attachments
On 4.03.2025 08:41, Cédric Le Goater wrote:
@@ -728,6 +728,12 @@ static int vfio_load_state(QEMUFile *f, void *opaque, int
version_id)
switch (data) {
case VFIO_MIG_FLAG_DEV_CONFIG_STATE:
{
+ if (vfio_multifd_transfer_enabled(vbasedev)) {
+
On 2.03.2025 15:41, Avihai Horon wrote:
On 19/02/2025 22:34, Maciej S. Szmigiero wrote:
External email: Use caution opening links or attachments
From: "Maciej S. Szmigiero"
Implement the multifd device state transfer via additional per-device
thread inside save_live_complete_prec
On 2.03.2025 13:46, Avihai Horon wrote:
On 19/02/2025 22:33, Maciej S. Szmigiero wrote:
External email: Use caution opening links or attachments
From: "Maciej S. Szmigiero"
A new function multifd_queue_device_state() is provided for device to queue
its state for transmission via
On 2.03.2025 15:15, Avihai Horon wrote:
On 19/02/2025 22:34, Maciej S. Szmigiero wrote:
External email: Use caution opening links or attachments
From: "Maciej S. Szmigiero"
Maybe add a sentence talking about the load thread itself first? E.g.:
Add a thread which loads the V
On 2.03.2025 15:19, Avihai Horon wrote:
On 26/02/2025 15:49, Cédric Le Goater wrote:
External email: Use caution opening links or attachments
On 2/19/25 21:34, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
Since it's important to finish loading device state tran
On 2.03.2025 15:25, Avihai Horon wrote:
On 19/02/2025 22:34, Maciej S. Szmigiero wrote:
External email: Use caution opening links or attachments
From: "Maciej S. Szmigiero"
Load device config received via multifd using the existing machinery
behind vfio_load_device_config_stat
On 2.03.2025 15:48, Avihai Horon wrote:
On 19/02/2025 22:34, Maciej S. Szmigiero wrote:
External email: Use caution opening links or attachments
From: "Maciej S. Szmigiero"
This property allows configuring at runtime whether to transfer the
IIUC, in this patch it's not
On 2.03.2025 14:12, Avihai Horon wrote:
On 19/02/2025 22:34, Maciej S. Szmigiero wrote:
External email: Use caution opening links or attachments
From: "Maciej S. Szmigiero"
The multifd received data needs to be reassembled since device state
packets sent via different multifd ch
On 3.03.2025 07:42, Cédric Le Goater wrote:
On 3/2/25 14:00, Avihai Horon wrote:
On 19/02/2025 22:34, Maciej S. Szmigiero wrote:
External email: Use caution opening links or attachments
From: "Maciej S. Szmigiero"
Add VFIOStateBuffer(s) types and the associated methods.
T
On 2.03.2025 13:42, Avihai Horon wrote:
Hi Maciej,
Sorry for the long delay, I have been busy with other tasks.
I got some small comments for the series.
On 19/02/2025 22:33, Maciej S. Szmigiero wrote:
External email: Use caution opening links or attachments
From: "Maciej S. Szmi
On 1.03.2025 00:38, Fabiano Rosas wrote:
Cédric Le Goater writes:
On 2/27/25 23:01, Maciej S. Szmigiero wrote:
On 27.02.2025 07:59, Cédric Le Goater wrote:
On 2/19/25 21:34, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
Update the VFIO documentation at docs/devel
On 2.03.2025 14:00, Avihai Horon wrote:
On 19/02/2025 22:34, Maciej S. Szmigiero wrote:
External email: Use caution opening links or attachments
From: "Maciej S. Szmigiero"
Add VFIOStateBuffer(s) types and the associated methods.
These store received device state buffers and co
On 2.03.2025 15:54, Maciej S. Szmigiero wrote:
On 2.03.2025 15:53, Avihai Horon wrote:
On 19/02/2025 22:34, Maciej S. Szmigiero wrote:
External email: Use caution opening links or attachments
From: "Maciej S. Szmigiero"
Allow capping the maximum count of in-flight VFIO de
On 2.03.2025 15:53, Avihai Horon wrote:
On 19/02/2025 22:34, Maciej S. Szmigiero wrote:
External email: Use caution opening links or attachments
From: "Maciej S. Szmigiero"
Allow capping the maximum count of in-flight VFIO device state buffers
queued at the destination, o
On 28.02.2025 11:05, Cédric Le Goater wrote:
On 2/27/25 23:01, Maciej S. Szmigiero wrote:
On 27.02.2025 07:59, Cédric Le Goater wrote:
On 2/19/25 21:34, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
Update the VFIO documentation at docs/devel/migration describing t
On 28.02.2025 09:44, Cédric Le Goater wrote:
On 2/26/25 22:05, Maciej S. Szmigiero wrote:
On 26.02.2025 18:59, Cédric Le Goater wrote:
On 2/19/25 21:34, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
DEFINE_PROP_ON_OFF_AUTO() property isn't runtime-mutable so usin
On 28.02.2025 10:13, Cédric Le Goater wrote:
On 2/26/25 22:05, Maciej S. Szmigiero wrote:
On 26.02.2025 17:43, Cédric Le Goater wrote:
On 2/19/25 21:34, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
Implement the multifd device state transfer via additional per-device
thr
On 28.02.2025 09:53, Cédric Le Goater wrote:
On 2/27/25 23:01, Maciej S. Szmigiero wrote:
On 27.02.2025 07:48, Cédric Le Goater wrote:
On 2/19/25 21:34, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
Allow capping the maximum count of in-flight VFIO device state buffers
1 - 100 of 604 matches
Mail list logo
