3688fec8 | 20-Mar-2024 |
Cédric Le Goater <clg@redhat.com> |
memory: Add Error** argument to .log_global_start() handler
Modify all .log_global_start() handlers to take an Error** parameter and return a bool. Adapt memory_global_dirty_log_start() to interrupt
memory: Add Error** argument to .log_global_start() handler
Modify all .log_global_start() handlers to take an Error** parameter and return a bool. Adapt memory_global_dirty_log_start() to interrupt on the first error the loop on handlers. In such case, a rollback is performed to stop dirty logging on all listeners where it was previously enabled.
Cc: Stefano Stabellini <sstabellini@kernel.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Paul Durrant <paul@xen.org> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: David Hildenbrand <david@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Link: https://lore.kernel.org/r/20240320064911.545001-10-clg@redhat.com [peterx: modify & enrich the comment for listener_add_address_space() ] Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
e4fa064d | 20-Mar-2024 |
Cédric Le Goater <clg@redhat.com> |
migration: Add Error** argument to .load_setup() handler
This will be useful to report errors at a higher level, mostly in VFIO today.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Review
migration: Add Error** argument to .load_setup() handler
This will be useful to report errors at a higher level, mostly in VFIO today.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/r/20240320064911.545001-9-clg@redhat.com [peterx: drop comment for ERRP_GUARD, per Markus] Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
01c3ac68 | 20-Mar-2024 |
Cédric Le Goater <clg@redhat.com> |
migration: Add Error** argument to .save_setup() handler
The purpose is to record a potential error in the migration stream if qemu_savevm_state_setup() fails. Most of the current .save_setup() hand
migration: Add Error** argument to .save_setup() handler
The purpose is to record a potential error in the migration stream if qemu_savevm_state_setup() fails. Most of the current .save_setup() handlers can be modified to use the Error argument instead of managing their own and calling locally error_report().
Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Harsh Prateek Bora <harshpb@linux.ibm.com> Cc: Halil Pasic <pasic@linux.ibm.com> Cc: Thomas Huth <thuth@redhat.com> Cc: Eric Blake <eblake@redhat.com> Cc: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Cc: John Snow <jsnow@redhat.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Signed-off-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/r/20240320064911.545001-8-clg@redhat.com Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
31cf7c14 | 20-Mar-2024 |
Cédric Le Goater <clg@redhat.com> |
vfio: Always report an error in vfio_save_setup()
This will prepare ground for future changes adding an Error** argument to the save_setup() handler. We need to make sure that on failure, vfio_save_
vfio: Always report an error in vfio_save_setup()
This will prepare ground for future changes adding an Error** argument to the save_setup() handler. We need to make sure that on failure, vfio_save_setup() always sets a new error.
Reviewed-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/r/20240320064911.545001-3-clg@redhat.com Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
57001144 | 14-Mar-2024 |
Cédric Le Goater <clg@redhat.com> |
vfio/iommufd: Fix memory leak
Coverity reported a memory leak on variable 'contents' in routine iommufd_cdev_getfd(). Use g_autofree variables to simplify the exit path and get rid of g_free() calls
vfio/iommufd: Fix memory leak
Coverity reported a memory leak on variable 'contents' in routine iommufd_cdev_getfd(). Use g_autofree variables to simplify the exit path and get rid of g_free() calls.
Cc: Eric Auger <eric.auger@redhat.com> Cc: Yi Liu <yi.l.liu@intel.com> Fixes: CID 1540007 Fixes: 5ee3dc7af785 ("vfio/iommufd: Implement the iommufd backend") Suggested-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
show more ...
|
498696ef | 11-Mar-2024 |
Zhao Liu <zhao1.liu@intel.com> |
hw/vfio/platform: Fix missing ERRP_GUARD() for error_prepend()
As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() = * *
hw/vfio/platform: Fix missing ERRP_GUARD() for error_prepend()
As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() = * * Without ERRP_GUARD(), use of the @errp parameter is restricted: ... * - It should not be passed to error_prepend(), error_vprepend() or * error_append_hint(), because that doesn't work with &error_fatal. * ERRP_GUARD() lifts these restrictions. * * To use ERRP_GUARD(), add it right at the beginning of the function. * @errp can then be used without worrying about the argument being * NULL or &error_fatal.
ERRP_GUARD() could avoid the case when @errp is &error_fatal, the user can't see this additional information, because exit() happens in error_setg earlier than information is added [1].
The vfio_platform_realize() passes @errp to error_prepend(), and as a DeviceClass.realize method, there are too many possible callers to check the impact of this defect; it may or may not be harmless. Thus it is necessary to protect @errp with ERRP_GUARD().
To avoid the issue like [1] said, add missing ERRP_GUARD() at the beginning of this function.
[1]: Issue description in the commit message of commit ae7c80a7bd73 ("error: New macro ERRP_GUARD()").
Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Cédric Le Goater <clg@redhat.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Message-ID: <20240311033822.3142585-25-zhao1.liu@linux.intel.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
cf8afdfa | 11-Mar-2024 |
Zhao Liu <zhao1.liu@intel.com> |
hw/vfio/pci: Fix missing ERRP_GUARD() for error_prepend()
As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() = * * Witho
hw/vfio/pci: Fix missing ERRP_GUARD() for error_prepend()
As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() = * * Without ERRP_GUARD(), use of the @errp parameter is restricted: ... * - It should not be passed to error_prepend(), error_vprepend() or * error_append_hint(), because that doesn't work with &error_fatal. * ERRP_GUARD() lifts these restrictions. * * To use ERRP_GUARD(), add it right at the beginning of the function. * @errp can then be used without worrying about the argument being * NULL or &error_fatal.
ERRP_GUARD() could avoid the case when @errp is &error_fatal, the user can't see this additional information, because exit() happens in error_setg earlier than information is added [1].
In hw/vfio/pci.c, there are 2 functions passing @errp to error_prepend() without ERRP_GUARD(): - vfio_add_std_cap() - vfio_realize()
The @errp of vfio_add_std_cap() is also from vfio_realize(). And vfio_realize(), as a PCIDeviceClass.realize method, its @errp is from DeviceClass.realize so that there is no guarantee that the @errp won't point to @error_fatal.
To avoid the issue like [1] said, add missing ERRP_GUARD() at their beginning.
[1]: Issue description in the commit message of commit ae7c80a7bd73 ("error: New macro ERRP_GUARD()").
Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Cédric Le Goater <clg@redhat.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Message-ID: <20240311033822.3142585-24-zhao1.liu@linux.intel.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
44765508 | 11-Mar-2024 |
Zhao Liu <zhao1.liu@intel.com> |
hw/vfio/pci-quirks: Fix missing ERRP_GUARD() for error_prepend()
As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() = *
hw/vfio/pci-quirks: Fix missing ERRP_GUARD() for error_prepend()
As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() = * * Without ERRP_GUARD(), use of the @errp parameter is restricted: ... * - It should not be passed to error_prepend(), error_vprepend() or * error_append_hint(), because that doesn't work with &error_fatal. * ERRP_GUARD() lifts these restrictions. * * To use ERRP_GUARD(), add it right at the beginning of the function. * @errp can then be used without worrying about the argument being * NULL or &error_fatal.
ERRP_GUARD() could avoid the case when @errp is &error_fatal, the user can't see this additional information, because exit() happens in error_setg earlier than information is added [1].
In hw/vfio/pci-quirks.c, there are 2 functions passing @errp to error_prepend() without ERRP_GUARD(): - vfio_add_nv_gpudirect_cap() - vfio_add_vmd_shadow_cap()
There are too many possible callers to check the impact of this defect; it may or may not be harmless. Thus it is necessary to protect their @errp with ERRP_GUARD().
To avoid the issue like [1] said, add missing ERRP_GUARD() at the beginning of this function.
[1]: Issue description in the commit message of commit ae7c80a7bd73 ("error: New macro ERRP_GUARD()").
Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Cédric Le Goater <clg@redhat.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Message-ID: <20240311033822.3142585-23-zhao1.liu@linux.intel.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
5cf8f51c | 11-Mar-2024 |
Zhao Liu <zhao1.liu@intel.com> |
hw/vfio/iommufd: Fix missing ERRP_GUARD() for error_prepend()
As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() = * * W
hw/vfio/iommufd: Fix missing ERRP_GUARD() for error_prepend()
As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() = * * Without ERRP_GUARD(), use of the @errp parameter is restricted: ... * - It should not be passed to error_prepend(), error_vprepend() or * error_append_hint(), because that doesn't work with &error_fatal. * ERRP_GUARD() lifts these restrictions. * * To use ERRP_GUARD(), add it right at the beginning of the function. * @errp can then be used without worrying about the argument being * NULL or &error_fatal.
ERRP_GUARD() could avoid the case when @errp is &error_fatal, the user can't see this additional information, because exit() happens in error_setg earlier than information is added [1].
The iommufd_cdev_getfd() passes @errp to error_prepend(). Its @errp is from vfio_attach_device(), and there are too many possible callers to check the impact of this defect; it may or may not be harmless. Thus it is necessary to protect @errp with ERRP_GUARD().
To avoid the issue like [1] said, add missing ERRP_GUARD() at the beginning of this function.
[1]: Issue description in the commit message of commit ae7c80a7bd73 ("error: New macro ERRP_GUARD()").
Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Cédric Le Goater <clg@redhat.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Message-ID: <20240311033822.3142585-22-zhao1.liu@linux.intel.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
89a8a2e9 | 11-Mar-2024 |
Zhao Liu <zhao1.liu@intel.com> |
hw/vfio/helpers: Fix missing ERRP_GUARD() for error_prepend()
As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() = * * W
hw/vfio/helpers: Fix missing ERRP_GUARD() for error_prepend()
As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() = * * Without ERRP_GUARD(), use of the @errp parameter is restricted: ... * - It should not be passed to error_prepend(), error_vprepend() or * error_append_hint(), because that doesn't work with &error_fatal. * ERRP_GUARD() lifts these restrictions. * * To use ERRP_GUARD(), add it right at the beginning of the function. * @errp can then be used without worrying about the argument being * NULL or &error_fatal.
ERRP_GUARD() could avoid the case when @errp is &error_fatal, the user can't see this additional information, because exit() happens in error_setg earlier than information is added [1].
In hw/vfio/helpers.c, there are 3 functions passing @errp to error_prepend() without ERRP_GUARD(): - vfio_set_irq_signaling() - vfio_device_get_name() - vfio_device_set_fd()
There are too many possible callers to check the impact of this defect; it may or may not be harmless. Thus it is necessary to protect their @errp with ERRP_GUARD().
To avoid the issue like [1] said, add missing ERRP_GUARD() at their beginning.
[1]: Issue description in the commit message of commit ae7c80a7bd73 ("error: New macro ERRP_GUARD()").
Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Cédric Le Goater <clg@redhat.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Message-ID: <20240311033822.3142585-21-zhao1.liu@linux.intel.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
93a518ba | 11-Mar-2024 |
Zhao Liu <zhao1.liu@intel.com> |
hw/vfio/container: Fix missing ERRP_GUARD() for error_prepend()
As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() = * *
hw/vfio/container: Fix missing ERRP_GUARD() for error_prepend()
As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() = * * Without ERRP_GUARD(), use of the @errp parameter is restricted: ... * - It should not be passed to error_prepend(), error_vprepend() or * error_append_hint(), because that doesn't work with &error_fatal. * ERRP_GUARD() lifts these restrictions. * * To use ERRP_GUARD(), add it right at the beginning of the function. * @errp can then be used without worrying about the argument being * NULL or &error_fatal.
ERRP_GUARD() could avoid the case when @errp is &error_fatal, the user can't see this additional information, because exit() happens in error_setg earlier than information is added [1].
The vfio_get_group() passes @errp to error_prepend(). Its @errp is from vfio_attach_device(), and there are too many possible callers to check the impact of this defect; it may or may not be harmless. Thus it is necessary to protect @errp with ERRP_GUARD().
To avoid the issue like [1] said, add missing ERRP_GUARD() at the beginning of this function.
[1]: Issue description in the commit message of commit ae7c80a7bd73 ("error: New macro ERRP_GUARD()").
Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Cédric Le Goater <clg@redhat.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Message-ID: <20240311033822.3142585-20-zhao1.liu@linux.intel.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
c9e21f99 | 11-Mar-2024 |
Zhao Liu <zhao1.liu@intel.com> |
hw/vfio/ap: Fix missing ERRP_GUARD() for error_prepend()
As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() = * * Withou
hw/vfio/ap: Fix missing ERRP_GUARD() for error_prepend()
As the comment in qapi/error, passing @errp to error_prepend() requires ERRP_GUARD():
* = Why, when and how to use ERRP_GUARD() = * * Without ERRP_GUARD(), use of the @errp parameter is restricted: ... * - It should not be passed to error_prepend(), error_vprepend() or * error_append_hint(), because that doesn't work with &error_fatal. * ERRP_GUARD() lifts these restrictions. * * To use ERRP_GUARD(), add it right at the beginning of the function. * @errp can then be used without worrying about the argument being * NULL or &error_fatal.
ERRP_GUARD() could avoid the case when @errp is &error_fatal, the user can't see this additional information, because exit() happens in error_setg earlier than information is added [1].
The vfio_ap_realize() passes @errp to error_prepend(), and as a DeviceClass.realize method, there are too many possible callers to check the impact of this defect; it may or may not be harmless. Thus it is necessary to protect @errp with ERRP_GUARD().
To avoid the issue like [1] said, add missing ERRP_GUARD() at the beginning of this function.
[1]: Issue description in the commit message of commit ae7c80a7bd73 ("error: New macro ERRP_GUARD()").
Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Cédric Le Goater <clg@redhat.com> Cc: Tony Krowiak <akrowiak@linux.ibm.com> Cc: Halil Pasic <pasic@linux.ibm.com> Cc: Jason Herne <jjherne@linux.ibm.com> Cc: Thomas Huth <thuth@redhat.com> Cc: qemu-s390x@nongnu.org Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Message-ID: <20240311033822.3142585-19-zhao1.liu@linux.intel.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
20c64c8a | 11-Mar-2024 |
Steve Sistare <steven.sistare@oracle.com> |
migration: migration_file_set_error
Define and export migration_file_set_error to eliminate a dependency on MigrationState.
Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Link: https://lo
migration: migration_file_set_error
Define and export migration_file_set_error to eliminate a dependency on MigrationState.
Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Link: https://lore.kernel.org/r/1710179338-294359-9-git-send-email-steven.sistare@oracle.com Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
9bb630c6 | 11-Mar-2024 |
Steve Sistare <steven.sistare@oracle.com> |
migration: migration_is_device
Define and export migration_is_device to eliminate a dependency on MigrationState.
Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Link: https://lore.kernel.
migration: migration_is_device
Define and export migration_is_device to eliminate a dependency on MigrationState.
Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Link: https://lore.kernel.org/r/1710179338-294359-8-git-send-email-steven.sistare@oracle.com Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
3a6813b6 | 11-Mar-2024 |
Steve Sistare <steven.sistare@oracle.com> |
migration: export migration_is_active
Delete the MigrationState parameter from migration_is_active so it can be exported and used without including migration.h.
Signed-off-by: Steve Sistare <steven
migration: export migration_is_active
Delete the MigrationState parameter from migration_is_active so it can be exported and used without including migration.h.
Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Link: https://lore.kernel.org/r/1710179338-294359-4-git-send-email-steven.sistare@oracle.com Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
7dcb3c87 | 11-Mar-2024 |
Steve Sistare <steven.sistare@oracle.com> |
migration: export migration_is_setup_or_active
Delete the MigrationState parameter from migration_is_setup_or_active and move it to the public API in misc.h.
Signed-off-by: Steve Sistare <steven.si
migration: export migration_is_setup_or_active
Delete the MigrationState parameter from migration_is_setup_or_active and move it to the public API in misc.h.
Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Link: https://lore.kernel.org/r/1710179338-294359-3-git-send-email-steven.sistare@oracle.com Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
f853fa07 | 11-Mar-2024 |
Steve Sistare <steven.sistare@oracle.com> |
migration: remove migration.h references
Remove migration.h from files that no longer need it due to previous commits.
Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Link: https://lore.ke
migration: remove migration.h references
Remove migration.h from files that no longer need it due to previous commits.
Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Link: https://lore.kernel.org/r/1710179338-294359-2-git-send-email-steven.sistare@oracle.com Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
f3bff6c4 | 11-Mar-2024 |
Steve Sistare <steven.sistare@oracle.com> |
migration: export fewer options
A small number of migration options are accessed by migration clients, but to see them clients must include all of options.h, which is mostly for migration core code.
migration: export fewer options
A small number of migration options are accessed by migration clients, but to see them clients must include all of options.h, which is mostly for migration core code. migrate_mode() in particular will be needed by multiple clients.
Refactor the option declarations so clients can see the necessary few via misc.h, which already exports a portion of the client API.
Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Link: https://lore.kernel.org/r/1710179319-294320-1-git-send-email-steven.sistare@oracle.com Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
ff64e0ba | 04-Mar-2024 |
Avihai Horon <avihaih@nvidia.com> |
vfio/migration: Add a note about migration rate limiting
VFIO migration buffer size is currently limited to 1MB. Therefore, there is no need to check if migration rate exceeded, as in the worst case
vfio/migration: Add a note about migration rate limiting
VFIO migration buffer size is currently limited to 1MB. Therefore, there is no need to check if migration rate exceeded, as in the worst case it will exceed by only 1MB.
However, if the buffer size is later changed to a bigger value, vfio_save_iterate() should enforce migration rate (similar to migration RAM code).
Add a note about this in vfio_save_iterate() to serve as a reminder.
Suggested-by: Peter Xu <peterx@redhat.com> Signed-off-by: Avihai Horon <avihaih@nvidia.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240304105339.20713-4-avihaih@nvidia.com Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
3f6ed59e | 04-Mar-2024 |
Avihai Horon <avihaih@nvidia.com> |
vfio/migration: Refactor vfio_save_state() return value
Currently, vfio_save_state() returns 1 regardless of whether there is more data to send or not. This was done to prevent a fast changing VFIO
vfio/migration: Refactor vfio_save_state() return value
Currently, vfio_save_state() returns 1 regardless of whether there is more data to send or not. This was done to prevent a fast changing VFIO device from potentially blocking other devices from sending their data, as qemu_savevm_state_iterate() serialized devices.
Now that qemu_savevm_state_iterate() no longer serializes devices, there is no need for that.
Refactor vfio_save_state() to return 0 if more data is available and 1 if no more data is available.
Signed-off-by: Avihai Horon <avihaih@nvidia.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240304105339.20713-3-avihaih@nvidia.com Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
75d5a5fe | 01-Mar-2024 |
Frediano Ziglio <freddy77@gmail.com> |
hw/vfio/pci.c: Make some structure static
Not used outside C module.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by:
hw/vfio/pci.c: Make some structure static
Not used outside C module.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
show more ...
|
0cb51c18 | 22-Feb-2024 |
Steve Sistare <steven.sistare@oracle.com> |
vfio: allow cpr-reboot migration if suspended
Allow cpr-reboot for vfio if the guest is in the suspended runstate. The guest drivers' suspend methods flush outstanding requests and re-initialize th
vfio: allow cpr-reboot migration if suspended
Allow cpr-reboot for vfio if the guest is in the suspended runstate. The guest drivers' suspend methods flush outstanding requests and re-initialize the devices, and thus there is no device state to save and restore. The user is responsible for suspending the guest before initiating cpr, such as by issuing guest-suspend-ram to the qemu guest agent.
Relax the vfio blocker so it does not apply to cpr, and add a notifier that verifies the guest is suspended.
Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Reviewed-by: Cédric Le Goater <clg@redhat.com>
show more ...
|
d9fa4223 | 22-Feb-2024 |
Steve Sistare <steven.sistare@oracle.com> |
vfio: register container for cpr
Define entry points to perform per-container cpr-specific initialization and teardown.
Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Reviewed-by: Cédric
vfio: register container for cpr
Define entry points to perform per-container cpr-specific initialization and teardown.
Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Reviewed-by: Cédric Le Goater <clg@redhat.com>
show more ...
|
5663dd3f | 22-Feb-2024 |
Steve Sistare <steven.sistare@oracle.com> |
migration: MigrationNotifyFunc
Define MigrationNotifyFunc to improve type safety and simplify migration notifiers.
Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Reviewed-by: Peter Xu <pe
migration: MigrationNotifyFunc
Define MigrationNotifyFunc to improve type safety and simplify migration notifiers.
Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Link: https://lore.kernel.org/r/1708622920-68779-7-git-send-email-steven.sistare@oracle.com Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
9d9babf7 | 22-Feb-2024 |
Steve Sistare <steven.sistare@oracle.com> |
migration: MigrationEvent for notifiers
Passing MigrationState to notifiers is unsound because they could access unstable migration state internals or even modify the state. Instead, pass the minim
migration: MigrationEvent for notifiers
Passing MigrationState to notifiers is unsound because they could access unstable migration state internals or even modify the state. Instead, pass the minimal info needed in a new MigrationEvent struct, which could be extended in the future if needed.
Suggested-by: Peter Xu <peterx@redhat.com> Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Link: https://lore.kernel.org/r/1708622920-68779-5-git-send-email-steven.sistare@oracle.com Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|