fork()ed processes currently start with
current_cpu->in_exclusive_context set, which is, strictly speaking, not
correct, but does not cause problems (even assertion failures).
With one of the next patches, the code begins to rely on this value, so
fix it by always calling end_exclusive() in fork_end().
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Message-Id: <20230214140829.45392-2-iii@linux.ibm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
The linux kernel's trap tables vector all unassigned trap
numbers to BAD_TRAP, which then raises SIGILL.
Tested-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reported-by: Ilya Leoshkevich <iii@linux.ibm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
If an instruction straddles a page boundary, and the first page
was ram, but the second page was MMIO, we would abort. Handle
this as if both pages are MMIO, by setting the ram_addr_t for
the first page to -1.
Reported-by: Sid Manning <sidneym@quicinc.com>
Reported-by: Jørgen Hansen <Jorgen.Hansen@wdc.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Before this commit, when GDB attached an OS working on QEMU, order of FPU
stack registers printed by GDB command 'info float' was wrong. There was a
bug causing the problem in 'g' packets sent by QEMU to GDB. The packets have
values of registers of machine emulated by QEMU containing FPU stack
registers. There are 2 ways to specify a x87 FPU stack register. The first
is specifying by absolute indexed register names (R0, ..., R7). The second
is specifying by stack top relative indexed register names (ST0, ..., ST7).
Values of the FPU stack registers should be located in 'g' packet and be
ordered by the relative index. But QEMU had located these registers ordered
by the absolute index. After this commit, when QEMU reads registers to make
a 'g' packet, QEMU specifies FPU stack registers by the relative index.
Then, the registers are ordered correctly in the packet. As a result, GDB,
the packet receiver, can print FPU stack registers in the correct order.
Signed-off-by: TaiseiIto <taisei1212@outlook.jp>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <TY0PR0101MB4285923FBE9AD97CE832D95BA4E59@TY0PR0101MB4285.apcprd01.prod.exchangelabs.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
# -----BEGIN PGP SIGNATURE-----
# Version: GnuPG v1
#
# iQEcBAABAgAGBQJj7xKYAAoJEO8Ells5jWIRDZQH/Rao24sq3j97qE5RzekvANzq
# GnHUyLnl3yeOSNumv2BJInZTvgUpYL2etGQr3DtGRwOrr7w1vKB3zhY3V3jQefkh
# f4rsEGkamL/qM2N2cGUIUSqevo7OGnP8aQojpEi4MWWZ30B3L6jqd4NqyA1gyndV
# 1eBkpR+BY2PjcLbgvFUZEXeAn/vapE5NKULXUGhg5mMvgwYH3CgZXpqqkxr876za
# S4rZMtReXKNeid14Z35SUjJdV2WKYmo/lN9+GQxF2YNLmDC3RtuFQVm038erSqvs
# uLVSg8tiIlCyOcSDpR/BARNrxVwzlJp5X6ocapHubS/i0Rp/Zo7ezSk/XWH1gfU=
# =UbzF
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 17 Feb 2023 05:37:28 GMT
# gpg: using RSA key EF04965B398D6211
# gpg: Good signature from "Jason Wang (Jason Wang on RedHat) <jasowang@redhat.com>" [marginal]
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg: It is not certain that the signature belongs to the owner.
# Primary key fingerprint: 215D 46F4 8246 689E C77F 3562 EF04 965B 398D 6211
* tag 'net-pull-request' of https://github.com/jasowang/qemu:
vdpa: fix VHOST_BACKEND_F_IOTLB_ASID flag check
net: stream: add a new option to automatically reconnect
vmnet: stop recieving events when VM is stopped
net: Increase L2TPv3 buffer to fit jumboframes
hw/net/vmxnet3: allow VMXNET3_MAX_MTU itself as a value
hw/net/lan9118: log [read|write]b when mode_16bit is enabled rather than abort
net: Replace "Supported NIC models" with "Available NIC models"
net: Restore printing of the help text with "-nic help"
net: Move the code to collect available NIC models to a separate function
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Replace fork-based fuzzing with reboots.
Now the fuzzers will reboot the guest between inputs.
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCgAdFiEE+tTiv4cTddY0BRfETmYd3lg6lk4FAmPu/LoACgkQTmYd3lg6
# lk6RHg/7BRGI5ZPXb1MmTNCC+SroQ6TT++lO4b0hbkN2HO6U+WVvfuA6+0wg+8qC
# 4bp+G1Tabpcq1MTYUuim6DBtWswgpqr0AbWNwn1eF7hya+3W9woH2POVYY2wwc7m
# S3EdwXCCKo9gGXlaNrotnbwIk+o8B4BzXOXLIlRtg26wGYhT5fkJA/BQcHKDXz37
# ctyWxlyjIM8pNCgfybMvjC7MYtp8DufPsv/rrKx9t0TM7f1jPVgXLek7t0+ZwjeY
# qz2Om2jiij1INgK9hTieWs4eHwpwre6vH2a+JKRkZ3sS7WYcj1auNKVJb3GvDqmc
# wy+Nz5Lz4+aPP19pkCYjfz5w3CqEEsSlSDn5UVRbfl2fbENSceoNwo9huMXsF1pB
# oO6NK2NxbOygmNpYxp+JEt45KFIXzUcIFQwbn8aCDODIl+0H2yu7/ll6XgELf1Pa
# P83THOaVxIxfcI9VOdt/FwDq1ZzmV5nk/BkIGJeIWNYMbU4Gze6YoaL3U8AHDxKH
# f6f3qDzcVJjqD0wKhvYcQ3kSPq+vHc/ioh6mYwos6VUEVYz/SLOY876MaSB/K4PE
# ofBV7y6HvJ6AMwg1TBg4YtOP08gWK+4sYH+I09oU40U3UcwEpkbkQTF72lPQHxFs
# 8UVRJrgWv/xzrwzXTX5ruQ633F8zuhqQTeERqksj1pPHJ3NdHps=
# =F6qI
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 17 Feb 2023 04:04:10 GMT
# gpg: using RSA key FAD4E2BF871375D6340517C44E661DDE583A964E
# gpg: Good signature from "Alexander Bulekov <alxndr@bu.edu>" [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: FAD4 E2BF 8713 75D6 3405 17C4 4E66 1DDE 583A 964E
* tag 'pr-2023-02-16' of https://gitlab.com/a1xndr/qemu:
docs/fuzz: remove mentions of fork-based fuzzing
fuzz: remove fork-fuzzing scaffolding
fuzz/i440fx: remove fork-based fuzzer
fuzz/virtio-blk: remove fork-based fuzzer
fuzz/virtio-net: remove fork-based fuzzer
fuzz/virtio-scsi: remove fork-based fuzzer
fuzz/generic-fuzz: add a limit on DMA bytes written
fuzz/generic-fuzz: use reboots instead of forks to reset state
fuzz: add fuzz_reset API
hw/sparse-mem: clear memory on reset
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Remove C virtiofsd
We deprecated the C virtiofsd in commit 34deee7b6a
in v7.0 in favour of the Rust implementation at
https://gitlab.com/virtio-fs/virtiofsd
since then, the Rust version has had more development and
has held up well. It's time to say goodbye to the C version
that got us going.
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEERfXHG0oMt/uXep+pBRYzHrxb/ecFAmPudNkACgkQBRYzHrxb
# /ed2ZBAAlz+bjTIoWjJr5/5nSjydd5ucARYDX4n0PI2byVDHFVaUCTIi+rLrxCYs
# qnb7HVmQW4y6zy15sM1xsbqSyrVgqvDheAJPWVekkoIuVT1t6wVpAZ7sykwx8U1I
# ge2T6pXcc4xKptyGnMAB0v0T5r9hN2Peghg3/KBn6WSD1WM2rD6KmvU4untYOeST
# I/KeoEDc4WUHtaPoDIduQlEcxGKJft6ifS0ksL0Jlf06aDg9UXxcuovtN6GtmnD2
# oNPYR0qG6aN4FynTrcVBN38N3cEosdCtEK0kgvbxulnQ4Iwxyi9hBkvUJA3UmjQ/
# THkWa9Gl+bFTGfNFxUEBV+0bBI46MFn2zXmpatPeV6NvKhiaDi4DDUczueUH1+s+
# C5KWYN3LuDznmM2NQzFipG1NtP2tif6wM2dYTOHf62n4UZBSe0xSdM1OKwqKXQnN
# w5TPlZEvnaYY7vz2fjDlnLKAD9WxlxvMYjr/eJrrjDPSWGxAoe59q0nXBlzXi1Bl
# 6GcCqt/GQpLbY9X2l2pb1bvFOZcPtPZ6CiLBCslKZ5MxmiCvZWnJQ2ZHe9ccQeUX
# 22wWB5gkvWz/1bPddQR7JJ48HxBEPRd4aZ93A3jJfZqWCaTaHQ6bZboghVywMbXJ
# P0wkwaXsFshcyuZfus/dq61y+jsIVR3EyxxRMxd2rO6Mg6nvTcs=
# =0FYt
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 16 Feb 2023 18:24:25 GMT
# gpg: using RSA key 45F5C71B4A0CB7FB977A9FA90516331EBC5BFDE7
# gpg: Good signature from "Dr. David Alan Gilbert (RH2) <dgilbert@redhat.com>" [full]
# Primary key fingerprint: 45F5 C71B 4A0C B7FB 977A 9FA9 0516 331E BC5B FDE7
* tag 'pull-virtiofs-20230216b' of https://gitlab.com/dagrh/qemu:
virtiofsd: Swing deprecated message to removed-features
virtiofsd: Remove source
virtiofsd: Remove build and docs glue
virtiofsd: Remove test
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Historically, the critical dependency for both building and running
QEMU has been the distro packages. Because QEMU is written in C and C's
package management has been tied to distros (at least if you do not want
to bundle libraries with the binary, otherwise I suppose you could use
something like conda or wrapdb), C dependencies of QEMU would target the
version that is shipped in relatively old but still commonly used distros.
For non-C libraries, however, the situation is different, as these
languages have their own package management tool (cpan, pip, gem, npm,
and so on). For some of these languages, the amount of dependencies
for even a simple program can easily balloon to the point that many
distros have given up on packaging non-C code. For this reason, it has
become increasingly normal for developers to download dependencies into
a self-contained local environment, instead of relying on distro packages.
Fortunately, this affects QEMU only at build time, as qemu.git does
not package non-C artifacts such as the qemu.qmp package; but still,
as we make more use of Python, we experience a clash between a support
policy that is written for the C world, and dependencies (both direct
and indirect) that increasingly do not care for the distro versions
and are quick at moving past Python runtime versions that are declared
end-of-life.
For example, Python 3.6 has been EOL'd since December 2021 and Meson 0.62
(released the following March) already dropped support for it. Yet,
Python 3.6 is the default version of the Python runtime for RHEL/CentOS
8 and SLE 15, respectively the penultimate and the most recent version
of two distros that QEMU would like to support. (It is also the version
used by Ubuntu 18.04, but QEMU stopped supporting it in April 2022).
There are good reasons to move forward with the deprecation of Python
3.6 in QEMU as well: completing the configure->meson switch (which
requires Meson 0.63), and making the QAPI generator fully typed (which
requires newer versions of not just mypy but also Python, due to PEP563).
Fortunately, these long-term support distros do include newer versions of
the Python runtime. However, these more recent runtimes only come with
a very small subset of the Python packages that the distro includes.
Because most dependencies are optional tests (avocado, mypy, flake8)
and Meson is bundled with QEMU, the most noticeably missing package is
Sphinx (and the readthedocs theme). There are four possibilities:
* we change the support policy and stop supporting CentOS 8 and SLE 15;
not a good idea since CentOS 8 is not an unreasonable distro for us to
want to continue to support
* we keep supporting Python 3.6 until CentOS 8 and SLE 15 stop being
supported. This is a possibility---but we may want to revise the support
policy anyway because SLE 16 has not even been released, so this would
mean delaying those desirable reasons for perhaps three years;
* we support Python 3.6 just for building documentation, i.e. we are
careful not to use Python 3.7+ features in our Sphinx extensions but are
free to use them elsewhere. Besides being more complicated to understand
for developers, this can be quite limiting; parts of the QAPI generator
run at sphinx-build time, which would exclude one of the areas which
would benefit from a newer version of the runtime;
* we only support Python 3.7+, which means CentOS 8 CI and users
have to either install Sphinx from pip or disable documentation.
This proposed update to the support policy chooses the last of these
possibilities. It does by modifying three aspects of the support
policy:
* it introduces different support periods for *native* vs. *non-native*
dependencies. Non-native dependencies are currently Python ones only,
and for simplicity the policy only mentions Python; however, the concept
generalizes to other languages with a well-known upstream package
manager, that users of older distributions can fetch dependencies from;
* it opens up the possibility of taking non-native dependencies from their
own package index instead of using the version in the distribution. The
wording right now is specific to dependencies that are only required at
build time. In the future we may have to refine it if, for example, parts
of QEMU will be written in Rust; in that case, crates would be handled
in a similar way to submodules and vendored in the release tarballs.
* it mentions specifically that optional build dependencies are excluded
from the platform policy. Tools such as mypy don't affect the ability
to build QEMU and move fast enough that distros cannot standardize on
a single version of them (for example RHEL9 does not package them at
all, nor does it run them at rpmbuild time). In other cases, such as
cross compilers, we have alternatives.
Right now, non-native dependencies have to be download manually by
running "pip" before "configure". In the future, it will be desirable
for configure to set up a virtual environment and download them in the
same way that it populates git submodules (but, in this case, without
vendoring them in the release tarballs).
Just like with submodules, this would make things easier for people
that can afford accessing the network in their build environment; the
option to populate the build environment manually would remain for
people whose build machines lack network access. The change to the
support policy neither requires nor forbids this future change.
[Thanks to Daniel P. Berrangé, Peter Maydell and others for discussions
that were copied or summarized in the above commit message]
Cc: Markus Armbruster <armbru@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: John Snow <jsnow@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Block layer patches
- configure: Enable -Wthread-safety if present
- no_co_wrapper to fix bdrv_open*() calls from coroutine context
- curl fixes, including enablement of newer libcurl versions
- MAINTAINERS: drop Vladimir from parallels block driver
- hbitmap: fix hbitmap_status() return value for first dirty bit case
- file-posix: Fix assertion failure in write_zeroes after moving
bdrv_getlength() to co_wrapper
# -----BEGIN PGP SIGNATURE-----
#
# iQJFBAABCAAvFiEE3D3rFZqa+V09dFb+fwmycsiPL9YFAmPvgm0RHGt3b2xmQHJl
# ZGhhdC5jb20ACgkQfwmycsiPL9ZxQg//ZWwwh/s/P1PnKAjInNZZNklAWKThNEbZ
# cF1S94w26IhEQqM0i6MflqcDsPU5t4xZtBUOizx++9M4G8amWnomJSdczUcKULla
# Az9yweFC1Gu6ENdw+ql5VOzCfpdH5Bn9Jkly5fxuI4vmnBz1PH1Dnd3P4wuLq2sL
# xna5dijVEhRc5mTKWjbp4nFfvQhucuEBPSNjgnZwEPbhciWxTMmB1GmyRvTxZy8v
# UY8PcoTlxdKeVQ6DTmkOirphpGj7HeNCEQnZppWs7vHys2oGi9kmR5qTKUNZxGrY
# 8yWiCiVDqbb50fhEC1srhph79bCij87QC1N33Bm+NuGjnjG4bKVx2B9DC8+6S/JS
# e3x6u+r0dd6/t0rjKnt1+inYqmM+i5lBJ7+R0yhWUQ+DYkvttNf5yiotD8qvccWJ
# Kcx14lfjPLK7siAMEY5K0bNMimhN4RR9oCLoPTOHei+vlxdfiMm2XPN61NNht5gD
# lYZ8JMBsEF/o2ebqTgsJrIHS+Q/8MqcwSunBc54fcXZoF+eiza3W2ArXLNfAEfGE
# U4JowNK2PrTIrpEjD+Vs0RsBBSmN5PcYIAz04ioODpDnYMq73/t3x9MKdVoxOT64
# AM7w58fSyWu8iwvkeA0d3XeVtSHFqZ49PqqIem4IegtnC/AXMUNrJ/VT99xHjeJY
# oLhOJz7LUg0=
# =FtaA
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 17 Feb 2023 13:34:37 GMT
# gpg: using RSA key DC3DEB159A9AF95D3D7456FE7F09B272C88F2FD6
# gpg: issuer "kwolf@redhat.com"
# gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" [full]
# Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6
* tag 'for-upstream' of https://repo.or.cz/qemu/kevin: (22 commits)
hbitmap: fix hbitmap_status() return value for first dirty bit case
block/file-posix: don't use functions calling AIO_WAIT_WHILE in worker threads
MAINTAINERS: drop Vladimir from parallels block driver
block: temporarily hold the new AioContext of bs_top in bdrv_append()
block: Handle curl 7.55.0, 7.85.0 version changes
block: Assert non-coroutine context for bdrv_open_inherit()
block: Fix bdrv_co_create_opts_simple() to open images with no_co_wrapper
vpc: Fix .bdrv_co_create(_opts) to open images with no_co_wrapper
vmdk: Fix .bdrv_co_create(_opts) to open images with no_co_wrapper
vhdx: Fix .bdrv_co_create(_opts) to open images with no_co_wrapper
vdi: Fix .bdrv_co_create(_opts) to open images with no_co_wrapper
qed: Fix .bdrv_co_create(_opts) to open images with no_co_wrapper
qcow2: Fix open/create to open images with no_co_wrapper
qcow: Fix .bdrv_co_create(_opts) to open images with no_co_wrapper
parallels: Fix .bdrv_co_create(_opts) to open images with no_co_wrapper
luks: Fix .bdrv_co_create(_opts) to open images with no_co_wrapper
block: Create no_co_wrappers for open functions
block-coroutine-wrapper: Introduce no_co_wrapper
curl: Fix error path in curl_open()
configure: Enable -Wthread-safety if present
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
When calling bdrv_getlength() in handle_aiocb_write_zeroes(), the
function creates a new coroutine and then waits that it finishes using
AIO_WAIT_WHILE.
The problem is that this function could also run in a worker thread,
that has a different AioContext from main loop and iothreads, therefore
in AIO_WAIT_WHILE we will have in_aio_context_home_thread(ctx) == false
and therefore
assert(qemu_get_current_aio_context() == qemu_get_aio_context());
in the else branch will fail, crashing QEMU.
Aside from that, bdrv_getlength() is wrong also conceptually, because
it reads the BDS graph from another thread and is not protected by
any lock.
Replace it with raw_co_getlength, that doesn't create a coroutine and
doesn't read the BDS graph.
Reported-by: Ninad Palsule <ninad@linux.vnet.ibm.com>
Suggested-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
Message-Id: <20230209154522.1164401-1-eesposit@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
bdrv_append() is called with bs_top AioContext held, but
bdrv_attach_child_noperm() could change the AioContext of bs_top.
bdrv_replace_node_noperm() calls bdrv_drained_begin() starting from
commit 2398747128 ("block: Don't poll in bdrv_replace_child_noperm()").
bdrv_drained_begin() can call BDRV_POLL_WHILE that assumes the new lock
is taken, so let's temporarily hold the new AioContext to prevent QEMU
from failing in BDRV_POLL_WHILE when it tries to release the wrong
AioContext.
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2168209
Reported-by: Aihua Liang <aliang@redhat.com>
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Message-Id: <20230214171621.11574-1-sgarzare@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
.bdrv_co_create implementations run in a coroutine, as does
qcow2_do_open(). Therefore they are not allowed to open images directly.
Fix the calls to use the corresponding no_co_wrappers instead.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20230126172432.436111-7-kwolf@redhat.com>
Reviewed-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
Reviewed-by: Hanna Czenczek <hreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Images can't be opened in coroutine context because opening needs to
change the block graph. Add no_co_wrappers so that coroutines have a
simple way of opening images in a BH instead.
At the same time, mark the wrapped functions as no_coroutine_fn.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20230126172432.436111-3-kwolf@redhat.com>
Reviewed-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
Reviewed-by: Hanna Czenczek <hreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Some functions must not be called from coroutine context. The common
pattern to use them anyway from a coroutine is running them in a BH and
letting the calling coroutine yield to be woken up when the BH is
completed.
Instead of manually writing such wrappers, add support for generating
them to block-coroutine-wrapper.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20230126172432.436111-2-kwolf@redhat.com>
Reviewed-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
Reviewed-by: Hanna Czenczek <hreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
g_hash_table_destroy() and g_hash_table_foreach_remove() (called by
curl_drop_all_sockets()) both require the table to be non-NULL, or will
print assertion failures (just print, no abort).
There are several paths in curl_open() that can lead to the out_noclean
label without s->sockets being allocated, so clean it only if it has
been allocated.
Example reproducer:
$ qemu-img info -f http ''
qemu-img: GLib: g_hash_table_foreach_remove: assertion 'hash_table != NULL' failed
qemu-img: GLib: g_hash_table_destroy: assertion 'hash_table != NULL' failed
qemu-img: Could not open '': http curl driver cannot handle the URL '' (does not start with 'http://')
Closes: https://gitlab.com/qemu-project/qemu/-/issues/1475
Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-Id: <20230206132949.92917-1-hreitz@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@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>
FreeBSD implements pthread headers using TSA (thread safety analysis)
annotations, therefore when an application is compiled with
-Wthread-safety there are some locking/annotation requirements that the
user of the pthread API has to follow.
This will also be the case in QEMU, since bsd-user/mmap.c uses the
pthread API. Therefore when building it with -Wthread-safety the
compiler will throw warnings because the functions are not properly
annotated. We need TSA to be enabled because it ensures that the
critical sections of an annotated variable are properly locked.
In order to make the compiler happy and avoid adding all the necessary
macros to all callers (lock functions should use TSA_ACQUIRE, while
unlock TSA_RELEASE, and this applies to all users of pthread_mutex_lock
and pthread_mutex_unlock), simply use TSA_NO_TSA to supppress such
warnings.
Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
Message-Id: <20230117135203.3049709-3-eesposit@redhat.com>
Reviewed-by: Warner Losh <imp@bsdimp.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
FreeBSD implements pthread headers using TSA (thread safety analysis)
annotations, therefore when an application is compiled with
-Wthread-safety there are some locking/annotation requirements that the
user of the pthread API has to follow.
This will also be the case in QEMU, since util/qemu-thread-posix.c uses
the pthread API. Therefore when building it with -Wthread-safety, the
compiler will throw warnings because the functions are not properly
annotated. We need TSA to be enabled because it ensures that the
critical sections of an annotated variable are properly locked.
In order to make the compiler happy and avoid adding all the necessary
macros to all callers (lock functions should use TSA_ACQUIRE, while
unlock TSA_RELEASE, and this applies to all users of pthread_mutex_lock
and pthread_mutex_unlock), simply use TSA_NO_TSA to supppress such
warnings.
Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
Message-Id: <20230117135203.3049709-2-eesposit@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
VHOST_BACKEND_F_IOTLB_ASID is the feature bit, not the bitmask. Since
the device under test also provided VHOST_BACKEND_F_IOTLB_MSG_V2 and
VHOST_BACKEND_F_IOTLB_BATCH, this went unnoticed.
Fixes: c1a1008685 ("vdpa: always start CVQ in SVQ mode if possible")
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
In stream mode, if the server shuts down there is currently
no way to reconnect the client to a new server without removing
the NIC device and the netdev backend (or to reboot).
This patch introduces a reconnect option that specifies a delay
to try to reconnect with the same parameters.
Add a new test in qtest to test the reconnect option and the
connect/disconnect events.
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
When the VM is stopped using the HMP command "stop", soon the handler will
stop reading from the vmnet interface. This causes a flood of
`VMNET_INTERFACE_PACKETS_AVAILABLE` events to arrive and puts the host CPU
at 100%. We fix this by removing the event handler from vmnet when the VM
is no longer in a running state and restore it when we return to a running
state.
Signed-off-by: Joelle van Dyne <j@getutm.app>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Increase the allocated buffer size to fit larger packets.
Given that jumboframes can commonly be up to 9000 bytes the closest suitable
value seems to be 16 KiB.
Tested by running qemu towards a Linux L2TPv3 endpoint and pushing
jumboframe traffic through the interfaces.
Signed-off-by: Christian Svensson <blue@cmd.nu>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Currently, VMXNET3_MAX_MTU itself (being 9000) is not considered a
valid value for the MTU, but a guest running ESXi 7.0 might try to
set it and fail the assert [0].
In the Linux kernel, dev->max_mtu itself is a valid value for the MTU
and for the vmxnet3 driver it's 9000, so a guest running Linux will
also fail the assert when trying to set an MTU of 9000.
VMXNET3_MAX_MTU and s->mtu don't seem to be used in relation to buffer
allocations/accesses, so allowing the upper limit itself as a value
should be fine.
[0]: https://forum.proxmox.com/threads/114011/
Fixes: d05dcd94ae ("net: vmxnet3: validate configuration values during activate (CVE-2021-20203)")
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Just because a NIC model is compiled into the QEMU binary does not
necessary mean that it can be used with each and every machine.
So let's rather talk about "available" models instead of "supported"
models, just to avoid confusion.
Reviewed-by: Claudio Fontana <cfontana@suse.de>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Running QEMU with "-nic help" used to work in QEMU 5.2 and earlier versions
(it showed the available netdev backends), but this feature got broken during
some refactoring in version 6.0. Let's restore the old behavior, and while
we're at it, let's also print the available NIC models here now since this
option can be used to configure both, netdev backend and model in one go.
Fixes: ad6f932fe8 ("net: do not exit on "netdev_add help" monitor command")
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
The code that collects the available NIC models is not really specific
to PCI anymore and will be required in the next patch, too, so let's
move this into a new separate function in net.c instead.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Fork-fuzzing provides a few pros, but our implementation prevents us
from using fuzzers other than libFuzzer, and may be causing issues such
as coverage-failure builds on OSS-Fuzz. It is not a great long-term
solution as it depends on internal implementation details of libFuzzer
(which is no longer in active development). Remove it in favor of other
methods of resetting state between inputs.
Signed-off-by: Alexander Bulekov <alxndr@bu.edu>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
As we have repplaced fork-based fuzzing, with reboots - we can no longer
use a timeout+exit() to avoid slow inputs. Libfuzzer has its own timer
that it uses to catch slow inputs, however these timeouts are usually
seconds-minutes long: more than enough to bog-down the fuzzing process.
However, I found that slow inputs often attempt to fill overly large DMA
requests. Thus, we can mitigate most timeouts by setting a cap on the
total number of DMA bytes written by an input.
Signed-off-by: Alexander Bulekov <alxndr@bu.edu>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
