Since CONFIG_EPOLL is now unused, it's okay to
perform this rename, to make it less ugly.
Since epoll is linux-specific and is always present on linux,
define CONFIG_EPOLL to 1 on linux, without compile-time test.
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The only place where we used CONFIG_EPOLL was linux-user,
which now enables it unconditionally.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
epoll is in linux since 2.6 (glibc 2.3.2).
epoll_init1 has been added in 2.6.27 (glibc 2.9).
There's no need to check for its presence, including all other
epoll-related syscalls.
Modern architectures don't have epoll_create(), only
epoll_create1(), so keep conditional around the former.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
the only place in qemu which used the check for inotify_init()
was linux-user, which now assumes inotify_init() is always
present. There's no need to check for this function anymore.
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
inotify_init() and other syscalls appeared in linux 2.6.13,
inotify_init1() - in linux 2.6.27.
There's no need to check their presence on linux anymore.
Keep condition on TARGET_NR_inotify_init because modern
architectures have only more generic inotify_init1().
Other, not linux-specific, places of the code checks for
inotify_init1() syscall only.
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
CONFIG_SPLICE was only needed for linux-user/, where it is not
used anymore (assuming splice &Co is always present)
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
xbzrle is a feature of migration and thus this file should go
into the docs/devel/migration/ folder. While we're at it, turn
it into proper .rst format, too.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The check that xcc->model is not NULL occurs after it is dereferenced
inside x86_cpu_get_versioned_cache_info(), so something like
`-cpu host,legacy-cache=off` leads to a segfault rather than an error.
This patch fixes that.
Fixes: cca0a000d0 ("target/i386: allow versioned CPUs to specify new cache_info")
Signed-off-by: Sergei Heifetz <heifetz@yandex-team.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
[Mjt: simplify the following condition too]
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
It is useless to assert that block is not NULL because it is
already dereferenced in the first line of the function.
The assertion is also unnecessary because the function is called
in only two places, and `block` can't be NULL in either of them:
- In `migration/ram.c`, we have already dereferenced `block` in
the code just before the call.
- In `system/memory.c`, we assert `mr->ram_block` before passing
it to the function.
(We could split the declaration and initialization of oldsize,
but then we would need to remove the const qualifier. As the
assertion is useless anyway, removing the const qualifier seems
worse.)
Signed-off-by: Sergei Heifetz <heifetz@yandex-team.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Reorder the code so the assertion of mis->from_src_file occurs before
the call to migration_ioc_unregister_yank_from_file, which dereferences
it in qemu_file_get_ioc.
Fixes: 39675ffffb ("migration: Move the yank unregister of channel_close out")
Signed-off-by: Sergei Heifetz <heifetz@yandex-team.com>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
I won't have that much time for QEMU anymore in the future, so downgrade
the status of the "functional testing framework" section to "Odd Fixes"
to avoid wrong expectations. While we're at it, also switch to my other
e-mail address here that I'm already using for the other sections where
I am still listed as maintainer / reviewer.
Message-ID: <20260313113424.15583-5-thuth@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
I likely won't have much time in the future for QEMU anymore, so
remove myself from various sections that have already enough other
maintainers / reviewers.
Message-ID: <20260313113424.15583-4-thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
I'm going to move to another project next month, so I will not have
enough time to take care of s390x patches anymore. Fortunately,
Cornelia volunteered to take over the job of collecting s390x patches,
and Eric and Matthew offered help to back her up, so we can keep
the "S390 general architecture support" section in the "supported"
state. Thanks for your help, Cornelia, Eric and Matthew!
Message-ID: <20260313113424.15583-3-thuth@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Acked-by: Eric Farman <farman@linux.ibm.com>
Acked-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Calling qdev_get_machine() in the acpi_ged_initfn function would result
in the following assert
../hw/core/qdev.c:858: qdev_get_machine: Assertion `dev' failed.
when trying to run
./qemu-system-aarch64 -S -display none -M virt -device acpi-ged,help
as the machine wasn't created yet. We call qdev_get_machine() to obtain
the ram slots of the machine. So instead of initialising the GED in
the init let's instead do it in the realise where the machine
will exist.
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Tested-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20260312043158.4191378-8-alistair.francis@wdc.com>
[thuth: Replaced soc_init with acpi_ged_initfn in the patch description]
Signed-off-by: Thomas Huth <thuth@redhat.com>
Calling qdev_get_machine() in the soc_init function would result in
the following assert
../hw/core/qdev.c:858: qdev_get_machine: Assertion `dev' failed.
when trying to run
./qemu-system-aarch64 -S -display none -M virt -device fsl-imx6,help
as the machine wasn't created yet. We call qdev_get_machine() to obtain
the number of CPUs in the machine. So instead of initialising the CPUs in
the SoC init let's instead do it in the realise where the machine
will exist.
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20260312043158.4191378-7-alistair.francis@wdc.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Calling qdev_get_machine() in the soc_init function would result in
the following assert
../hw/core/qdev.c:858: qdev_get_machine: Assertion `dev' failed.
when trying to run
./qemu-system-aarch64 -S -display none -M virt -device fsl-imx8mp,help
as the machine wasn't created yet. We call qdev_get_machine() to obtain
the number of CPUs in the machine. So instead of initialising the CPUs in
the SoC init let's instead do it in the realise where the machine
will exist.
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20260312043158.4191378-6-alistair.francis@wdc.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Calling qdev_get_machine() in the soc_init function would result in
the following assert
../hw/core/qdev.c:858: qdev_get_machine: Assertion `dev' failed.
when trying to run
./qemu-system-aarch64 -S -display none -M virt -device fsl-imx7,help
as the machine wasn't created yet. We call qdev_get_machine() to obtain
the number of CPUs in the machine. So instead of initialising the CPUs in
the SoC init let's instead do it in the realise where the machine
will exist.
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20260312043158.4191378-5-alistair.francis@wdc.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Calling qdev_get_machine() in the soc_init function would result in
the following assert
../hw/core/qdev.c:858: qdev_get_machine: Assertion `dev' failed.
when trying to run
./qemu-system-aarch64 -S -display none -M virt -device xlnx-zynqmp,help
as the machine wasn't created yet. We call qdev_get_machine() to obtain
the number of CPUs in the machine. So instead of initialising the CPUs in
the SoC init let's instead do it in the realise where the machine
will exist.
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20260312043158.4191378-4-alistair.francis@wdc.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Calling qdev_get_machine() in the soc_init function would result in
the following assert
../hw/core/qdev.c:858: qdev_get_machine: Assertion `dev' failed.
when trying to run
./qemu-system-riscv64 -S -display none -M virt -device microchip.pfsoc,help
as the machine wasn't created yet. We call qdev_get_machine() to obtain
the number of CPUs in the machine. So instead of setting the CPU
num-harts in the init function let's set it in realise where the machine
will exist.
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20260312043158.4191378-3-alistair.francis@wdc.com>
[thuth: Fix a complaint from checkpatch.pl with regards to multi-line comment]
Signed-off-by: Thomas Huth <thuth@redhat.com>
Calling qdev_get_machine() in the soc_init function would result in
the following assert
../hw/core/qdev.c:858: qdev_get_machine: Assertion `dev' failed.
when trying to run
./qemu-system-riscv64 -S -display none -M virt -device riscv.sifive.e.soc,help
as the machine wasn't created yet. We call qdev_get_machine() to obtain
the number of CPUs in the machine. So instead of setting the CPU
num-harts in the init function let's set it in realise where the machine
will exist.
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Tested-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20260312043158.4191378-2-alistair.francis@wdc.com>
[thuth: Fix a complaint from checkpatch.pl with regards to multi-line comment]
Signed-off-by: Thomas Huth <thuth@redhat.com>
When introspecting the Loongson-3A4000 CPUs from the command line, QEMU
currently crashes:
$ ./qemu-system-mips64el -device Loongson-3A4000-mips64-cpu,help
qemu-system-mips64el: ../../devel/qemu/system/physmem.c:1401:
register_multipage: Assertion `num_pages' failed.
Aborted (core dumped)
Move the initialization of the memory regions to the realize function
to fix this problem.
Reported-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <87y0jxzdrk.fsf@pond.sub.org>
Tested-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260311211629.118608-1-thuth@redhat.com>
When introspecting the xtensa CPUs from the command line, QEMU currently
crashes:
$ ./qemu-system-xtensa -device dc233c-xtensa-cpu,help
qemu-system-xtensa: ../../devel/qemu/system/physmem.c:1401:
register_multipage: Assertion `num_pages' failed.
Aborted (core dumped)
Move the initialization of the memory regions to the realize function
to fix this problem.
Reported-by: Markus Armbruster <armbru@redhat.com>
Tested-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20260311202503.107026-1-thuth@redhat.com>
Older versions of gcc with -Wformat-overflow=2 don't like the usage of
fixed size char arrays in this test; gcc 7.5.0 (SUSE Linux) says:
../tests/qtest/aspeed_gpio-test.c: In function ‘test_set_input_pins’:
../tests/qtest/aspeed_gpio-test.c:149:36: error: ‘sprintf’ may write a terminating nul past the end of the destination [-Werror=format-overflow=]
sprintf(name, "gpio%c%d", c, i);
^
../tests/qtest/aspeed_gpio-test.c:149:13: note: ‘sprintf’ output between 7 and 17 bytes into a destination of size 16
sprintf(name, "gpio%c%d", c, i);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This can't actually happen because of the limited size of the values
being substituted in. However rather than require readers to check
whether the arrays really have been declared large enough, we prefer
to use g_strdup_printf() for this kind of string work.
Reported-by: Fabiano Rosas <farosas@suse.de>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Tested-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260310153334.3063224-3-peter.maydell@linaro.org
Older versions of gcc with -Wformat-overflow=2 don't like the usage of
fixed size char arrays in this test; gcc 7.5.0 (SUSE Linux) says:
../tests/qtest/ast2700-gpio-test.c: In function ‘test_input_pins’:
../tests/qtest/ast2700-gpio-test.c:54:36: error: ‘sprintf’ may write a terminating nul past the end of the destination [-Werror=format-overflow=]
sprintf(name, "gpio%c%d", c, i);
^
../tests/qtest/ast2700-gpio-test.c:54:13: note: ‘sprintf’ output between 7 and 17 bytes into a destination of size 16
sprintf(name, "gpio%c%d", c, i);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This can't actually happen because of the limited size of the values
being substituted in. However rather than require readers to check
whether the arrays really have been declared large enough, we prefer
to use g_strdup_printf() for this kind of string work.
Reported-by: Fabiano Rosas <farosas@suse.de>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Tested-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260310153334.3063224-2-peter.maydell@linaro.org
Older versions of gcc with -Wformat-overflow=2 don't like the usage of
fixed size char arrays in this test; gcc 7.5.0 (SUSE Linux) says:
../tests/qtest/arm-cpu-features.c: In function ‘test_query_cpu_model_expansion_kvm’:
../tests/qtest/arm-cpu-features.c:578:35: error: ‘%u’ directive writing
between 1 and 10 bytes into a region of size 5
[-Werror=format-overflow=]
These can't actually happen because of the limited size of the values
being substituted in. However rather than require readers to check
whether the arrays really have been declared large enough, we prefer
to use g_strdup_printf() for this kind of string work.
Reported-by: Fabiano Rosas <farosas@suse.de>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Tested-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20260310151507.2973843-3-peter.maydell@linaro.org
Older versions of gcc with -Wformat-overflow=2 don't like the usage of
fixed size char arrays in this test; gcc 7.5.0 (SUSE Linux) says:
../tests/qtest/ast2700-sgpio-test.c: In function ‘test_output_pins’:
../tests/qtest/ast2700-sgpio-test.c:27:33: error: ‘sprintf’ may write a
terminating nul past the end of the destination
[-Werror=format-overflow=]
../tests/qtest/ast2700-sgpio-test.c: In function ‘test_irq_level_high’:
../tests/qtest/ast2700-sgpio-test.c:85:33: error: ‘sprintf’ may write a
terminating nul past the end of the destination
[-Werror=format-overflow=]
These can't actually happen because of the limited size of the values
being substituted in. However rather than require readers to check
whether the arrays really have been declared large enough, we prefer
to use g_strdup_printf() for this kind of string work.
Reported-by: Fabiano Rosas <farosas@suse.de>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Tested-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Message-id: 20260310151507.2973843-2-peter.maydell@linaro.org
Chris Browy's listed email address is undeliverable:
The recipient server did not accept our requests to connect; it
times out on attempts to connect by my sending mail server (gmail):
[avery-design.com 99.83.249.127: timed out]
[avery-design.com 75.2.78.167: timed out]
Remove his name from the file.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260306120555.2035421-7-peter.maydell@linaro.org
Eduardo Habkost doesn't wish to be listed in MAINTAINERS any more;
remove his email, and also the git trees he used to use.
Move the QOM boilerplate conversion script scripts/codeconverter
to "Orphan" status, as it no longer has any listed maintainers.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260306120555.2035421-4-peter.maydell@linaro.org
Hannes Reinecke doesn't wish to be listed in MAINTAINERS any more;
remove his email from the relevant sections.
As 'megasas' no longer has any listed maintainers, move it to
"Orphan" status.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260306120555.2035421-2-peter.maydell@linaro.org
The PL080 channel LLI (linked list item) register has bits [31:2] of
the address of the next LLI in bits [31:2], with bit [1] reserved
and bits [0] the AHB master select. We were incorrectly using the
whole register value as the address, which meant that if the guest
programmed something into the AHB master select bit we would use
an incorrect address, and read incorrect data from memory.
The following reproducer creates a setup which has bit 0 set in
an LLI value:
Configuration
../configure --target-list=arm-softmmu --enable-debug
Reproducer
./qemu-system-arm -M versatilepb -m 128M -nographic -S \
-device loader,addr=0x00002000,data=0x00000004,data-len=4 \
-device loader,addr=0x00002004,data=0x00001004,data-len=4 \
-device loader,addr=0x00002008,data=0x00000000,data-len=4 \
-device loader,addr=0x0000200c,data=0x9e4bf001,data-len=4 \
-device loader,addr=0x00000000,data=0x44332211,data-len=4 \
-device loader,addr=0x00000004,data=0x88776655,data-len=4 \
-device loader,addr=0x00001000,data=0x00000000,data-len=4 \
-device loader,addr=0x00001004,data=0x00000000,data-len=4 \
-device loader,addr=0x10130030,data=0x00000001,data-len=4 \
-device loader,addr=0x10130100,data=0x00000000,data-len=4 \
-device loader,addr=0x10130104,data=0x00001000,data-len=4 \
-device loader,addr=0x10130108,data=0x00002001,data-len=4 \
-device loader,addr=0x1013010C,data=0x1e4bf001,data-len=4 \
-device loader,addr=0x10130110,data=0x0000c001,data-len=4
The correct result with this bug fix:
(qemu) xp /1wx 0x00001000
00001000: 0x44332211
(qemu) xp /1wx 0x00001004
00001004: 0x88776655
Cc: qemu-stable@nongnu.org
Signed-off-by: Tao Ding <dingtao0430@163.com>
[PMM: Adjusted commit message]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: cb35c1b622674da7a2b70691402132f691933f2c.1773301927.git.dingtao0430@163.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
In the codepath in pl080_write() where we run the DMA engine
after a change in the channel configuration register, we were
missing a pl080_update() call, which meant that we weren't
raising any interrupts generated by that DMA transfer.
A repro case for this is to program the PL080 and then
check the interrupt status by looking at the PL190 status
register, since the PL080 interrupt output is connected
to input 17 of the PL190. We look at the register value via
the QEMU monitor:
Reproducer
./qemu-system-arm -M versatilepb -m 128M -nographic -S \
-device loader,addr=0x00000000,data=0x11223344,data-len=4 \
-device loader,addr=0x00001000,data=0x00000000,data-len=4 \
-device loader,addr=0x10130030,data=0x00000001,data-len=4 \
-device loader,addr=0x10130100,data=0x00000000,data-len=4 \
-device loader,addr=0x10130104,data=0x00001000,data-len=4 \
-device loader,addr=0x10130108,data=0x00000000,data-len=4 \
-device loader,addr=0x1013010C,data=0x9e4bf001,data-len=4 \
-device loader,addr=0x10130110,data=0x0000c001,data-len=4
Qemu monitor
(qemu) xp /1wx 0x10140008
10140008: 0x00000000
The correct result after this fix:
(qemu) xp /1wx 0x10140008
10140008: 0x00020000
Cc: qemu-stable@nongnu.org
Signed-off-by: Tao Ding <dingtao0430@163.com>
Message-id: 7584486ba62bc6d767c0d132dc843067f8c5efff.1773301927.git.dingtao0430@163.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
[PMM: Adjusted commit message]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The PL080 TRM states that the DWidth and SWidth fields of the channel
control registers can only validly specify widths up to 32 bits (i.e.
values from 0 to 2) and all other values are reserved.
Currently we don't check this, so if the guest specifies an invalid
value we will transfer more data into our local 'buff[]' array than
it can hold.
Check the widths; since the TRM doesn't clearly specify any behaviour
for what to do on invalid values, we choose to log them and then
ignore the channel for transfers.
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3203
Reviewed-by: Jim MacArthur <jim.macarthur@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260306152140.2191653-1-peter.maydell@linaro.org
When old_size is zero and old_address refers to a shareable mapping,
mremap() should create a new mapping of the same pages according to the
mremap(2) man page. The MREMAP_MAYMOVE flag must be specified in this case.
Previously, QEMU's target_mremap() rejected this valid case with EFAULT
during the initial validation, before checking for the special
old_size == 0 behaviour.
This patch adds proper handling for old_size == 0:
- Validates that MREMAP_MAYMOVE flag is set (required by man spec)
- Passes the call through to the host mremap()
- Creates a new mapping without invalidating the original, with both
being valid and sharing the same physical memory frames.
- Ensures the new mapping address falls within the valid guest address
region before returning it to the guest.
Tested with the reproducer from the issue on qemu-riscv64, qemu-hppa,
and qemu-aarch64.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3105
Signed-off-by: Razvan Ghiorghe <razvanghiorghe16@gmail.com>
Tested-by: Helge Deller <deller@gmx.de>
Reviewed-by: Helge Deller <deller@gmx.de>
Signed-off-by: Helge Deller <deller@gmx.de>
zero_bss() incorrectly assumed that any PT_LOAD containing .bss must be
writable, rejecting valid ELF binaries where .bss overlaps the tail of
an RX file-backed page.
Instead of failing, temporarily enable write access on the overlapping
page to zero the fractional bss range, then restore the original page
permissions once initialization is complete.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3179
Signed-off-by: Razvan Ghiorghe <razvanghiorghe16@gmail.com>
Reviewed-by: Helge Deller <deller@gmx.de>
Signed-off-by: Helge Deller <deller@gmx.de>
