86fae16e | 20-Feb-2024 |
Peter Maydell <peter.maydell@linaro.org> |
hw/core/reset: Add qemu_{register, unregister}_resettable()
Implement new functions qemu_register_resettable() and qemu_unregister_resettable(). These are intended to be three-phase-reset aware equ
hw/core/reset: Add qemu_{register, unregister}_resettable()
Implement new functions qemu_register_resettable() and qemu_unregister_resettable(). These are intended to be three-phase-reset aware equivalents of the old qemu_register_reset() and qemu_unregister_reset(). Instead of passing in a function pointer and opaque, you register any QOM object that implements the Resettable interface.
The implementation is simple: we have a single global instance of a ResettableContainer, which we reset in qemu_devices_reset(), and the Resettable objects passed to qemu_register_resettable() are added to it.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-id: 20240220160622.114437-8-peter.maydell@linaro.org Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
show more ...
|
5422d2a8 | 03-Dec-2023 |
Gavin Shan <gshan@redhat.com> |
machine: Print CPU model name instead of CPU type
The names of supported CPU models instead of CPU types should be printed when the user specified CPU type isn't supported, to be consistent with the
machine: Print CPU model name instead of CPU type
The names of supported CPU models instead of CPU types should be printed when the user specified CPU type isn't supported, to be consistent with the output from '-cpu ?'.
Correct the error messages to print CPU model names instead of CPU type names.
Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20231204004726.483558-5-gshan@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
show more ...
|
e702cbc1 | 03-Dec-2023 |
Gavin Shan <gshan@redhat.com> |
machine: Improve is_cpu_type_supported()
It's no sense to check the CPU type when mc->valid_cpu_types[0] is NULL, which is a program error. Raise an assert on this.
A precise hint for the error mes
machine: Improve is_cpu_type_supported()
It's no sense to check the CPU type when mc->valid_cpu_types[0] is NULL, which is a program error. Raise an assert on this.
A precise hint for the error message is given when mc->valid_cpu_types[0] is the only valid entry. Besides, enumeration on mc->valid_cpu_types[0] when we have mutiple valid entries there is avoided to increase the code readability, as suggested by Philippe Mathieu-Daudé.
Besides, @cc comes from machine->cpu_type or mc->default_cpu_type. For the later case, it can be NULL and it's also a program error. We should use assert() in this case.
Signed-off-by: Gavin Shan <gshan@redhat.com> Message-ID: <20231204004726.483558-4-gshan@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
show more ...
|
acbadc5a | 03-Dec-2023 |
Gavin Shan <gshan@redhat.com> |
machine: Introduce helper is_cpu_type_supported()
The logic, to check if the specified CPU type is supported in machine_run_board_init(), is independent enough. Factor it out into helper is_cpu_type
machine: Introduce helper is_cpu_type_supported()
The logic, to check if the specified CPU type is supported in machine_run_board_init(), is independent enough. Factor it out into helper is_cpu_type_supported(). machine_run_board_init() looks a bit clean with this. Since we're here, @machine_class is renamed to @mc to avoid multiple line spanning of code. The comments are tweaked a bit either.
No functional change intended.
Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20231204004726.483558-3-gshan@redhat.com> [PMD: Only call new helper if machine->cpu_type is not NULL] Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
show more ...
|
b9f45214 | 03-Dec-2023 |
Gavin Shan <gshan@redhat.com> |
machine: Use error handling when CPU type is checked
Functions that use an Error **errp parameter to return errors should not also report them to the user, because reporting is the caller's job. The
machine: Use error handling when CPU type is checked
Functions that use an Error **errp parameter to return errors should not also report them to the user, because reporting is the caller's job. The principle is violated by machine_run_board_init() because it calls error_report(), error_printf(), and exit(1) when the machine doesn't support the requested CPU type.
Clean this up by using error_setg() and error_append_hint() instead. No functional change, as the only caller passes &error_fatal.
Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-ID: <20231204004726.483558-2-gshan@redhat.com> [PMD: Correct error_append_hint() argument] Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
show more ...
|
cf03a152 | 20-Dec-2023 |
Stefan Hajnoczi <stefanha@redhat.com> |
qdev: add IOThreadVirtQueueMappingList property type
virtio-blk and virtio-scsi devices will need a way to specify the mapping between IOThreads and virtqueues. At the moment all virtqueues are assi
qdev: add IOThreadVirtQueueMappingList property type
virtio-blk and virtio-scsi devices will need a way to specify the mapping between IOThreads and virtqueues. At the moment all virtqueues are assigned to a single IOThread or the main loop. This single thread can be a CPU bottleneck, so it is necessary to allow finer-grained assignment to spread the load.
Introduce DEFINE_PROP_IOTHREAD_VQ_MAPPING_LIST() so devices can take a parameter that maps virtqueues to IOThreads. The command-line syntax for this new property is as follows:
--device '{"driver":"foo","iothread-vq-mapping":[{"iothread":"iothread0","vqs":[0,1,2]},...]}'
IOThreads are specified by name and virtqueues are specified by 0-based index.
It will be common to simply assign virtqueues round-robin across a set of IOThreads. A convenient syntax that does not require specifying individual virtqueue indices is available:
--device '{"driver":"foo","iothread-vq-mapping":[{"iothread":"iothread0"},{"iothread":"iothread1"},...]}'
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20231220134755.814917-4-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
show more ...
|
d90014fc | 23-Oct-2023 |
Cédric Le Goater <clg@redhat.com> |
igb: Add Function Level Reset to PF and VF
The Intel 82576EB GbE Controller say that the Physical and Virtual Functions support Function Level Reset. Add the capability to the PF device model using
igb: Add Function Level Reset to PF and VF
The Intel 82576EB GbE Controller say that the Physical and Virtual Functions support Function Level Reset. Add the capability to the PF device model using device property "x-pcie-flr-init" which is "on" by default and "off" for machines <= 8.1 to preserve compatibility.
The FLR capability of the VF model is defined according to the FLR property of the PF, this to avoid adding an extra compatibility property.
Cc: Sriram Yagnaraman <sriram.yagnaraman@est.tech> Fixes: 3a977deebe6b ("Intrdocue igb device emulation") Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Tested-by: Akihiko Odaki <akihiko.odaki@daynix.com> Signed-off-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
show more ...
|