summary refs log tree commit diff stats
path: root/scripts/qapi/error.py (unfollow)
Commit message (Collapse)AuthorFilesLines
2025-03-06vfio/migration: Multifd device state transfer support - send sideMaciej S. Szmigiero6-8/+189
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 transfer is enabled or not. Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/4d727e2e0435e0022d50004e474077632830e08d.1741124640.git.maciej.szmigiero@oracle.com [ clg: - Reordered savevm_vfio_handlers - Updated save_live_complete_precopy* documentation ] Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06vfio/migration: Multifd device state transfer support - config loading supportMaciej S. Szmigiero3-3/+57
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 <maciej.szmigiero@oracle.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/5dbd3f3703ec1097da2cf82a7262233452146fee.1741124640.git.maciej.szmigiero@oracle.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06migration/qemu-file: Define g_autoptr() cleanup function for QEMUFileMaciej S. Szmigiero1-0/+2
Automatic memory management helps avoid memory safety issues. Reviewed-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Link: https://lore.kernel.org/qemu-devel/2fd01d773a783d572dcf538a064a98cc09e75c12.1741124640.git.maciej.szmigiero@oracle.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06vfio/migration: Multifd device state transfer support - load threadMaciej S. Szmigiero5-0/+251
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(). Since it's important to finish loading device state transferred via the main migration channel (via save_live_iterate SaveVMHandler) before starting loading the data asynchronously transferred via multifd the thread doing the actual loading of the multifd transferred data is only started from switchover_start SaveVMHandler. switchover_start handler is called when MIG_CMD_SWITCHOVER_START sub-command of QEMU_VM_COMMAND is received via the main migration channel. This sub-command is only sent after all save_live_iterate data have already been posted so it is safe to commence loading of the multifd-transferred device state upon receiving it - loading of save_live_iterate data happens synchronously in the main migration thread (much like the processing of MIG_CMD_SWITCHOVER_START) so by the time MIG_CMD_SWITCHOVER_START is processed all the proceeding data must have already been loaded. Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/9abe612d775aaf42e31646796acd2363c723a57a.1741124640.git.maciej.szmigiero@oracle.com [ clg: - Reordered savevm_vfio_handlers - Added switchover_start documentation ] Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06vfio/migration: Multifd device state transfer support - received buffers queuingMaciej S. Szmigiero5-0/+178
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 state data is saved into a VFIOStateBuffer for later in-order loading into the device. The last such VFIO device state packet should have VFIO_DEVICE_STATE_CONFIG_STATE flag set and carry the device config state. Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/e3bff515a8d61c582b94b409eb12a45b1a143a69.1741124640.git.maciej.szmigiero@oracle.com [ clg: - Reordered savevm_vfio_handlers - Added load_state_buffer documentation ] Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06vfio/migration: Setup and cleanup multifd transfer in these general methodsMaciej S. Szmigiero1-2/+22
Wire VFIO multifd transfer specific setup and cleanup functions into general VFIO load/save setup and cleanup methods. Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/b1f864a65fafd4fdab1f89230df52e46ae41f2ac.1741124640.git.maciej.szmigiero@oracle.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06vfio/migration: Multifd setup/cleanup functions and associated VFIOMultifdMaciej S. Szmigiero3-0/+51
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 <maciej.szmigiero@oracle.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/c0520523053b1087787152ddf2163257d3030be0.1741124640.git.maciej.szmigiero@oracle.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06vfio/migration: Multifd device state transfer - add support checking functionMaciej S. Szmigiero2-0/+8
Add vfio_multifd_transfer_supported() function that tells whether the multifd device state transfer is supported. Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Link: https://lore.kernel.org/qemu-devel/8ce50256f341b3d47342bb217cb5fbb2deb14639.1741124640.git.maciej.szmigiero@oracle.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06vfio/migration: Multifd device state transfer support - basic typesMaciej S. Szmigiero4-0/+52
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 migration-multifd.h header file. Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/4eedd529e6617f80f3d6a66d7268a0db2bc173fa.1741124640.git.maciej.szmigiero@oracle.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06vfio/migration: Move migration channel flags to vfio-common.h header fileMaciej S. Szmigiero2-17/+17
This way they can also be referenced in other translation units than migration.c. Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Link: https://lore.kernel.org/qemu-devel/26a940f6b22c1b685818251b7a3ddbbca601b1d6.1741124640.git.maciej.szmigiero@oracle.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06vfio/migration: Add vfio_add_bytes_transferred()Maciej S. Szmigiero2-1/+7
This way bytes_transferred can also be incremented in other translation units than migration.c. Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/d1fbc27ac2417b49892f354ba20f6c6b3f7209f8.1741124640.git.maciej.szmigiero@oracle.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06vfio/migration: Convert bytes_transferred counter to atomicMaciej S. Szmigiero1-4/+4
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 problem in practice since they can't realistically address more memory anyway. Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Link: https://lore.kernel.org/qemu-devel/dc391771d2d9ad0f311994f0cb9e666da564aeaf.1741124640.git.maciej.szmigiero@oracle.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06vfio/migration: Add load_device_config_state_start trace eventMaciej S. Szmigiero2-2/+5
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 operation (a long, BQL-serialized operation) are known. Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Link: https://lore.kernel.org/qemu-devel/1b6c5a2097e64c272eb7e53f9e4cca4b79581b38.1741124640.git.maciej.szmigiero@oracle.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06migration: Add save_live_complete_precopy_thread handlerMaciej S. Szmigiero5-1/+170
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 when multifd device state transfer is supported. Management of these threads in done in the multifd migration code, wrapping them in the generic thread pool. Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Reviewed-by: Peter Xu <peterx@redhat.com> Link: https://lore.kernel.org/qemu-devel/eac74a4ca7edd8968bbf72aa07b9041c76364a16.1741124640.git.maciej.szmigiero@oracle.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06migration/multifd: Add multifd_device_state_supported()Maciej S. Szmigiero2-0/+8
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: Fabiano Rosas <farosas@suse.de> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Link: https://lore.kernel.org/qemu-devel/1ff0d98b85f470e5a33687406e877583b8fab74e.1741124640.git.maciej.szmigiero@oracle.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06migration/multifd: Make MultiFDSendData a structPeter Xu4-36/+22
The newly introduced device state buffer can be used for either storing VFIO's read() raw data, but already also possible to store generic device states. After noticing that device states may not easily provide a max buffer size (also the fact that RAM MultiFDPages_t after all also want to have flexibility on managing offset[] array), it may not be a good idea to stick with union on MultiFDSendData.. as it won't play well with such flexibility. Switch MultiFDSendData to a struct. It won't consume a lot more space in reality, after all the real buffers were already dynamically allocated, so it's so far only about the two structs (pages, device_state) that will be duplicated, but they're small. With this, we can remove the pretty hard to understand alloc size logic. Because now we can allocate offset[] together with the SendData, and properly free it when the SendData is freed. [MSS: Make sure to clear possible device state payload before freeing MultiFDSendData, remove placeholders for other patches not included] Signed-off-by: Peter Xu <peterx@redhat.com> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Acked-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/qemu-devel/7b02baba8e6ddb23ef7c349d312b9b631db09d7e.1741124640.git.maciej.szmigiero@oracle.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06migration/multifd: Device state transfer support - send sideMaciej S. Szmigiero6-16/+197
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 <peterx@redhat.com> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Link: https://lore.kernel.org/qemu-devel/ebd55768d3e5fecb5eb3f197bad9c0c07e5bc084.1741124640.git.maciej.szmigiero@oracle.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06migration/multifd: Add an explicit MultiFDSendData destructorMaciej S. Szmigiero3-5/+34
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 to fill a previously empty MultiFDSendData with some payload, not the other way around. Reviewed-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Link: https://lore.kernel.org/qemu-devel/6755205f2b95abbed251f87061feee1c0e410836.1741124640.git.maciej.szmigiero@oracle.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06migration/multifd: Make multifd_send() thread safeMaciej S. Szmigiero1-0/+8
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 <peterx@redhat.com> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Link: https://lore.kernel.org/qemu-devel/dd0f3bcc02ca96a7d523ca58ea69e495a33b453b.1741124640.git.maciej.szmigiero@oracle.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06migration/multifd: Device state transfer support - receive sideMaciej S. Szmigiero2-12/+108
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) or RAM data (existing MultiFDPacket_t) is read. The received device state data is provided to qemu_loadvm_load_state_buffer() function for processing in the device's load_state_buffer handler. Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Link: https://lore.kernel.org/qemu-devel/9b86f806c134e7815ecce0eee84f0e0e34aa0146.1741124640.git.maciej.szmigiero@oracle.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06migration/multifd: Split packet into header and RAM dataMaciej S. Szmigiero2-11/+49
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. Reviewed-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Link: https://lore.kernel.org/qemu-devel/832ad055fe447561ac1ad565d61658660cb3f63f.1741124640.git.maciej.szmigiero@oracle.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06migration: Add thread pool of optional load threadsMaciej S. Szmigiero6-4/+105
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 facilitate this use case. The migration core will wait for these threads to finish before (re)starting the VM at destination. Reviewed-by: Fabiano Rosas <farosas@suse.de> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Link: https://lore.kernel.org/qemu-devel/b09fd70369b6159c75847e69f235cb908b02570c.1741124640.git.maciej.szmigiero@oracle.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06error: define g_autoptr() cleanup function for the Error typeMaciej S. Szmigiero1-0/+2
Automatic memory management helps avoid memory safety issues. Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Link: https://lore.kernel.org/qemu-devel/a5843c5fa64d7e5239a4316092ec0ef0d10c2320.1741124640.git.maciej.szmigiero@oracle.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06migration: Always take BQL for migration_incoming_state_destroy()Maciej S. Szmigiero2-0/+17
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 code it makes sense to always call that function under BQL rather than to have it deal with both cases (with BQL and without BQL). Add the necessary bql_lock() and bql_unlock() to postcopy_ram_listen_thread(). qemu_loadvm_state_main() in postcopy_ram_listen_thread() could call "load_state" SaveVMHandlers that are expecting BQL to be held. In principle, the only devices that should be arriving on migration channel serviced by postcopy_ram_listen_thread() are those that are postcopiable and whose load handlers are safe to be called without BQL being held. But nothing currently prevents the source from sending data for "unsafe" devices which would cause trouble there. Add a TODO comment there so it's clear that it would be good to improve handling of such (erroneous) case in the future. Acked-by: Peter Xu <peterx@redhat.com> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Link: https://lore.kernel.org/qemu-devel/21bb5ca337b1d5a802e697f553f37faf296b5ff4.1741193259.git.maciej.szmigiero@oracle.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06migration: Add qemu_loadvm_load_state_buffer() and its handlerMaciej S. Szmigiero3-0/+41
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 <farosas@suse.de> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Link: https://lore.kernel.org/qemu-devel/71ca753286b87831ced4afd422e2e2bed071af25.1741124640.git.maciej.szmigiero@oracle.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06migration: Add MIG_CMD_SWITCHOVER_START and its load handlerMaciej S. Szmigiero12-0/+87
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 can start to process post-switchover data that it might have received via other migration channels like the multifd ones. Add also the relevant MigrationState bit stream compatibility property and its hw_compat entry. Reviewed-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Zhang Chen <zhangckid@gmail.com> # for the COLO part Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Link: https://lore.kernel.org/qemu-devel/311be6da85fc7e49a7598684d80aa631778dcbce.1741124640.git.maciej.szmigiero@oracle.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06thread-pool: Implement generic (non-AIO) pool supportMaciej S. Szmigiero2-0/+170
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 ThreadPool in use. Implement generic (non-AIO) ThreadPool by essentially wrapping Glib's GThreadPool. This brings a few new operations on a pool: * thread_pool_wait() operation waits until all the submitted work requests have finished. * thread_pool_set_max_threads() explicitly sets the maximum thread count in the pool. * thread_pool_adjust_max_threads_to_work() adjusts the maximum thread count in the pool to equal the number of still waiting in queue or unfinished work. Reviewed-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Link: https://lore.kernel.org/qemu-devel/b1efaebdbea7cb7068b8fb74148777012383e12b.1741124640.git.maciej.szmigiero@oracle.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06thread-pool: Rename AIO pool functions to *_aio() and data types to *AioMaciej S. Szmigiero5-42/+42
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 <farosas@suse.de> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Link: https://lore.kernel.org/qemu-devel/70f9e0fb4b01042258a1a57996c64d19779dc7f0.1741124640.git.maciej.szmigiero@oracle.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06thread-pool: Remove thread_pool_submit() functionMaciej S. Szmigiero4-12/+6
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 <farosas@suse.de> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Link: https://lore.kernel.org/qemu-devel/6830f07777f939edaf0a2d301c39adcaaf3817f0.1741124640.git.maciej.szmigiero@oracle.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06migration: Clarify that {load, save}_cleanup handlers can run without setupMaciej S. Szmigiero1-1/+5
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 migration core cleanup code will call all corresponding cleanup handlers, even for these devices which haven't had its setup handler called. Since this behavior can generate some surprises let's clearly document it in these SaveVMHandlers description. Reviewed-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Link: https://lore.kernel.org/qemu-devel/991636623fb780350f493b5f045cb17e13ce4c0f.1741124640.git.maciej.szmigiero@oracle.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06vfio-platform: Deprecate all forms of vfio-platform devicesEric Auger4-0/+30
As an outcome of KVM forum 2024 "vfio-platform: live and let die?" talk, let's deprecate vfio-platform devices. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250305124225.952791-1-eric.auger@redhat.com [ clg: Fixed spelling in vfio-amd-xgbe section ] Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06MAINTAINERS: Add myself as vfio-igd maintainerTomita Moeko1-1/+8
As suggested by Cédric, I'm glad to be a maintainer of vfio-igd. Signed-off-by: Tomita Moeko <tomitamoeko@gmail.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250227162741.9860-1-tomitamoeko@gmail.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06hw/vfio/pci: Re-order pre-resetAlex Williamson1-9/+9
We want the device in the D0 power state going into reset, but the config write can enable the BARs in the address space, which are then removed from the address space once we clear the memory enable bit in the command register. Re-order to clear the command bit first, so the power state change doesn't enable the BARs. Cc: Cédric Le Goater <clg@redhat.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250225215237.3314011-6-alex.williamson@redhat.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06pcie, virtio: Remove redundant pm_capAlex Williamson3-8/+3
The pm_cap on the PCIExpressDevice object can be distilled down to the new instance on the PCIDevice object. Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250225215237.3314011-5-alex.williamson@redhat.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06vfio/pci: Delete local pm_capAlex Williamson2-6/+4
This is now redundant to PCIDevice.pm_cap. Cc: Cédric Le Goater <clg@redhat.com> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250225215237.3314011-4-alex.williamson@redhat.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06pci: Use PCI PM capability initializerAlex Williamson7-13/+12
Switch callers directly initializing the PCI PM capability with pci_add_capability() to use pci_pm_init(). Cc: Dmitry Fleytman <dmitry.fleytman@gmail.com> Cc: Akihiko Odaki <akihiko.odaki@daynix.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Stefan Weil <sw@weilnetz.de> Cc: Sriram Yagnaraman <sriram.yagnaraman@ericsson.com> Cc: Keith Busch <kbusch@kernel.org> Cc: Klaus Jensen <its@irrelevant.dk> Cc: Jesper Devantier <foss@defmacro.it> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Cc: Cédric Le Goater <clg@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250225215237.3314011-3-alex.williamson@redhat.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06hw/pci: Basic support for PCI power managementAlex Williamson4-2/+99
The memory and IO BARs for devices are only accessible in the D0 power state. In other power states the PCI spec defines that the device responds to TLPs and messages with an Unsupported Request response. To approximate this behavior, consider the BARs as unmapped when the device is not in the D0 power state. This makes the BARs inaccessible and has the additional bonus for vfio-pci that we don't attempt to DMA map BARs for devices in a non-D0 power state. To support this, an interface is added for devices to register the PM capability, which allows central tracking to enforce valid transitions and unmap BARs in non-D0 states. NB. We currently have device models (eepro100 and pcie_pci_bridge) that register a PM capability but do not set wmask to enable writes to the power state field. In order to maintain migration compatibility, this new helper does not manage the wmask to enable guest writes to initiate a power state change. The contents and write access of the PM capability are still managed by the caller. Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250225215237.3314011-2-alex.williamson@redhat.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06vfio/ccw: Replace warn_once_pfch() with warn_report_once()Cédric Le Goater1-10/+2
Use the common helper warn_report_once() instead of implementing its own. Cc: Eric Farman <farman@linux.ibm.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Link: https://lore.kernel.org/qemu-devel/20250214161936.1720039-1-clg@redhat.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-06vfio: Add property documentationCédric Le Goater4-0/+173
Investigate the git history to uncover when and why the VFIO properties were introduced and update the models. This is mostly targeting vfio-pci device, since vfio-platform, vfio-ap and vfio-ccw devices are simpler. Sort the properties based on the QEMU version in which they were introduced. Cc: Tony Krowiak <akrowiak@linux.ibm.com> Cc: Eric Farman <farman@linux.ibm.com> Cc: Eric Auger <eric.auger@redhat.com> Reviewed-by: Kirti Wankhede <kwankhede@nvidia.com> Reviewed-by: Anthony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> # vfio-ccw Reviewed-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Link: https://lore.kernel.org/qemu-devel/20250217173455.449983-1-clg@redhat.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2025-03-05chardev: use remoteAddr if the chardev is clientHaoqian He1-3/+7
If the chardev is client, the socket file path in localAddr may be NULL. This is because the socket path comes from getsockname(), according to man page, getsockname() returns the current address bound by the socket sockfd. If the chardev is client, it's socket is unbound sockfd. Therefore, when computing the client chardev socket file path, using remoteAddr is more appropriate. Signed-off-by: Haoqian He <haoqian.he@smartx.com> Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-ID: <20250225104526.2924175-1-haoqian.he@smartx.com>
2025-03-05ui/console-vc: implement DCH (delete) and ICH (insert) commandsRoman Penyaev1-0/+88
This patch implements DCH (delete character) and ICH (insert character) commands. DCH - Delete Character: "As characters are deleted, the remaining characters between the cursor and right margin move to the left. Character attributes move with the characters. The terminal adds blank spaces with no visual character attributes at the right margin. DCH has no effect outside the scrolling margins" [1]. ICH - Insert Character: "The ICH sequence inserts Pn blank characters with the normal character attribute. The cursor remains at the beginning of the blank characters. Text between the cursor and right margin moves to the right. Characters scrolled past the right margin are lost. ICH has no effect outside the scrolling margins" [2]. Without these commands console is barely usable. [1] https://vt100.net/docs/vt510-rm/DCH.html [1] https://vt100.net/docs/vt510-rm/ICH.html Signed-off-by: Roman Penyaev <r.peniaev@gmail.com> Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com> Cc: qemu-devel@nongnu.org Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-ID: <20250226075913.353676-6-r.peniaev@gmail.com>
2025-03-05ui/console-vc: add support for cursor DECSC and DECRC commandsRoman Penyaev1-6/+34
There are aliases for save and restore cursor commands: * save cursor `ESC 7` (DEC Save Cursor [1], older VT100) `ESC [ s` (CSI Save Cursor, standard ANSI) * load cursor `ESC 8` (DEC Restore Cursor [2], older VT100) `ESC [ u` (CSI Restore Cursor, standard ANSI) This change introduces older DEC sequencies for compatibility with some scripts (for example [3]) and tools. This change also adds saving and restoring of character attributes, which is according to the VT spec [1][2] [1] https://vt100.net/docs/vt510-rm/DECSC.html [2] https://vt100.net/docs/vt510-rm/DECRC.html [3] https://wiki.archlinux.org/title/Working_with_the_serial_console#Resizing_a_terminal Signed-off-by: Roman Penyaev <r.peniaev@gmail.com> Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com> Cc: qemu-devel@nongnu.org Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-ID: <20250226075913.353676-5-r.peniaev@gmail.com>
2025-03-05ui/console-vc: report cursor position in the screen not in the scroll bufferRoman Penyaev1-2/+1
The format of the CSI cursor position report is `ESC[row;columnR`, where `row` is a row of a cursor in the screen, not in the scrollback buffer. What's the difference? Let's say the terminal screen has 24 lines, no matter how long the scrollback buffer may be, the last line is the 24th. For example the following command can be executed in xterm on the last screen line: $ echo -en '\e[6n'; IFS='[;' read -sdR _ row col; echo $row:$col 24:1 It shows the cursor position on the current screen and not relative to the backscroll buffer. Before this change the row number was always increasing for the QEMU VC and represents the cursor position relative to the backscroll buffer. Signed-off-by: Roman Penyaev <r.peniaev@gmail.com> Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com> Cc: qemu-devel@nongnu.org Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-ID: <20250226075913.353676-4-r.peniaev@gmail.com>
2025-03-05ui/console-vc: report to the application instead of screen renderingRoman Penyaev1-4/+3
Terminal Device Status Report (DSR) [1] should be sent to an application, not rendered to the screen. This patch fixes rendering of terminal report, which appear only on the graphical screen of the terminal (console "vc") and can be reproduced by the following command: echo -en '\e[6n'; IFS='[;' read -sdR _ row col; echo $row:$col Command requests cursor position and waits for terminal response, but instead, the response is rendered to the graphical screen and never sent to an application. Why bother? Busybox shell (ash) in Alpine distribution requests cursor position on each shell prompt (once <ENTER> is pressed), which makes a prompt on a graphical screen corrupted with repeating Cursor Position Report (CPR) [2]: [root@alpine ~]# \033[57;1R] Which is very annoying and incorrect. [1] https://vt100.net/docs/vt100-ug/chapter3.html#DSR [2] https://vt100.net/docs/vt100-ug/chapter3.html#CPR Signed-off-by: Roman Penyaev <r.peniaev@gmail.com> Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com> Cc: qemu-devel@nongnu.org Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-ID: <20250226075913.353676-3-r.peniaev@gmail.com>
2025-03-05ui/console-vc: introduce parsing of the 'ESC ( <ch>' sequenceRoman Penyaev1-0/+16
This change introduces parsing of the 'ESC ( <ch>' sequence, which is supposed to change character set [1]. In the QEMU case, the introduced parsing logic does not actually change the character set, but simply parses the sequence and does not let output of a tool to be corrupted with leftovers: `top` sends 'ESC ( B', so if character sequence is not parsed correctly, chracter 'B' appears in the output: Btop - 11:08:42 up 5 min, 1 user, load average: 0BB Tasks:B 158 Btotal,B 1 Brunning,B 157 Bsleeping,B 0 BsBB %Cpu(s):B 0.0 Bus,B 0.0 Bsy,B 0.0 Bni,B 99.8 Bid,B 0.2 BB MiB Mem :B 7955.6 Btotal,B 7778.6 Bfree,B 79.6 BB MiB Swap:B 0.0 Btotal,B 0.0 Bfree,B 0.0 BB PID USER PR NI VIRT RES SHR S B B 735 root 20 0 9328 3540 3152 R B B 1 root 20 0 20084 10904 8404 S B B 2 root 20 0 0 0 0 S B [1] https://vt100.net/docs/vt100-ug/chapter3.html#SCS Signed-off-by: Roman Penyaev <r.peniaev@gmail.com> Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com> Cc: qemu-devel@nongnu.org Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-ID: <20250226075913.353676-2-r.peniaev@gmail.com>
2025-03-05target/loongarch: Adjust the cpu reset action to a proper positionXianglai Li1-1/+1
The commit 5a99a10da6cf ("target/loongarch: fix vcpu reset command word issue") fixes the error in the cpu reset ioctl command word delivery process, so that the command word can be delivered correctly, and adds the judgment and processing of the error return value, which exposes another problem that under loongarch, the cpu reset action is earlier than the creation of vcpu. An error occurs when the cpu reset command is sent. Now adjust the order of cpu reset and vcpu create actions to fix this problem Signed-off-by: Xianglai Li <lixianglai@loongson.cn> Acked-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Bibo Mao <maobibo@loongson.cn>
2025-03-05hw/loongarch/virt: Enable cpu hotplug feature on virt machineBibo Mao1-2/+42
On virt machine, enable CPU hotplug feature has_hotpluggable_cpus. For hot-added CPUs, there is socket-id/core-id/thread-id property set, arch_id can be caculated from these properties. So that cpu slot can be searched from its arch_id. Co-developed-by: Xianglai Li <lixianglai@loongson.cn> Signed-off-by: Bibo Mao <maobibo@loongson.cn>
2025-03-05hw/loongarch/virt: Update the ACPI table for hotplug cpuBibo Mao4-3/+44
On LoongArch virt machine, ACPI GED hardware is used for CPU hotplug handler, here CPU hotplug support feature is added based on GED handler, also CPU scan and reject method is added about CPU device in DSDT table. Co-developed-by: Xianglai Li <lixianglai@loongson.cn> Signed-off-by: Bibo Mao <maobibo@loongson.cn>
2025-03-05hw/loongarch/virt: Implement cpu plug interfaceBibo Mao2-11/+78
Implement cpu plug interface, and cold-plug cpu uses plug interface when cpu object is created. Co-developed-by: Xianglai Li <lixianglai@loongson.cn> Signed-off-by: Bibo Mao <maobibo@loongson.cn>
2025-03-05hw/loongarch/virt: Implement cpu unplug interfaceBibo Mao1-0/+58
Implement cpu unplug interfaces including virt_cpu_unplug_request() and virt_cpu_unplug(). Co-developed-by: Xianglai Li <lixianglai@loongson.cn> Signed-off-by: Bibo Mao <maobibo@loongson.cn>