| a8e1ea4c | 09-Aug-2024 |
Eric Blake <eblake@redhat.com> |
docs: Typo fix in live disk backup
Add in the missing space in the section header.
Fixes: 1084159b31 ("qapi: deprecate drive-backup", v6.2.0)
Signed-off-by: Eric Blake <eblake@redhat.com>
Signed-of
docs: Typo fix in live disk backup
Add in the missing space in the section header.
Fixes: 1084159b31 ("qapi: deprecate drive-backup", v6.2.0)
Signed-off-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
show more ...
|
| 09334420 | 09-Aug-2024 |
Peter Maydell <peter.maydell@linaro.org> |
docs/interop/prl-xml.rst: Fix minor grammar nits
Fix some minor grammar nits in the prl-xml documentation.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <ri
docs/interop/prl-xml.rst: Fix minor grammar nits
Fix some minor grammar nits in the prl-xml documentation.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20240801170131.3977807-6-peter.maydell@linaro.org
show more ...
|
| 7d9fc7e7 | 09-Aug-2024 |
Peter Maydell <peter.maydell@linaro.org> |
docs/interop/prl-xml.txt: Convert to rST
Convert prl-xml.txt to rST format.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Rev
docs/interop/prl-xml.txt: Convert to rST
Convert prl-xml.txt to rST format.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20240801170131.3977807-5-peter.maydell@linaro.org
show more ...
|
| 1bc0fc0a | 09-Aug-2024 |
Peter Maydell <peter.maydell@linaro.org> |
docs/interop/parallels.txt: Convert to rST
Convert parallels.txt to rST format.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
docs/interop/parallels.txt: Convert to rST
Convert parallels.txt to rST format.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20240801170131.3977807-4-peter.maydell@linaro.org
show more ...
|
| 16c84ec1 | 19-Jul-2024 |
Thomas Weißschuh <thomas.weissschuh@linutronix.de> |
docs/interop/firmware.json: convert "Example" section
Since commit 3c5f6114d9ff ("qapi: remove "Example" doc section")
the "Example" section is not valid anymore.
It has been replaced by the "qmp-ex
docs/interop/firmware.json: convert "Example" section
Since commit 3c5f6114d9ff ("qapi: remove "Example" doc section")
the "Example" section is not valid anymore.
It has been replaced by the "qmp-example" directive.
This was not detected earlier as firmware.json was not validated.
As this validation is about to be added, adapt firmware.json.
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Message-ID: <20240719-qapi-firmware-json-v6-3-c2e3de390b58@linutronix.de>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
show more ...
|
| d5d0070b | 19-Jul-2024 |
Thomas Weißschuh <thomas.weissschuh@linutronix.de> |
docs/interop/firmware.json: add new enum FirmwareArchitecture
Only a small subset of all architectures supported by qemu make use of
firmware files. Introduce and use a new enum to represent this.
docs/interop/firmware.json: add new enum FirmwareArchitecture
Only a small subset of all architectures supported by qemu make use of
firmware files. Introduce and use a new enum to represent this.
This also removes the dependency to machine.json from the global qapi
definitions.
Claim "Since: 3.0" for the new enum, because that's correct for most of
its members, and the members are what matters in the interface.
Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20240719-qapi-firmware-json-v6-2-c2e3de390b58@linutronix.de>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
show more ...
|
| ce226161 | 18-Jul-2024 |
Thomas Lamprecht <t.lamprecht@proxmox.com> |
guest-agent: document allow-rpcs in config file section
While the `allow-rpcs` option is documented in the CLI options
section, it was missing in the section about the configuration file
syntax.
An
guest-agent: document allow-rpcs in config file section
While the `allow-rpcs` option is documented in the CLI options
section, it was missing in the section about the configuration file
syntax.
And while it's mentioned that "the list of keys follows the command line
options", having `block-rpcs` there but not `allow-rpcs` seems like
being a potential source of confusion; and as it's cheap to add let's
just do so.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Reviewed-by: Konstantin Kostiuk <kkostiuk@redhat.com>
Message-ID: <20240718140407.444160-1-t.lamprecht@proxmox.com>
Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com>
show more ...
|
| 2e3b166c | 12-Jul-2024 |
Daniel P. Berrangé <berrange@redhat.com> |
qga: centralize logic for disabling/enabling commands
It is confusing having many different pieces of code enabling and
disabling commands, and it is not clear that they all have the same
semantics,
qga: centralize logic for disabling/enabling commands
It is confusing having many different pieces of code enabling and
disabling commands, and it is not clear that they all have the same
semantics, especially wrt prioritization of the block/allow lists.
The code attempted to prevent the user from setting both the block
and allow lists concurrently, however, the logic was flawed as it
checked settings in the configuration file separately from the
command line arguments. Thus it was possible to set a block list
in the config file and an allow list via a command line argument.
The --dump-conf option also creates a configuration file with both
keys present, even if unset, which means it is creating a config
that cannot actually be loaded again.
Centralizing the code in a single method "ga_apply_command_filters"
will provide a strong guarantee of consistency and clarify the
intended behaviour. With this there is no compelling technical
reason to prevent concurrent setting of both the allow and block
lists, so this flawed restriction is removed.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Konstantin Kostiuk <kkostiuk@redhat.com>
Message-ID: <20240712132459.3974109-23-berrange@redhat.com>
Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com>
show more ...
|
| 56fa4f34 | 07-Mar-2024 |
Thomas Weißschuh <thomas.weissschuh@linutronix.de> |
docs/interop/firmware.json: Fix doc for FirmwareFlashMode
The doc title did not match the actual definition.
Fixes: 2720ceda05 ("docs: expand firmware descriptor to allow flash without NVRAM")
Sign
docs/interop/firmware.json: Fix doc for FirmwareFlashMode
The doc title did not match the actual definition.
Fixes: 2720ceda05 ("docs: expand firmware descriptor to allow flash without NVRAM")
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20240307-qapi-firmware-json-v2-2-3b29eabb9b9a@linutronix.de>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
show more ...
|
| 01923309 | 16-Oct-2023 |
Hanna Czenczek <hreitz@redhat.com> |
vhost-user.rst: Migrating back-end-internal state
For vhost-user devices, qemu can migrate the virtio state, but not the
back-end's internal state. To do so, we need to be able to transfer
this int
vhost-user.rst: Migrating back-end-internal state
For vhost-user devices, qemu can migrate the virtio state, but not the
back-end's internal state. To do so, we need to be able to transfer
this internal state between front-end (qemu) and back-end.
At this point, this new feature is added for the purpose of virtio-fs
migration. Because virtiofsd's internal state will not be too large, we
believe it is best to transfer it as a single binary blob after the
streaming phase.
These are the additions to the protocol:
- New vhost-user protocol feature VHOST_USER_PROTOCOL_F_DEVICE_STATE
- SET_DEVICE_STATE_FD function: Front-end and back-end negotiate a file
descriptor over which to transfer the state.
- CHECK_DEVICE_STATE: After the state has been transferred through the
file descriptor, the front-end invokes this function to verify
success. There is no in-band way (through the file descriptor) to
indicate failure, so we need to check explicitly.
Once the transfer FD has been established via SET_DEVICE_STATE_FD
(which includes establishing the direction of transfer and migration
phase), the sending side writes its data into it, and the reading side
reads it until it sees an EOF. Then, the front-end will check for
success via CHECK_DEVICE_STATE, which on the destination side includes
checking for integrity (i.e. errors during deserialization).
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-Id: <20231016134243.68248-5-hreitz@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
| a6e76dd3 | 16-Oct-2023 |
Hanna Czenczek <hreitz@redhat.com> |
vhost-user.rst: Introduce suspended state
In vDPA, GET_VRING_BASE does not stop the queried vring, which is why
SUSPEND was introduced so that the returned index would be stable. In
vhost-user, it
vhost-user.rst: Introduce suspended state
In vDPA, GET_VRING_BASE does not stop the queried vring, which is why
SUSPEND was introduced so that the returned index would be stable. In
vhost-user, it does stop the vring, so under the same reasoning, it can
get away without SUSPEND.
Still, we do want to clarify that if the device is completely stopped,
i.e. all vrings are stopped, the back-end should cease to modify any
state relating to the guest. Do this by calling it "suspended".
Suggested-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-Id: <20231016134243.68248-4-hreitz@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
| eae69cc3 | 16-Oct-2023 |
Hanna Czenczek <hreitz@redhat.com> |
vhost-user.rst: Clarify enabling/disabling vrings
Currently, the vhost-user documentation says that rings are to be
initialized in a disabled state when VHOST_USER_F_PROTOCOL_FEATURES is
negotiated.
vhost-user.rst: Clarify enabling/disabling vrings
Currently, the vhost-user documentation says that rings are to be
initialized in a disabled state when VHOST_USER_F_PROTOCOL_FEATURES is
negotiated. However, by the time of feature negotiation, all rings have
already been initialized, so it is not entirely clear what this means.
At least the vhost-user-backend Rust crate's implementation interpreted
it to mean that whenever this feature is negotiated, all rings are to
put into a disabled state, which means that every SET_FEATURES call
would disable all rings, effectively halting the device. This is
problematic because the VHOST_F_LOG_ALL feature is also set or cleared
this way, which happens during migration. Doing so should not halt the
device.
Other implementations have interpreted this to mean that the device is
to be initialized with all rings disabled, and a subsequent SET_FEATURES
call that does not set VHOST_USER_F_PROTOCOL_FEATURES will enable all of
them. Here, SET_FEATURES will never disable any ring.
This interpretation does not suffer the problem of unintentionally
halting the device whenever features are set or cleared, so it seems
better and more reasonable.
We can clarify this in the documentation by making it explicit that the
enabled/disabled state is tracked even while the vring is stopped.
Every vring is initialized in a disabled state, and SET_FEATURES without
VHOST_USER_F_PROTOCOL_FEATURES simply becomes one way to enable all
vrings.
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-Id: <20231016134243.68248-3-hreitz@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|