Block drivers may optimize I/O requests accessing buffers previously
registered with bdrv_register_buf(). Checking whether all elements of a
request's QEMUIOVector are within previously registered buffers is
expensive, so we need a hint from the user to avoid costly checks.
Add a BDRV_REQ_REGISTERED_BUF request flag to indicate that all
QEMUIOVector elements in an I/O request are known to be within
previously registered buffers.
Always pass the flag through to driver read/write functions. There is
little harm in passing the flag to a driver that does not use it.
Passing the flag to drivers avoids changes across many block drivers.
Filter drivers would need to explicitly support the flag and pass
through to their children when the children support it. That's a lot of
code changes and it's hard to remember to do that everywhere, leading to
silent reduced performance when the flag is accidentally dropped.
The only problematic scenario with the approach in this patch is when a
driver passes the flag through to internal I/O requests that don't use
the same I/O buffer. In that case the hint may be set when it should
actually be clear. This is a rare case though so the risk is low.
Some drivers have assert(!flags), which no longer works when
BDRV_REQ_REGISTERED_BUF is passed in. These assertions aren't very
useful anyway since the functions are called almost exclusively by
bdrv_driver_preadv/pwritev() so if we get flags handling right there
then the assertion is not needed.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 20221013185908.1297568-7-stefanha@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Use the enum type so GDB displays the enum members instead of printing a
numeric constant.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Message-id: 20221013185908.1297568-6-stefanha@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
The only implementor of bdrv_register_buf() is block/nvme.c, where the
size is not needed when unregistering a buffer. This is because
util/vfio-helpers.c can look up mappings by address.
Future block drivers that implement bdrv_register_buf() may not be able
to do their job given only the buffer address. Add a size argument to
bdrv_unregister_buf().
Also document the assumptions about
bdrv_register_buf()/bdrv_unregister_buf() calls. The same <host, size>
values that were given to bdrv_register_buf() must be given to
bdrv_unregister_buf().
gcc 11.2.1 emits a spurious warning that img_bench()'s buf_size local
variable might be uninitialized, so it's necessary to silence the
compiler.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Message-id: 20221013185908.1297568-5-stefanha@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
When a RAMBlockNotifier is added, ->ram_block_added() is called with all
existing RAMBlocks. There is no equivalent ->ram_block_removed() call
when a RAMBlockNotifier is removed.
The util/vfio-helpers.c code (the sole user of RAMBlockNotifier) is fine
with this asymmetry because it does not rely on RAMBlockNotifier for
cleanup. It walks its internal list of DMA mappings and unmaps them by
itself.
Future users of RAMBlockNotifier may not have an internal data structure
that records added RAMBlocks so they will need ->ram_block_removed()
callbacks.
This patch makes ram_block_notifier_remove() symmetric with respect to
callbacks. Now util/vfio-helpers.c needs to unmap remaining DMA mappings
after ram_block_notifier_remove() has been called. This is necessary
since users like block/nvme.c may create additional DMA mappings that do
not originate from the RAMBlockNotifier.
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 20221013185908.1297568-4-stefanha@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
libblkio (https://gitlab.com/libblkio/libblkio/) is a library for
high-performance disk I/O. It currently supports io_uring,
virtio-blk-vhost-user, and virtio-blk-vhost-vdpa with additional drivers
under development.
One of the reasons for developing libblkio is that other applications
besides QEMU can use it. This will be particularly useful for
virtio-blk-vhost-user which applications may wish to use for connecting
to qemu-storage-daemon.
libblkio also gives us an opportunity to develop in Rust behind a C API
that is easy to consume from QEMU.
This commit adds io_uring, nvme-io_uring, virtio-blk-vhost-user, and
virtio-blk-vhost-vdpa BlockDrivers to QEMU using libblkio. It will be
easy to add other libblkio drivers since they will share the majority of
code.
For now I/O buffers are copied through bounce buffers if the libblkio
driver requires it. Later commits add an optimization for
pre-registering guest RAM to avoid bounce buffers.
The syntax is:
--blockdev io_uring,node-name=drive0,filename=test.img,readonly=on|off,cache.direct=on|off
--blockdev nvme-io_uring,node-name=drive0,filename=/dev/ng0n1,readonly=on|off,cache.direct=on
--blockdev virtio-blk-vhost-vdpa,node-name=drive0,path=/dev/vdpa...,readonly=on|off,cache.direct=on
--blockdev virtio-blk-vhost-user,node-name=drive0,path=vhost-user-blk.sock,readonly=on|off,cache.direct=on
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Message-id: 20221013185908.1297568-3-stefanha@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
When a coroutine wakes up it may determine that it must re-queue.
Normally coroutines are pushed onto the back of the CoQueue, but for
fairness it may be necessary to push it onto the front of the CoQueue.
Add a flag to specify that the coroutine should be pushed onto the front
of the CoQueue. A later patch will use this to ensure fairness in the
bounce buffer CoQueue used by the blkio BlockDriver.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 20221013185908.1297568-2-stefanha@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
When the emulation stops with a hard exception it's very useful for
debugging purposes to dump the current guest memory layout (for an
example see /proc/self/maps) beside the CPU registers.
The open_self_maps() function provides such a memory dump, but since
it's located in the syscall.c file, various changes (add #includes, make
this function externally visible, ...) are needed to be able to call it
from the existing EXCP_DUMP() macro.
This patch takes another approach by re-defining EXCP_DUMP() to call
target_exception_dump(), which is in syscall.c, consolidates the log
print functions and allows to add the call to dump the memory layout.
Beside a reduced code footprint, this approach keeps the changes across
the various callers minimal, and keeps EXCP_DUMP() highlighted as
important macro/function.
Signed-off-by: Helge Deller <deller@gmx.de>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <Y1bzAWbw07WBKPxw@p100>
[lv: remove pc declaration and setting]
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
* Highlight of this PR is Linus Heckemann's GHashTable patch which
brings massive general performance improvements of 9p server
somewhere between factor 6 .. 12.
* Bin Meng's g_mkdir patch is a preparatory patch for upcoming
Windows host support of 9p server.
* The rest of the patches in this PR are 9p test code restructuring
and refactoring changes to improve readability and to ease
maintenance of 9p test code on the long-term.
-----BEGIN PGP SIGNATURE-----
iQJLBAABCgA1FiEEltjREM96+AhPiFkBNMK1h2Wkc5UFAmNWbs8XHHFlbXVfb3Nz
QGNydWRlYnl0ZS5jb20ACgkQNMK1h2Wkc5V4cw/8CqoSJqoJixlP8kAGDYWq3CgF
SKd09rIzLSWyyufAoZr1TqLwRrvEQRlZJSpL4fGvRpQLv0IQCu4x59ohHRob25Tm
Fe7IxYBNuBwLW4yu+Y7FaujeGoYAi9Qw5q4ijq3/aSSiIeuXySKB2JmW71CQ+Tbe
uwivsnMtWzQ7qsNwrtXYbxDs7UGkdsiW2sEQUS26GMApAXZoB+38hwtTW2Y9MOrC
58JuZza/fUVPzo0V1D0ggRawb5O2VTF5fz8aGFG4FvoyIW6DDZFSfnyre9QxivOl
5McWwSQ/D04vdEK9ornGPYr9YRGuP8g07p1EW9OfKeie4I41e9pS3UminK5lVCgo
SfBHzz96efM5XR+Wnl4yVKowivmTqjwUU8lDqW2eB/7YBRuYUzrpxYe//UPv4q1J
zaQV3pgwFAVkVJCnkcLCa1JQbH581bXSsuRlDdYqoRYfyzXoxbywNjvn9BXE0PrG
WRecS//GyN3GVZYxMwb3H052110pYsYIg2YZ2H4QiqCwpEHHvy+L/ZXm19vbDm7B
GYJQPUK8/y0NGwZsUYcUSx1TWlU9ZPwrbqZfv7e7+B6FL4VNjdaqb8PvS9admWSq
LOSzrVVIus+nb7tP99d1Fb6oRyCy3x8E48gTr5UtTJHC4SAw/OBJmem6GOc/D490
H7Dq8Y27qsQ6fT7iPm8=
=MxSG
-----END PGP SIGNATURE-----
Merge tag 'pull-9p-20221024' of https://github.com/cschoenebeck/qemu into staging
9pfs: performance, Windows host prep, tests restructure
* Highlight of this PR is Linus Heckemann's GHashTable patch which
brings massive general performance improvements of 9p server
somewhere between factor 6 .. 12.
* Bin Meng's g_mkdir patch is a preparatory patch for upcoming
Windows host support of 9p server.
* The rest of the patches in this PR are 9p test code restructuring
and refactoring changes to improve readability and to ease
maintenance of 9p test code on the long-term.
# -----BEGIN PGP SIGNATURE-----
#
# iQJLBAABCgA1FiEEltjREM96+AhPiFkBNMK1h2Wkc5UFAmNWbs8XHHFlbXVfb3Nz
# QGNydWRlYnl0ZS5jb20ACgkQNMK1h2Wkc5V4cw/8CqoSJqoJixlP8kAGDYWq3CgF
# SKd09rIzLSWyyufAoZr1TqLwRrvEQRlZJSpL4fGvRpQLv0IQCu4x59ohHRob25Tm
# Fe7IxYBNuBwLW4yu+Y7FaujeGoYAi9Qw5q4ijq3/aSSiIeuXySKB2JmW71CQ+Tbe
# uwivsnMtWzQ7qsNwrtXYbxDs7UGkdsiW2sEQUS26GMApAXZoB+38hwtTW2Y9MOrC
# 58JuZza/fUVPzo0V1D0ggRawb5O2VTF5fz8aGFG4FvoyIW6DDZFSfnyre9QxivOl
# 5McWwSQ/D04vdEK9ornGPYr9YRGuP8g07p1EW9OfKeie4I41e9pS3UminK5lVCgo
# SfBHzz96efM5XR+Wnl4yVKowivmTqjwUU8lDqW2eB/7YBRuYUzrpxYe//UPv4q1J
# zaQV3pgwFAVkVJCnkcLCa1JQbH581bXSsuRlDdYqoRYfyzXoxbywNjvn9BXE0PrG
# WRecS//GyN3GVZYxMwb3H052110pYsYIg2YZ2H4QiqCwpEHHvy+L/ZXm19vbDm7B
# GYJQPUK8/y0NGwZsUYcUSx1TWlU9ZPwrbqZfv7e7+B6FL4VNjdaqb8PvS9admWSq
# LOSzrVVIus+nb7tP99d1Fb6oRyCy3x8E48gTr5UtTJHC4SAw/OBJmem6GOc/D490
# H7Dq8Y27qsQ6fT7iPm8=
# =MxSG
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 24 Oct 2022 06:54:07 EDT
# 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-20221024' of https://github.com/cschoenebeck/qemu: (23 commits)
tests/9p: remove unnecessary g_strdup() calls
tests/9p: merge v9fs_tunlinkat() and do_unlinkat()
tests/9p: merge v9fs_tlink() and do_hardlink()
tests/9p: merge v9fs_tsymlink() and do_symlink()
tests/9p: merge v9fs_tlcreate() and do_lcreate()
tests/9p: merge v9fs_tmkdir() and do_mkdir()
tests/9p: convert v9fs_tflush() to declarative arguments
tests/9p: simplify callers of twrite()
tests/9p: convert v9fs_twrite() to declarative arguments
tests/9p: simplify callers of tlopen()
tests/9p: convert v9fs_tlopen() to declarative arguments
tests/9p: simplify callers of treaddir()
tests/9p: convert v9fs_treaddir() to declarative arguments
tests/9p: simplify callers of tgetattr()
tests/9p: convert v9fs_tgetattr() to declarative arguments
tests/9p: simplify callers of tattach()
tests/9p: merge v9fs_tattach(), do_attach(), do_attach_rqid()
tests/9p: merge v9fs_tversion() and do_version()
tests/9p: simplify callers of twalk()
tests/9p: merge *walk*() functions
...
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Commit 8f9abdf586 ("chardev: src buffer const for write functions")
changed the type of the second parameter of qemu_chr_be_write()
from uint8_t * to const uint8_t *. Remove the now useless type
casts from qemu_chr_be_write() function calls in ui/console.c and
ui/gtk.c.
Cc: qemu-trivial@nongnu.org
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Claudio Fontana <cfontana@suse.de>
Message-Id: <20221022141204.29358-1-vr_qemu@t-online.de>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
This is a leftover from before the recent function merge and
refactoring patches:
As these functions do not return control to the caller in
between, it is not necessary to duplicate strings passed to them.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <0f80141cde3904ed0591354059da49d1d60bcdbc.1664917004.git.qemu_oss@crudebyte.com>
As with previous patches, unify those 2 functions into a single function
v9fs_tunlinkat() by using a declarative function arguments approach.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <1dea593edd464908d92501933c068388c01f1744.1664917004.git.qemu_oss@crudebyte.com>
As with previous patches, unify those 2 functions into a single function
v9fs_tlink() by using a declarative function arguments approach.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <cb4d42203e1e4e6027df4924bbe4bdbc002f668b.1664917004.git.qemu_oss@crudebyte.com>
As with previous patches, unify those 2 functions into a single function
v9fs_tsymlink() by using a declarative function arguments approach.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <563f3ad04fe596ce0ae1e2654d1d08237f18c830.1664917004.git.qemu_oss@crudebyte.com>
As with previous patches, unify those 2 functions into a single function
v9fs_tlcreate() by using a declarative function arguments approach.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <4c01b2caa5f5b54a2020fc92701deadd2abf0571.1664917004.git.qemu_oss@crudebyte.com>
As with previous patches, unify those 2 functions into a single function
v9fs_tmkdir() by using a declarative function arguments approach.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <b87b2c972921df980440ff5b2d3e6bb8163d6551.1664917004.git.qemu_oss@crudebyte.com>
Use declarative function arguments for function v9fs_tflush().
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <91b7b154298c500d100b05137146c2905c3acdec.1664917004.git.qemu_oss@crudebyte.com>
Now as twrite() is using a declarative approach, simplify the
code of callers of this function.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <7f280ec6a1f9d8afed46567a796562c4dc28afa9.1664917004.git.qemu_oss@crudebyte.com>
Use declarative function arguments for function v9fs_twrite().
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <be0326e2d9ab66f68c06b1766ddf103849d570b4.1664917004.git.qemu_oss@crudebyte.com>
Now as tlopen() is using a declarative approach, simplify the
code of callers of this function.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <f74b6153e079fc7a340e5cb575ee32e0fe1e0ae6.1664917004.git.qemu_oss@crudebyte.com>
Use declarative function arguments for function v9fs_tlopen().
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <765ab515353c56f88f0a163631f626a44e9565d6.1664917004.git.qemu_oss@crudebyte.com>
Now as treaddir() is using a declarative approach, simplify the
code of callers of this function.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <7cec6f2c7011a481806c34908893b7282702a7a6.1664917004.git.qemu_oss@crudebyte.com>
Use declarative function arguments for function v9fs_treaddir().
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <a66aae4ceb19ec12d245b8c7f33a639584c8e272.1664917004.git.qemu_oss@crudebyte.com>
Now as tgetattr() is using a declarative approach, simplify the
code of callers of this function.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <60c6a083f320b86f3172951445df7bbc895932e2.1664917004.git.qemu_oss@crudebyte.com>
Use declarative function arguments for function v9fs_tgetattr().
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <d340a91be96fbfecfb8dacdd7558223b3c0d0e2c.1664917004.git.qemu_oss@crudebyte.com>
Now as tattach() is using a declarative approach, simplify the
code of callers of this function.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <9b50e5b89a0072e84a9191d18c19a53546a28bba.1664917004.git.qemu_oss@crudebyte.com>
As with previous patches, unify those 3 functions into a single function
v9fs_tattach() by using a declarative function arguments approach.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <a6756b30bf2a1b25729c5bbabd1c9534a8f20d6f.1664917004.git.qemu_oss@crudebyte.com>
As with previous patches, unify functions v9fs_tversion() and do_version()
into a single function v9fs_tversion() by using a declarative function
arguments approach.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <2d253491aaffd267ec295f056dda47456692cd0c.1664917004.git.qemu_oss@crudebyte.com>
Now as twalk() is using a declarative approach, simplify the
code of callers of this function.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <8b9d3c656ad43b6c953d6bdacd8d9f4c8e599b2a.1664917004.git.qemu_oss@crudebyte.com>
Introduce declarative function calls.
There are currently 4 different functions for sending a 9p 'Twalk'
request: v9fs_twalk(), do_walk(), do_walk_rqids() and
do_walk_expect_error(). They are all doing the same thing, just in a
slightly different way and with slightly different function arguments.
Merge those 4 functions into a single function by using a struct for
function call arguments and use designated initializers when calling
this function to turn usage into a declarative approach, which is
better readable and easier to maintain.
Also move private functions genfid(), split() and split_free() from
virtio-9p-test.c to virtio-9p-client.c.
Based-on: <E1odrya-0004Fv-97@lizzy.crudebyte.com>
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <607969dbfbc63c1be008df9131133711b046e979.1664917004.git.qemu_oss@crudebyte.com>
The previous implementation would iterate over the fid table for
lookup operations, resulting in an operation with O(n) complexity on
the number of open files and poor cache locality -- for every open,
stat, read, write, etc operation.
This change uses a hashtable for this instead, significantly improving
the performance of the 9p filesystem. The runtime of NixOS's simple
installer test, which copies ~122k files totalling ~1.8GiB from 9p,
decreased by a factor of about 10.
Signed-off-by: Linus Heckemann <git@sphalerite.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Greg Kurz <groug@kaod.org>
[CS: - Retain BUG_ON(f->clunked) in get_fid().
- Add TODO comment in clunk_fid(). ]
Message-Id: <20221004104121.713689-1-git@sphalerite.org>
[CS: - Drop unnecessary goto and out: label. ]
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
This patch is pure refactoring, it does not change behaviour.
virtio-9p-test.c grew to 1657 lines. Let's split this file up between
actual 9p test cases vs. 9p test client, to make it easier to
concentrate on the actual 9p tests.
Move the 9p test client code to a new unit virtio-9p-client.c, which
are basically all functions and types prefixed with v9fs_* already.
Note that some client wrapper functions (do_*) are preserved in
virtio-9p-test.c, simply because these wrapper functions are going to
be wiped with subsequent patches anyway.
As the global QGuestAllocator variable is moved to virtio-9p-client.c,
add a new function v9fs_set_allocator() to be used by virtio-9p-test.c
instead of fiddling with a global variable across units and libraries.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <E1odrya-0004Fv-97@lizzy.crudebyte.com>
Use g_mkdir() to create a directory on all platforms.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <20220927110632.1973965-27-bmeng.cn@gmail.com>
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Rather than poking directly into RAM, add the bootinfo block as a proper
ROM, so that it's restored when rebooting the system. This way, if the
guest corrupts any of the bootinfo items, but then tries to reboot,
it'll still be restored back to normal as expected.
Then, since the RNG seed needs to be fresh on each boot, regenerate the
RNG seed in the ROM when reseting the CPU.
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Laurent Vivier <laurent@vivier.eu>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Message-Id: <20221023191340.36238-1-Jason@zx2c4.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
In commit 1454509726 we removed the function
scsi_legacy_handle_cmdline() and all of its callers, but forgot to
delete the prototype from the header function. Delete the prototype
too.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20221013130500.967432-1-peter.maydell@linaro.org>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Jump statements, such as return and continue let you
change the default flow of program execution,
but jump statements that direct the control flow to
the original direction are just a waste of keystrokes.
Signed-off-by: dinglimin <dinglimin@cmss.chinamobile.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Message-Id: <20220928090312.2537-1-dinglimin@cmss.chinamobile.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
When tmpfs is NULL, a build warning is seen with GCC 9.3.0.
It's strange that GCC 11.2.0 on Ubuntu 22.04 does not catch this,
neither did the QEMU CI.
While we are here, improve the error message as well.
Reported-by: Shengjiang Wu <shengjiang.wu@windriver.com>
Fixes: e6efe236c1 ("tests/qtest: vhost-user-test: Avoid using hardcoded /tmp")
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20221017132023.2228641-2-bmeng.cn@gmail.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
When tmpfs is NULL, a build warning is seen with GCC 9.3.0.
It's strange that GCC 11.2.0 on Ubuntu 22.04 does not catch this,
neither did the QEMU CI.
While we are here, improve the error message as well.
Reported-by: Shengjiang Wu <shengjiang.wu@windriver.com>
Fixes: e5553c1b8d ("tests/qtest: migration-test: Avoid using hardcoded /tmp")
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20221017132023.2228641-1-bmeng.cn@gmail.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
These memory allocation functions return void *, and casting to
another pointer type is useless clutter. Drop these casts.
If you really want another pointer type, consider g_new().
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20220923120025.448759-3-armbru@redhat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
The 'kdgb' is allocating memory in get_kdbg(), but it is not freed in
error path. So fix that.
Signed-off-by: lu zhipeng <luzhipeng@cestc.cn>
Reviewed-by: Viktor Prutyanov <viktor.prutyanov@phystech.edu>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20221007020128.760-1-luzhipeng@cestc.cn>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Add /.vscode/, .clang-format and .gdb_history to .gitignore because:
- For VSCode, workspace settings as well as debugging and task
configurations are stored at the root in a .vscode folder;
- For ClangFormat, the .clang-format file is searched relative to
the current working directory when reading stdin;
- For GDB, GDB command history file defaults to the value of the
environment variable GDBHISTFILE, or to ./.gdb_history if this
variable is not set.
Signed-off-by: Wang, Lei <lei4.wang@intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20221020171921.1078533-1-lei4.wang@intel.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
The only issue with FMA instructions is that there are _a lot_ of them (30
opcodes, each of which comes in up to 4 versions depending on VEX.W and
VEX.L; a total of 96 possibilities). However, they can be implement with
only 6 helpers, two for scalar operations and four for packed operations.
(Scalar versions do not do any merging; they only affect the bottom 32
or 64 bits of the output operand. Therefore, there is no separate XMM
and YMM of the scalar helpers).
First, we can reduce the number of helpers to one third by passing four
operands (one output and three inputs); the reordering of which operands
go to the multiply and which go to the add is done in emit.c.
Second, the different instructions also dispatch to the same softfloat
function, so the flags for float32_muladd and float64_muladd are passed
in the helper as int arguments, with a little extra complication to
handle FMADDSUB and FMSUBADD.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Following a change on the kernel side (see link), pass BI_RNG_SEED
instead of BI_VIRT_RNG_SEED. This should have no impact on
compatibility, as there will simply be no effect if it's an old kernel,
which is how things have always been. We then use this as an opportunity
to add this to q800, since now we can, which is a nice improvement.
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Laurent Vivier <laurent@vivier.eu>
Link: https://lore.kernel.org/lkml/20220923170340.4099226-3-Jason@zx2c4.com/
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Message-Id: <20220926113900.1256630-1-Jason@zx2c4.com>
[lv: s/^I/ /g]
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
User space has been preferring this syscall for a while, due to its
closer match with C semantics, and newer platforms such as LoongArch
apparently have libc implementations that don't fallback to faccessat
so normal access checks are failing without the emulation in place.
Tested by successfully emerging several packages within a Gentoo loong
stage3 chroot, emulated on amd64 with help of static qemu-loongarch64.
Reported-by: Andreas K. Hüttel <dilfridge@gentoo.org>
Signed-off-by: WANG Xuerui <xen0n@gentoo.org>
Message-Id: <20221009060813.2289077-1-xen0n@gentoo.org>
[lv: removing defined(__NR_faccessat2) in syscall.c,
adding defined(TARGET_NR_faccessat2) on print_faccessat()]
Signed-off-by: Laurent Vivier <laurent@vivier.eu>