| 3348e7e3 | 23-Jan-2020 |
Johannes Berg <johannes.berg@intel.com> |
docs: vhost-user: add in-band kick/call messages
For good reason, vhost-user is currently built asynchronously, that way better performance can be obtained. However, for certain use cases such as si
docs: vhost-user: add in-band kick/call messages
For good reason, vhost-user is currently built asynchronously, that way better performance can be obtained. However, for certain use cases such as simulation, this is problematic.
Consider an event-based simulation in which both the device and CPU have scheduled according to a simulation "calendar". Now, consider the CPU sending I/O to the device, over a vring in the vhost-user protocol. In this case, the CPU must wait for the vring interrupt to have been processed by the device, so that the device is able to put an entry onto the simulation calendar to obtain time to handle the interrupt. Note that this doesn't mean the I/O is actually done at this time, it just means that the handling of it is scheduled before the CPU can continue running.
This cannot be done with the asynchronous eventfd based vring kick and call design.
Extend the protocol slightly, so that a message can be used for kick and call instead, if VHOST_USER_PROTOCOL_F_INBAND_NOTIFICATIONS is negotiated. This in itself doesn't guarantee synchronisation, but both sides can also negotiate VHOST_USER_PROTOCOL_F_REPLY_ACK and thus get a reply to this message by setting the need_reply flag, and ensure synchronisation this way.
To really use it in both directions, VHOST_USER_PROTOCOL_F_SLAVE_REQ is also needed.
Since it is used for simulation purposes and too many messages on the socket can lock up the virtual machine, document that this should only be used together with the mentioned features.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Message-Id: <20200123081708.7817-6-johannes@sipsolutions.net> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
| 168468fe | 05-Feb-2020 |
David Edmondson <david.edmondson@oracle.com> |
qemu-img: Add --target-is-zero to convert
In many cases the target of a convert operation is a newly provisioned target that the user knows is blank (reads as zero). In this situation there is no re
qemu-img: Add --target-is-zero to convert
In many cases the target of a convert operation is a newly provisioned target that the user knows is blank (reads as zero). In this situation there is no requirement for qemu-img to wastefully zero out the entire device.
Add a new option, --target-is-zero, allowing the user to indicate that an existing target device will return zeros for all reads.
Signed-off-by: David Edmondson <david.edmondson@oracle.com> Message-Id: <20200205110248.2009589-2-david.edmondson@oracle.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
show more ...
|
| 66fcbca5 | 31-Jan-2020 |
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> |
docs: qcow2: introduce compression type feature
The patch adds a new additional field to the qcow2 header: compression_type, which specifies compression type. If field is absent or zero, default com
docs: qcow2: introduce compression type feature
The patch adds a new additional field to the qcow2 header: compression_type, which specifies compression type. If field is absent or zero, default compression type is set: ZLIB, which corresponds to current behavior.
New compression type (ZSTD) is to be added in further commit.
Suggested-by: Denis Plotnikov <dplotnikov@virtuozzo.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20200131142219.3264-3-vsementsov@virtuozzo.com> [mreitz: s/Bits 3-63: Reserved/Bits 4-63: Reserved/] Signed-off-by: Max Reitz <mreitz@redhat.com>
show more ...
|
| 78813586 | 24-Jan-2020 |
Peter Maydell <peter.maydell@linaro.org> |
virtfs-proxy-helper: Convert documentation to rST
The virtfs-proxy-helper documentation is currently in fsdev/qemu-trace-stap.texi in Texinfo format, which we present to the user as: * a virtfs-pro
virtfs-proxy-helper: Convert documentation to rST
The virtfs-proxy-helper documentation is currently in fsdev/qemu-trace-stap.texi in Texinfo format, which we present to the user as: * a virtfs-proxy-helper manpage * but not (unusually for QEMU) part of the HTML docs
Convert the documentation to rST format that lives in the docs/ subdirectory, and present it to the user as: * a virtfs-proxy-helper manpage * part of the interop/ Sphinx manual
There are minor formatting changes to suit Sphinx, but no content changes. In particular I've split the -u and -g options into each having their own description text.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Greg Kurz <groug@kaod.org> Message-id: 20200124162606.8787-9-peter.maydell@linaro.org
show more ...
|
| 605ffebb | 24-Jan-2020 |
Peter Maydell <peter.maydell@linaro.org> |
scripts/qemu-trace-stap: Convert documentation to rST
The qemu-trace-stap documentation is currently in scripts/qemu-trace-stap.texi in Texinfo format, which we present to the user as: * a qemu-tra
scripts/qemu-trace-stap: Convert documentation to rST
The qemu-trace-stap documentation is currently in scripts/qemu-trace-stap.texi in Texinfo format, which we present to the user as: * a qemu-trace-stap manpage * but not (unusually for QEMU) part of the HTML docs
Convert the documentation to rST format that lives in the docs/ subdirectory, and present it to the user as: * a qemu-trace-stap manpage * part of the interop/ Sphinx manual
There are minor formatting changes to suit Sphinx, but no content changes.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20200124162606.8787-8-peter.maydell@linaro.org
show more ...
|
| 5010cec2 | 16-Dec-2019 |
Marc-André Lureau <marcandre.lureau@redhat.com> |
Add dbus-vmstate object
When instantiated, this object will connect to the given D-Bus bus "addr". During migration, it will take/restore the data from org.qemu.VMState1 instances. See documentation
Add dbus-vmstate object
When instantiated, this object will connect to the given D-Bus bus "addr". During migration, it will take/restore the data from org.qemu.VMState1 instances. See documentation for details.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
show more ...
|