#
a0359b56 |
| 15-May-2024 |
Avihai Horon <avihaih@nvidia.com> |
qapi/vfio: Add VFIO migration QAPI event
Add a new QAPI event for VFIO migration. This event will be emitted when a VFIO device changes its migration state, for example, during migration or when sto
qapi/vfio: Add VFIO migration QAPI event
Add a new QAPI event for VFIO migration. This event will be emitted when a VFIO device changes its migration state, for example, during migration or when stopping/starting the guest.
This event can be used by management applications to get updates on the current state of the VFIO device for their own purposes.
Note that this new event is introduced since VFIO devices have a unique set of migration states which cannot be described as accurately by other existing events such as run state or migration status.
Signed-off-by: Avihai Horon <avihaih@nvidia.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
show more ...
|
Revision tags: v8.2.4, v8.2.3, v7.2.11, v9.0.0, v9.0.0-rc4, v9.0.0-rc3, v9.0.0-rc2 |
|
#
1dfd42c4 |
| 28-Mar-2024 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
hw/rdma: Remove deprecated pvrdma device and rdmacm-mux helper
The whole RDMA subsystem was deprecated in commit e9a54265f5 ("hw/rdma: Deprecate the pvrdma device and the rdma subsystem") released i
hw/rdma: Remove deprecated pvrdma device and rdmacm-mux helper
The whole RDMA subsystem was deprecated in commit e9a54265f5 ("hw/rdma: Deprecate the pvrdma device and the rdma subsystem") released in v8.2.
Remove: - PVRDMA device - generated vmw_pvrdma/ directory from linux-headers - rdmacm-mux tool from contrib/
Cc: Yuval Shaia <yuval.shaia.ml@gmail.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20240328130255.52257-2-philmd@linaro.org>
show more ...
|
Revision tags: v9.0.0-rc1, v9.0.0-rc0 |
|
#
e88899fa |
| 12-Mar-2024 |
Andrew Melnychenko <andrew@daynix.com> |
qmp: Added new command to retrieve eBPF blob.
Now, the binary objects may be retrieved by id. It would require for future qmp commands that may require specific eBPF blob.
Added command "request-eb
qmp: Added new command to retrieve eBPF blob.
Now, the binary objects may be retrieved by id. It would require for future qmp commands that may require specific eBPF blob.
Added command "request-ebpf". This command returns eBPF program encoded base64. The program taken from the skeleton and essentially is an ELF object that can be loaded in the future with libbpf.
The reason to use the command to provide the eBPF object instead of a separate artifact was to avoid issues related to finding the eBPF itself. eBPF object is an ELF binary that contains the eBPF program and eBPF map description(BTF). Overall, eBPF object should contain the program and enough metadata to create/load eBPF with libbpf. As the eBPF maps/program should correspond to QEMU, the eBPF can't be used from different QEMU build.
The first solution was a helper that comes with QEMU and loads appropriate eBPF objects. And the issue is to find a proper helper if the system has several different QEMUs installed and/or built from the source, which helpers may not be compatible.
Another issue is QEMU updating while there is a running QEMU instance. With an updated helper, it may not be possible to hotplug virtio-net device to the already running QEMU. Overall, requesting the eBPF object from QEMU itself solves possible failures with acceptable effort.
Links: [PATCH 3/5] qmp: Added the helper stamp check. https://lore.kernel.org/all/20230219162100.174318-4-andrew@daynix.com/
Signed-off-by: Andrew Melnychenko <andrew@daynix.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
show more ...
|
Revision tags: v9.0.0-rc1, v9.0.0-rc0 |
|
#
e88899fa |
| 12-Mar-2024 |
Andrew Melnychenko <andrew@daynix.com> |
qmp: Added new command to retrieve eBPF blob.
Now, the binary objects may be retrieved by id. It would require for future qmp commands that may require specific eBPF blob.
Added command "request-eb
qmp: Added new command to retrieve eBPF blob.
Now, the binary objects may be retrieved by id. It would require for future qmp commands that may require specific eBPF blob.
Added command "request-ebpf". This command returns eBPF program encoded base64. The program taken from the skeleton and essentially is an ELF object that can be loaded in the future with libbpf.
The reason to use the command to provide the eBPF object instead of a separate artifact was to avoid issues related to finding the eBPF itself. eBPF object is an ELF binary that contains the eBPF program and eBPF map description(BTF). Overall, eBPF object should contain the program and enough metadata to create/load eBPF with libbpf. As the eBPF maps/program should correspond to QEMU, the eBPF can't be used from different QEMU build.
The first solution was a helper that comes with QEMU and loads appropriate eBPF objects. And the issue is to find a proper helper if the system has several different QEMUs installed and/or built from the source, which helpers may not be compatible.
Another issue is QEMU updating while there is a running QEMU instance. With an updated helper, it may not be possible to hotplug virtio-net device to the already running QEMU. Overall, requesting the eBPF object from QEMU itself solves possible failures with acceptable effort.
Links: [PATCH 3/5] qmp: Added the helper stamp check. https://lore.kernel.org/all/20230219162100.174318-4-andrew@daynix.com/
Signed-off-by: Andrew Melnychenko <andrew@daynix.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
show more ...
|
Revision tags: v9.0.0-rc1, v9.0.0-rc0 |
|
#
e88899fa |
| 12-Mar-2024 |
Andrew Melnychenko <andrew@daynix.com> |
qmp: Added new command to retrieve eBPF blob.
Now, the binary objects may be retrieved by id. It would require for future qmp commands that may require specific eBPF blob.
Added command "request-eb
qmp: Added new command to retrieve eBPF blob.
Now, the binary objects may be retrieved by id. It would require for future qmp commands that may require specific eBPF blob.
Added command "request-ebpf". This command returns eBPF program encoded base64. The program taken from the skeleton and essentially is an ELF object that can be loaded in the future with libbpf.
The reason to use the command to provide the eBPF object instead of a separate artifact was to avoid issues related to finding the eBPF itself. eBPF object is an ELF binary that contains the eBPF program and eBPF map description(BTF). Overall, eBPF object should contain the program and enough metadata to create/load eBPF with libbpf. As the eBPF maps/program should correspond to QEMU, the eBPF can't be used from different QEMU build.
The first solution was a helper that comes with QEMU and loads appropriate eBPF objects. And the issue is to find a proper helper if the system has several different QEMUs installed and/or built from the source, which helpers may not be compatible.
Another issue is QEMU updating while there is a running QEMU instance. With an updated helper, it may not be possible to hotplug virtio-net device to the already running QEMU. Overall, requesting the eBPF object from QEMU itself solves possible failures with acceptable effort.
Links: [PATCH 3/5] qmp: Added the helper stamp check. https://lore.kernel.org/all/20230219162100.174318-4-andrew@daynix.com/
Signed-off-by: Andrew Melnychenko <andrew@daynix.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
show more ...
|
Revision tags: v8.2.2, v7.2.10, v8.2.1, v8.1.5, v7.2.9, v8.1.4, v7.2.8, v8.2.0, v8.2.0-rc4, v8.2.0-rc3, v8.2.0-rc2, v8.2.0-rc1, v7.2.7, v8.1.3, v8.2.0-rc0 |
|
#
5de1aff2 |
| 16-Oct-2023 |
Pierre Morel <pmorel@linux.ibm.com> |
CPU topology: extend with s390 specifics
S390 adds two new SMP levels, drawers and books to the CPU topology. S390 CPUs have specific topology features like dedication and entitlement. These indicat
CPU topology: extend with s390 specifics
S390 adds two new SMP levels, drawers and books to the CPU topology. S390 CPUs have specific topology features like dedication and entitlement. These indicate to the guest information on host vCPU scheduling and help the guest make better scheduling decisions.
Add the new levels to the relevant QAPI structs. Add all the supported topology levels, dedication and entitlement as properties to S390 CPUs. Create machine-common.json so we can later include it in machine-target.json also.
Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Co-developed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Message-ID: <20231016183925.2384704-3-nsg@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
Revision tags: v8.2.2, v7.2.10, v8.2.1, v8.1.5, v7.2.9, v8.1.4, v7.2.8, v8.2.0, v8.2.0-rc4, v8.2.0-rc3, v8.2.0-rc2, v8.2.0-rc1, v7.2.7, v8.1.3, v8.2.0-rc0 |
|
#
5de1aff2 |
| 16-Oct-2023 |
Pierre Morel <pmorel@linux.ibm.com> |
CPU topology: extend with s390 specifics
S390 adds two new SMP levels, drawers and books to the CPU topology. S390 CPUs have specific topology features like dedication and entitlement. These indicat
CPU topology: extend with s390 specifics
S390 adds two new SMP levels, drawers and books to the CPU topology. S390 CPUs have specific topology features like dedication and entitlement. These indicate to the guest information on host vCPU scheduling and help the guest make better scheduling decisions.
Add the new levels to the relevant QAPI structs. Add all the supported topology levels, dedication and entitlement as properties to S390 CPUs. Create machine-common.json so we can later include it in machine-target.json also.
Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Co-developed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Message-ID: <20231016183925.2384704-3-nsg@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
Revision tags: v8.2.2, v7.2.10, v8.2.1, v8.1.5, v7.2.9, v8.1.4, v7.2.8, v8.2.0, v8.2.0-rc4, v8.2.0-rc3, v8.2.0-rc2, v8.2.0-rc1, v7.2.7, v8.1.3, v8.2.0-rc0 |
|
#
5de1aff2 |
| 16-Oct-2023 |
Pierre Morel <pmorel@linux.ibm.com> |
CPU topology: extend with s390 specifics
S390 adds two new SMP levels, drawers and books to the CPU topology. S390 CPUs have specific topology features like dedication and entitlement. These indicat
CPU topology: extend with s390 specifics
S390 adds two new SMP levels, drawers and books to the CPU topology. S390 CPUs have specific topology features like dedication and entitlement. These indicate to the guest information on host vCPU scheduling and help the guest make better scheduling decisions.
Add the new levels to the relevant QAPI structs. Add all the supported topology levels, dedication and entitlement as properties to S390 CPUs. Create machine-common.json so we can later include it in machine-target.json also.
Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Co-developed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Message-ID: <20231016183925.2384704-3-nsg@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
Revision tags: v8.2.2, v7.2.10, v8.2.1, v8.1.5, v7.2.9, v8.1.4, v7.2.8, v8.2.0, v8.2.0-rc4, v8.2.0-rc3, v8.2.0-rc2, v8.2.0-rc1, v7.2.7, v8.1.3, v8.2.0-rc0 |
|
#
5de1aff2 |
| 16-Oct-2023 |
Pierre Morel <pmorel@linux.ibm.com> |
CPU topology: extend with s390 specifics
S390 adds two new SMP levels, drawers and books to the CPU topology. S390 CPUs have specific topology features like dedication and entitlement. These indicat
CPU topology: extend with s390 specifics
S390 adds two new SMP levels, drawers and books to the CPU topology. S390 CPUs have specific topology features like dedication and entitlement. These indicate to the guest information on host vCPU scheduling and help the guest make better scheduling decisions.
Add the new levels to the relevant QAPI structs. Add all the supported topology levels, dedication and entitlement as properties to S390 CPUs. Create machine-common.json so we can later include it in machine-target.json also.
Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Co-developed-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Message-ID: <20231016183925.2384704-3-nsg@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
Revision tags: v8.1.2, v8.1.1, v7.2.6, v8.0.5, v8.1.0, v8.1.0-rc4, v8.1.0-rc3, v7.2.5, v8.0.4, v8.1.0-rc2, v8.1.0-rc1, v8.1.0-rc0, v8.0.3, v7.2.4 |
|
#
c7b64948 |
| 13-Jun-2023 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
meson: Replace CONFIG_SOFTMMU -> CONFIG_SYSTEM_ONLY
Since we *might* have user emulation with softmmu, use the clearer 'CONFIG_SYSTEM_ONLY' key to check for system emulation.
Signed-off-by: Philipp
meson: Replace CONFIG_SOFTMMU -> CONFIG_SYSTEM_ONLY
Since we *might* have user emulation with softmmu, use the clearer 'CONFIG_SYSTEM_ONLY' key to check for system emulation.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230613133347.82210-9-philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
show more ...
|
Revision tags: v8.0.2, v8.0.1, v7.2.3, v7.2.2, v8.0.0, v8.0.0-rc4, v8.0.0-rc3, v7.2.1, v8.0.0-rc2, v8.0.0-rc1, v8.0.0-rc0 |
|
#
415442a1 |
| 02-Mar-2023 |
Jonathan Cameron <Jonathan.Cameron@huawei.com> |
hw/mem/cxl_type3: Add CXL RAS Error Injection Support.
CXL uses PCI AER Internal errors to signal to the host that an error has occurred. The host can then read more detailed status from the CXL RAS
hw/mem/cxl_type3: Add CXL RAS Error Injection Support.
CXL uses PCI AER Internal errors to signal to the host that an error has occurred. The host can then read more detailed status from the CXL RAS capability.
For uncorrectable errors: support multiple injection in one operation as this is needed to reliably test multiple header logging support in an OS. The equivalent feature doesn't exist for correctable errors, so only one error need be injected at a time.
Note: - Header content needs to be manually specified in a fashion that matches the specification for what can be in the header for each error type.
Injection via QMP: { "execute": "qmp_capabilities" } ... { "execute": "cxl-inject-uncorrectable-errors", "arguments": { "path": "/machine/peripheral/cxl-pmem0", "errors": [ { "type": "cache-address-parity", "header": [ 3, 4] }, { "type": "cache-data-parity", "header": [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31] }, { "type": "internal", "header": [ 1, 2, 4] } ] }} ... { "execute": "cxl-inject-correctable-error", "arguments": { "path": "/machine/peripheral/cxl-pmem0", "type": "physical" } }
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20230302133709.30373-9-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
#
14c9fd16 |
| 01-Mar-2023 |
zhenwei pi <pizhenwei@bytedance.com> |
cryptodev: Introduce cryptodev.json
Introduce QCryptodevBackendType in cryptodev.json, also apply this to related codes. Then we can drop 'enum CryptoDevBackendOptionsType'.
Note that `CRYPTODEV_BA
cryptodev: Introduce cryptodev.json
Introduce QCryptodevBackendType in cryptodev.json, also apply this to related codes. Then we can drop 'enum CryptoDevBackendOptionsType'.
Note that `CRYPTODEV_BACKEND_TYPE_NONE` is *NOT* used by anywhere, so drop it(no 'none' enum in QCryptodevBackendType).
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: zhenwei pi <pizhenwei@bytedance.com> Message-Id: <20230301105847.253084-2-pizhenwei@bytedance.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
Revision tags: v8.0.2, v8.0.1, v7.2.3, v7.2.2, v8.0.0, v8.0.0-rc4, v8.0.0-rc3, v7.2.1, v8.0.0-rc2, v8.0.0-rc1, v8.0.0-rc0 |
|
#
415442a1 |
| 02-Mar-2023 |
Jonathan Cameron <Jonathan.Cameron@huawei.com> |
hw/mem/cxl_type3: Add CXL RAS Error Injection Support.
CXL uses PCI AER Internal errors to signal to the host that an error has occurred. The host can then read more detailed status from the CXL RAS
hw/mem/cxl_type3: Add CXL RAS Error Injection Support.
CXL uses PCI AER Internal errors to signal to the host that an error has occurred. The host can then read more detailed status from the CXL RAS capability.
For uncorrectable errors: support multiple injection in one operation as this is needed to reliably test multiple header logging support in an OS. The equivalent feature doesn't exist for correctable errors, so only one error need be injected at a time.
Note: - Header content needs to be manually specified in a fashion that matches the specification for what can be in the header for each error type.
Injection via QMP: { "execute": "qmp_capabilities" } ... { "execute": "cxl-inject-uncorrectable-errors", "arguments": { "path": "/machine/peripheral/cxl-pmem0", "errors": [ { "type": "cache-address-parity", "header": [ 3, 4] }, { "type": "cache-data-parity", "header": [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31] }, { "type": "internal", "header": [ 1, 2, 4] } ] }} ... { "execute": "cxl-inject-correctable-error", "arguments": { "path": "/machine/peripheral/cxl-pmem0", "type": "physical" } }
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20230302133709.30373-9-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
#
14c9fd16 |
| 01-Mar-2023 |
zhenwei pi <pizhenwei@bytedance.com> |
cryptodev: Introduce cryptodev.json
Introduce QCryptodevBackendType in cryptodev.json, also apply this to related codes. Then we can drop 'enum CryptoDevBackendOptionsType'.
Note that `CRYPTODEV_BA
cryptodev: Introduce cryptodev.json
Introduce QCryptodevBackendType in cryptodev.json, also apply this to related codes. Then we can drop 'enum CryptoDevBackendOptionsType'.
Note that `CRYPTODEV_BACKEND_TYPE_NONE` is *NOT* used by anywhere, so drop it(no 'none' enum in QCryptodevBackendType).
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: zhenwei pi <pizhenwei@bytedance.com> Message-Id: <20230301105847.253084-2-pizhenwei@bytedance.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
Revision tags: v8.0.2, v8.0.1, v7.2.3, v7.2.2, v8.0.0, v8.0.0-rc4, v8.0.0-rc3, v7.2.1, v8.0.0-rc2, v8.0.0-rc1, v8.0.0-rc0 |
|
#
415442a1 |
| 02-Mar-2023 |
Jonathan Cameron <Jonathan.Cameron@huawei.com> |
hw/mem/cxl_type3: Add CXL RAS Error Injection Support.
CXL uses PCI AER Internal errors to signal to the host that an error has occurred. The host can then read more detailed status from the CXL RAS
hw/mem/cxl_type3: Add CXL RAS Error Injection Support.
CXL uses PCI AER Internal errors to signal to the host that an error has occurred. The host can then read more detailed status from the CXL RAS capability.
For uncorrectable errors: support multiple injection in one operation as this is needed to reliably test multiple header logging support in an OS. The equivalent feature doesn't exist for correctable errors, so only one error need be injected at a time.
Note: - Header content needs to be manually specified in a fashion that matches the specification for what can be in the header for each error type.
Injection via QMP: { "execute": "qmp_capabilities" } ... { "execute": "cxl-inject-uncorrectable-errors", "arguments": { "path": "/machine/peripheral/cxl-pmem0", "errors": [ { "type": "cache-address-parity", "header": [ 3, 4] }, { "type": "cache-data-parity", "header": [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31] }, { "type": "internal", "header": [ 1, 2, 4] } ] }} ... { "execute": "cxl-inject-correctable-error", "arguments": { "path": "/machine/peripheral/cxl-pmem0", "type": "physical" } }
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20230302133709.30373-9-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
#
14c9fd16 |
| 01-Mar-2023 |
zhenwei pi <pizhenwei@bytedance.com> |
cryptodev: Introduce cryptodev.json
Introduce QCryptodevBackendType in cryptodev.json, also apply this to related codes. Then we can drop 'enum CryptoDevBackendOptionsType'.
Note that `CRYPTODEV_BA
cryptodev: Introduce cryptodev.json
Introduce QCryptodevBackendType in cryptodev.json, also apply this to related codes. Then we can drop 'enum CryptoDevBackendOptionsType'.
Note that `CRYPTODEV_BACKEND_TYPE_NONE` is *NOT* used by anywhere, so drop it(no 'none' enum in QCryptodevBackendType).
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: zhenwei pi <pizhenwei@bytedance.com> Message-Id: <20230301105847.253084-2-pizhenwei@bytedance.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
Revision tags: v8.0.2, v8.0.1, v7.2.3, v7.2.2, v8.0.0, v8.0.0-rc4, v8.0.0-rc3, v7.2.1, v8.0.0-rc2, v8.0.0-rc1, v8.0.0-rc0 |
|
#
415442a1 |
| 02-Mar-2023 |
Jonathan Cameron <Jonathan.Cameron@huawei.com> |
hw/mem/cxl_type3: Add CXL RAS Error Injection Support.
CXL uses PCI AER Internal errors to signal to the host that an error has occurred. The host can then read more detailed status from the CXL RAS
hw/mem/cxl_type3: Add CXL RAS Error Injection Support.
CXL uses PCI AER Internal errors to signal to the host that an error has occurred. The host can then read more detailed status from the CXL RAS capability.
For uncorrectable errors: support multiple injection in one operation as this is needed to reliably test multiple header logging support in an OS. The equivalent feature doesn't exist for correctable errors, so only one error need be injected at a time.
Note: - Header content needs to be manually specified in a fashion that matches the specification for what can be in the header for each error type.
Injection via QMP: { "execute": "qmp_capabilities" } ... { "execute": "cxl-inject-uncorrectable-errors", "arguments": { "path": "/machine/peripheral/cxl-pmem0", "errors": [ { "type": "cache-address-parity", "header": [ 3, 4] }, { "type": "cache-data-parity", "header": [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31] }, { "type": "internal", "header": [ 1, 2, 4] } ] }} ... { "execute": "cxl-inject-correctable-error", "arguments": { "path": "/machine/peripheral/cxl-pmem0", "type": "physical" } }
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20230302133709.30373-9-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
#
14c9fd16 |
| 01-Mar-2023 |
zhenwei pi <pizhenwei@bytedance.com> |
cryptodev: Introduce cryptodev.json
Introduce QCryptodevBackendType in cryptodev.json, also apply this to related codes. Then we can drop 'enum CryptoDevBackendOptionsType'.
Note that `CRYPTODEV_BA
cryptodev: Introduce cryptodev.json
Introduce QCryptodevBackendType in cryptodev.json, also apply this to related codes. Then we can drop 'enum CryptoDevBackendOptionsType'.
Note that `CRYPTODEV_BACKEND_TYPE_NONE` is *NOT* used by anywhere, so drop it(no 'none' enum in QCryptodevBackendType).
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: zhenwei pi <pizhenwei@bytedance.com> Message-Id: <20230301105847.253084-2-pizhenwei@bytedance.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
Revision tags: v7.2.0, v7.2.0-rc4, v7.2.0-rc3, v7.2.0-rc2, v7.2.0-rc1 |
|
#
e0091133 |
| 10-Nov-2022 |
Thomas Huth <thuth@redhat.com> |
qga: Allow building of the guest agent without system emulators or tools
If configuring with "--disable-system --disable-user --enable-guest-agent" the linking currently fails with:
qga/qemu-ga.p/c
qga: Allow building of the guest agent without system emulators or tools
If configuring with "--disable-system --disable-user --enable-guest-agent" the linking currently fails with:
qga/qemu-ga.p/commands.c.o: In function `qmp_command_info': build/../../home/thuth/devel/qemu/qga/commands.c:70: undefined reference to `qmp_command_name' build/../../home/thuth/devel/qemu/qga/commands.c:71: undefined reference to `qmp_command_is_enabled' build/../../home/thuth/devel/qemu/qga/commands.c:72: undefined reference to `qmp_has_success_response' qga/qemu-ga.p/commands.c.o: In function `qmp_guest_info': build/../../home/thuth/devel/qemu/qga/commands.c:82: undefined reference to `qmp_for_each_command' qga/qemu-ga.p/commands.c.o: In function `qmp_guest_exec': build/../../home/thuth/devel/qemu/qga/commands.c:410: undefined reference to `qbase64_decode' qga/qemu-ga.p/channel-posix.c.o: In function `ga_channel_open': build/../../home/thuth/devel/qemu/qga/channel-posix.c:214: undefined reference to `unix_listen' build/../../home/thuth/devel/qemu/qga/channel-posix.c:228: undefined reference to `socket_parse' build/../../home/thuth/devel/qemu/qga/channel-posix.c:234: undefined reference to `socket_listen' qga/qemu-ga.p/commands-posix.c.o: In function `qmp_guest_file_write': build/../../home/thuth/devel/qemu/qga/commands-posix.c:527: undefined reference to `qbase64_decode'
Let's make sure that we also compile and link the required files if the system emulators have not been enabled.
Message-Id: <20221110083626.31899-1-thuth@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
Revision tags: v7.2.0, v7.2.0-rc4, v7.2.0-rc3, v7.2.0-rc2, v7.2.0-rc1 |
|
#
e0091133 |
| 10-Nov-2022 |
Thomas Huth <thuth@redhat.com> |
qga: Allow building of the guest agent without system emulators or tools
If configuring with "--disable-system --disable-user --enable-guest-agent" the linking currently fails with:
qga/qemu-ga.p/c
qga: Allow building of the guest agent without system emulators or tools
If configuring with "--disable-system --disable-user --enable-guest-agent" the linking currently fails with:
qga/qemu-ga.p/commands.c.o: In function `qmp_command_info': build/../../home/thuth/devel/qemu/qga/commands.c:70: undefined reference to `qmp_command_name' build/../../home/thuth/devel/qemu/qga/commands.c:71: undefined reference to `qmp_command_is_enabled' build/../../home/thuth/devel/qemu/qga/commands.c:72: undefined reference to `qmp_has_success_response' qga/qemu-ga.p/commands.c.o: In function `qmp_guest_info': build/../../home/thuth/devel/qemu/qga/commands.c:82: undefined reference to `qmp_for_each_command' qga/qemu-ga.p/commands.c.o: In function `qmp_guest_exec': build/../../home/thuth/devel/qemu/qga/commands.c:410: undefined reference to `qbase64_decode' qga/qemu-ga.p/channel-posix.c.o: In function `ga_channel_open': build/../../home/thuth/devel/qemu/qga/channel-posix.c:214: undefined reference to `unix_listen' build/../../home/thuth/devel/qemu/qga/channel-posix.c:228: undefined reference to `socket_parse' build/../../home/thuth/devel/qemu/qga/channel-posix.c:234: undefined reference to `socket_listen' qga/qemu-ga.p/commands-posix.c.o: In function `qmp_guest_file_write': build/../../home/thuth/devel/qemu/qga/commands-posix.c:527: undefined reference to `qbase64_decode'
Let's make sure that we also compile and link the required files if the system emulators have not been enabled.
Message-Id: <20221110083626.31899-1-thuth@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
show more ...
|
Revision tags: v7.2.0-rc0, v7.1.0, v7.1.0-rc4, v7.1.0-rc3 |
|
#
a5ebce38 |
| 11-Aug-2022 |
Laurent Vivier <lvivier@redhat.com> |
qmp: add QMP command x-query-virtio
This new command lists all the instances of VirtIODevices with their canonical QOM path and name.
[Jonah: @virtio_list duplicates information that already exists
qmp: add QMP command x-query-virtio
This new command lists all the instances of VirtIODevices with their canonical QOM path and name.
[Jonah: @virtio_list duplicates information that already exists in the QOM composition tree. However, extracting necessary information from this tree seems to be a bit convoluted.
Instead, we still create our own list of realized virtio devices but use @qmp_qom_get with the device's canonical QOM path to confirm that the device exists and is realized. If the device exists but is actually not realized, then we remove it from our list (for synchronicity to the QOM composition tree).
Also, the QMP command @x-query-virtio is redundant as @qom-list and @qom-get are sufficient to search '/machine/' for realized virtio devices. However, @x-query-virtio is much more convenient in listing realized virtio devices.]
Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Jonah Palmer <jonah.palmer@oracle.com> Message-Id: <1660220684-24909-2-git-send-email-jonah.palmer@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
Revision tags: v7.2.0-rc0, v7.1.0, v7.1.0-rc4, v7.1.0-rc3 |
|
#
a5ebce38 |
| 11-Aug-2022 |
Laurent Vivier <lvivier@redhat.com> |
qmp: add QMP command x-query-virtio
This new command lists all the instances of VirtIODevices with their canonical QOM path and name.
[Jonah: @virtio_list duplicates information that already exists
qmp: add QMP command x-query-virtio
This new command lists all the instances of VirtIODevices with their canonical QOM path and name.
[Jonah: @virtio_list duplicates information that already exists in the QOM composition tree. However, extracting necessary information from this tree seems to be a bit convoluted.
Instead, we still create our own list of realized virtio devices but use @qmp_qom_get with the device's canonical QOM path to confirm that the device exists and is realized. If the device exists but is actually not realized, then we remove it from our list (for synchronicity to the QOM composition tree).
Also, the QMP command @x-query-virtio is redundant as @qom-list and @qom-get are sufficient to search '/machine/' for realized virtio devices. However, @x-query-virtio is much more convenient in listing realized virtio devices.]
Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Jonah Palmer <jonah.palmer@oracle.com> Message-Id: <1660220684-24909-2-git-send-email-jonah.palmer@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
Revision tags: v7.2.0-rc0, v7.1.0, v7.1.0-rc4, v7.1.0-rc3 |
|
#
a5ebce38 |
| 11-Aug-2022 |
Laurent Vivier <lvivier@redhat.com> |
qmp: add QMP command x-query-virtio
This new command lists all the instances of VirtIODevices with their canonical QOM path and name.
[Jonah: @virtio_list duplicates information that already exists
qmp: add QMP command x-query-virtio
This new command lists all the instances of VirtIODevices with their canonical QOM path and name.
[Jonah: @virtio_list duplicates information that already exists in the QOM composition tree. However, extracting necessary information from this tree seems to be a bit convoluted.
Instead, we still create our own list of realized virtio devices but use @qmp_qom_get with the device's canonical QOM path to confirm that the device exists and is realized. If the device exists but is actually not realized, then we remove it from our list (for synchronicity to the QOM composition tree).
Also, the QMP command @x-query-virtio is redundant as @qom-list and @qom-get are sufficient to search '/machine/' for realized virtio devices. However, @x-query-virtio is much more convenient in listing realized virtio devices.]
Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Jonah Palmer <jonah.palmer@oracle.com> Message-Id: <1660220684-24909-2-git-send-email-jonah.palmer@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
Revision tags: v7.2.0-rc0, v7.1.0, v7.1.0-rc4, v7.1.0-rc3 |
|
#
a5ebce38 |
| 11-Aug-2022 |
Laurent Vivier <lvivier@redhat.com> |
qmp: add QMP command x-query-virtio
This new command lists all the instances of VirtIODevices with their canonical QOM path and name.
[Jonah: @virtio_list duplicates information that already exists
qmp: add QMP command x-query-virtio
This new command lists all the instances of VirtIODevices with their canonical QOM path and name.
[Jonah: @virtio_list duplicates information that already exists in the QOM composition tree. However, extracting necessary information from this tree seems to be a bit convoluted.
Instead, we still create our own list of realized virtio devices but use @qmp_qom_get with the device's canonical QOM path to confirm that the device exists and is realized. If the device exists but is actually not realized, then we remove it from our list (for synchronicity to the QOM composition tree).
Also, the QMP command @x-query-virtio is redundant as @qom-list and @qom-get are sufficient to search '/machine/' for realized virtio devices. However, @x-query-virtio is much more convenient in listing realized virtio devices.]
Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Jonah Palmer <jonah.palmer@oracle.com> Message-Id: <1660220684-24909-2-git-send-email-jonah.palmer@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
Revision tags: v7.2.0-rc0, v7.1.0, v7.1.0-rc4, v7.1.0-rc3 |
|
#
a5ebce38 |
| 11-Aug-2022 |
Laurent Vivier <lvivier@redhat.com> |
qmp: add QMP command x-query-virtio
This new command lists all the instances of VirtIODevices with their canonical QOM path and name.
[Jonah: @virtio_list duplicates information that already exists
qmp: add QMP command x-query-virtio
This new command lists all the instances of VirtIODevices with their canonical QOM path and name.
[Jonah: @virtio_list duplicates information that already exists in the QOM composition tree. However, extracting necessary information from this tree seems to be a bit convoluted.
Instead, we still create our own list of realized virtio devices but use @qmp_qom_get with the device's canonical QOM path to confirm that the device exists and is realized. If the device exists but is actually not realized, then we remove it from our list (for synchronicity to the QOM composition tree).
Also, the QMP command @x-query-virtio is redundant as @qom-list and @qom-get are sufficient to search '/machine/' for realized virtio devices. However, @x-query-virtio is much more convenient in listing realized virtio devices.]
Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Jonah Palmer <jonah.palmer@oracle.com> Message-Id: <1660220684-24909-2-git-send-email-jonah.palmer@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|