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>
fw-cfg file directory iteration code can be used by other functions that may
want to implement fw-cfg file operations. Refactor it into a smaller helper
so that it can be reused.
No functional change.
Signed-off-by: Ani Sinha <anisinha@redhat.com>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Message-ID: <20250120043847.954881-2-anisinha@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
This adds a few lines describing `hub` aggregator configuration
for aggregation of several backend devices with a single frontend
device.
Signed-off-by: Roman Penyaev <r.peniaev@gmail.com>
Reviewed-by: "Marc-André Lureau" <marcandre.lureau@redhat.com>
Cc: qemu-devel@nongnu.org
Message-ID: <20250123085327.965501-5-r.peniaev@gmail.com>
This commit introduces a new test function `char_hub_test` to validate
the functionality and constraints of the "hub" chardev backend in QEMU.
The test includes multiple scenarios:
1. Invalid hub creation:
- Creating a hub without defining `chardevs.N` (expects an error).
- Creating a hub with an embedded multiplexer (`mux=on`) or a chardev
already in use (expects errors).
2. Max backend limit:
- Ensures the hub does not accept more backends than the maximum
allowed, with appropriate error handling.
3. Valid hub creation and data aggregation:
- Successfully creating a hub with two ring buffer backends.
- Verifying data aggregation from backends to a frontend and vice versa.
- Ensuring correct error handling for attempts to attach a hub multiple
times or remove busy chardevs.
4. Extended EAGAIN simulation (non-Windows only):
- Simulates a setup with three backends, including a pipe, to test
EAGAIN handling and watcher behavior.
- Verifies data flow and recovery in scenarios involving buffer
overflows and drained pipes.
The test also ensures correct cleanup of chardevs in all cases, covering
both valid and invalid configurations.
Signed-off-by: Roman Penyaev <r.peniaev@gmail.com>
Reviewed-by: "Marc-André Lureau" <marcandre.lureau@redhat.com>
Cc: qemu-devel@nongnu.org
Message-ID: <20250123085327.965501-4-r.peniaev@gmail.com>
This patch implements a new chardev backend `hub` device, which
aggregates input from multiple backend devices and forwards it to a
single frontend device. Additionally, `hub` device takes the output
from the frontend device and sends it back to all the connected
backend devices. This allows for seamless interaction between
different backend devices and a single frontend interface.
The idea of the change is trivial: keep list of backend devices
(up to 4), init them on demand and forward data buffer back and
forth.
The following is QEMU command line example:
-chardev pty,path=/tmp/pty,id=pty0 \
-chardev vc,id=vc0 \
-chardev hub,id=hub0,chardevs.0=pty0,chardevs.1=vc0 \
-device virtconsole,chardev=hub0 \
-vnc 0.0.0.0:0
Which creates 2 backend devices: text virtual console (`vc0`) and a
pseudo TTY (`pty0`) connected to the single virtio hvc console with
the backend aggregator (`hub0`) help. `vc0` renders text to an image,
which can be shared over the VNC protocol. `pty0` is a pseudo TTY
backend which provides biderectional communication to the virtio hvc
console.
'chardevs.N' list syntax is used for the sake of compatibility with
the representation of JSON lists in 'key=val' pairs format of the
util/keyval.c, despite the fact that modern QAPI way of parsing,
namely qobject_input_visitor_new_str(), is not used. Choice of keeping
QAPI list syntax may help to smoothly switch to modern parsing in the
future.
Signed-off-by: Roman Penyaev <r.peniaev@gmail.com>
Reviewed-by: "Marc-André Lureau" <marcandre.lureau@redhat.com>
Cc: qemu-devel@nongnu.org
Message-ID: <20250123085327.965501-3-r.peniaev@gmail.com>
Change makes code symmetric to the code, which handles
the "connected" state, i.e. send CHR_EVENT_CLOSED when
state changes from "connected" to "disconnected".
This behavior is similar to char-socket, for example.
Signed-off-by: Roman Penyaev <r.peniaev@gmail.com>
Reviewed-by: "Marc-André Lureau" <marcandre.lureau@redhat.com>
Reviewed-by: "Alex Bennée" <alex.bennee@linaro.org>
Cc: qemu-devel@nongnu.org
Message-ID: <20250123085327.965501-2-r.peniaev@gmail.com>
The 64-bit hppa qemu emulation still fails to boot 64-bit HP-UX.
This patch series improves the emulation a lot, since it enables us to boot
64-bit HP-UX installer silently up until an endless loop where the machine
reports that it's up an running (it crashed before). This still needs further
analysis, but it's a big step forward.
Main changes to archieve this includes:
- Implementing diagnose registers (especially %dr2 for space-register hashing)
- a new SeaBIOS-hppa version 18, which includes those fixes and enhancements:
- Fix IRT table entries to use slot number
- Increase PCI alignment for memory bars to 64k
- Fix PDC_CACHE/PDC_CACHE_RET_SPID return value
- Allow up to 256 GB RAM on 64-bit machines
V2:
- fix linux-user build by adding missing "#ifndef CONFIG_USER_ONLY ... #endif"
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCZ5yWTwAKCRD3ErUQojoP
X1p5AP4iSfKlBsUZrww2/M1ArqB9jZuJBO1kdZ7OcCN2Jn0yxgEAx0CPUof7NnZV
EY7u3Qq4E8ZnOk4XgHt06bsdNcJN+gc=
=RoAh
-----END PGP SIGNATURE-----
Merge tag 'hppa-system-mfdiag-for-v10-pull-request' of https://github.com/hdeller/qemu-hppa into staging
hppa 64-bit mfdiag improvements
The 64-bit hppa qemu emulation still fails to boot 64-bit HP-UX.
This patch series improves the emulation a lot, since it enables us to boot
64-bit HP-UX installer silently up until an endless loop where the machine
reports that it's up an running (it crashed before). This still needs further
analysis, but it's a big step forward.
Main changes to archieve this includes:
- Implementing diagnose registers (especially %dr2 for space-register hashing)
- a new SeaBIOS-hppa version 18, which includes those fixes and enhancements:
- Fix IRT table entries to use slot number
- Increase PCI alignment for memory bars to 64k
- Fix PDC_CACHE/PDC_CACHE_RET_SPID return value
- Allow up to 256 GB RAM on 64-bit machines
V2:
- fix linux-user build by adding missing "#ifndef CONFIG_USER_ONLY ... #endif"
# -----BEGIN PGP SIGNATURE-----
#
# iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCZ5yWTwAKCRD3ErUQojoP
# X1p5AP4iSfKlBsUZrww2/M1ArqB9jZuJBO1kdZ7OcCN2Jn0yxgEAx0CPUof7NnZV
# EY7u3Qq4E8ZnOk4XgHt06bsdNcJN+gc=
# =RoAh
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 31 Jan 2025 04:22:23 EST
# gpg: using EDDSA key BCE9123E1AD29F07C049BBDEF712B510A23A0F5F
# gpg: Good signature from "Helge Deller <deller@gmx.de>" [unknown]
# gpg: aka "Helge Deller <deller@kernel.org>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 4544 8228 2CD9 10DB EF3D 25F8 3E5F 3D04 A7A2 4603
# Subkey fingerprint: BCE9 123E 1AD2 9F07 C049 BBDE F712 B510 A23A 0F5F
* tag 'hppa-system-mfdiag-for-v10-pull-request' of https://github.com/hdeller/qemu-hppa:
target/hppa: Update SeaBIOS-hppa to version 18
target/hppa: Implement space register hashing for 64-bit HP-UX
target/hppa: 64-bit CPUs start with space register hashing enabled
target/hppa: Add instruction decoding for mfdiag and mtdiag
target/hppa: Drop diag_getshadowregs_pa2 and diag_putshadowregs_pa2
target/hppa: Add CPU diagnose registers
disas/hppa: implement mfdiag/mtdiag disassembly
hppa: Sync contents of hppa_hardware.h header file with SeaBIOS-hppa
MAINTAINERS: Add myself as HPPA maintainer
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Now that sd_enable() has been removed, SD::enable is set to true in
sd_instance_init() and then never changed. So we can remove it.
Note that the VMSTATE_UNUSED() size argument should be '1', not
'sizeof(bool)', as noted in the CAUTION comment in vmstate.h.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250128104519.3981448-12-peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
The sdcard_legacy.h header defines function prototypes for the "legacy"
SD card API, which was used by non-qdevified SD controller models.
We've now converted the only remaining non-qdev SD controller, so
we can drop the legacy API.
Entirely unused functions:
sd_init(), sd_set_cb(), sd_enable()
Functions which now become static inside sd.c (they are the
underlying implementations of methods on SDCardClass):
sd_do_command(), sd_write_byte(), sd_read_byte()
Removal of sd_init() means that we can also remove the
me_no_qdev_me_kill_mammoth_with_rocks flag, the codepaths that were
only reachable when it was set, and the inserted_cb and readonly_cb
qemu_irq lines that went with that.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20250128104519.3981448-11-peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
The SDCardClass has an 'enable' method, but nothing actually invokes it.
The underlying implementation is sd_enable(), which is documented
in sdcard_legacy.h as something that should not be used and was only
present for the benefit of the now-removed nseries boards. Unlike
all the other method pointers in SDCardClass, this one doesn't have
an sdbus_foo() function wrapper in hw/sd/core.c.
Remove the unused method.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250128104519.3981448-10-peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
This is a very old source file, and still has some lingering
hard-coded tabs; untabify it.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250128104519.3981448-9-peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
The coverswitch qemu_irq is never connected to anything, and the only thing
we do with it is set it in omap_mmc_reset(). Remove it.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250128104519.3981448-8-peter.maydell@linaro.org>
[PMD: Remove unused 'coverswitch' field]
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Our style for other conversions of OMAP devices to qdev has been to
inline the creation and wiring into omap310_mpu_init() -- see for
instance the handling of omap-intc, omap-gpio and omap_i2c. Do
the same for omap-mmc.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250128104519.3981448-7-peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
The approach we've settled on for handling the omap_clk wiring for
OMAP devices converted to QDev is to have a function omap_foo_set_clk()
whose implementation just sets the field directly in the device's
state struct. (See the "TODO" comment near the top of omap.h.)
Make omap_mmc do the same.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250128104519.3981448-6-peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Convert the OMAP MMC controller to the new SDBus API:
* the controller creates an SDBus bus
* instead of sd_foo functions on the SDState object, call
sdbus_foo functions on the SDBus
* the board code creates a proper TYPE_SD_CARD object and attaches
it to the controller's SDBus, instead of the controller creating
a card directly via sd_init() that never gets attached to any bus
* because the SD card object is on a bus, it gets reset automatically
by the "traverse the qbus tree resetting things" code, and we don't
need to manually reset the card from the controller reset function
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250128104519.3981448-5-peter.maydell@linaro.org>
[PMD: Include "hw/sd/sd.h" instead of "hw/sd/sdcard_legacy.h",
create bus in omap_mmc_initfn() instead of omap_mmc_realize()]
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
The omap_mmc device has three outbound qemu_irq lines:
* one actual interrupt line
* two which connect to the DMA controller and are signalled for
TX and RX DMA
Convert these to a sysbus IRQ and two named GPIO outputs.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250128104519.3981448-4-peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Mechanically convert the remaining uses of 'struct omap_mmc_s' to
'OMAPMMCState'.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250128104519.3981448-3-peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Do a minimal conversion of the omap_mmc device model to QDev.
In this commit we do the bare minimum to produce a working device:
* add the SysBusDevice parent_obj and the usual type boilerplate
* omap_mmc_init() now returns a DeviceState*
* reset is handled by sysbus reset, so the SoC reset function
doesn't need to call omap_mmc_reset() any more
* code that should obviously be in init/realize is moved there
from omap_mmc_init()
We leave various pieces of cleanup to later commits:
* rationalizing 'struct omap_mmc_s *' to 'OMAPMMCState *'
* using gpio lines rather than having omap_mmc_init() directly
set s->irq, s->dma
* switching away from the legacy SD API and instead having
the SD card plugged into a bus
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250128104519.3981448-2-peter.maydell@linaro.org>
[PMD: Do not add omap_mmc_realize()]
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Rather than passing a boolean 'is_big_endian' argument,
directly pass the ELFDATA, which can be unspecified using
the ELFDATANONE value.
Update the call sites:
0 -> ELFDATA2LSB
1 -> ELFDATA2MSB
TARGET_BIG_ENDIAN -> TARGET_BIG_ENDIAN ? ELFDATA2MSB : ELFDATA2LSB
Suggested-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20250127113824.50177-7-philmd@linaro.org>
