748e62db | 08-Apr-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
stubs: move monitor_fdsets_cleanup with other fdset stubs
Even though monitor_get_fd() has to remain separate because it is mocked by tests/unit/test-util-sockets, monitor_fdsets_cleanup() is logica
stubs: move monitor_fdsets_cleanup with other fdset stubs
Even though monitor_get_fd() has to remain separate because it is mocked by tests/unit/test-util-sockets, monitor_fdsets_cleanup() is logically part of the stubs for monitor/fds.c, so move it there.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20240408155330.522792-19-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
3a156049 | 08-Apr-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
stubs: include stubs only if needed
Currently it is not documented anywhere why some functions need to be stubbed.
Group the files in stubs/meson.build according to who needs them, both to reduce t
stubs: include stubs only if needed
Currently it is not documented anywhere why some functions need to be stubbed.
Group the files in stubs/meson.build according to who needs them, both to reduce the size of the compilation and to clarify the use of stubs.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-ID: <20240408155330.522792-18-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
957eca9e | 08-Apr-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
stubs: split record/replay stubs further
replay.c symbols are only needed by user mode emulation, with the exception of replay_mode that is needed by both user mode emulation (by way of qemu_guest_g
stubs: split record/replay stubs further
replay.c symbols are only needed by user mode emulation, with the exception of replay_mode that is needed by both user mode emulation (by way of qemu_guest_getrandom) and block layer tools (by way of util/qemu-timer.c).
Since it is needed by libqemuutil rather than specific files that are part of the tools and emulators, split the replay_mode stub into its own file.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-ID: <20240408155330.522792-17-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
857f504c | 08-Apr-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
colo: move stubs out of stubs/
Since the colo stubs are needed exactly when the build options are not enabled, move them together with the code they stub.
Signed-off-by: Paolo Bonzini <pbonzini@red
colo: move stubs out of stubs/
Since the colo stubs are needed exactly when the build options are not enabled, move them together with the code they stub.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-ID: <20240408155330.522792-16-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
2c888feb | 08-Apr-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
memory-device: move stubs out of stubs/
Since the memory-device stubs are needed exactly when the Kconfig symbols are not needed, move them to hw/mem/.
Signed-off-by: Paolo Bonzini <pbonzini@redhat
memory-device: move stubs out of stubs/
Since the memory-device stubs are needed exactly when the Kconfig symbols are not needed, move them to hw/mem/.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20240408155330.522792-15-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
5643190b | 08-Apr-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
ramfb: move stubs out of stubs/
Since the ramfb stubs are needed exactly when the Kconfig symbols are not needed, move them to hw/display/ and compile them when ramfb.c is absent.
Signed-off-by: Pa
ramfb: move stubs out of stubs/
Since the ramfb stubs are needed exactly when the Kconfig symbols are not needed, move them to hw/display/ and compile them when ramfb.c is absent.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20240408155330.522792-14-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
5837db46 | 08-Apr-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
semihosting: move stubs out of stubs/
Since the semihosting stubs are needed exactly when the Kconfig symbols are not needed, move them to semihosting/ and conditionalize them on CONFIG_SEMIHOSTING
semihosting: move stubs out of stubs/
Since the semihosting stubs are needed exactly when the Kconfig symbols are not needed, move them to semihosting/ and conditionalize them on CONFIG_SEMIHOSTING and/or CONFIG_SYSTEM_ONLY.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-ID: <20240408155330.522792-13-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
f2604d85 | 08-Apr-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
hw/virtio: move stubs out of stubs/
Since the virtio memory device stubs are needed exactly when the Kconfig symbol is not enabled, they can be placed in hw/virtio/ and conditionalized on CONFIG_VIR
hw/virtio: move stubs out of stubs/
Since the virtio memory device stubs are needed exactly when the Kconfig symbol is not enabled, they can be placed in hw/virtio/ and conditionalized on CONFIG_VIRTIO_MD.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20240408155330.522792-12-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
89857312 | 08-Apr-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
hw/usb: move stubs out of stubs/
Since the USB stubs are needed exactly when the Kconfig symbols are not enabled, they can be placed in hw/usb/ and conditionalized on CONFIG_USB.
Signed-off-by: Pao
hw/usb: move stubs out of stubs/
Since the USB stubs are needed exactly when the Kconfig symbols are not enabled, they can be placed in hw/usb/ and conditionalized on CONFIG_USB.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20240408155330.522792-11-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
d4d0ebb7 | 08-Apr-2024 |
Paolo Bonzini <pbonzini@redhat.com> |
stubs: remove obsolete stubs
These file define functions are are not called from common code anymore. Delete those functions and, if applicable, the entire files.
Signed-off-by: Paolo Bonzini <pbo
stubs: remove obsolete stubs
These file define functions are are not called from common code anymore. Delete those functions and, if applicable, the entire files.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Acked-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20240408155330.522792-10-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
8e98c27d | 08-Dec-2023 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
system/cpu-timers: Introduce ICountMode enumerator
Rather than having to lookup for what the 0, 1, 2, ... icount values are, use a enum definition.
Signed-off-by: Philippe Mathieu-Daudé <philmd@lin
system/cpu-timers: Introduce ICountMode enumerator
Rather than having to lookup for what the 0, 1, 2, ... icount values are, use a enum definition.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20231208113529.74067-4-philmd@linaro.org>
show more ...
|
c8a7fc51 | 18-Oct-2023 |
Steve Sistare <steven.sistare@oracle.com> |
migration: simplify blockers
Modify migrate_add_blocker and migrate_del_blocker to take an Error ** reason. This allows migration to own the Error object, so that if an error occurs in migrate_add_
migration: simplify blockers
Modify migrate_add_blocker and migrate_del_blocker to take an Error ** reason. This allows migration to own the Error object, so that if an error occurs in migrate_add_blocker, migration code can free the Error and clear the client handle, simplifying client code. It also simplifies the migrate_del_blocker call site.
In addition, this is a pre-requisite for a proposed future patch that would add a mode argument to migration requests to support live update, and maintain a list of blockers for each mode. A blocker may apply to a single mode or to multiple modes, and passing Error** will allow one Error object to be registered for multiple modes.
No functional change.
Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Tested-by: Michael Galaxy <mgalaxy@akamai.com> Reviewed-by: Michael Galaxy <mgalaxy@akamai.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <1697634216-84215-1-git-send-email-steven.sistare@oracle.com>
show more ...
|
a2335113 | 26-Sep-2023 |
David Hildenbrand <david@redhat.com> |
memory-device,vhost: Support automatic decision on the number of memslots
We want to support memory devices that can automatically decide how many memslots they will use. In the worst case, they hav
memory-device,vhost: Support automatic decision on the number of memslots
We want to support memory devices that can automatically decide how many memslots they will use. In the worst case, they have to use a single memslot.
The target use cases are virtio-mem and the hyper-v balloon.
Let's calculate a reasonable limit such a memory device may use, and instruct the device to make a decision based on that limit. Use a simple heuristic that considers: * A memslot soft-limit for all memory devices of 256; also, to not consume too many memslots -- which could harm performance. * Actually still free and unreserved memslots * The percentage of the remaining device memory region that memory device will occupy.
Further, while we properly check before plugging a memory device whether there still is are free memslots, we have other memslot consumers (such as boot memory, PCI BARs) that don't perform any checks and might dynamically consume memslots without any prior reservation. So we might succeed in plugging a memory device, but once we dynamically map a PCI BAR we would be in trouble. Doing accounting / reservation / checks for all such users is problematic (e.g., sometimes we might temporarily split boot memory into two memslots, triggered by the BIOS).
We use the historic magic memslot number of 509 as orientation to when supporting 256 memory devices -> memslots (leaving 253 for boot memory and other devices) has been proven to work reliable. We'll fallback to suggesting a single memslot if we don't have at least 509 total memslots.
Plugging vhost devices with less than 509 memslots available while we have memory devices plugged that consume multiple memslots due to automatic decisions can be problematic. Most configurations might just fail due to "limit < used + reserved", however, it can also happen that these memory devices would suddenly consume memslots that would actually be required by other memslot consumers (boot, PCI BARs) later. Note that this has always been sketchy with vhost devices that support only a small number of memslots; but we don't want to make it any worse.So let's keep it simple and simply reject plugging such vhost devices in such a configuration.
Eventually, all vhost devices that want to be fully compatible with such memory devices should support a decent number of memslots (>= 509).
Message-ID: <20230926185738.277351-13-david@redhat.com> Reviewed-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
show more ...
|
766aa0a6 | 26-Sep-2023 |
David Hildenbrand <david@redhat.com> |
memory-device,vhost: Support memory devices that dynamically consume memslots
We want to support memory devices that have a dynamically managed memory region container as device memory region. This
memory-device,vhost: Support memory devices that dynamically consume memslots
We want to support memory devices that have a dynamically managed memory region container as device memory region. This device memory region maps multiple RAM memory subregions (e.g., aliases to the same RAM memory region), whereby these subregions can be (un)mapped on demand.
Each RAM subregion will consume a memslot in KVM and vhost, resulting in such a new device consuming memslots dynamically, and initially usually 0. We already track the number of used vs. required memslots for all memslots. From that, we can derive the number of reserved memslots that must not be used otherwise.
The target use case is virtio-mem and the hyper-v balloon, which will dynamically map aliases to RAM memory region into their device memory region container.
Properly document what's supported and what's not and extend the vhost memslot check accordingly.
Message-ID: <20230926185738.277351-10-david@redhat.com> Reviewed-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
show more ...
|