2010-10-26 10:39:19 +02:00
|
|
|
/*
|
|
|
|
* os-posix-lib.c
|
|
|
|
*
|
|
|
|
* Copyright (c) 2003-2008 Fabrice Bellard
|
|
|
|
* Copyright (c) 2010 Red Hat, Inc.
|
|
|
|
*
|
|
|
|
* QEMU library functions on POSIX which are shared between QEMU and
|
|
|
|
* the QEMU tools.
|
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
|
|
* of this software and associated documentation files (the "Software"), to deal
|
|
|
|
* in the Software without restriction, including without limitation the rights
|
|
|
|
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
|
|
* copies of the Software, and to permit persons to whom the Software is
|
|
|
|
* furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice shall be included in
|
|
|
|
* all copies or substantial portions of the Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
|
|
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
|
|
|
|
* THE SOFTWARE.
|
|
|
|
*/
|
|
|
|
|
2016-01-29 18:49:55 +01:00
|
|
|
#include "qemu/osdep.h"
|
2013-11-14 11:54:16 +01:00
|
|
|
#include <termios.h>
|
|
|
|
|
2013-05-18 06:31:48 +02:00
|
|
|
#include <glib/gprintf.h>
|
|
|
|
|
2012-12-17 18:20:04 +01:00
|
|
|
#include "sysemu/sysemu.h"
|
2010-10-26 10:39:19 +02:00
|
|
|
#include "trace.h"
|
include/qemu/osdep.h: Don't include qapi/error.h
Commit 57cb38b included qapi/error.h into qemu/osdep.h to get the
Error typedef. Since then, we've moved to include qemu/osdep.h
everywhere. Its file comment explains: "To avoid getting into
possible circular include dependencies, this file should not include
any other QEMU headers, with the exceptions of config-host.h,
compiler.h, os-posix.h and os-win32.h, all of which are doing a
similar job to this file and are under similar constraints."
qapi/error.h doesn't do a similar job, and it doesn't adhere to
similar constraints: it includes qapi-types.h. That's in excess of
100KiB of crap most .c files don't actually need.
Add the typedef to qemu/typedefs.h, and include that instead of
qapi/error.h. Include qapi/error.h in .c files that need it and don't
get it now. Include qapi-types.h in qom/object.h for uint16List.
Update scripts/clean-includes accordingly. Update it further to match
reality: replace config.h by config-target.h, add sysemu/os-posix.h,
sysemu/os-win32.h. Update the list of includes in the qemu/osdep.h
comment quoted above similarly.
This reduces the number of objects depending on qapi/error.h from "all
of them" to less than a third. Unfortunately, the number depending on
qapi-types.h shrinks only a little. More work is needed for that one.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
[Fix compilation without the spice devel packages. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-03-14 09:01:28 +01:00
|
|
|
#include "qapi/error.h"
|
2021-12-17 14:46:10 +01:00
|
|
|
#include "qemu/error-report.h"
|
2022-02-08 21:08:52 +01:00
|
|
|
#include "qemu/madvise.h"
|
2012-12-17 18:20:00 +01:00
|
|
|
#include "qemu/sockets.h"
|
Include qemu/main-loop.h less
In my "build everything" tree, changing qemu/main-loop.h triggers a
recompile of some 5600 out of 6600 objects (not counting tests and
objects that don't depend on qemu/osdep.h). It includes block/aio.h,
which in turn includes qemu/event_notifier.h, qemu/notify.h,
qemu/processor.h, qemu/qsp.h, qemu/queue.h, qemu/thread-posix.h,
qemu/thread.h, qemu/timer.h, and a few more.
Include qemu/main-loop.h only where it's needed. Touching it now
recompiles only some 1700 objects. For block/aio.h and
qemu/event_notifier.h, these numbers drop from 5600 to 2800. For the
others, they shrink only slightly.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20190812052359.30071-21-armbru@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-08-12 07:23:50 +02:00
|
|
|
#include "qemu/thread.h"
|
2014-02-10 07:48:51 +01:00
|
|
|
#include <libgen.h>
|
2016-03-20 18:16:19 +01:00
|
|
|
#include "qemu/cutils.h"
|
2021-12-17 14:46:07 +01:00
|
|
|
#include "qemu/units.h"
|
util: Introduce ThreadContext user-creatable object
Setting the CPU affinity of QEMU threads is a bit problematic, because
QEMU doesn't always have permissions to set the CPU affinity itself,
for example, with seccomp after initialized by QEMU:
-sandbox enable=on,resourcecontrol=deny
General information about CPU affinities can be found in the man page of
taskset:
CPU affinity is a scheduler property that "bonds" a process to a given
set of CPUs on the system. The Linux scheduler will honor the given CPU
affinity and the process will not run on any other CPUs.
While upper layers are already aware of how to handle CPU affinities for
long-lived threads like iothreads or vcpu threads, especially short-lived
threads, as used for memory-backend preallocation, are more involved to
handle. These threads are created on demand and upper layers are not even
able to identify and configure them.
Introduce the concept of a ThreadContext, that is essentially a thread
used for creating new threads. All threads created via that context
thread inherit the configured CPU affinity. Consequently, it's
sufficient to create a ThreadContext and configure it once, and have all
threads created via that ThreadContext inherit the same CPU affinity.
The CPU affinity of a ThreadContext can be configured two ways:
(1) Obtaining the thread id via the "thread-id" property and setting the
CPU affinity manually (e.g., via taskset).
(2) Setting the "cpu-affinity" property and letting QEMU try set the
CPU affinity itself. This will fail if QEMU doesn't have permissions
to do so anymore after seccomp was initialized.
A simple QEMU example to set the CPU affinity to host CPU 0,1,6,7 would be:
qemu-system-x86_64 -S \
-object thread-context,id=tc1,cpu-affinity=0-1,cpu-affinity=6-7
And we can query it via HMP/QMP:
(qemu) qom-get tc1 cpu-affinity
[
0,
1,
6,
7
]
But note that due to dynamic library loading this example will not work
before we actually make use of thread_context_create_thread() in QEMU
code, because the type will otherwise not get registered. We'll wire
this up next to make it work.
In general, the interface behaves like pthread_setaffinity_np(): host
CPU numbers that are currently not available are ignored; only host CPU
numbers that are impossible with the current kernel will fail. If the
list of host CPU numbers does not include a single CPU that is
available, setting the CPU affinity will fail.
A ThreadContext can be reused, simply by reconfiguring the CPU affinity.
Note that the CPU affinity of previously created threads will not get
adjusted.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20221014134720.168738-4-david@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
2022-10-14 15:47:16 +02:00
|
|
|
#include "qemu/thread-context.h"
|
2024-01-31 17:53:27 +01:00
|
|
|
#include "qemu/main-loop.h"
|
2010-10-26 10:39:19 +02:00
|
|
|
|
2011-09-12 16:20:11 +02:00
|
|
|
#ifdef CONFIG_LINUX
|
|
|
|
#include <sys/syscall.h>
|
|
|
|
#endif
|
|
|
|
|
2014-03-13 14:27:59 +01:00
|
|
|
#ifdef __FreeBSD__
|
2020-05-26 09:25:26 +02:00
|
|
|
#include <sys/thr.h>
|
2022-05-25 16:41:26 +02:00
|
|
|
#include <sys/user.h>
|
2016-09-27 17:24:56 +02:00
|
|
|
#include <libutil.h>
|
2014-03-13 14:27:59 +01:00
|
|
|
#endif
|
|
|
|
|
2017-10-28 21:48:33 +02:00
|
|
|
#ifdef __NetBSD__
|
2020-05-26 09:25:26 +02:00
|
|
|
#include <lwp.h>
|
2017-10-28 21:48:33 +02:00
|
|
|
#endif
|
|
|
|
|
2016-06-22 19:11:19 +02:00
|
|
|
#include "qemu/mmap-alloc.h"
|
2015-09-24 13:41:17 +02:00
|
|
|
|
2017-03-21 07:50:06 +01:00
|
|
|
#define MAX_MEM_PREALLOC_THREAD_COUNT 16
|
2017-02-24 04:31:43 +01:00
|
|
|
|
2021-12-17 14:46:06 +01:00
|
|
|
struct MemsetThread;
|
|
|
|
|
2024-01-31 17:53:27 +01:00
|
|
|
static QLIST_HEAD(, MemsetContext) memset_contexts =
|
|
|
|
QLIST_HEAD_INITIALIZER(memset_contexts);
|
|
|
|
|
2021-12-17 14:46:06 +01:00
|
|
|
typedef struct MemsetContext {
|
|
|
|
bool all_threads_created;
|
|
|
|
bool any_thread_failed;
|
|
|
|
struct MemsetThread *threads;
|
|
|
|
int num_threads;
|
2024-01-31 17:53:27 +01:00
|
|
|
QLIST_ENTRY(MemsetContext) next;
|
2021-12-17 14:46:06 +01:00
|
|
|
} MemsetContext;
|
|
|
|
|
2017-02-24 04:31:43 +01:00
|
|
|
struct MemsetThread {
|
|
|
|
char *addr;
|
2017-10-16 22:29:12 +02:00
|
|
|
size_t numpages;
|
|
|
|
size_t hpagesize;
|
2017-02-24 04:31:43 +01:00
|
|
|
QemuThread pgthread;
|
|
|
|
sigjmp_buf env;
|
2021-12-17 14:46:06 +01:00
|
|
|
MemsetContext *context;
|
2017-02-24 04:31:43 +01:00
|
|
|
};
|
|
|
|
typedef struct MemsetThread MemsetThread;
|
|
|
|
|
2021-12-17 14:46:06 +01:00
|
|
|
/* used by sigbus_handler() */
|
|
|
|
static MemsetContext *sigbus_memset_context;
|
2021-12-17 14:46:10 +01:00
|
|
|
struct sigaction sigbus_oldact;
|
2021-12-17 14:46:09 +01:00
|
|
|
static QemuMutex sigbus_mutex;
|
2017-02-24 04:31:43 +01:00
|
|
|
|
mem-prealloc: optimize large guest startup
[desc]:
Large memory VM starts slowly when using -mem-prealloc, and
there are some areas to optimize in current method;
1、mmap will be used to alloc threads stack during create page
clearing threads, and it will attempt mm->mmap_sem for write
lock, but clearing threads have hold read lock, this competition
will cause threads createion very slow;
2、methods of calcuating pages for per threads is not well;if we use
64 threads to split 160 hugepage,63 threads clear 2page,1 thread
clear 34 page,so the entire speed is very slow;
to solve the first problem,we add a mutex in thread function,and
start all threads when all threads finished createion;
and the second problem, we spread remainder to other threads,in
situation that 160 hugepage and 64 threads, there are 32 threads
clear 3 pages,and 32 threads clear 2 pages.
[test]:
320G 84c VM start time can be reduced to 10s
680G 84c VM start time can be reduced to 18s
Signed-off-by: bauerchen <bauerchen@tencent.com>
Reviewed-by: Pan Rui <ruippan@tencent.com>
Reviewed-by: Ivan Ren <ivanren@tencent.com>
[Simplify computation of the number of pages per thread. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-02-11 10:10:35 +01:00
|
|
|
static QemuMutex page_mutex;
|
|
|
|
static QemuCond page_cond;
|
|
|
|
|
2011-09-12 16:20:11 +02:00
|
|
|
int qemu_get_thread_id(void)
|
|
|
|
{
|
|
|
|
#if defined(__linux__)
|
|
|
|
return syscall(SYS_gettid);
|
2020-05-26 09:25:26 +02:00
|
|
|
#elif defined(__FreeBSD__)
|
|
|
|
/* thread id is up to INT_MAX */
|
|
|
|
long tid;
|
|
|
|
thr_self(&tid);
|
|
|
|
return (int)tid;
|
|
|
|
#elif defined(__NetBSD__)
|
|
|
|
return _lwp_self();
|
2020-07-20 11:25:36 +02:00
|
|
|
#elif defined(__OpenBSD__)
|
|
|
|
return getthrid();
|
2011-09-12 16:20:11 +02:00
|
|
|
#else
|
|
|
|
return getpid();
|
|
|
|
#endif
|
|
|
|
}
|
2011-06-07 05:34:10 +02:00
|
|
|
|
|
|
|
int qemu_daemon(int nochdir, int noclose)
|
|
|
|
{
|
|
|
|
return daemon(nochdir, noclose);
|
|
|
|
}
|
|
|
|
|
util: add qemu_write_pidfile()
There are variants of qemu_create_pidfile() in qemu-pr-helper and
qemu-ga. Let's have a common implementation in libqemuutil.
The code is initially based from pr-helper write_pidfile(), with
various improvements and suggestions from Daniel Berrangé:
QEMU will leave the pidfile existing on disk when it exits which
initially made me think it avoids the deletion race. The app
managing QEMU, however, may well delete the pidfile after it has
seen QEMU exit, and even if the app locks the pidfile before
deleting it, there is still a race.
eg consider the following sequence
QEMU 1 libvirtd QEMU 2
1. lock(pidfile)
2. exit()
3. open(pidfile)
4. lock(pidfile)
5. open(pidfile)
6. unlink(pidfile)
7. close(pidfile)
8. lock(pidfile)
IOW, at step 8 the new QEMU has successfully acquired the lock, but
the pidfile no longer exists on disk because it was deleted after
the original QEMU exited.
While we could just say no external app should ever delete the
pidfile, I don't think that is satisfactory as people don't read
docs, and admins don't like stale pidfiles being left around on
disk.
To make this robust, I think we might want to copy libvirt's
approach to pidfile acquisition which runs in a loop and checks that
the file on disk /after/ acquiring the lock matches the file that
was locked. Then we could in fact safely let QEMU delete its own
pidfiles on clean exit..
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20180831145314.14736-2-marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-08-31 16:53:12 +02:00
|
|
|
bool qemu_write_pidfile(const char *path, Error **errp)
|
|
|
|
{
|
|
|
|
int fd;
|
|
|
|
char pidstr[32];
|
|
|
|
|
|
|
|
while (1) {
|
|
|
|
struct stat a, b;
|
2018-08-31 16:53:13 +02:00
|
|
|
struct flock lock = {
|
|
|
|
.l_type = F_WRLCK,
|
|
|
|
.l_whence = SEEK_SET,
|
|
|
|
.l_len = 0,
|
|
|
|
};
|
util: add qemu_write_pidfile()
There are variants of qemu_create_pidfile() in qemu-pr-helper and
qemu-ga. Let's have a common implementation in libqemuutil.
The code is initially based from pr-helper write_pidfile(), with
various improvements and suggestions from Daniel Berrangé:
QEMU will leave the pidfile existing on disk when it exits which
initially made me think it avoids the deletion race. The app
managing QEMU, however, may well delete the pidfile after it has
seen QEMU exit, and even if the app locks the pidfile before
deleting it, there is still a race.
eg consider the following sequence
QEMU 1 libvirtd QEMU 2
1. lock(pidfile)
2. exit()
3. open(pidfile)
4. lock(pidfile)
5. open(pidfile)
6. unlink(pidfile)
7. close(pidfile)
8. lock(pidfile)
IOW, at step 8 the new QEMU has successfully acquired the lock, but
the pidfile no longer exists on disk because it was deleted after
the original QEMU exited.
While we could just say no external app should ever delete the
pidfile, I don't think that is satisfactory as people don't read
docs, and admins don't like stale pidfiles being left around on
disk.
To make this robust, I think we might want to copy libvirt's
approach to pidfile acquisition which runs in a loop and checks that
the file on disk /after/ acquiring the lock matches the file that
was locked. Then we could in fact safely let QEMU delete its own
pidfiles on clean exit..
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20180831145314.14736-2-marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-08-31 16:53:12 +02:00
|
|
|
|
2022-04-20 15:26:20 +02:00
|
|
|
fd = qemu_create(path, O_WRONLY, S_IRUSR | S_IWUSR, errp);
|
util: add qemu_write_pidfile()
There are variants of qemu_create_pidfile() in qemu-pr-helper and
qemu-ga. Let's have a common implementation in libqemuutil.
The code is initially based from pr-helper write_pidfile(), with
various improvements and suggestions from Daniel Berrangé:
QEMU will leave the pidfile existing on disk when it exits which
initially made me think it avoids the deletion race. The app
managing QEMU, however, may well delete the pidfile after it has
seen QEMU exit, and even if the app locks the pidfile before
deleting it, there is still a race.
eg consider the following sequence
QEMU 1 libvirtd QEMU 2
1. lock(pidfile)
2. exit()
3. open(pidfile)
4. lock(pidfile)
5. open(pidfile)
6. unlink(pidfile)
7. close(pidfile)
8. lock(pidfile)
IOW, at step 8 the new QEMU has successfully acquired the lock, but
the pidfile no longer exists on disk because it was deleted after
the original QEMU exited.
While we could just say no external app should ever delete the
pidfile, I don't think that is satisfactory as people don't read
docs, and admins don't like stale pidfiles being left around on
disk.
To make this robust, I think we might want to copy libvirt's
approach to pidfile acquisition which runs in a loop and checks that
the file on disk /after/ acquiring the lock matches the file that
was locked. Then we could in fact safely let QEMU delete its own
pidfiles on clean exit..
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20180831145314.14736-2-marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-08-31 16:53:12 +02:00
|
|
|
if (fd == -1) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (fstat(fd, &b) < 0) {
|
|
|
|
error_setg_errno(errp, errno, "Cannot stat file");
|
|
|
|
goto fail_close;
|
|
|
|
}
|
|
|
|
|
2018-08-31 16:53:13 +02:00
|
|
|
if (fcntl(fd, F_SETLK, &lock)) {
|
util: add qemu_write_pidfile()
There are variants of qemu_create_pidfile() in qemu-pr-helper and
qemu-ga. Let's have a common implementation in libqemuutil.
The code is initially based from pr-helper write_pidfile(), with
various improvements and suggestions from Daniel Berrangé:
QEMU will leave the pidfile existing on disk when it exits which
initially made me think it avoids the deletion race. The app
managing QEMU, however, may well delete the pidfile after it has
seen QEMU exit, and even if the app locks the pidfile before
deleting it, there is still a race.
eg consider the following sequence
QEMU 1 libvirtd QEMU 2
1. lock(pidfile)
2. exit()
3. open(pidfile)
4. lock(pidfile)
5. open(pidfile)
6. unlink(pidfile)
7. close(pidfile)
8. lock(pidfile)
IOW, at step 8 the new QEMU has successfully acquired the lock, but
the pidfile no longer exists on disk because it was deleted after
the original QEMU exited.
While we could just say no external app should ever delete the
pidfile, I don't think that is satisfactory as people don't read
docs, and admins don't like stale pidfiles being left around on
disk.
To make this robust, I think we might want to copy libvirt's
approach to pidfile acquisition which runs in a loop and checks that
the file on disk /after/ acquiring the lock matches the file that
was locked. Then we could in fact safely let QEMU delete its own
pidfiles on clean exit..
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20180831145314.14736-2-marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-08-31 16:53:12 +02:00
|
|
|
error_setg_errno(errp, errno, "Cannot lock pid file");
|
|
|
|
goto fail_close;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now make sure the path we locked is the same one that now
|
|
|
|
* exists on the filesystem.
|
|
|
|
*/
|
|
|
|
if (stat(path, &a) < 0) {
|
|
|
|
/*
|
|
|
|
* PID file disappeared, someone else must be racing with
|
|
|
|
* us, so try again.
|
|
|
|
*/
|
|
|
|
close(fd);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (a.st_ino == b.st_ino) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* PID file was recreated, someone else must be racing with
|
|
|
|
* us, so try again.
|
|
|
|
*/
|
|
|
|
close(fd);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ftruncate(fd, 0) < 0) {
|
|
|
|
error_setg_errno(errp, errno, "Failed to truncate pid file");
|
|
|
|
goto fail_unlink;
|
|
|
|
}
|
|
|
|
|
|
|
|
snprintf(pidstr, sizeof(pidstr), FMT_pid "\n", getpid());
|
2022-04-20 15:26:19 +02:00
|
|
|
if (qemu_write_full(fd, pidstr, strlen(pidstr)) != strlen(pidstr)) {
|
util: add qemu_write_pidfile()
There are variants of qemu_create_pidfile() in qemu-pr-helper and
qemu-ga. Let's have a common implementation in libqemuutil.
The code is initially based from pr-helper write_pidfile(), with
various improvements and suggestions from Daniel Berrangé:
QEMU will leave the pidfile existing on disk when it exits which
initially made me think it avoids the deletion race. The app
managing QEMU, however, may well delete the pidfile after it has
seen QEMU exit, and even if the app locks the pidfile before
deleting it, there is still a race.
eg consider the following sequence
QEMU 1 libvirtd QEMU 2
1. lock(pidfile)
2. exit()
3. open(pidfile)
4. lock(pidfile)
5. open(pidfile)
6. unlink(pidfile)
7. close(pidfile)
8. lock(pidfile)
IOW, at step 8 the new QEMU has successfully acquired the lock, but
the pidfile no longer exists on disk because it was deleted after
the original QEMU exited.
While we could just say no external app should ever delete the
pidfile, I don't think that is satisfactory as people don't read
docs, and admins don't like stale pidfiles being left around on
disk.
To make this robust, I think we might want to copy libvirt's
approach to pidfile acquisition which runs in a loop and checks that
the file on disk /after/ acquiring the lock matches the file that
was locked. Then we could in fact safely let QEMU delete its own
pidfiles on clean exit..
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20180831145314.14736-2-marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-08-31 16:53:12 +02:00
|
|
|
error_setg(errp, "Failed to write pid file");
|
|
|
|
goto fail_unlink;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
|
|
|
fail_unlink:
|
|
|
|
unlink(path);
|
|
|
|
fail_close:
|
|
|
|
close(fd);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2010-10-26 10:39:19 +02:00
|
|
|
/* alloc shared memory pages */
|
2021-05-10 13:43:21 +02:00
|
|
|
void *qemu_anon_ram_alloc(size_t size, uint64_t *alignment, bool shared,
|
|
|
|
bool noreserve)
|
2010-10-26 10:39:19 +02:00
|
|
|
{
|
2021-05-10 13:43:21 +02:00
|
|
|
const uint32_t qemu_map_flags = (shared ? QEMU_MAP_SHARED : 0) |
|
|
|
|
(noreserve ? QEMU_MAP_NORESERVE : 0);
|
2011-09-05 10:07:05 +02:00
|
|
|
size_t align = QEMU_VMALLOC_ALIGN;
|
2021-05-10 13:43:20 +02:00
|
|
|
void *ptr = qemu_ram_mmap(-1, size, align, qemu_map_flags, 0);
|
2011-09-05 10:07:05 +02:00
|
|
|
|
2013-04-09 17:43:43 +02:00
|
|
|
if (ptr == MAP_FAILED) {
|
2013-07-31 15:11:11 +02:00
|
|
|
return NULL;
|
2011-10-31 21:29:46 +01:00
|
|
|
}
|
|
|
|
|
2014-10-31 17:38:37 +01:00
|
|
|
if (alignment) {
|
|
|
|
*alignment = align;
|
|
|
|
}
|
2015-09-10 15:36:51 +02:00
|
|
|
|
2013-05-13 16:19:55 +02:00
|
|
|
trace_qemu_anon_ram_alloc(size, ptr);
|
2011-07-25 17:13:36 +02:00
|
|
|
return ptr;
|
2010-10-26 10:39:19 +02:00
|
|
|
}
|
|
|
|
|
2013-05-13 16:19:56 +02:00
|
|
|
void qemu_anon_ram_free(void *ptr, size_t size)
|
|
|
|
{
|
|
|
|
trace_qemu_anon_ram_free(ptr, size);
|
2019-01-31 00:36:05 +01:00
|
|
|
qemu_ram_munmap(-1, ptr, size);
|
2013-05-13 16:19:56 +02:00
|
|
|
}
|
|
|
|
|
2022-04-25 15:33:47 +02:00
|
|
|
void qemu_socket_set_block(int fd)
|
2011-10-05 09:17:32 +02:00
|
|
|
{
|
2022-04-25 09:56:42 +02:00
|
|
|
g_unix_set_fd_nonblocking(fd, false, NULL);
|
2011-10-05 09:17:32 +02:00
|
|
|
}
|
|
|
|
|
2022-04-25 15:33:47 +02:00
|
|
|
int qemu_socket_try_set_nonblock(int fd)
|
2010-10-26 10:39:20 +02:00
|
|
|
{
|
2022-04-25 09:56:42 +02:00
|
|
|
return g_unix_set_fd_nonblocking(fd, true, NULL) ? 0 : -errno;
|
net: check if the file descriptor is valid before using it
qemu_set_nonblock() checks that the file descriptor can be used and, if
not, crashes QEMU. An assert() is used for that. The use of assert() is
used to detect programming error and the coredump will allow to debug
the problem.
But in the case of the tap device, this assert() can be triggered by
a misconfiguration by the user. At startup, it's not a real problem, but it
can also happen during the hot-plug of a new device, and here it's a
problem because we can crash a perfectly healthy system.
For instance:
# ip link add link virbr0 name macvtap0 type macvtap mode bridge
# ip link set macvtap0 up
# TAP=/dev/tap$(ip -o link show macvtap0 | cut -d: -f1)
# qemu-system-x86_64 -machine q35 -device pcie-root-port,id=pcie-root-port-0 -monitor stdio 9<> $TAP
(qemu) netdev_add type=tap,id=hostnet0,vhost=on,fd=9
(qemu) device_add driver=virtio-net-pci,netdev=hostnet0,id=net0,bus=pcie-root-port-0
(qemu) device_del net0
(qemu) netdev_del hostnet0
(qemu) netdev_add type=tap,id=hostnet1,vhost=on,fd=9
qemu-system-x86_64: .../util/oslib-posix.c:247: qemu_set_nonblock: Assertion `f != -1' failed.
Aborted (core dumped)
To avoid that, add a function, qemu_try_set_nonblock(), that allows to report the
problem without crashing.
In the same way, we also update the function for vhostfd in net_init_tap_one() and
for fd in net_init_socket() (both descriptors are provided by the user and can
be wrong).
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
2020-07-07 20:45:14 +02:00
|
|
|
}
|
|
|
|
|
2022-04-25 15:33:47 +02:00
|
|
|
void qemu_socket_set_nonblock(int fd)
|
net: check if the file descriptor is valid before using it
qemu_set_nonblock() checks that the file descriptor can be used and, if
not, crashes QEMU. An assert() is used for that. The use of assert() is
used to detect programming error and the coredump will allow to debug
the problem.
But in the case of the tap device, this assert() can be triggered by
a misconfiguration by the user. At startup, it's not a real problem, but it
can also happen during the hot-plug of a new device, and here it's a
problem because we can crash a perfectly healthy system.
For instance:
# ip link add link virbr0 name macvtap0 type macvtap mode bridge
# ip link set macvtap0 up
# TAP=/dev/tap$(ip -o link show macvtap0 | cut -d: -f1)
# qemu-system-x86_64 -machine q35 -device pcie-root-port,id=pcie-root-port-0 -monitor stdio 9<> $TAP
(qemu) netdev_add type=tap,id=hostnet0,vhost=on,fd=9
(qemu) device_add driver=virtio-net-pci,netdev=hostnet0,id=net0,bus=pcie-root-port-0
(qemu) device_del net0
(qemu) netdev_del hostnet0
(qemu) netdev_add type=tap,id=hostnet1,vhost=on,fd=9
qemu-system-x86_64: .../util/oslib-posix.c:247: qemu_set_nonblock: Assertion `f != -1' failed.
Aborted (core dumped)
To avoid that, add a function, qemu_try_set_nonblock(), that allows to report the
problem without crashing.
In the same way, we also update the function for vhostfd in net_init_tap_one() and
for fd in net_init_socket() (both descriptors are provided by the user and can
be wrong).
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
2020-07-07 20:45:14 +02:00
|
|
|
{
|
|
|
|
int f;
|
2022-04-25 15:33:47 +02:00
|
|
|
f = qemu_socket_try_set_nonblock(fd);
|
net: check if the file descriptor is valid before using it
qemu_set_nonblock() checks that the file descriptor can be used and, if
not, crashes QEMU. An assert() is used for that. The use of assert() is
used to detect programming error and the coredump will allow to debug
the problem.
But in the case of the tap device, this assert() can be triggered by
a misconfiguration by the user. At startup, it's not a real problem, but it
can also happen during the hot-plug of a new device, and here it's a
problem because we can crash a perfectly healthy system.
For instance:
# ip link add link virbr0 name macvtap0 type macvtap mode bridge
# ip link set macvtap0 up
# TAP=/dev/tap$(ip -o link show macvtap0 | cut -d: -f1)
# qemu-system-x86_64 -machine q35 -device pcie-root-port,id=pcie-root-port-0 -monitor stdio 9<> $TAP
(qemu) netdev_add type=tap,id=hostnet0,vhost=on,fd=9
(qemu) device_add driver=virtio-net-pci,netdev=hostnet0,id=net0,bus=pcie-root-port-0
(qemu) device_del net0
(qemu) netdev_del hostnet0
(qemu) netdev_add type=tap,id=hostnet1,vhost=on,fd=9
qemu-system-x86_64: .../util/oslib-posix.c:247: qemu_set_nonblock: Assertion `f != -1' failed.
Aborted (core dumped)
To avoid that, add a function, qemu_try_set_nonblock(), that allows to report the
problem without crashing.
In the same way, we also update the function for vhostfd in net_init_tap_one() and
for fd in net_init_socket() (both descriptors are provided by the user and can
be wrong).
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
2020-07-07 20:45:14 +02:00
|
|
|
assert(f == 0);
|
2010-10-26 10:39:20 +02:00
|
|
|
}
|
|
|
|
|
2013-10-02 12:23:12 +02:00
|
|
|
int socket_set_fast_reuse(int fd)
|
|
|
|
{
|
|
|
|
int val = 1, ret;
|
|
|
|
|
|
|
|
ret = setsockopt(fd, SOL_SOCKET, SO_REUSEADDR,
|
|
|
|
(const char *)&val, sizeof(val));
|
|
|
|
|
|
|
|
assert(ret == 0);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2010-10-26 10:39:20 +02:00
|
|
|
void qemu_set_cloexec(int fd)
|
|
|
|
{
|
|
|
|
int f;
|
|
|
|
f = fcntl(fd, F_GETFD);
|
2017-05-09 21:04:52 +02:00
|
|
|
assert(f != -1);
|
|
|
|
f = fcntl(fd, F_SETFD, f | FD_CLOEXEC);
|
|
|
|
assert(f != -1);
|
2010-10-26 10:39:20 +02:00
|
|
|
}
|
2010-10-26 10:39:21 +02:00
|
|
|
|
2022-08-23 09:50:39 +02:00
|
|
|
int qemu_socketpair(int domain, int type, int protocol, int sv[2])
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
#ifdef SOCK_CLOEXEC
|
|
|
|
ret = socketpair(domain, type | SOCK_CLOEXEC, protocol, sv);
|
|
|
|
if (ret != -1 || errno != EINVAL) {
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
ret = socketpair(domain, type, protocol, sv);;
|
|
|
|
if (ret == 0) {
|
|
|
|
qemu_set_cloexec(sv[0]);
|
|
|
|
qemu_set_cloexec(sv[1]);
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2013-05-18 06:31:48 +02:00
|
|
|
char *
|
2022-04-20 15:26:21 +02:00
|
|
|
qemu_get_local_state_dir(void)
|
2013-05-18 06:31:48 +02:00
|
|
|
{
|
2022-04-20 15:26:21 +02:00
|
|
|
return get_relocated_path(CONFIG_QEMU_LOCALSTATEDIR);
|
2013-05-18 06:31:48 +02:00
|
|
|
}
|
2013-11-14 11:54:16 +01:00
|
|
|
|
|
|
|
void qemu_set_tty_echo(int fd, bool echo)
|
|
|
|
{
|
|
|
|
struct termios tty;
|
|
|
|
|
|
|
|
tcgetattr(fd, &tty);
|
|
|
|
|
|
|
|
if (echo) {
|
|
|
|
tty.c_lflag |= ECHO | ECHONL | ICANON | IEXTEN;
|
|
|
|
} else {
|
|
|
|
tty.c_lflag &= ~(ECHO | ECHONL | ICANON | IEXTEN);
|
|
|
|
}
|
|
|
|
|
|
|
|
tcsetattr(fd, TCSANOW, &tty);
|
|
|
|
}
|
2014-02-10 07:48:51 +01:00
|
|
|
|
2021-12-17 14:46:10 +01:00
|
|
|
#ifdef CONFIG_LINUX
|
|
|
|
static void sigbus_handler(int signal, siginfo_t *siginfo, void *ctx)
|
|
|
|
#else /* CONFIG_LINUX */
|
2014-05-14 11:43:21 +02:00
|
|
|
static void sigbus_handler(int signal)
|
2021-12-17 14:46:10 +01:00
|
|
|
#endif /* CONFIG_LINUX */
|
2014-05-14 11:43:21 +02:00
|
|
|
{
|
2017-02-24 04:31:43 +01:00
|
|
|
int i;
|
2021-12-17 14:46:06 +01:00
|
|
|
|
|
|
|
if (sigbus_memset_context) {
|
|
|
|
for (i = 0; i < sigbus_memset_context->num_threads; i++) {
|
|
|
|
MemsetThread *thread = &sigbus_memset_context->threads[i];
|
|
|
|
|
|
|
|
if (qemu_thread_is_self(&thread->pgthread)) {
|
|
|
|
siglongjmp(thread->env, 1);
|
2017-02-24 04:31:43 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2021-12-17 14:46:10 +01:00
|
|
|
|
|
|
|
#ifdef CONFIG_LINUX
|
|
|
|
/*
|
|
|
|
* We assume that the MCE SIGBUS handler could have been registered. We
|
|
|
|
* should never receive BUS_MCEERR_AO on any of our threads, but only on
|
|
|
|
* the main thread registered for PR_MCE_KILL_EARLY. Further, we should not
|
|
|
|
* receive BUS_MCEERR_AR triggered by action of other threads on one of
|
|
|
|
* our threads. So, no need to check for unrelated SIGBUS when seeing one
|
|
|
|
* for our threads.
|
|
|
|
*
|
|
|
|
* We will forward to the MCE handler, which will either handle the SIGBUS
|
|
|
|
* or reinstall the default SIGBUS handler and reraise the SIGBUS. The
|
|
|
|
* default SIGBUS handler will crash the process, so we don't care.
|
|
|
|
*/
|
|
|
|
if (sigbus_oldact.sa_flags & SA_SIGINFO) {
|
|
|
|
sigbus_oldact.sa_sigaction(signal, siginfo, ctx);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
#endif /* CONFIG_LINUX */
|
2022-10-14 15:47:14 +02:00
|
|
|
warn_report("qemu_prealloc_mem: unrelated SIGBUS detected and ignored");
|
2014-05-14 11:43:21 +02:00
|
|
|
}
|
|
|
|
|
2017-02-24 04:31:43 +01:00
|
|
|
static void *do_touch_pages(void *arg)
|
|
|
|
{
|
|
|
|
MemsetThread *memset_args = (MemsetThread *)arg;
|
|
|
|
sigset_t set, oldset;
|
2021-12-17 14:46:04 +01:00
|
|
|
int ret = 0;
|
2017-02-24 04:31:43 +01:00
|
|
|
|
mem-prealloc: optimize large guest startup
[desc]:
Large memory VM starts slowly when using -mem-prealloc, and
there are some areas to optimize in current method;
1、mmap will be used to alloc threads stack during create page
clearing threads, and it will attempt mm->mmap_sem for write
lock, but clearing threads have hold read lock, this competition
will cause threads createion very slow;
2、methods of calcuating pages for per threads is not well;if we use
64 threads to split 160 hugepage,63 threads clear 2page,1 thread
clear 34 page,so the entire speed is very slow;
to solve the first problem,we add a mutex in thread function,and
start all threads when all threads finished createion;
and the second problem, we spread remainder to other threads,in
situation that 160 hugepage and 64 threads, there are 32 threads
clear 3 pages,and 32 threads clear 2 pages.
[test]:
320G 84c VM start time can be reduced to 10s
680G 84c VM start time can be reduced to 18s
Signed-off-by: bauerchen <bauerchen@tencent.com>
Reviewed-by: Pan Rui <ruippan@tencent.com>
Reviewed-by: Ivan Ren <ivanren@tencent.com>
[Simplify computation of the number of pages per thread. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-02-11 10:10:35 +01:00
|
|
|
/*
|
|
|
|
* On Linux, the page faults from the loop below can cause mmap_sem
|
|
|
|
* contention with allocation of the thread stacks. Do not start
|
|
|
|
* clearing until all threads have been created.
|
|
|
|
*/
|
|
|
|
qemu_mutex_lock(&page_mutex);
|
2021-12-17 14:46:06 +01:00
|
|
|
while (!memset_args->context->all_threads_created) {
|
mem-prealloc: optimize large guest startup
[desc]:
Large memory VM starts slowly when using -mem-prealloc, and
there are some areas to optimize in current method;
1、mmap will be used to alloc threads stack during create page
clearing threads, and it will attempt mm->mmap_sem for write
lock, but clearing threads have hold read lock, this competition
will cause threads createion very slow;
2、methods of calcuating pages for per threads is not well;if we use
64 threads to split 160 hugepage,63 threads clear 2page,1 thread
clear 34 page,so the entire speed is very slow;
to solve the first problem,we add a mutex in thread function,and
start all threads when all threads finished createion;
and the second problem, we spread remainder to other threads,in
situation that 160 hugepage and 64 threads, there are 32 threads
clear 3 pages,and 32 threads clear 2 pages.
[test]:
320G 84c VM start time can be reduced to 10s
680G 84c VM start time can be reduced to 18s
Signed-off-by: bauerchen <bauerchen@tencent.com>
Reviewed-by: Pan Rui <ruippan@tencent.com>
Reviewed-by: Ivan Ren <ivanren@tencent.com>
[Simplify computation of the number of pages per thread. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-02-11 10:10:35 +01:00
|
|
|
qemu_cond_wait(&page_cond, &page_mutex);
|
|
|
|
}
|
|
|
|
qemu_mutex_unlock(&page_mutex);
|
|
|
|
|
2017-02-24 04:31:43 +01:00
|
|
|
/* unblock SIGBUS */
|
|
|
|
sigemptyset(&set);
|
|
|
|
sigaddset(&set, SIGBUS);
|
|
|
|
pthread_sigmask(SIG_UNBLOCK, &set, &oldset);
|
|
|
|
|
|
|
|
if (sigsetjmp(memset_args->env, 1)) {
|
2021-12-17 14:46:04 +01:00
|
|
|
ret = -EFAULT;
|
2017-02-24 04:31:43 +01:00
|
|
|
} else {
|
2017-10-16 22:29:12 +02:00
|
|
|
char *addr = memset_args->addr;
|
|
|
|
size_t numpages = memset_args->numpages;
|
|
|
|
size_t hpagesize = memset_args->hpagesize;
|
|
|
|
size_t i;
|
2017-02-24 04:31:43 +01:00
|
|
|
for (i = 0; i < numpages; i++) {
|
2017-03-03 12:32:55 +01:00
|
|
|
/*
|
|
|
|
* Read & write back the same value, so we don't
|
|
|
|
* corrupt existing user/app data that might be
|
|
|
|
* stored.
|
|
|
|
*
|
|
|
|
* 'volatile' to stop compiler optimizing this away
|
|
|
|
* to a no-op
|
|
|
|
*/
|
|
|
|
*(volatile char *)addr = *addr;
|
2017-02-24 04:31:43 +01:00
|
|
|
addr += hpagesize;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
pthread_sigmask(SIG_SETMASK, &oldset, NULL);
|
2021-12-17 14:46:04 +01:00
|
|
|
return (void *)(uintptr_t)ret;
|
2017-02-24 04:31:43 +01:00
|
|
|
}
|
|
|
|
|
util/oslib-posix: Support MADV_POPULATE_WRITE for os_mem_prealloc()
Let's sense support and use it for preallocation. MADV_POPULATE_WRITE
does not require a SIGBUS handler, doesn't actually touch page content,
and avoids context switches; it is, therefore, faster and easier to handle
than our current approach.
While MADV_POPULATE_WRITE is, in general, faster than manual
prefaulting, and especially faster with 4k pages, there is still value in
prefaulting using multiple threads to speed up preallocation.
More details on MADV_POPULATE_WRITE can be found in the Linux commits
4ca9b3859dac ("mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault
page tables") and eb2faa513c24 ("mm/madvise: report SIGBUS as -EFAULT for
MADV_POPULATE_(READ|WRITE)"), and in the man page proposal [1].
This resolves the TODO in do_touch_pages().
In the future, we might want to look into using fallocate(), eventually
combined with MADV_POPULATE_READ, when dealing with shared file/fd
mappings and not caring about memory bindings.
[1] https://lkml.kernel.org/r/20210816081922.5155-1-david@redhat.com
Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20211217134611.31172-3-david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-12-17 14:46:05 +01:00
|
|
|
static void *do_madv_populate_write_pages(void *arg)
|
|
|
|
{
|
|
|
|
MemsetThread *memset_args = (MemsetThread *)arg;
|
|
|
|
const size_t size = memset_args->numpages * memset_args->hpagesize;
|
|
|
|
char * const addr = memset_args->addr;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
/* See do_touch_pages(). */
|
|
|
|
qemu_mutex_lock(&page_mutex);
|
2021-12-17 14:46:06 +01:00
|
|
|
while (!memset_args->context->all_threads_created) {
|
util/oslib-posix: Support MADV_POPULATE_WRITE for os_mem_prealloc()
Let's sense support and use it for preallocation. MADV_POPULATE_WRITE
does not require a SIGBUS handler, doesn't actually touch page content,
and avoids context switches; it is, therefore, faster and easier to handle
than our current approach.
While MADV_POPULATE_WRITE is, in general, faster than manual
prefaulting, and especially faster with 4k pages, there is still value in
prefaulting using multiple threads to speed up preallocation.
More details on MADV_POPULATE_WRITE can be found in the Linux commits
4ca9b3859dac ("mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault
page tables") and eb2faa513c24 ("mm/madvise: report SIGBUS as -EFAULT for
MADV_POPULATE_(READ|WRITE)"), and in the man page proposal [1].
This resolves the TODO in do_touch_pages().
In the future, we might want to look into using fallocate(), eventually
combined with MADV_POPULATE_READ, when dealing with shared file/fd
mappings and not caring about memory bindings.
[1] https://lkml.kernel.org/r/20210816081922.5155-1-david@redhat.com
Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20211217134611.31172-3-david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-12-17 14:46:05 +01:00
|
|
|
qemu_cond_wait(&page_cond, &page_mutex);
|
|
|
|
}
|
|
|
|
qemu_mutex_unlock(&page_mutex);
|
|
|
|
|
|
|
|
if (size && qemu_madvise(addr, size, QEMU_MADV_POPULATE_WRITE)) {
|
|
|
|
ret = -errno;
|
|
|
|
}
|
|
|
|
return (void *)(uintptr_t)ret;
|
|
|
|
}
|
|
|
|
|
2021-12-17 14:46:07 +01:00
|
|
|
static inline int get_memset_num_threads(size_t hpagesize, size_t numpages,
|
2022-10-14 15:47:14 +02:00
|
|
|
int max_threads)
|
2017-03-21 07:50:06 +01:00
|
|
|
{
|
|
|
|
long host_procs = sysconf(_SC_NPROCESSORS_ONLN);
|
|
|
|
int ret = 1;
|
|
|
|
|
|
|
|
if (host_procs > 0) {
|
2022-10-14 15:47:14 +02:00
|
|
|
ret = MIN(MIN(host_procs, MAX_MEM_PREALLOC_THREAD_COUNT), max_threads);
|
2017-03-21 07:50:06 +01:00
|
|
|
}
|
2021-12-17 14:46:07 +01:00
|
|
|
|
|
|
|
/* Especially with gigantic pages, don't create more threads than pages. */
|
|
|
|
ret = MIN(ret, numpages);
|
|
|
|
/* Don't start threads to prealloc comparatively little memory. */
|
|
|
|
ret = MIN(ret, MAX(1, hpagesize * numpages / (64 * MiB)));
|
|
|
|
|
2017-03-21 07:50:06 +01:00
|
|
|
/* In case sysconf() fails, we fall back to single threaded */
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2024-01-31 17:53:27 +01:00
|
|
|
static int wait_and_free_mem_prealloc_context(MemsetContext *context)
|
|
|
|
{
|
|
|
|
int i, ret = 0, tmp;
|
|
|
|
|
|
|
|
for (i = 0; i < context->num_threads; i++) {
|
|
|
|
tmp = (uintptr_t)qemu_thread_join(&context->threads[i].pgthread);
|
|
|
|
|
|
|
|
if (tmp) {
|
|
|
|
ret = tmp;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
g_free(context->threads);
|
|
|
|
g_free(context);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2021-12-17 14:46:04 +01:00
|
|
|
static int touch_all_pages(char *area, size_t hpagesize, size_t numpages,
|
2024-01-31 17:53:27 +01:00
|
|
|
int max_threads, ThreadContext *tc, bool async,
|
2022-10-14 15:47:18 +02:00
|
|
|
bool use_madv_populate_write)
|
2017-02-24 04:31:43 +01:00
|
|
|
{
|
2020-03-10 18:58:30 +01:00
|
|
|
static gsize initialized = 0;
|
2024-01-31 17:53:27 +01:00
|
|
|
MemsetContext *context = g_malloc0(sizeof(MemsetContext));
|
mem-prealloc: optimize large guest startup
[desc]:
Large memory VM starts slowly when using -mem-prealloc, and
there are some areas to optimize in current method;
1、mmap will be used to alloc threads stack during create page
clearing threads, and it will attempt mm->mmap_sem for write
lock, but clearing threads have hold read lock, this competition
will cause threads createion very slow;
2、methods of calcuating pages for per threads is not well;if we use
64 threads to split 160 hugepage,63 threads clear 2page,1 thread
clear 34 page,so the entire speed is very slow;
to solve the first problem,we add a mutex in thread function,and
start all threads when all threads finished createion;
and the second problem, we spread remainder to other threads,in
situation that 160 hugepage and 64 threads, there are 32 threads
clear 3 pages,and 32 threads clear 2 pages.
[test]:
320G 84c VM start time can be reduced to 10s
680G 84c VM start time can be reduced to 18s
Signed-off-by: bauerchen <bauerchen@tencent.com>
Reviewed-by: Pan Rui <ruippan@tencent.com>
Reviewed-by: Ivan Ren <ivanren@tencent.com>
[Simplify computation of the number of pages per thread. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-02-11 10:10:35 +01:00
|
|
|
size_t numpages_per_thread, leftover;
|
util/oslib-posix: Support MADV_POPULATE_WRITE for os_mem_prealloc()
Let's sense support and use it for preallocation. MADV_POPULATE_WRITE
does not require a SIGBUS handler, doesn't actually touch page content,
and avoids context switches; it is, therefore, faster and easier to handle
than our current approach.
While MADV_POPULATE_WRITE is, in general, faster than manual
prefaulting, and especially faster with 4k pages, there is still value in
prefaulting using multiple threads to speed up preallocation.
More details on MADV_POPULATE_WRITE can be found in the Linux commits
4ca9b3859dac ("mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault
page tables") and eb2faa513c24 ("mm/madvise: report SIGBUS as -EFAULT for
MADV_POPULATE_(READ|WRITE)"), and in the man page proposal [1].
This resolves the TODO in do_touch_pages().
In the future, we might want to look into using fallocate(), eventually
combined with MADV_POPULATE_READ, when dealing with shared file/fd
mappings and not caring about memory bindings.
[1] https://lkml.kernel.org/r/20210816081922.5155-1-david@redhat.com
Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20211217134611.31172-3-david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-12-17 14:46:05 +01:00
|
|
|
void *(*touch_fn)(void *);
|
2024-01-31 17:53:27 +01:00
|
|
|
int ret, i = 0;
|
2017-02-24 04:31:43 +01:00
|
|
|
char *addr = area;
|
|
|
|
|
2024-01-31 17:53:27 +01:00
|
|
|
/*
|
|
|
|
* Asynchronous preallocation is only allowed when using MADV_POPULATE_WRITE
|
|
|
|
* and prealloc context for thread placement.
|
|
|
|
*/
|
|
|
|
if (!use_madv_populate_write || !tc) {
|
|
|
|
async = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
context->num_threads =
|
|
|
|
get_memset_num_threads(hpagesize, numpages, max_threads);
|
|
|
|
|
2020-03-10 18:58:30 +01:00
|
|
|
if (g_once_init_enter(&initialized)) {
|
|
|
|
qemu_mutex_init(&page_mutex);
|
|
|
|
qemu_cond_init(&page_cond);
|
|
|
|
g_once_init_leave(&initialized, 1);
|
|
|
|
}
|
|
|
|
|
util/oslib-posix: Support MADV_POPULATE_WRITE for os_mem_prealloc()
Let's sense support and use it for preallocation. MADV_POPULATE_WRITE
does not require a SIGBUS handler, doesn't actually touch page content,
and avoids context switches; it is, therefore, faster and easier to handle
than our current approach.
While MADV_POPULATE_WRITE is, in general, faster than manual
prefaulting, and especially faster with 4k pages, there is still value in
prefaulting using multiple threads to speed up preallocation.
More details on MADV_POPULATE_WRITE can be found in the Linux commits
4ca9b3859dac ("mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault
page tables") and eb2faa513c24 ("mm/madvise: report SIGBUS as -EFAULT for
MADV_POPULATE_(READ|WRITE)"), and in the man page proposal [1].
This resolves the TODO in do_touch_pages().
In the future, we might want to look into using fallocate(), eventually
combined with MADV_POPULATE_READ, when dealing with shared file/fd
mappings and not caring about memory bindings.
[1] https://lkml.kernel.org/r/20210816081922.5155-1-david@redhat.com
Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20211217134611.31172-3-david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-12-17 14:46:05 +01:00
|
|
|
if (use_madv_populate_write) {
|
2024-01-31 17:53:27 +01:00
|
|
|
/*
|
|
|
|
* Avoid creating a single thread for MADV_POPULATE_WRITE when
|
|
|
|
* preallocating synchronously.
|
|
|
|
*/
|
|
|
|
if (context->num_threads == 1 && !async) {
|
2024-03-04 23:48:17 +01:00
|
|
|
ret = 0;
|
2021-12-17 14:46:08 +01:00
|
|
|
if (qemu_madvise(area, hpagesize * numpages,
|
|
|
|
QEMU_MADV_POPULATE_WRITE)) {
|
2024-03-04 23:48:17 +01:00
|
|
|
ret = -errno;
|
2021-12-17 14:46:08 +01:00
|
|
|
}
|
2024-03-04 23:48:17 +01:00
|
|
|
g_free(context);
|
|
|
|
return ret;
|
2021-12-17 14:46:08 +01:00
|
|
|
}
|
util/oslib-posix: Support MADV_POPULATE_WRITE for os_mem_prealloc()
Let's sense support and use it for preallocation. MADV_POPULATE_WRITE
does not require a SIGBUS handler, doesn't actually touch page content,
and avoids context switches; it is, therefore, faster and easier to handle
than our current approach.
While MADV_POPULATE_WRITE is, in general, faster than manual
prefaulting, and especially faster with 4k pages, there is still value in
prefaulting using multiple threads to speed up preallocation.
More details on MADV_POPULATE_WRITE can be found in the Linux commits
4ca9b3859dac ("mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault
page tables") and eb2faa513c24 ("mm/madvise: report SIGBUS as -EFAULT for
MADV_POPULATE_(READ|WRITE)"), and in the man page proposal [1].
This resolves the TODO in do_touch_pages().
In the future, we might want to look into using fallocate(), eventually
combined with MADV_POPULATE_READ, when dealing with shared file/fd
mappings and not caring about memory bindings.
[1] https://lkml.kernel.org/r/20210816081922.5155-1-david@redhat.com
Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20211217134611.31172-3-david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-12-17 14:46:05 +01:00
|
|
|
touch_fn = do_madv_populate_write_pages;
|
|
|
|
} else {
|
|
|
|
touch_fn = do_touch_pages;
|
|
|
|
}
|
|
|
|
|
2024-01-31 17:53:27 +01:00
|
|
|
context->threads = g_new0(MemsetThread, context->num_threads);
|
|
|
|
numpages_per_thread = numpages / context->num_threads;
|
|
|
|
leftover = numpages % context->num_threads;
|
|
|
|
for (i = 0; i < context->num_threads; i++) {
|
|
|
|
context->threads[i].addr = addr;
|
|
|
|
context->threads[i].numpages = numpages_per_thread + (i < leftover);
|
|
|
|
context->threads[i].hpagesize = hpagesize;
|
|
|
|
context->threads[i].context = context;
|
2022-10-14 15:47:18 +02:00
|
|
|
if (tc) {
|
2024-01-31 17:53:27 +01:00
|
|
|
thread_context_create_thread(tc, &context->threads[i].pgthread,
|
2022-10-14 15:47:18 +02:00
|
|
|
"touch_pages",
|
2024-01-31 17:53:27 +01:00
|
|
|
touch_fn, &context->threads[i],
|
2022-10-14 15:47:18 +02:00
|
|
|
QEMU_THREAD_JOINABLE);
|
|
|
|
} else {
|
2024-01-31 17:53:27 +01:00
|
|
|
qemu_thread_create(&context->threads[i].pgthread, "touch_pages",
|
|
|
|
touch_fn, &context->threads[i],
|
2022-10-14 15:47:18 +02:00
|
|
|
QEMU_THREAD_JOINABLE);
|
|
|
|
}
|
2024-01-31 17:53:27 +01:00
|
|
|
addr += context->threads[i].numpages * hpagesize;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (async) {
|
|
|
|
/*
|
|
|
|
* async requests currently require the BQL. Add it to the list and kick
|
|
|
|
* preallocation off during qemu_finish_async_prealloc_mem().
|
|
|
|
*/
|
|
|
|
assert(bql_locked());
|
|
|
|
QLIST_INSERT_HEAD(&memset_contexts, context, next);
|
|
|
|
return 0;
|
2021-12-17 14:46:06 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!use_madv_populate_write) {
|
2024-01-31 17:53:27 +01:00
|
|
|
sigbus_memset_context = context;
|
2017-02-24 04:31:43 +01:00
|
|
|
}
|
2020-04-06 04:36:54 +02:00
|
|
|
|
|
|
|
qemu_mutex_lock(&page_mutex);
|
2024-01-31 17:53:27 +01:00
|
|
|
context->all_threads_created = true;
|
mem-prealloc: optimize large guest startup
[desc]:
Large memory VM starts slowly when using -mem-prealloc, and
there are some areas to optimize in current method;
1、mmap will be used to alloc threads stack during create page
clearing threads, and it will attempt mm->mmap_sem for write
lock, but clearing threads have hold read lock, this competition
will cause threads createion very slow;
2、methods of calcuating pages for per threads is not well;if we use
64 threads to split 160 hugepage,63 threads clear 2page,1 thread
clear 34 page,so the entire speed is very slow;
to solve the first problem,we add a mutex in thread function,and
start all threads when all threads finished createion;
and the second problem, we spread remainder to other threads,in
situation that 160 hugepage and 64 threads, there are 32 threads
clear 3 pages,and 32 threads clear 2 pages.
[test]:
320G 84c VM start time can be reduced to 10s
680G 84c VM start time can be reduced to 18s
Signed-off-by: bauerchen <bauerchen@tencent.com>
Reviewed-by: Pan Rui <ruippan@tencent.com>
Reviewed-by: Ivan Ren <ivanren@tencent.com>
[Simplify computation of the number of pages per thread. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-02-11 10:10:35 +01:00
|
|
|
qemu_cond_broadcast(&page_cond);
|
2020-04-06 04:36:54 +02:00
|
|
|
qemu_mutex_unlock(&page_mutex);
|
mem-prealloc: optimize large guest startup
[desc]:
Large memory VM starts slowly when using -mem-prealloc, and
there are some areas to optimize in current method;
1、mmap will be used to alloc threads stack during create page
clearing threads, and it will attempt mm->mmap_sem for write
lock, but clearing threads have hold read lock, this competition
will cause threads createion very slow;
2、methods of calcuating pages for per threads is not well;if we use
64 threads to split 160 hugepage,63 threads clear 2page,1 thread
clear 34 page,so the entire speed is very slow;
to solve the first problem,we add a mutex in thread function,and
start all threads when all threads finished createion;
and the second problem, we spread remainder to other threads,in
situation that 160 hugepage and 64 threads, there are 32 threads
clear 3 pages,and 32 threads clear 2 pages.
[test]:
320G 84c VM start time can be reduced to 10s
680G 84c VM start time can be reduced to 18s
Signed-off-by: bauerchen <bauerchen@tencent.com>
Reviewed-by: Pan Rui <ruippan@tencent.com>
Reviewed-by: Ivan Ren <ivanren@tencent.com>
[Simplify computation of the number of pages per thread. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-02-11 10:10:35 +01:00
|
|
|
|
2024-01-31 17:53:27 +01:00
|
|
|
ret = wait_and_free_mem_prealloc_context(context);
|
2021-12-17 14:46:04 +01:00
|
|
|
|
2024-01-31 17:53:27 +01:00
|
|
|
if (!use_madv_populate_write) {
|
|
|
|
sigbus_memset_context = NULL;
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool qemu_finish_async_prealloc_mem(Error **errp)
|
|
|
|
{
|
|
|
|
int ret = 0, tmp;
|
|
|
|
MemsetContext *context, *next_context;
|
|
|
|
|
|
|
|
/* Waiting for preallocation requires the BQL. */
|
|
|
|
assert(bql_locked());
|
|
|
|
if (QLIST_EMPTY(&memset_contexts)) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
qemu_mutex_lock(&page_mutex);
|
|
|
|
QLIST_FOREACH(context, &memset_contexts, next) {
|
|
|
|
context->all_threads_created = true;
|
|
|
|
}
|
|
|
|
qemu_cond_broadcast(&page_cond);
|
|
|
|
qemu_mutex_unlock(&page_mutex);
|
|
|
|
|
|
|
|
QLIST_FOREACH_SAFE(context, &memset_contexts, next, next_context) {
|
|
|
|
QLIST_REMOVE(context, next);
|
|
|
|
tmp = wait_and_free_mem_prealloc_context(context);
|
2021-12-17 14:46:04 +01:00
|
|
|
if (tmp) {
|
|
|
|
ret = tmp;
|
|
|
|
}
|
2017-02-24 04:31:43 +01:00
|
|
|
}
|
2021-12-17 14:46:06 +01:00
|
|
|
|
2024-01-31 17:53:27 +01:00
|
|
|
if (ret) {
|
|
|
|
error_setg_errno(errp, -ret,
|
|
|
|
"qemu_prealloc_mem: preallocating memory failed");
|
|
|
|
return false;
|
2021-12-17 14:46:06 +01:00
|
|
|
}
|
2024-01-31 17:53:27 +01:00
|
|
|
return true;
|
2017-02-24 04:31:43 +01:00
|
|
|
}
|
|
|
|
|
util/oslib-posix: Support MADV_POPULATE_WRITE for os_mem_prealloc()
Let's sense support and use it for preallocation. MADV_POPULATE_WRITE
does not require a SIGBUS handler, doesn't actually touch page content,
and avoids context switches; it is, therefore, faster and easier to handle
than our current approach.
While MADV_POPULATE_WRITE is, in general, faster than manual
prefaulting, and especially faster with 4k pages, there is still value in
prefaulting using multiple threads to speed up preallocation.
More details on MADV_POPULATE_WRITE can be found in the Linux commits
4ca9b3859dac ("mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault
page tables") and eb2faa513c24 ("mm/madvise: report SIGBUS as -EFAULT for
MADV_POPULATE_(READ|WRITE)"), and in the man page proposal [1].
This resolves the TODO in do_touch_pages().
In the future, we might want to look into using fallocate(), eventually
combined with MADV_POPULATE_READ, when dealing with shared file/fd
mappings and not caring about memory bindings.
[1] https://lkml.kernel.org/r/20210816081922.5155-1-david@redhat.com
Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20211217134611.31172-3-david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-12-17 14:46:05 +01:00
|
|
|
static bool madv_populate_write_possible(char *area, size_t pagesize)
|
|
|
|
{
|
|
|
|
return !qemu_madvise(area, pagesize, QEMU_MADV_POPULATE_WRITE) ||
|
|
|
|
errno != EINVAL;
|
|
|
|
}
|
|
|
|
|
2023-11-20 15:33:19 +01:00
|
|
|
bool qemu_prealloc_mem(int fd, char *area, size_t sz, int max_threads,
|
2024-01-31 17:53:27 +01:00
|
|
|
ThreadContext *tc, bool async, Error **errp)
|
2014-05-14 11:43:21 +02:00
|
|
|
{
|
2021-12-17 14:46:09 +01:00
|
|
|
static gsize initialized;
|
2014-06-24 22:52:29 +02:00
|
|
|
int ret;
|
2017-02-24 04:31:43 +01:00
|
|
|
size_t hpagesize = qemu_fd_getpagesize(fd);
|
2022-10-14 15:47:14 +02:00
|
|
|
size_t numpages = DIV_ROUND_UP(sz, hpagesize);
|
util/oslib-posix: Support MADV_POPULATE_WRITE for os_mem_prealloc()
Let's sense support and use it for preallocation. MADV_POPULATE_WRITE
does not require a SIGBUS handler, doesn't actually touch page content,
and avoids context switches; it is, therefore, faster and easier to handle
than our current approach.
While MADV_POPULATE_WRITE is, in general, faster than manual
prefaulting, and especially faster with 4k pages, there is still value in
prefaulting using multiple threads to speed up preallocation.
More details on MADV_POPULATE_WRITE can be found in the Linux commits
4ca9b3859dac ("mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault
page tables") and eb2faa513c24 ("mm/madvise: report SIGBUS as -EFAULT for
MADV_POPULATE_(READ|WRITE)"), and in the man page proposal [1].
This resolves the TODO in do_touch_pages().
In the future, we might want to look into using fallocate(), eventually
combined with MADV_POPULATE_READ, when dealing with shared file/fd
mappings and not caring about memory bindings.
[1] https://lkml.kernel.org/r/20210816081922.5155-1-david@redhat.com
Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20211217134611.31172-3-david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-12-17 14:46:05 +01:00
|
|
|
bool use_madv_populate_write;
|
2021-12-17 14:46:10 +01:00
|
|
|
struct sigaction act;
|
2023-11-20 15:33:19 +01:00
|
|
|
bool rv = true;
|
2014-05-14 11:43:21 +02:00
|
|
|
|
util/oslib-posix: Support MADV_POPULATE_WRITE for os_mem_prealloc()
Let's sense support and use it for preallocation. MADV_POPULATE_WRITE
does not require a SIGBUS handler, doesn't actually touch page content,
and avoids context switches; it is, therefore, faster and easier to handle
than our current approach.
While MADV_POPULATE_WRITE is, in general, faster than manual
prefaulting, and especially faster with 4k pages, there is still value in
prefaulting using multiple threads to speed up preallocation.
More details on MADV_POPULATE_WRITE can be found in the Linux commits
4ca9b3859dac ("mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault
page tables") and eb2faa513c24 ("mm/madvise: report SIGBUS as -EFAULT for
MADV_POPULATE_(READ|WRITE)"), and in the man page proposal [1].
This resolves the TODO in do_touch_pages().
In the future, we might want to look into using fallocate(), eventually
combined with MADV_POPULATE_READ, when dealing with shared file/fd
mappings and not caring about memory bindings.
[1] https://lkml.kernel.org/r/20210816081922.5155-1-david@redhat.com
Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20211217134611.31172-3-david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-12-17 14:46:05 +01:00
|
|
|
/*
|
|
|
|
* Sense on every invocation, as MADV_POPULATE_WRITE cannot be used for
|
|
|
|
* some special mappings, such as mapping /dev/mem.
|
|
|
|
*/
|
|
|
|
use_madv_populate_write = madv_populate_write_possible(area, hpagesize);
|
|
|
|
|
|
|
|
if (!use_madv_populate_write) {
|
2021-12-17 14:46:09 +01:00
|
|
|
if (g_once_init_enter(&initialized)) {
|
|
|
|
qemu_mutex_init(&sigbus_mutex);
|
|
|
|
g_once_init_leave(&initialized, 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
qemu_mutex_lock(&sigbus_mutex);
|
util/oslib-posix: Support MADV_POPULATE_WRITE for os_mem_prealloc()
Let's sense support and use it for preallocation. MADV_POPULATE_WRITE
does not require a SIGBUS handler, doesn't actually touch page content,
and avoids context switches; it is, therefore, faster and easier to handle
than our current approach.
While MADV_POPULATE_WRITE is, in general, faster than manual
prefaulting, and especially faster with 4k pages, there is still value in
prefaulting using multiple threads to speed up preallocation.
More details on MADV_POPULATE_WRITE can be found in the Linux commits
4ca9b3859dac ("mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault
page tables") and eb2faa513c24 ("mm/madvise: report SIGBUS as -EFAULT for
MADV_POPULATE_(READ|WRITE)"), and in the man page proposal [1].
This resolves the TODO in do_touch_pages().
In the future, we might want to look into using fallocate(), eventually
combined with MADV_POPULATE_READ, when dealing with shared file/fd
mappings and not caring about memory bindings.
[1] https://lkml.kernel.org/r/20210816081922.5155-1-david@redhat.com
Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20211217134611.31172-3-david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-12-17 14:46:05 +01:00
|
|
|
memset(&act, 0, sizeof(act));
|
2021-12-17 14:46:10 +01:00
|
|
|
#ifdef CONFIG_LINUX
|
|
|
|
act.sa_sigaction = &sigbus_handler;
|
|
|
|
act.sa_flags = SA_SIGINFO;
|
|
|
|
#else /* CONFIG_LINUX */
|
util/oslib-posix: Support MADV_POPULATE_WRITE for os_mem_prealloc()
Let's sense support and use it for preallocation. MADV_POPULATE_WRITE
does not require a SIGBUS handler, doesn't actually touch page content,
and avoids context switches; it is, therefore, faster and easier to handle
than our current approach.
While MADV_POPULATE_WRITE is, in general, faster than manual
prefaulting, and especially faster with 4k pages, there is still value in
prefaulting using multiple threads to speed up preallocation.
More details on MADV_POPULATE_WRITE can be found in the Linux commits
4ca9b3859dac ("mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault
page tables") and eb2faa513c24 ("mm/madvise: report SIGBUS as -EFAULT for
MADV_POPULATE_(READ|WRITE)"), and in the man page proposal [1].
This resolves the TODO in do_touch_pages().
In the future, we might want to look into using fallocate(), eventually
combined with MADV_POPULATE_READ, when dealing with shared file/fd
mappings and not caring about memory bindings.
[1] https://lkml.kernel.org/r/20210816081922.5155-1-david@redhat.com
Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20211217134611.31172-3-david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-12-17 14:46:05 +01:00
|
|
|
act.sa_handler = &sigbus_handler;
|
|
|
|
act.sa_flags = 0;
|
2021-12-17 14:46:10 +01:00
|
|
|
#endif /* CONFIG_LINUX */
|
util/oslib-posix: Support MADV_POPULATE_WRITE for os_mem_prealloc()
Let's sense support and use it for preallocation. MADV_POPULATE_WRITE
does not require a SIGBUS handler, doesn't actually touch page content,
and avoids context switches; it is, therefore, faster and easier to handle
than our current approach.
While MADV_POPULATE_WRITE is, in general, faster than manual
prefaulting, and especially faster with 4k pages, there is still value in
prefaulting using multiple threads to speed up preallocation.
More details on MADV_POPULATE_WRITE can be found in the Linux commits
4ca9b3859dac ("mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault
page tables") and eb2faa513c24 ("mm/madvise: report SIGBUS as -EFAULT for
MADV_POPULATE_(READ|WRITE)"), and in the man page proposal [1].
This resolves the TODO in do_touch_pages().
In the future, we might want to look into using fallocate(), eventually
combined with MADV_POPULATE_READ, when dealing with shared file/fd
mappings and not caring about memory bindings.
[1] https://lkml.kernel.org/r/20210816081922.5155-1-david@redhat.com
Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20211217134611.31172-3-david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-12-17 14:46:05 +01:00
|
|
|
|
2021-12-17 14:46:10 +01:00
|
|
|
ret = sigaction(SIGBUS, &act, &sigbus_oldact);
|
util/oslib-posix: Support MADV_POPULATE_WRITE for os_mem_prealloc()
Let's sense support and use it for preallocation. MADV_POPULATE_WRITE
does not require a SIGBUS handler, doesn't actually touch page content,
and avoids context switches; it is, therefore, faster and easier to handle
than our current approach.
While MADV_POPULATE_WRITE is, in general, faster than manual
prefaulting, and especially faster with 4k pages, there is still value in
prefaulting using multiple threads to speed up preallocation.
More details on MADV_POPULATE_WRITE can be found in the Linux commits
4ca9b3859dac ("mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault
page tables") and eb2faa513c24 ("mm/madvise: report SIGBUS as -EFAULT for
MADV_POPULATE_(READ|WRITE)"), and in the man page proposal [1].
This resolves the TODO in do_touch_pages().
In the future, we might want to look into using fallocate(), eventually
combined with MADV_POPULATE_READ, when dealing with shared file/fd
mappings and not caring about memory bindings.
[1] https://lkml.kernel.org/r/20210816081922.5155-1-david@redhat.com
Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20211217134611.31172-3-david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-12-17 14:46:05 +01:00
|
|
|
if (ret) {
|
2022-01-11 13:08:30 +01:00
|
|
|
qemu_mutex_unlock(&sigbus_mutex);
|
util/oslib-posix: Support MADV_POPULATE_WRITE for os_mem_prealloc()
Let's sense support and use it for preallocation. MADV_POPULATE_WRITE
does not require a SIGBUS handler, doesn't actually touch page content,
and avoids context switches; it is, therefore, faster and easier to handle
than our current approach.
While MADV_POPULATE_WRITE is, in general, faster than manual
prefaulting, and especially faster with 4k pages, there is still value in
prefaulting using multiple threads to speed up preallocation.
More details on MADV_POPULATE_WRITE can be found in the Linux commits
4ca9b3859dac ("mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault
page tables") and eb2faa513c24 ("mm/madvise: report SIGBUS as -EFAULT for
MADV_POPULATE_(READ|WRITE)"), and in the man page proposal [1].
This resolves the TODO in do_touch_pages().
In the future, we might want to look into using fallocate(), eventually
combined with MADV_POPULATE_READ, when dealing with shared file/fd
mappings and not caring about memory bindings.
[1] https://lkml.kernel.org/r/20210816081922.5155-1-david@redhat.com
Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20211217134611.31172-3-david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-12-17 14:46:05 +01:00
|
|
|
error_setg_errno(errp, errno,
|
2022-10-14 15:47:14 +02:00
|
|
|
"qemu_prealloc_mem: failed to install signal handler");
|
2023-11-20 15:33:19 +01:00
|
|
|
return false;
|
util/oslib-posix: Support MADV_POPULATE_WRITE for os_mem_prealloc()
Let's sense support and use it for preallocation. MADV_POPULATE_WRITE
does not require a SIGBUS handler, doesn't actually touch page content,
and avoids context switches; it is, therefore, faster and easier to handle
than our current approach.
While MADV_POPULATE_WRITE is, in general, faster than manual
prefaulting, and especially faster with 4k pages, there is still value in
prefaulting using multiple threads to speed up preallocation.
More details on MADV_POPULATE_WRITE can be found in the Linux commits
4ca9b3859dac ("mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault
page tables") and eb2faa513c24 ("mm/madvise: report SIGBUS as -EFAULT for
MADV_POPULATE_(READ|WRITE)"), and in the man page proposal [1].
This resolves the TODO in do_touch_pages().
In the future, we might want to look into using fallocate(), eventually
combined with MADV_POPULATE_READ, when dealing with shared file/fd
mappings and not caring about memory bindings.
[1] https://lkml.kernel.org/r/20210816081922.5155-1-david@redhat.com
Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20211217134611.31172-3-david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-12-17 14:46:05 +01:00
|
|
|
}
|
2014-05-14 11:43:21 +02:00
|
|
|
}
|
|
|
|
|
2017-02-24 04:31:43 +01:00
|
|
|
/* touch pages simultaneously */
|
2024-01-31 17:53:27 +01:00
|
|
|
ret = touch_all_pages(area, hpagesize, numpages, max_threads, tc, async,
|
util/oslib-posix: Support MADV_POPULATE_WRITE for os_mem_prealloc()
Let's sense support and use it for preallocation. MADV_POPULATE_WRITE
does not require a SIGBUS handler, doesn't actually touch page content,
and avoids context switches; it is, therefore, faster and easier to handle
than our current approach.
While MADV_POPULATE_WRITE is, in general, faster than manual
prefaulting, and especially faster with 4k pages, there is still value in
prefaulting using multiple threads to speed up preallocation.
More details on MADV_POPULATE_WRITE can be found in the Linux commits
4ca9b3859dac ("mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault
page tables") and eb2faa513c24 ("mm/madvise: report SIGBUS as -EFAULT for
MADV_POPULATE_(READ|WRITE)"), and in the man page proposal [1].
This resolves the TODO in do_touch_pages().
In the future, we might want to look into using fallocate(), eventually
combined with MADV_POPULATE_READ, when dealing with shared file/fd
mappings and not caring about memory bindings.
[1] https://lkml.kernel.org/r/20210816081922.5155-1-david@redhat.com
Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20211217134611.31172-3-david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-12-17 14:46:05 +01:00
|
|
|
use_madv_populate_write);
|
2021-12-17 14:46:04 +01:00
|
|
|
if (ret) {
|
|
|
|
error_setg_errno(errp, -ret,
|
2022-10-14 15:47:14 +02:00
|
|
|
"qemu_prealloc_mem: preallocating memory failed");
|
2023-11-20 15:33:19 +01:00
|
|
|
rv = false;
|
2016-07-20 11:54:03 +02:00
|
|
|
}
|
2014-05-14 11:43:21 +02:00
|
|
|
|
util/oslib-posix: Support MADV_POPULATE_WRITE for os_mem_prealloc()
Let's sense support and use it for preallocation. MADV_POPULATE_WRITE
does not require a SIGBUS handler, doesn't actually touch page content,
and avoids context switches; it is, therefore, faster and easier to handle
than our current approach.
While MADV_POPULATE_WRITE is, in general, faster than manual
prefaulting, and especially faster with 4k pages, there is still value in
prefaulting using multiple threads to speed up preallocation.
More details on MADV_POPULATE_WRITE can be found in the Linux commits
4ca9b3859dac ("mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault
page tables") and eb2faa513c24 ("mm/madvise: report SIGBUS as -EFAULT for
MADV_POPULATE_(READ|WRITE)"), and in the man page proposal [1].
This resolves the TODO in do_touch_pages().
In the future, we might want to look into using fallocate(), eventually
combined with MADV_POPULATE_READ, when dealing with shared file/fd
mappings and not caring about memory bindings.
[1] https://lkml.kernel.org/r/20210816081922.5155-1-david@redhat.com
Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20211217134611.31172-3-david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-12-17 14:46:05 +01:00
|
|
|
if (!use_madv_populate_write) {
|
2021-12-17 14:46:10 +01:00
|
|
|
ret = sigaction(SIGBUS, &sigbus_oldact, NULL);
|
util/oslib-posix: Support MADV_POPULATE_WRITE for os_mem_prealloc()
Let's sense support and use it for preallocation. MADV_POPULATE_WRITE
does not require a SIGBUS handler, doesn't actually touch page content,
and avoids context switches; it is, therefore, faster and easier to handle
than our current approach.
While MADV_POPULATE_WRITE is, in general, faster than manual
prefaulting, and especially faster with 4k pages, there is still value in
prefaulting using multiple threads to speed up preallocation.
More details on MADV_POPULATE_WRITE can be found in the Linux commits
4ca9b3859dac ("mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault
page tables") and eb2faa513c24 ("mm/madvise: report SIGBUS as -EFAULT for
MADV_POPULATE_(READ|WRITE)"), and in the man page proposal [1].
This resolves the TODO in do_touch_pages().
In the future, we might want to look into using fallocate(), eventually
combined with MADV_POPULATE_READ, when dealing with shared file/fd
mappings and not caring about memory bindings.
[1] https://lkml.kernel.org/r/20210816081922.5155-1-david@redhat.com
Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20211217134611.31172-3-david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-12-17 14:46:05 +01:00
|
|
|
if (ret) {
|
|
|
|
/* Terminate QEMU since it can't recover from error */
|
2022-10-14 15:47:14 +02:00
|
|
|
perror("qemu_prealloc_mem: failed to reinstall signal handler");
|
util/oslib-posix: Support MADV_POPULATE_WRITE for os_mem_prealloc()
Let's sense support and use it for preallocation. MADV_POPULATE_WRITE
does not require a SIGBUS handler, doesn't actually touch page content,
and avoids context switches; it is, therefore, faster and easier to handle
than our current approach.
While MADV_POPULATE_WRITE is, in general, faster than manual
prefaulting, and especially faster with 4k pages, there is still value in
prefaulting using multiple threads to speed up preallocation.
More details on MADV_POPULATE_WRITE can be found in the Linux commits
4ca9b3859dac ("mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault
page tables") and eb2faa513c24 ("mm/madvise: report SIGBUS as -EFAULT for
MADV_POPULATE_(READ|WRITE)"), and in the man page proposal [1].
This resolves the TODO in do_touch_pages().
In the future, we might want to look into using fallocate(), eventually
combined with MADV_POPULATE_READ, when dealing with shared file/fd
mappings and not caring about memory bindings.
[1] https://lkml.kernel.org/r/20210816081922.5155-1-david@redhat.com
Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20211217134611.31172-3-david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-12-17 14:46:05 +01:00
|
|
|
exit(1);
|
|
|
|
}
|
2021-12-17 14:46:09 +01:00
|
|
|
qemu_mutex_unlock(&sigbus_mutex);
|
2014-06-24 22:52:29 +02:00
|
|
|
}
|
2023-11-20 15:33:19 +01:00
|
|
|
return rv;
|
2014-05-14 11:43:21 +02:00
|
|
|
}
|
2015-05-12 18:09:19 +02:00
|
|
|
|
2016-09-27 17:24:56 +02:00
|
|
|
char *qemu_get_pid_name(pid_t pid)
|
|
|
|
{
|
|
|
|
char *name = NULL;
|
|
|
|
|
|
|
|
#if defined(__FreeBSD__)
|
|
|
|
/* BSDs don't have /proc, but they provide a nice substitute */
|
|
|
|
struct kinfo_proc *proc = kinfo_getproc(pid);
|
|
|
|
|
|
|
|
if (proc) {
|
|
|
|
name = g_strdup(proc->ki_comm);
|
|
|
|
free(proc);
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
/* Assume a system with reasonable procfs */
|
|
|
|
char *pid_path;
|
|
|
|
size_t len;
|
|
|
|
|
|
|
|
pid_path = g_strdup_printf("/proc/%d/cmdline", pid);
|
|
|
|
g_file_get_contents(pid_path, &name, &len, NULL);
|
|
|
|
g_free(pid_path);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
return name;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2016-09-27 11:58:40 +02:00
|
|
|
void *qemu_alloc_stack(size_t *sz)
|
|
|
|
{
|
2023-09-09 23:37:24 +02:00
|
|
|
void *ptr;
|
2018-10-19 14:52:39 +02:00
|
|
|
int flags;
|
2016-09-27 11:58:45 +02:00
|
|
|
#ifdef CONFIG_DEBUG_STACK_USAGE
|
|
|
|
void *ptr2;
|
|
|
|
#endif
|
2022-03-23 16:57:22 +01:00
|
|
|
size_t pagesz = qemu_real_host_page_size();
|
2016-09-27 11:58:40 +02:00
|
|
|
#ifdef _SC_THREAD_STACK_MIN
|
|
|
|
/* avoid stacks smaller than _SC_THREAD_STACK_MIN */
|
|
|
|
long min_stack_sz = sysconf(_SC_THREAD_STACK_MIN);
|
|
|
|
*sz = MAX(MAX(min_stack_sz, 0), *sz);
|
|
|
|
#endif
|
|
|
|
/* adjust stack size to a multiple of the page size */
|
|
|
|
*sz = ROUND_UP(*sz, pagesz);
|
|
|
|
/* allocate one extra page for the guard page */
|
|
|
|
*sz += pagesz;
|
|
|
|
|
2018-10-19 14:52:39 +02:00
|
|
|
flags = MAP_PRIVATE | MAP_ANONYMOUS;
|
|
|
|
#if defined(MAP_STACK) && defined(__OpenBSD__)
|
|
|
|
/* Only enable MAP_STACK on OpenBSD. Other OS's such as
|
|
|
|
* Linux/FreeBSD/NetBSD have a flag with the same name
|
|
|
|
* but have differing functionality. OpenBSD will SEGV
|
|
|
|
* if it spots execution with a stack pointer pointing
|
|
|
|
* at memory that was not allocated with MAP_STACK.
|
|
|
|
*/
|
|
|
|
flags |= MAP_STACK;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
ptr = mmap(NULL, *sz, PROT_READ | PROT_WRITE, flags, -1, 0);
|
2016-09-27 11:58:40 +02:00
|
|
|
if (ptr == MAP_FAILED) {
|
2017-08-29 23:20:53 +02:00
|
|
|
perror("failed to allocate memory for stack");
|
2016-09-27 11:58:40 +02:00
|
|
|
abort();
|
|
|
|
}
|
|
|
|
|
2023-09-09 23:37:24 +02:00
|
|
|
/* Stack grows down -- guard page at the bottom. */
|
|
|
|
if (mprotect(ptr, pagesz, PROT_NONE) != 0) {
|
2017-08-29 23:20:53 +02:00
|
|
|
perror("failed to set up stack guard page");
|
2016-09-27 11:58:40 +02:00
|
|
|
abort();
|
|
|
|
}
|
|
|
|
|
2016-09-27 11:58:45 +02:00
|
|
|
#ifdef CONFIG_DEBUG_STACK_USAGE
|
|
|
|
for (ptr2 = ptr + pagesz; ptr2 < ptr + *sz; ptr2 += sizeof(uint32_t)) {
|
|
|
|
*(uint32_t *)ptr2 = 0xdeadbeaf;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2016-09-27 11:58:40 +02:00
|
|
|
return ptr;
|
|
|
|
}
|
|
|
|
|
2016-09-27 11:58:45 +02:00
|
|
|
#ifdef CONFIG_DEBUG_STACK_USAGE
|
|
|
|
static __thread unsigned int max_stack_usage;
|
|
|
|
#endif
|
|
|
|
|
2016-09-27 11:58:40 +02:00
|
|
|
void qemu_free_stack(void *stack, size_t sz)
|
|
|
|
{
|
2016-09-27 11:58:45 +02:00
|
|
|
#ifdef CONFIG_DEBUG_STACK_USAGE
|
|
|
|
unsigned int usage;
|
|
|
|
void *ptr;
|
|
|
|
|
2022-03-23 16:57:22 +01:00
|
|
|
for (ptr = stack + qemu_real_host_page_size(); ptr < stack + sz;
|
2016-09-27 11:58:45 +02:00
|
|
|
ptr += sizeof(uint32_t)) {
|
|
|
|
if (*(uint32_t *)ptr != 0xdeadbeaf) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
usage = sz - (uintptr_t) (ptr - stack);
|
|
|
|
if (usage > max_stack_usage) {
|
|
|
|
error_report("thread %d max stack usage increased from %u to %u",
|
|
|
|
qemu_get_thread_id(), max_stack_usage, usage);
|
|
|
|
max_stack_usage = usage;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2016-09-27 11:58:40 +02:00
|
|
|
munmap(stack, sz);
|
|
|
|
}
|
2017-02-08 13:22:12 +01:00
|
|
|
|
cfi: Initial support for cfi-icall in QEMU
LLVM/Clang, supports runtime checks for forward-edge Control-Flow
Integrity (CFI).
CFI on indirect function calls (cfi-icall) ensures that, in indirect
function calls, the function called is of the right signature for the
pointer type defined at compile time.
For this check to work, the code must always respect the function
signature when using function pointer, the function must be defined
at compile time, and be compiled with link-time optimization.
This rules out, for example, shared libraries that are dynamically loaded
(given that functions are not known at compile time), and code that is
dynamically generated at run-time.
This patch:
1) Introduces the CONFIG_CFI flag to support cfi in QEMU
2) Introduces a decorator to allow the definition of "sensitive"
functions, where a non-instrumented function may be called at runtime
through a pointer. The decorator will take care of disabling cfi-icall
checks on such functions, when cfi is enabled.
3) Marks functions currently in QEMU that exhibit such behavior,
in particular:
- The function in TCG that calls pre-compiled TBs
- The function in TCI that interprets instructions
- Functions in the plugin infrastructures that jump to callbacks
- Functions in util that directly call a signal handler
Signed-off-by: Daniele Buono <dbuono@linux.vnet.ibm.com>
Acked-by: Alex Bennée <alex.bennee@linaro.org
Message-Id: <20201204230615.2392-3-dbuono@linux.vnet.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-12-05 00:06:12 +01:00
|
|
|
/*
|
|
|
|
* Disable CFI checks.
|
2023-08-23 08:53:15 +02:00
|
|
|
* We are going to call a signal handler directly. Such handler may or may not
|
cfi: Initial support for cfi-icall in QEMU
LLVM/Clang, supports runtime checks for forward-edge Control-Flow
Integrity (CFI).
CFI on indirect function calls (cfi-icall) ensures that, in indirect
function calls, the function called is of the right signature for the
pointer type defined at compile time.
For this check to work, the code must always respect the function
signature when using function pointer, the function must be defined
at compile time, and be compiled with link-time optimization.
This rules out, for example, shared libraries that are dynamically loaded
(given that functions are not known at compile time), and code that is
dynamically generated at run-time.
This patch:
1) Introduces the CONFIG_CFI flag to support cfi in QEMU
2) Introduces a decorator to allow the definition of "sensitive"
functions, where a non-instrumented function may be called at runtime
through a pointer. The decorator will take care of disabling cfi-icall
checks on such functions, when cfi is enabled.
3) Marks functions currently in QEMU that exhibit such behavior,
in particular:
- The function in TCG that calls pre-compiled TBs
- The function in TCI that interprets instructions
- Functions in the plugin infrastructures that jump to callbacks
- Functions in util that directly call a signal handler
Signed-off-by: Daniele Buono <dbuono@linux.vnet.ibm.com>
Acked-by: Alex Bennée <alex.bennee@linaro.org
Message-Id: <20201204230615.2392-3-dbuono@linux.vnet.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-12-05 00:06:12 +01:00
|
|
|
* have been defined in our binary, so there's no guarantee that the pointer
|
|
|
|
* used to set the handler is a cfi-valid pointer. Since the handlers are
|
|
|
|
* stored in kernel memory, changing the handler to an attacker-defined
|
|
|
|
* function requires being able to call a sigaction() syscall,
|
|
|
|
* which is not as easy as overwriting a pointer in memory.
|
|
|
|
*/
|
|
|
|
QEMU_DISABLE_CFI
|
2017-02-08 13:22:12 +01:00
|
|
|
void sigaction_invoke(struct sigaction *action,
|
|
|
|
struct qemu_signalfd_siginfo *info)
|
|
|
|
{
|
2017-07-20 18:32:21 +02:00
|
|
|
siginfo_t si = {};
|
2017-02-08 13:22:12 +01:00
|
|
|
si.si_signo = info->ssi_signo;
|
|
|
|
si.si_errno = info->ssi_errno;
|
|
|
|
si.si_code = info->ssi_code;
|
|
|
|
|
|
|
|
/* Convert the minimal set of fields defined by POSIX.
|
|
|
|
* Positive si_code values are reserved for kernel-generated
|
|
|
|
* signals, where the valid siginfo fields are determined by
|
|
|
|
* the signal number. But according to POSIX, it is unspecified
|
|
|
|
* whether SI_USER and SI_QUEUE have values less than or equal to
|
|
|
|
* zero.
|
|
|
|
*/
|
|
|
|
if (info->ssi_code == SI_USER || info->ssi_code == SI_QUEUE ||
|
|
|
|
info->ssi_code <= 0) {
|
|
|
|
/* SIGTERM, etc. */
|
|
|
|
si.si_pid = info->ssi_pid;
|
|
|
|
si.si_uid = info->ssi_uid;
|
|
|
|
} else if (info->ssi_signo == SIGILL || info->ssi_signo == SIGFPE ||
|
|
|
|
info->ssi_signo == SIGSEGV || info->ssi_signo == SIGBUS) {
|
|
|
|
si.si_addr = (void *)(uintptr_t)info->ssi_addr;
|
|
|
|
} else if (info->ssi_signo == SIGCHLD) {
|
|
|
|
si.si_pid = info->ssi_pid;
|
|
|
|
si.si_status = info->ssi_status;
|
|
|
|
si.si_uid = info->ssi_uid;
|
|
|
|
}
|
|
|
|
action->sa_sigaction(info->ssi_signo, &si, NULL);
|
|
|
|
}
|
2020-06-22 20:19:35 +02:00
|
|
|
|
2020-07-24 08:44:57 +02:00
|
|
|
size_t qemu_get_host_physmem(void)
|
|
|
|
{
|
|
|
|
#ifdef _SC_PHYS_PAGES
|
|
|
|
long pages = sysconf(_SC_PHYS_PAGES);
|
|
|
|
if (pages > 0) {
|
2022-03-23 16:57:22 +01:00
|
|
|
if (pages > SIZE_MAX / qemu_real_host_page_size()) {
|
2020-07-24 08:44:57 +02:00
|
|
|
return SIZE_MAX;
|
|
|
|
} else {
|
2022-03-23 16:57:22 +01:00
|
|
|
return pages * qemu_real_host_page_size();
|
2020-07-24 08:44:57 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
return 0;
|
|
|
|
}
|
2022-03-23 16:57:40 +01:00
|
|
|
|
2022-04-20 15:26:03 +02:00
|
|
|
int qemu_msync(void *addr, size_t length, int fd)
|
|
|
|
{
|
|
|
|
size_t align_mask = ~(qemu_real_host_page_size() - 1);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* There are no strict reqs as per the length of mapping
|
|
|
|
* to be synced. Still the length needs to follow the address
|
|
|
|
* alignment changes. Additionally - round the size to the multiple
|
|
|
|
* of PAGE_SIZE
|
|
|
|
*/
|
|
|
|
length += ((uintptr_t)addr & (qemu_real_host_page_size() - 1));
|
|
|
|
length = (length + ~align_mask) & align_mask;
|
|
|
|
|
|
|
|
addr = (void *)((uintptr_t)addr & align_mask);
|
|
|
|
|
|
|
|
return msync(addr, length, MS_SYNC);
|
|
|
|
}
|