* Greg Kurz steps back as maintainer of 9pfs.
* Make multidevs=remap default option (instead of multidevs=warn)
and update documentation related to this option.
* Improve tracing (i.e. usefulness of log output content).
-----BEGIN PGP SIGNATURE-----
iQJLBAABCgA1FiEEltjREM96+AhPiFkBNMK1h2Wkc5UFAmel2AEXHHFlbXVfb3Nz
QGNydWRlYnl0ZS5jb20ACgkQNMK1h2Wkc5UOuw//YMqU1N1JV7ppHMOKgu9GBSPI
xFS5fhGHQd0b2DhXlX0m0vlwCN5m7up7Q1NwkgXzfaIV3wdU8XH1DgMXonjQdBaT
ipIGdCR9aeGCUlFjlkQCEUVooDAuyU2zqIpfzvX7eCUFI96S2DI+jjmSqOhlJSsz
yJnTJOK0LuoMpaFDxHJiEuTfoMycUWT78hTHRE8h/UWfTcKrzz5uIajq05bA1QLd
XRtMa2k8ZWZf+uOcky3Qq/g5UHCc9LUidnVvTBejRQeEeE+qhLX9CzTUF+elNRiF
BKPjQLfdyTMeleOj3KWxAkIV0GP4LA5naEi7Li56Kx/qOSySOnlbfUR0rXm1L58t
yJdtavJEXFiRDa1BPvZeuDEGbSf229gOvQtD9yhURtw9XtdhZ8WuX7edes9/S5xz
nc0slBD4UMkUL0VqD5LX4nwW/IJbUGD/sgqg1sMMXC+cSptPWCTQjf56VGZHg0Kf
oasIe2pKyOu0NEIpxpolu+AGlgGsOHgEknBdG5GJ/dFzKb+9sukVEFxzZP/eRQjp
d7ShWkn1o96vMgReFaYIXboVXNdeePDjfvLLD8+xKp3KEvidGEQs1PGPWyU0juIT
2en3PwZfYvm3Wfys3dAl7g1XJOzFM177SHKYKbEEeziIeRNN5oTjPxAIu0+M2yVK
y2Khd01ZJQBGhiYYgVw=
=Tr40
-----END PGP SIGNATURE-----
Merge tag 'pull-9p-20250207' of https://github.com/cschoenebeck/qemu into staging
9pfs changes:
* Greg Kurz steps back as maintainer of 9pfs.
* Make multidevs=remap default option (instead of multidevs=warn)
and update documentation related to this option.
* Improve tracing (i.e. usefulness of log output content).
# -----BEGIN PGP SIGNATURE-----
#
# iQJLBAABCgA1FiEEltjREM96+AhPiFkBNMK1h2Wkc5UFAmel2AEXHHFlbXVfb3Nz
# QGNydWRlYnl0ZS5jb20ACgkQNMK1h2Wkc5UOuw//YMqU1N1JV7ppHMOKgu9GBSPI
# xFS5fhGHQd0b2DhXlX0m0vlwCN5m7up7Q1NwkgXzfaIV3wdU8XH1DgMXonjQdBaT
# ipIGdCR9aeGCUlFjlkQCEUVooDAuyU2zqIpfzvX7eCUFI96S2DI+jjmSqOhlJSsz
# yJnTJOK0LuoMpaFDxHJiEuTfoMycUWT78hTHRE8h/UWfTcKrzz5uIajq05bA1QLd
# XRtMa2k8ZWZf+uOcky3Qq/g5UHCc9LUidnVvTBejRQeEeE+qhLX9CzTUF+elNRiF
# BKPjQLfdyTMeleOj3KWxAkIV0GP4LA5naEi7Li56Kx/qOSySOnlbfUR0rXm1L58t
# yJdtavJEXFiRDa1BPvZeuDEGbSf229gOvQtD9yhURtw9XtdhZ8WuX7edes9/S5xz
# nc0slBD4UMkUL0VqD5LX4nwW/IJbUGD/sgqg1sMMXC+cSptPWCTQjf56VGZHg0Kf
# oasIe2pKyOu0NEIpxpolu+AGlgGsOHgEknBdG5GJ/dFzKb+9sukVEFxzZP/eRQjp
# d7ShWkn1o96vMgReFaYIXboVXNdeePDjfvLLD8+xKp3KEvidGEQs1PGPWyU0juIT
# 2en3PwZfYvm3Wfys3dAl7g1XJOzFM177SHKYKbEEeziIeRNN5oTjPxAIu0+M2yVK
# y2Khd01ZJQBGhiYYgVw=
# =Tr40
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 07 Feb 2025 04:53:05 EST
# gpg: using RSA key 96D8D110CF7AF8084F88590134C2B58765A47395
# gpg: issuer "qemu_oss@crudebyte.com"
# gpg: Good signature from "Christian Schoenebeck <qemu_oss@crudebyte.com>" [unknown]
# gpg: WARNING: The key's User ID is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: ECAB 1A45 4014 1413 BA38 4926 30DB 47C3 A012 D5F4
# Subkey fingerprint: 96D8 D110 CF7A F808 4F88 5901 34C2 B587 65A4 7395
* tag 'pull-9p-20250207' of https://github.com/cschoenebeck/qemu:
MAINTAINERS: Mark me as reviewer only for 9pfs
9pfs: improve v9fs_open() tracing
9pfs: make multidevs=remap default
9pfs: improve v9fs_walk() tracing
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
I still review 9pfs changes from time to time but I'm definitely
not able to do actual maintainer work. Drop my tree on the way
as I'll obviously not use it anymore, and it has been left
untouched since May 2020.
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <20250115100849.259612-1-groug@kaod.org>
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Some items of Cargo.toml (readme, homepage, repository) are
only present because of clippy::cargo warnings being enabled in
rust/hw/char/pl011/src/lib.rs. But these items are not
particularly useful and would be all the same for all Cargo.toml
files in the QEMU workspace. Clean them up.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Without it, recent bindgen will give an error
error: extern block cannot be declared unsafe
if rustc is not new enough to support the "unsafe extern" construct.
Cc: qemu-rust@nongnu.org
Cc: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20250206111514.2134895-1-pbonzini@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Improve tracing of 9p 'Topen' request type by showing open() flags as
human-readable text.
E.g. trace output:
v9fs_open tag 0 id 12 fid 2 mode 100352
would become:
v9fs_open tag=0 id=12 fid=2 mode=100352(RDONLY|NONBLOCK|DIRECTORY|
TMPFILE|NDELAY)
Therefor add a new utility function qemu_open_flags_tostr() that converts
numeric open() flags from host's native O_* flag constants to a string
presentation.
9p2000.L and 9p2000.u protocol variants use different numeric 'mode'
constants for 'Topen' requests. Instead of writing string conversion code
for both protocol variants, use the already existing conversion functions
that convert the mode flags from respective protocol constants to host's
native open() numeric flag constants and pass that result to the new
string conversion function qemu_open_flags_tostr().
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <E1tTgDR-000oRr-9g@kylie.crudebyte.com>
1a6ed33cc5 introduced option multidevs=remap|forbid|warn and made
"warn" the default option.
As it turned out though, e.g. by several reports in conjunction with
following 9p client issue:
850925a813
Many people are just ignoring this warning, or even do not notice the
warning at all. Therefore make multidevs=remap the new default option to
prevent people to run into such kind of severe misbehaviours in the first
place.
From performance PoV the runtime overhead of multidevs=remap is
neglectable with few or even just only one device being shared with the
same 9p export, expected to be constant Theta(1). The inode numbers
emitted to guest also just loose one bit (since 6b6aa8285d) for the 1st
device being shared.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <09cc84e5561f66b6a8cf49b3532c6c78a6acc806.1734876877.git.qemu_oss@crudebyte.com>
'Twalk' is the most important request type in the 9p protocol to look out
for when debugging 9p communication. That's because it is the only part
of the 9p protocol which actually deals with human-readable path names,
whereas all other 9p request types work on numeric file IDs (FIDs) only.
Improve tracing of 'Twalk' requests, e.g. let's say client wanted to walk
to "/home/bob/src", then improve trace output from:
v9fs_walk tag 0 id 110 fid 0 newfid 1 nwnames 3
to:
v9fs_walk tag=0 id=110 fid=0 newfid=1 nwnames=3 wnames={home, bob, src}
To achieve this, add a new helper function trace_v9fs_walk_wnames() which
converts the received V9fsString array of individual path elements into a
comma-separated string presentation for being passed to the tracing system.
As this conversion is somewhat expensive, this conversion function is only
called if tracing of event 'v9fs_walk' is currently enabled.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <E1tJamT-007Cqk-9E@kylie.crudebyte.com>
BLOCK_OP_TYPE_DATAPLANE prevents BlockDriverState from being used by
virtio-blk/virtio-scsi with IOThread. Commit b112a65c52 ("block:
declare blockjobs and dataplane friends!") eliminated the main reason
for this blocker in 2014.
Nowadays the block layer supports I/O from multiple AioContexts, so
there is even less reason to block IOThread users. Any legitimate
reasons related to interference would probably also apply to
non-IOThread users.
The only remaining users are bdrv_op_unblock(BLOCK_OP_TYPE_DATAPLANE)
calls after bdrv_op_block_all(). If we remove BLOCK_OP_TYPE_DATAPLANE
their behavior doesn't change.
Existing bdrv_op_block_all() callers that don't explicitly unblock
BLOCK_OP_TYPE_DATAPLANE seem to do so simply because no one bothered to
rather than because it is necessary to keep BLOCK_OP_TYPE_DATAPLANE
blocked.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20250203182529.269066-1-stefanha@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
This tests different types of operations on inactive block nodes
(including graph changes, block jobs and NBD exports) to make sure that
users manually activating and inactivating nodes doesn't break things.
Support for inactive nodes in other export types will have to come with
separate test cases because they have different dependencies like blkio
or root permissions and we don't want to disable this basic test when
they are not fulfilled.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Acked-by: Fabiano Rosas <farosas@suse.de>
Message-ID: <20250204211407.381505-17-kwolf@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Test that it's possible to migrate a VM that uses an image on shared
storage through qemu-storage-daemon.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Acked-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-ID: <20250204211407.381505-16-kwolf@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
The open-coded form of this filter has been copied into enough tests
that it's better to move it into iotests.py.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Acked-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-ID: <20250204211407.381505-15-kwolf@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
In order to support running an NBD export on inactive nodes, we must
make sure to return errors for any operations that aren't allowed on
inactive nodes. Reads are the only operation we know we need for
inactive images, so to err on the side of caution, return errors for
everything else, even if some operations could possibly be okay.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Acked-by: Fabiano Rosas <farosas@suse.de>
Message-ID: <20250204211407.381505-14-kwolf@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Add an option in BlockExportOptions to allow creating an export on an
inactive node without activating the node. This mode needs to be
explicitly supported by the export type (so that it doesn't perform any
operations that are forbidden for inactive nodes), so this patch alone
doesn't allow this option to be successfully used yet.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Acked-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20250204211407.381505-13-kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
So far the assumption has always been that if we try to inactivate a
node, it is already idle. This doesn't hold true any more if we allow
inactivating exported nodes because we can't know when new external
requests come in.
Drain the node around setting BDRV_O_INACTIVE so that requests can't
start operating on an active node and then in the middle it suddenly
becomes inactive. With this change, it's enough for exports to check
for new requests that they operate on an active node (or, like reads,
are allowed even on an inactive node).
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Acked-by: Fabiano Rosas <farosas@suse.de>
Message-ID: <20250204211407.381505-12-kwolf@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Currently, block exports can't handle inactive images correctly.
Incoming write requests would run into assertion failures. Make sure
that we return an error when creating an export can't activate the
image.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Acked-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20250204211407.381505-11-kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Device models have a relatively complex way to set up their block
backends, in which blk_attach_dev() sets blk->disable_perm = true.
We want to support inactive images in exports, too, so that
qemu-storage-daemon can be used with migration. Because they don't use
blk_attach_dev(), they need another way to set this flag. The most
convenient is to do this automatically when an inactive node is attached
to a BlockBackend that can be inactivated.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Acked-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20250204211407.381505-10-kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
The system emulator tries to automatically activate and inactivate block
nodes at the right point during migration. However, there are still
cases where it's necessary that the user can do this manually.
Images are only activated on the destination VM of a migration when the
VM is actually resumed. If the VM was paused, this doesn't happen
automatically. The user may want to perform some operation on a block
device (e.g. taking a snapshot or starting a block job) without also
resuming the VM yet. This is an example where a manual command is
necessary.
Another example is VM migration when the image files are opened by an
external qemu-storage-daemon instance on each side. In this case, the
process that needs to hand over the images isn't even part of the
migration and can't know when the migration completes. Management tools
need a way to explicitly inactivate images on the source and activate
them on the destination.
This adds a new blockdev-set-active QMP command that lets the user
change the status of individual nodes (this is necessary in
qemu-storage-daemon because it could be serving multiple VMs and only
one of them migrates at a time). For convenience, operating on all
devices (like QEMU does automatically during migration) is offered as an
option, too, and can be used in the context of single VM.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Acked-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20250204211407.381505-9-kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
In QEMU, nodes are automatically created inactive while expecting an
incoming migration (i.e. RUN_STATE_INMIGRATE). In qemu-storage-daemon,
the notion of runstates doesn't exist. It also wouldn't necessarily make
sense to introduce it because a single daemon can serve multiple VMs
that can be in different states.
Therefore, allow the user to explicitly open images as inactive with a
new option. The default is as before: Nodes are usually active, except
when created during RUN_STATE_INMIGRATE.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Acked-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20250204211407.381505-8-kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
In order for block_resize to fail gracefully on an inactive node instead
of crashing with an assertion failure in bdrv_co_write_req_prepare()
(called from bdrv_co_truncate()), we need to check for inactive nodes
also when they are attached as a root node and make sure that
BLK_PERM_RESIZE isn't among the permissions allowed for inactive nodes.
To this effect, don't enumerate the permissions that are incompatible
with inactive nodes any more, but allow only BLK_PERM_CONSISTENT_READ
for them.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Acked-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20250204211407.381505-7-kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
An active node makes unrestricted use of its children and would possibly
run into assertion failures when it operates on an inactive child node.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Acked-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20250204211407.381505-6-kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Block devices have an individual active state, a single global flag
can't cover this correctly. This becomes more important as we allow
users to manually manage which nodes are active or inactive.
Now that it's allowed to call bdrv_inactivate_all() even when some
nodes are already inactive, we can remove the flag and just
unconditionally call bdrv_inactivate_all() and, more importantly,
bdrv_activate_all() before we make use of the nodes.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Acked-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20250204211407.381505-5-kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Putting an active block node on top of an inactive one is strictly
speaking an invalid configuration and the next patch will turn it into a
hard error.
However, taking a snapshot while disk images are inactive after
completing migration has an important use case: After migrating to a
file, taking an external snapshot is what is needed to take a full VM
snapshot.
In order for this to keep working after the later patches, change
creating a snapshot such that it automatically inactivates an overlay
that is added on top of an already inactive node.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Acked-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20250204211407.381505-4-kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
What we wanted to catch with the assertion is cases where the recursion
finds that a child was inactive before its parent. This should never
happen. But if the user tries to inactivate an image that is already
inactive, that's harmless and we don't want to fail the assertion.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Acked-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20250204211407.381505-3-kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
This allows querying from QMP (and also HMP) whether an image is
currently active or inactive (in the sense of BDRV_O_INACTIVE).
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Acked-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20250204211407.381505-2-kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit 7452162ade introduced 'qom-path' argument to BLOCK_IO_ERROR
event but when the event is instantiated in 'send_qmp_error_event()' the
arguments for 'device' and 'qom_path' in
qapi_event_send_block_io_error() were reversed :
Generated code for sending event:
void qapi_event_send_block_io_error(const char *qom_path,
const char *device,
const char *node_name,
IoOperationType operation,
[...]
Call inside send_qmp_error_event():
qapi_event_send_block_io_error(blk_name(blk),
blk_get_attached_dev_path(blk),
bs ? bdrv_get_node_name(bs) : NULL, optype,
[...]
This results into reporting the QOM path as the device alias and vice
versa which in turn breaks libvirt, which expects the device alias being
either a valid alias or empty (which would make libvirt do the lookup by
node-name instead).
Cc: qemu-stable@nongnu.org
Fixes: 7452162ade ("qapi: add qom-path to BLOCK_IO_ERROR event")
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Message-ID: <09728d784888b38d7a8f09ee5e9e9c542c875e1e.1737973614.git.pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Dumping coroutines don't yet work with coredumps. Let's make it work.
We still kept most of the old code because they can be either more
flexible, or prettier. Only add the fallbacks when they stop working.
Currently the raw unwind is pretty ugly, but it works, like this:
(gdb) qemu bt
#0 process_incoming_migration_co (opaque=0x0) at ../migration/migration.c:788
#1 0x000055ae6c0dc4d9 in coroutine_trampoline (i0=-1711718576, i1=21934) at ../util/coroutine-ucontext.c:175
#2 0x00007f9f59d72f40 in ??? () at /lib64/libc.so.6
#3 0x00007ffd549214a0 in ??? ()
#4 0x0000000000000000 in ??? ()
Coroutine at 0x7f9f4c57c748:
#0 0x55ae6c0dc9a8 in qemu_coroutine_switch<+120> () at ../util/coroutine-ucontext.c:321
#1 0x55ae6c0da2f8 in qemu_aio_coroutine_enter<+356> () at ../util/qemu-coroutine.c:293
#2 0x55ae6c0da3f1 in qemu_coroutine_enter<+34> () at ../util/qemu-coroutine.c:316
#3 0x55ae6baf775e in migration_incoming_process<+43> () at ../migration/migration.c:876
#4 0x55ae6baf7ab4 in migration_ioc_process_incoming<+490> () at ../migration/migration.c:1008
#5 0x55ae6bae9ae7 in migration_channel_process_incoming<+145> () at ../migration/channel.c:45
#6 0x55ae6bb18e35 in socket_accept_incoming_migration<+118> () at ../migration/socket.c:132
#7 0x55ae6be939ef in qio_net_listener_channel_func<+131> () at ../io/net-listener.c:54
#8 0x55ae6be8ce1a in qio_channel_fd_source_dispatch<+78> () at ../io/channel-watch.c:84
#9 0x7f9f5b26728c in g_main_context_dispatch_unlocked.lto_priv<+315> ()
#10 0x7f9f5b267555 in g_main_context_dispatch<+36> ()
#11 0x55ae6c0d91a7 in glib_pollfds_poll<+90> () at ../util/main-loop.c:287
#12 0x55ae6c0d9235 in os_host_main_loop_wait<+128> () at ../util/main-loop.c:310
#13 0x55ae6c0d9364 in main_loop_wait<+203> () at ../util/main-loop.c:589
#14 0x55ae6bac212a in qemu_main_loop<+41> () at ../system/runstate.c:835
#15 0x55ae6bfdf522 in qemu_default_main<+19> () at ../system/main.c:37
#16 0x55ae6bfdf55f in main<+40> () at ../system/main.c:48
#17 0x7f9f59d42248 in __libc_start_call_main<+119> ()
#18 0x7f9f59d4230b in __libc_start_main_impl<+138> ()
Signed-off-by: Peter Xu <peterx@redhat.com>
Message-ID: <20241212204801.1420528-4-peterx@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
There're a bunch of code trying to fetch fs_base in different ways. IIUC
the simplest way instead is "$fs_base". It also has the benefit that it'll
work for both live gdb session or coredumps.
Signed-off-by: Peter Xu <peterx@redhat.com>
Message-ID: <20241212204801.1420528-3-peterx@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
It's easier for either debugging plugin errors, or issue reports.
Signed-off-by: Peter Xu <peterx@redhat.com>
Message-ID: <20241212204801.1420528-2-peterx@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
ASAN detected a leak when running the ahci-test
/ahci/io/dma/lba28/retry:
Direct leak of 35 byte(s) in 1 object(s) allocated from:
#0 in malloc
#1 in __vasprintf_internal
#2 in vasprintf
#3 in g_vasprintf
#4 in g_strdup_vprintf
#5 in g_strdup_printf
#6 in object_get_canonical_path ../qom/object.c:2096:19
#7 in blk_get_attached_dev_id_or_path ../block/block-backend.c:1033:12
#8 in blk_get_attached_dev_path ../block/block-backend.c:1047:12
#9 in send_qmp_error_event ../block/block-backend.c:2140:36
#10 in blk_error_action ../block/block-backend.c:2172:9
#11 in ide_handle_rw_error ../hw/ide/core.c:875:5
#12 in ide_dma_cb ../hw/ide/core.c:894:13
#13 in dma_complete ../system/dma-helpers.c:107:9
#14 in dma_blk_cb ../system/dma-helpers.c:129:9
#15 in blk_aio_complete ../block/block-backend.c:1552:9
#16 in blk_aio_write_entry ../block/block-backend.c:1619:5
#17 in coroutine_trampoline ../util/coroutine-ucontext.c:175:9
Plug the leak by freeing the device path string.
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20241111145214.8261-1-farosas@suse.de>
[PMD: Use g_autofree]
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20241111170333.43833-3-philmd@linaro.org>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Expose the method docstring in the header, and mention
returned value must be free'd by caller.
Reported-by: Fabiano Rosas <farosas@suse.de>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20241111170333.43833-2-philmd@linaro.org>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
It was found that 'qemu-nbd' is not able to work with some disk images
exported from Azure. Looking at the 512b footer (which contains VPC
metadata):
00000000 63 6f 6e 65 63 74 69 78 00 00 00 02 00 01 00 00 |conectix........|
00000010 ff ff ff ff ff ff ff ff 2e c7 9b 96 77 61 00 00 |............wa..|
00000020 00 07 00 00 57 69 32 6b 00 00 00 01 40 00 00 00 |....Wi2k....@...|
00000030 00 00 00 01 40 00 00 00 28 a2 10 3f 00 00 00 02 |....@...(..?....|
00000040 ff ff e7 47 8c 54 df 94 bd 35 71 4c 94 5f e5 44 |...G.T...5qL._.D|
00000050 44 53 92 1a 00 00 00 00 00 00 00 00 00 00 00 00 |DS..............|
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
we can see that Azure uses a different 'Creator application' --
'wa\0\0' (offset 0x1c, likely reads as 'Windows Azure') and QEMU uses this
field to determine how it can get image size. Apparently, Azure uses 'new'
method, just like Hyper-V.
Overall, it seems that only VPC and old QEMUs need to be ignored as all new
creator apps seem to have reliable current_size. Invert the logic and make
'current_size' method the default to avoid adding every new creator app to
the list.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-ID: <20241212134504.1983757-3-vkuznets@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
In preparation to making changes to the logic deciding whether CHS or
'current_size' need to be used in determining the image size, split off
vpc_ignore_current_size() helper.
No functional change intended.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-ID: <20241212134504.1983757-2-vkuznets@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Each Astro on 64-bit machines supports up to four LMMIO regions.
Those regions are used by graphic cards and other PCI devices which
need to map huge memory areas. The LMMIO regions are configured and
set up by SeaBIOS-hppa and then used as-is by the operating systems
(Linux, HP-UX).
With this addition it's now possible to add other PCI graphic
cards on the command line, e.g. with "-device ati-vga".
Signed-off-by: Helge Deller <deller@gmx.de>
Do not create the artist graphic card if the user disabled it
with "-global artist.disable=true" on the command line.
Signed-off-by: Helge Deller <deller@gmx.de>
Allow users to disable the artist graphic card on the command line
with the option "-global artist.disable=true".
This change allows to use other graphic cards when using Linux, e.g.
by adding "-device ati-vga".
Signed-off-by: Helge Deller <deller@gmx.de>
Until now we used a standard serial-pci device to emulate a HP serial
console. This worked nicely with 32-bit Linux and 32-bit HP-UX, but
64-bit HP-UX crashes with it and expects either a Diva GSP card, or a real
64-bit capable PCI graphic card (which we don't have yet).
In order to continue with 64-bit HP-UX, switch over to the recently
added Diva GSP card emulation.
Signed-off-by: Helge Deller <deller@gmx.de>
The Diva GSP ("Guardian Service Processor") PCI boards are Remote
Management cards for PA-RISC machines. They come with built-in 16550A
UARTs for serial consoles and modem functionalities, as well as a
mailbox-like memory area for hardware auto-reboot functionality.
Latest generation HP PA-RISC server machines use those Diva cards
for console output.
Signed-off-by: Helge Deller <deller@gmx.de>
- fw-cfg: DMA support and new vmcoreinfo test
- accel detection via QOM for non-KVM accels
- use virtio modern for vhost-user
-----BEGIN PGP SIGNATURE-----
iQJEBAABCAAuFiEEqhtIsKIjJqWkw2TPx5jcdBvsMZ0FAmeg8+cQHGZhcm9zYXNA
c3VzZS5kZQAKCRDHmNx0G+wxnS1jD/9/xx8i9fQgA9znEZmzMvQ0xXrlUz8jQkA8
yd/iCZT1ue4ff39XA/Z01J/lUaHFV5x4xV4/YL+I0IcMddwIuI3xXexAEyO76rRC
dRxjKrq20s2W6VPnOT0NHBnvpNnYoQDunIZxY+16QMWajTRbA45G8R7W4dWWOhLQ
2sWNuQHsj1lQ4lZMYlaMuFZC31PgFgPiEwIfS2NHST3WfxJVPpsLU5/Pc8UGs6fd
Sq58jXPS1Akhov7IuC8VG/icjnDpMe3f7OFWQ8u8MC5OhwFNnD7aNnf6V7LmM4f+
vhwLPewKxS3KQ2j1Vt2iWGebxlJHDbvifaBpIiVIibaHvtzcOdwK/bK0i+ji3oTk
NgDB80+UKEUGzj0A+BNMcI+ZMonRT2wmBucWdGCosEG1FUlDONdX2a8Zs5Cfxipe
N2a30OmIfbHo905JLYbTw5SXFSyWdYTSgXOEyNlXjq/B+v3qtpdrHXtMOJaXfk/V
Ln0pKT/mDKx/haiooJdMheJpvRDYxFUHub1MrqnVWWeoiTS2wRwu9QAbFusNwyrk
cEYQRPwuX0AnGk6swRUVLdd7HHeeNDZtVBr30Gi1hzQUZRsfW/YmKunoXJ38XAoG
ZD/7VdTgmpQcoXNBJFnyi9Ie6NSWZwgNmZmZn3yWQtV5ACWIt0cqwF8POh8TOY25
5mVQly/UAA==
=FJP7
-----END PGP SIGNATURE-----
Merge tag 'qtest-20250203-pull-request' of https://gitlab.com/farosas/qemu into staging
Qtest pull request
- fw-cfg: DMA support and new vmcoreinfo test
- accel detection via QOM for non-KVM accels
- use virtio modern for vhost-user
# -----BEGIN PGP SIGNATURE-----
#
# iQJEBAABCAAuFiEEqhtIsKIjJqWkw2TPx5jcdBvsMZ0FAmeg8+cQHGZhcm9zYXNA
# c3VzZS5kZQAKCRDHmNx0G+wxnS1jD/9/xx8i9fQgA9znEZmzMvQ0xXrlUz8jQkA8
# yd/iCZT1ue4ff39XA/Z01J/lUaHFV5x4xV4/YL+I0IcMddwIuI3xXexAEyO76rRC
# dRxjKrq20s2W6VPnOT0NHBnvpNnYoQDunIZxY+16QMWajTRbA45G8R7W4dWWOhLQ
# 2sWNuQHsj1lQ4lZMYlaMuFZC31PgFgPiEwIfS2NHST3WfxJVPpsLU5/Pc8UGs6fd
# Sq58jXPS1Akhov7IuC8VG/icjnDpMe3f7OFWQ8u8MC5OhwFNnD7aNnf6V7LmM4f+
# vhwLPewKxS3KQ2j1Vt2iWGebxlJHDbvifaBpIiVIibaHvtzcOdwK/bK0i+ji3oTk
# NgDB80+UKEUGzj0A+BNMcI+ZMonRT2wmBucWdGCosEG1FUlDONdX2a8Zs5Cfxipe
# N2a30OmIfbHo905JLYbTw5SXFSyWdYTSgXOEyNlXjq/B+v3qtpdrHXtMOJaXfk/V
# Ln0pKT/mDKx/haiooJdMheJpvRDYxFUHub1MrqnVWWeoiTS2wRwu9QAbFusNwyrk
# cEYQRPwuX0AnGk6swRUVLdd7HHeeNDZtVBr30Gi1hzQUZRsfW/YmKunoXJ38XAoG
# ZD/7VdTgmpQcoXNBJFnyi9Ie6NSWZwgNmZmZn3yWQtV5ACWIt0cqwF8POh8TOY25
# 5mVQly/UAA==
# =FJP7
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 03 Feb 2025 11:50:47 EST
# gpg: using RSA key AA1B48B0A22326A5A4C364CFC798DC741BEC319D
# gpg: issuer "farosas@suse.de"
# gpg: Good signature from "Fabiano Rosas <farosas@suse.de>" [unknown]
# gpg: aka "Fabiano Almeida Rosas <fabiano.rosas@suse.com>" [unknown]
# gpg: WARNING: The key's User ID is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: AA1B 48B0 A223 26A5 A4C3 64CF C798 DC74 1BEC 319D
* tag 'qtest-20250203-pull-request' of https://gitlab.com/farosas/qemu:
tests/qtest/vhost-user-test: Use modern virtio for vhost-user tests
tests/qtest: Make qtest_has_accel() generic
tests/qtest: Extract qtest_qom_has_concrete_type() helper
tests/qtest/vmcoreinfo: add a unit test to exercize basic vmcoreinfo function
tests/qtest/libqos: add DMA support for writing and reading fw_cfg files
libqos/fw_cfg: refactor file directory iteraton to make it more reusable
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
../contrib/plugins/cache.c:638:9: error: ‘l2_cache’ may be used uninitialized [-Werror=maybe-uninitialized]
638 | append_stats_line(rep, l1_dmem_accesses, l1_dmisses,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Is a false-positive, since cores > 1, so the variable is set in the
above loop.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
"-display dbus" hands over a file mapping handle to the peer
process (not a file handle).
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
GLib doesn't implement EXTERNAL on win32 at the moment, and disables
ANONYMOUS by default. zbus dropped support for COOKIE_SHA1 in 5.0,
making it no longer possible to connect to qemu -display dbus.
Since p2p connections are gated by existing QMP (or a D-Bus connection),
qemu -display dbus p2p can accept authentication with ANONYMOUS.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
All other vhost-user tests here use modern virtio, too, so let's
adjust the vhost-user-net test accordingly.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20250203124346.169607-1-thuth@redhat.com>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Since commit b14a0b7469 ("accel: Use QOM classes for accel types")
accelerators are registered as QOM objects. Use QOM as a generic
API to query for available accelerators. This is in particular
useful to query hardware accelerators such HFV, Xen or WHPX which
otherwise have their definitions poisoned in "exec/poison.h".
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250130103728.536-3-philmd@linaro.org>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Extract qtest_qom_has_concrete_type() out of qtest_has_device()
in order to re-use it in the following commit.
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250130103728.536-2-philmd@linaro.org>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
A new qtest is written that exercizes the fw-cfg DMA based read and write ops
to write values into vmcoreinfo fw-cfg file and read them back and verify that
they are the same.
Signed-off-by: Ani Sinha <anisinha@redhat.com>
Message-ID: <20250120043847.954881-4-anisinha@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
At present, the libqos/fw_cfg.c library does not support the modern DMA
interface which is required to write to the fw_cfg files. It only uses the IO
interface. Implement read and write methods based on DMA. This will enable
developers to add tests that writes to the fw_cfg file(s). The structure of
the code is taken from edk2 fw_cfg implementation. It has been tested by
writing a qtest that writes to a fw_cfg file.
Signed-off-by: Ani Sinha <anisinha@redhat.com>
Message-ID: <20250120043847.954881-3-anisinha@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
