| 139fbddf | 05-Nov-2025 |
Richard Henderson <richard.henderson@linaro.org> |
qapi/migration: Rewrap to 70 columns
Avoid
In file included from ../publish/qapi/qapi-schema.json:53:
.../qapi/migration.json:1750:1: documentation line longer than 70 characters
Fixes: ae00f0088f
qapi/migration: Rewrap to 70 columns
Avoid
In file included from ../publish/qapi/qapi-schema.json:53:
.../qapi/migration.json:1750:1: documentation line longer than 70 characters
Fixes: ae00f0088ff ("migration/qmp: Update "resume" flag doc in "migrate" command")
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
show more ...
|
| e76ff1ee | 03-Nov-2025 |
Markus Armbruster <armbru@redhat.com> |
qapi: Refill doc comments to conform to conventions
Sweep the entire documentation again. Last done in commit
01bed0ff14b (qapi: Refill doc comments to conform to conventions).
To check the genera
qapi: Refill doc comments to conform to conventions
Sweep the entire documentation again. Last done in commit
01bed0ff14b (qapi: Refill doc comments to conform to conventions).
To check the generated documentation does not change, I compared the
generated HTML before and after this commit with "wdiff -3". Finds no
differences. Comparing with diff is not useful, as the reflown
paragraphs are visible there.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Message-ID: <20251103082354.3273027-3-armbru@redhat.com>
show more ...
|
| 7b842fe3 | 03-Nov-2025 |
Juraj Marcin <jmarcin@redhat.com> |
migration: Introduce POSTCOPY_DEVICE state
Currently, when postcopy starts, the source VM starts switchover and
sends a package containing the state of all non-postcopiable devices.
When the destina
migration: Introduce POSTCOPY_DEVICE state
Currently, when postcopy starts, the source VM starts switchover and
sends a package containing the state of all non-postcopiable devices.
When the destination loads this package, the switchover is complete and
the destination VM starts. However, if the device state load fails or
the destination side crashes, the source side is already in
POSTCOPY_ACTIVE state and cannot be recovered, even when it has the most
up-to-date machine state as the destination has not yet started.
This patch introduces a new POSTCOPY_DEVICE state which is active while
the destination machine is loading the device state, is not yet running,
and the source side can be resumed in case of a migration failure.
Return-path is required for this state to function, otherwise it will be
skipped in favor of POSTCOPY_ACTIVE.
To transition from POSTCOPY_DEVICE to POSTCOPY_ACTIVE, the source
side uses a PONG message that is a response to a PING message processed
just before the POSTCOPY_RUN command that starts the destination VM.
Thus, this feature is effective even if the destination side does not
yet support this new state.
Signed-off-by: Juraj Marcin <jmarcin@redhat.com>
Link: https://lore.kernel.org/r/20251103183301.3840862-9-jmarcin@redhat.com
Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
| 015051a2 | 24-Sep-2025 |
Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> |
net/stream: remove deprecated 'reconnect' option
It was deprecated in 9.2, time to remove.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Reviewed-by: Daniil Tatianin <d-ta
net/stream: remove deprecated 'reconnect' option
It was deprecated in 9.2, time to remove.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Reviewed-by: Daniil Tatianin <d-tatianin@yandex-team.ru>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
show more ...
|
| 71d5babb | 13-Oct-2025 |
Paolo Bonzini <pbonzini@redhat.com> |
monitor: generalize query-mshv/"info mshv" to query-accelerators/"info accelerators"
The recently-introduced query-mshv command is a duplicate of query-kvm,
and neither provides a full view of which
monitor: generalize query-mshv/"info mshv" to query-accelerators/"info accelerators"
The recently-introduced query-mshv command is a duplicate of query-kvm,
and neither provides a full view of which accelerators are supported
by a particular binary of QEMU and which is in use.
KVM was the first accelerator added to QEMU, predating QOM and TYPE_ACCEL,
so it got a pass. But now, instead of adding a badly designed copy, solve
the problem completely for all accelerators with a command that provides
the whole picture:
>> {"execute": "query-accelerators"}
<< {"return": {"enabled": "tcg", "present": ["kvm", "mshv", "qtest", "tcg", "xen"]}}
Cc: Praveen K Paladugu <prapal@microsoft.com>
Cc: Magnus Kulke <magnuskulke@linux.microsoft.com>
Suggested-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
| ddd8f3ba | 23-Sep-2025 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
qapi/acpi-hest: add an interface to do generic CPER error injection
Create a QMP command to be used for generic ACPI APEI hardware error
injection (HEST) via GHESv2, and add support for it for ARM g
qapi/acpi-hest: add an interface to do generic CPER error injection
Create a QMP command to be used for generic ACPI APEI hardware error
injection (HEST) via GHESv2, and add support for it for ARM guests.
Error injection uses ACPI_HEST_SRC_ID_QMP source ID to be platform
independent. This is mapped at arch virt bindings, depending on the
types supported by QEMU and by the BIOS. So, on ARM, this is supported
via ACPI_GHES_NOTIFY_GPIO notification type.
This patch was co-authored:
- original ghes logic to inject a simple ARM record by Shiju Jose;
- generic logic to handle block addresses by Jonathan Cameron;
- generic GHESv2 error inject by Mauro Carvalho Chehab;
Co-authored-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Co-authored-by: Shiju Jose <shiju.jose@huawei.com>
Co-authored-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Shiju Jose <shiju.jose@huawei.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Acked-by: Igor Mammedov <imammedo@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <81e2118b3c8b7e5da341817f277d61251655e0db.1758610789.git.mchehab+huawei@kernel.org>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
| a3eae205 | 01-Oct-2025 |
Steve Sistare <steven.sistare@oracle.com> |
migration: cpr-exec mode
Add the cpr-exec migration mode. Usage:
qemu-system-$arch -machine aux-ram-share=on ...
migrate_set_parameter mode cpr-exec
migrate_set_parameter cpr-exec-command \
migration: cpr-exec mode
Add the cpr-exec migration mode. Usage:
qemu-system-$arch -machine aux-ram-share=on ...
migrate_set_parameter mode cpr-exec
migrate_set_parameter cpr-exec-command \
<arg1> <arg2> ... -incoming <uri-1> \
migrate -d <uri-1>
The migrate command stops the VM, saves state to uri-1,
directly exec's a new version of QEMU on the same host,
replacing the original process while retaining its PID, and
loads state from uri-1. Guest RAM is preserved in place,
albeit with new virtual addresses.
The new QEMU process is started by exec'ing the command
specified by the @cpr-exec-command parameter. The first word of
the command is the binary, and the remaining words are its
arguments. The command may be a direct invocation of new QEMU,
or may be a non-QEMU command that exec's the new QEMU binary.
This mode creates a second migration channel that is not visible
to the user. At the start of migration, old QEMU saves CPR state
to the second channel, and at the end of migration, it tells the
main loop to call cpr_exec. New QEMU loads CPR state early, before
objects are created.
Because old QEMU terminates when new QEMU starts, one cannot
stream data between the two, so uri-1 must be a type,
such as a file, that accepts all data before old QEMU exits.
Otherwise, old QEMU may quietly block writing to the channel.
Memory-backend objects must have the share=on attribute, but
memory-backend-epc is not supported. The VM must be started with
the '-machine aux-ram-share=on' option, which allows anonymous
memory to be transferred in place to the new process. The memfds
are kept open across exec by clearing the close-on-exec flag, their
values are saved in CPR state, and they are mmap'd in new QEMU.
Signed-off-by: Steve Sistare <steven.sistare@oracle.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Link: https://lore.kernel.org/r/1759332851-370353-7-git-send-email-steven.sistare@oracle.com
Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|
| 4af976ef | 11-Aug-2025 |
Kevin Wolf <kwolf@redhat.com> |
rbd: Fix .bdrv_get_specific_info implementation
qemu_rbd_get_specific_info() has at least two problems:
The first is that it issues a blocking rbd_read() call in order to probe
the encryption forma
rbd: Fix .bdrv_get_specific_info implementation
qemu_rbd_get_specific_info() has at least two problems:
The first is that it issues a blocking rbd_read() call in order to probe
the encryption format for the image while querying the node. This means
that if the connection to the server goes down, not only I/O is stuck
(which is unavoidable), but query-names-block-nodes will actually make
the whole QEMU instance unresponsive. .bdrv_get_specific_info
implementations shouldn't perform blocking operations, but only return
what is already known.
The second is that the information returned isn't even correct. If the
image is already opened with encryption enabled at the RBD level, we'll
probe for "double encryption", i.e. if the encrypted data contains
another encryption header. If it doesn't (which is the normal case), we
won't return the encryption format. If it does, we return misleading
information because it looks like we're talking about the outer level
(the encryption format of the image itself) while the information is
about an encryption header in the guest data.
Fix this by storing the encryption format in BDRVRBDState when the image
is opened (and we do blocking operations anyway) and returning only the
stored information in qemu_rbd_get_specific_info().
The information we'll store is either the actual encryption format that
we enabled on the RBD level, or if the image is unencrypted, the result
of the same probing as we previously did when querying the node. Probing
image formats based on content that can be modified by the guest has
long been known as problematic, but as long as we only output it to the
user instead of making decisions based on it, it should be okay. It is
undoubtedly useful in the context of 'qemu-img info' when you're trying
to figure out which encryption options you have to use to open the
image successfully.
Fixes: 42e4ac9ef5a6 ("block/rbd: Add support for rbd image encryption")
Buglink: https://issues.redhat.com/browse/RHEL-105440
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20250811134010.81787-1-kwolf@redhat.com>
Reviewed-by: Hanna Czenczek <hreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
show more ...
|
| a3004697 | 24-Jul-2025 |
Markus Armbruster <armbru@redhat.com> |
qapi/accelerator: Fix markup of heading
The docs generated for qapi/accelerator.json shows text "=
Accelerators" instead of a heading. This is because the patch that
added the heading crossed with
qapi/accelerator: Fix markup of heading
The docs generated for qapi/accelerator.json shows text "=
Accelerators" instead of a heading. This is because the patch that
added the heading crossed with the commit that changed heading
markup (commit 6c10778826a "docs/sphinx: remove special parsing for
freeform sections"). Fix the markup.
Fixes: 18da42ee4273 (qapi/accel: Move definitions related to accelerators in their own file)
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20250724091742.1950167-2-armbru@redhat.com>
show more ...
|