aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-01-22linux-user: Add support for getting/setting RTC wakeup alarm using ioctlsFilip Bozuta3-0/+9
This patch implements functionalities of following ioctls: RTC_WKALM_SET, RTC_WKALM_GET - Getting/Setting wakeup alarm Some RTCs support a more powerful alarm interface, using these ioctls to read or write the RTC's alarm time (respectively) with this structure: struct rtc_wkalrm { unsigned char enabled; unsigned char pending; struct rtc_time time; }; The enabled flag is used to enable or disable the alarm interrupt, or to read its current status; when using these calls, RTC_AIE_ON and RTC_AIE_OFF are not used. The pending flag is used by RTC_WKALM_RD to report a pending interrupt (so it's mostly useless on Linux, except when talking to the RTC managed by EFI firmware). The time field is as used with RTC_ALM_READ and RTC_ALM_SET except that the tm_mday, tm_mon, and tm_year fields are also valid. A pointer to this structure should be passed as the third ioctl's argument. Implementation notes: All ioctls in this patch have a pointer to a structure rtc_wkalrm as their third argument. That is the reason why corresponding definition is added in linux-user/syscall_types.h. Since all elements of this structure are either of type 'unsigned char' or 'struct rtc_time' (that was covered in one of previous patches), the rest of the implementation is straightforward. Reviewed-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Filip Bozuta <Filip.Bozuta@rt-rk.com> Message-Id: <1579117007-7565-5-git-send-email-Filip.Bozuta@rt-rk.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-01-22linux-user: Add support for getting/setting RTC periodic interrupt and epoch ↵Filip Bozuta2-0/+8
using ioctls This patch implements functionalities of following ioctls: RTC_IRQP_READ, RTC_IRQP_SET - Getting/Setting IRQ rate Read and set the frequency for periodic interrupts, for RTCs that support periodic interrupts. The periodic interrupt must be separately enabled or disabled using the RTC_PIE_ON, RTC_PIE_OFF requests. The third ioctl's argument is an unsigned long * or an unsigned long, respectively. The value is the frequency in interrupts per second. The set of allow‐ able frequencies is the multiples of two in the range 2 to 8192. Only a privileged process (i.e., one having the CAP_SYS_RESOURCE capability) can set frequencies above the value specified in /proc/sys/dev/rtc/max-user-freq. (This file contains the value 64 by default.) RTC_EPOCH_READ, RTC_EPOCH_SET - Getting/Setting epoch Many RTCs encode the year in an 8-bit register which is either interpreted as an 8-bit binary number or as a BCD number. In both cases, the number is interpreted relative to this RTC's Epoch. The RTC's Epoch is initialized to 1900 on most systems but on Alpha and MIPS it might also be initialized to 1952, 1980, or 2000, depending on the value of an RTC register for the year. With some RTCs, these operations can be used to read or to set the RTC's Epoch, respectively. The third ioctl's argument is an unsigned long * or an unsigned long, respectively, and the value returned (or assigned) is the Epoch. To set the RTC's Epoch the process must be privileged (i.e., have the CAP_SYS_TIME capability). Implementation notes: All ioctls in this patch have a pointer to 'ulong' as their third argument. That is the reason why corresponding parts of added code in linux-user/syscall_defs.h contain special handling related to 'ulong' type: they use 'abi_ulong' type to make sure that ioctl's code is calculated correctly for both 32-bit and 64-bit targets. Also, 'MK_PTR(TYPE_ULONG)' is used for the similar reason in linux-user/ioctls.h. Reviewed-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Filip Bozuta <Filip.Bozuta@rt-rk.com> Message-Id: <1579117007-7565-4-git-send-email-Filip.Bozuta@rt-rk.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-01-22linux-user: Add support for getting/setting RTC time and alarm using ioctlsFilip Bozuta3-0/+19
This patch implements functionalities of following ioctls: RTC_RD_TIME - Getting RTC time Returns this RTC's time in the following structure: struct rtc_time { int tm_sec; int tm_min; int tm_hour; int tm_mday; int tm_mon; int tm_year; int tm_wday; /* unused */ int tm_yday; /* unused */ int tm_isdst; /* unused */ }; The fields in this structure have the same meaning and ranges as the tm structure described in gmtime man page. A pointer to this structure should be passed as the third ioctl's argument. RTC_SET_TIME - Setting RTC time Sets this RTC's time to the time specified by the rtc_time structure pointed to by the third ioctl's argument. To set the RTC's time the process must be privileged (i.e., have the CAP_SYS_TIME capability). RTC_ALM_READ, RTC_ALM_SET - Getting/Setting alarm time Read and set the alarm time, for RTCs that support alarms. The alarm interrupt must be separately enabled or disabled using the RTC_AIE_ON, RTC_AIE_OFF requests. The third ioctl's argument is a pointer to a rtc_time structure. Only the tm_sec, tm_min, and tm_hour fields of this structure are used. Implementation notes: All ioctls in this patch have pointer to a structure rtc_time as their third argument. That is the reason why corresponding definition is added in linux-user/syscall_types.h. Since all elements of this structure are of type 'int', the rest of the implementation is straightforward. Reviewed-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Filip Bozuta <Filip.Bozuta@rt-rk.com> Message-Id: <1579117007-7565-3-git-send-email-Filip.Bozuta@rt-rk.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-01-22linux-user: Add support for enabling/disabling RTC features using ioctlsFilip Bozuta3-0/+20
This patch implements functionalities of following ioctls: RTC_AIE_ON, RTC_AIE_OFF - Alarm interrupt enabling on/off Enable or disable the alarm interrupt, for RTCs that support alarms. The third ioctl's argument is ignored. RTC_UIE_ON, RTC_UIE_OFF - Update interrupt enabling on/off Enable or disable the interrupt on every clock update, for RTCs that support this once-per-second interrupt. The third ioctl's argument is ignored. RTC_PIE_ON, RTC_PIE_OFF - Periodic interrupt enabling on/off Enable or disable the periodic interrupt, for RTCs that sup‐ port these periodic interrupts. The third ioctl's argument is ignored. Only a privileged process (i.e., one having the CAP_SYS_RESOURCE capability) can enable the periodic interrupt if the frequency is currently set above the value specified in /proc/sys/dev/rtc/max-user-freq. RTC_WIE_ON, RTC_WIE_OFF - Watchdog interrupt enabling on/off Enable or disable the Watchdog interrupt, for RTCs that sup- port this Watchdog interrupt. The third ioctl's argument is ignored. Implementation notes: Since all of involved ioctls have NULL as their third argument, their implementation was straightforward. The line '#include <linux/rtc.h>' was added to recognize preprocessor definitions for these ioctls. This needs to be done only once in this series of commits. Also, the content of this file (with respect to ioctl definitions) remained unchanged for a long time, therefore there is no need to worry about supporting older Linux kernel version. Reviewed-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Filip Bozuta <Filip.Bozuta@rt-rk.com> Message-Id: <1579117007-7565-2-git-send-email-Filip.Bozuta@rt-rk.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-01-22linux-user: Add support for TYPE_LONG and TYPE_ULONG in do_ioctl()Filip Bozuta1-0/+2
Function "do_ioctl()" located in file "syscall.c" was missing an option for TYPE_LONG and TYPE_ULONG. This caused some ioctls to not be recognised because they had the third argument that was of type 'long' or 'unsigned long'. For example: Since implemented ioctls RTC_IRQP_SET and RTC_EPOCH_SET are of type IOW(writing type) that have unsigned long as their third argument, they were not recognised in QEMU before the changes of this patch. Signed-off-by: Filip Bozuta <Filip.Bozuta@rt-rk.com> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <1579117007-7565-14-git-send-email-Filip.Bozuta@rt-rk.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-01-22linux-user: Add support for KCOV_INIT_TRACE ioctlAleksandar Markovic2-0/+2
KCOV_INIT_TRACE ioctl plays the role in kernel coverage tracing. This ioctl's third argument is of type 'unsigned long', and the implementation in QEMU is straightforward. Reviewed-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com> Message-Id: <1579214991-19602-13-git-send-email-aleksandar.markovic@rt-rk.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-01-22linux-user: Add support for KCOV_<ENABLE|DISABLE> ioctlsAleksandar Markovic3-0/+12
KCOV_ENABLE and KCOV_DISABLE play the role in kernel coverage tracing. These ioctls do not use the third argument of ioctl() system call and are straightforward to implement in QEMU. Reviewed-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com> Message-Id: <1579214991-19602-12-git-send-email-aleksandar.markovic@rt-rk.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-01-22configure: Detect kcov support and introduce CONFIG_KCOVAleksandar Markovic1-0/+9
kcov is kernel code coverage tracing tool. It requires kernel 4.4+ compiled with certain kernel options. This patch checks if kcov header "sys/kcov.h" is present on build machine, and stores the result in variable CONFIG_KCOV, meant to be used in linux-user code related to the support for three ioctls that were introduced at the same time as the mentioned header (their definition was a part of the first version of that header). Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <1579214991-19602-11-git-send-email-aleksandar.markovic@rt-rk.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-01-22linux-user: Add support for FDFMT<BEG|TRK|END> ioctlsAleksandar Markovic3-0/+11
FDFMTBEG, FDFMTTRK, and FDFMTEND ioctls provide means for controlling formatting of a floppy drive. FDFMTTRK's third agrument is a pointer to the structure: struct format_descr { unsigned int device,head,track; }; defined in Linux kernel header <linux/fd.h>. Since all fields of the structure are of type 'unsigned int', there is no need to define "target_format_descr". FDFMTBEG and FDFMTEND ioctls do not use the third argument. Reviewed-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com> Message-Id: <1579214991-19602-9-git-send-email-aleksandar.markovic@rt-rk.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-01-22linux-user: Add support for FD<SETEMSGTRESH|SETMAXERRS|GETMAXERRS> ioctlsAleksandar Markovic3-0/+13
FDSETEMSGTRESH, FDSETMAXERRS, and FDGETMAXERRS ioctls are commands for controlling error reporting of a floppy drive. FDSETEMSGTRESH's third agrument is a pointer to the structure: struct floppy_max_errors { unsigned int abort, /* number of errors to be reached before aborting */ read_track, /* maximal number of errors permitted to read an * entire track at once */ reset, /* maximal number of errors before a reset is tried */ recal, /* maximal number of errors before a recalibrate is * tried */ /* * Threshold for reporting FDC errors to the console. * Setting this to zero may flood your screen when using * ultra cheap floppies ;-) */ reporting; }; defined in Linux kernel header <linux/fd.h>. Since all fields of the structure are of type 'unsigned int', there is no need to define "target_floppy_max_errors". FDSETMAXERRS and FDGETMAXERRS ioctls do not use the third argument. Reviewed-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com> Message-Id: <1579214991-19602-8-git-send-email-aleksandar.markovic@rt-rk.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-01-22linux-user: Add support for FS_IOC32_<GET|SET>VERSION ioctlsAleksandar Markovic2-0/+4
These FS_IOC32_<GET|SET>VERSION ioctls are identical to FS_IOC_<GET|SET>VERSION ioctls, but without the anomaly of their number defined as if their third argument is of type long, while it is treated internally in kernel as is of type int. Reviewed-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com> Message-Id: <1579214991-19602-4-git-send-email-aleksandar.markovic@rt-rk.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-01-22linux-user: Add support for FS_IOC32_<GET|SET>FLAGS ioctlsAleksandar Markovic2-0/+4
These FS_IOC32_<GET|SET>FLAGS ioctls are identical to FS_IOC_<GET|SET>FLAGS ioctls, but without the anomaly of their number defined as if their third argument is of type long, while it is treated internally in kernel as is of type int. Reviewed-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com> Message-Id: <1579214991-19602-3-git-send-email-aleksandar.markovic@rt-rk.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-01-22linux-user: Add support for FS_IOC_<GET|SET>VERSION ioctlsAleksandar Markovic2-3/+7
A very specific thing for these two ioctls is that their code implies that their third argument is of type 'long', but the kernel uses that argument as if it is of type 'int'. This anomaly is recognized also in commit 6080723 (linux-user: Implement FS_IOC_GETFLAGS and FS_IOC_SETFLAGS ioctls). Reviewed-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com> Message-Id: <1579214991-19602-2-git-send-email-aleksandar.markovic@rt-rk.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-01-22linux-user: Reserve space for brkRichard Henderson2-17/+57
With bad luck, we can wind up with no space at all for brk, which will generally cause the guest malloc to fail. This bad luck is easier to come by with ET_DYN (PIE) binaries, where either the stack or the interpreter (ld.so) gets placed immediately after the main executable. But there's nothing preventing this same thing from happening with ET_EXEC (normal) binaries, during probe_guest_base(). In both cases, reserve some extra space via mmap and release it back to the system after loading the interpreter and allocating the stack. The choice of 16MB is somewhat arbitrary. It's enough for libc to get going, but without being so large that 32-bit guests or 32-bit hosts are in danger of running out of virtual address space. It is expected that libc will be able to fall back to mmap arenas after the limited brk space is exhausted. Launchpad: https://bugs.launchpad.net/qemu/+bug/1749393 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20200117230245.5040-1-richard.henderson@linaro.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-01-22linux-user:Fix align mistake when mmap guest spaceXinyu Li1-1/+1
In init_guest_space, we need to mmap guest space. If the return address of first mmap is not aligned with align, which was set to MAX(SHMLBA, qemu_host_page_size), we need unmap and a new mmap(space is larger than first size). The new size is named real_size, which is aligned_size + qemu_host_page_size. alugned_size is the guest space size. And add a qemu_host_page_size to avoid memory error when we align real_start manually (ROUND_UP(real_start, align)). But when SHMLBA > qemu_host_page_size, the added size will smaller than the size to align, which can make a mistake(in a mips machine, it appears). So change real_size from aligned_size +qemu_host_page_size to aligned_size + align will solve it. Signed-off-by: Xinyu Li <precinct@mail.ustc.edu.cn> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20191213022919.5934-1-precinct@mail.ustc.edu.cn> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2020-01-21Merge remote-tracking branch 'remotes/philmd-gitlab/tags/edk2-next-20200121' ↵Peter Maydell5-0/+84
into staging EDK2 firmware patches Another set of build-sys patches, to help building the firmware binaries we use for testing. We almost have reproducible builds. # gpg: Signature made Tue 21 Jan 2020 15:14:09 GMT # gpg: using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE # gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.org>" [full] # Primary key fingerprint: FAAB E75E 1291 7221 DCFD 6BB2 E3E3 2C2C DEAD C0DE * remotes/philmd-gitlab/tags/edk2-next-20200121: gitlab-ci.yml: Add jobs to build EDK2 firmware binaries roms/edk2-funcs: Force softfloat ARM toolchain prefix on Debian Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-21gitlab-ci.yml: Add jobs to build EDK2 firmware binariesPhilippe Mathieu-Daudé4-0/+81
Add two GitLab job to build the EDK2 firmware binaries. The first job build a Docker image with the packages requisite to build EDK2, and store this image in the GitLab registry. The second job pull the image from the registry and build the EDK2 firmware binaries. The docker image is only rebuilt if the GitLab YAML or the Dockerfile is updated. The second job is only built when the roms/edk2/ submodule is updated, when a git-ref starts with 'edk2' or when the last commit contains 'EDK2'. The files generated are archived in the artifacts.zip file. With edk2-stable201905, it took 2 minutes 52 seconds to build the docker image, and 36 minutes 28 seconds to generate the artifacts.zip with the firmware binaries (filesize: 10MiB). See: https://gitlab.com/philmd/qemu/pipelines/107553178 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-01-21roms/edk2-funcs: Force softfloat ARM toolchain prefix on DebianPhilippe Mathieu-Daudé1-0/+3
The Debian (based) distributions currently provides 2 ARM toolchains, documented as [1]: * The ARM EABI (armel) port targets a range of older 32-bit ARM devices, particularly those used in NAS hardware and a variety of *plug computers. * The newer ARM hard-float (armhf) port supports newer, more powerful 32-bit devices using version 7 of the ARM architecture specification. For various reasons documented in [2], the EDK2 project suggests to use the softfloat toolchain (named 'armel' by Debian). Force the softfloat cross toolchain prefix on Debian distributions. [1] https://www.debian.org/ports/arm/#status [2] https://github.com/tianocore/edk2/commit/41203b9a Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-01-21Merge remote-tracking branch 'remotes/vivier/tags/m68k-for-5.0-pull-request' ↵Peter Maydell1-15/+27
into staging Fix m68k single-stepping with remote gdb # gpg: Signature made Tue 21 Jan 2020 12:21:12 GMT # gpg: using RSA key CD2F75DDC8E3A4DC2E4F5173F30C38BD3F2FBE3C # gpg: issuer "laurent@vivier.eu" # gpg: Good signature from "Laurent Vivier <lvivier@redhat.com>" [full] # gpg: aka "Laurent Vivier <laurent@vivier.eu>" [full] # gpg: aka "Laurent Vivier (Red Hat) <lvivier@redhat.com>" [full] # Primary key fingerprint: CD2F 75DD C8E3 A4DC 2E4F 5173 F30C 38BD 3F2F BE3C * remotes/vivier/tags/m68k-for-5.0-pull-request: m68k: Fix regression causing Single-Step via GDB/RSP to not single step Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-21m68k: Fix regression causing Single-Step via GDB/RSP to not single stepLaurent Vivier1-15/+27
A regression that was introduced, with the refactor to TranslatorOps, drops two lines that update the PC when single-stepping is being performed. Fixes: 11ab74b01e0a ("target/m68k: Convert to TranslatorOps") Reported-by: Lucien Murray-Pitts <lucienmp_antispam@yahoo.com> Suggested-by: Lucien Murray-Pitts <lucienmp_antispam@yahoo.com> Suggested-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20200116165454.2076265-1-laurent@vivier.eu>
2020-01-21Makefile: add missing mkdir MANUAL_BUILDDIRStefan Hajnoczi1-0/+1
The MANUAL_BUILDDIR directory is automatically created by sphinx-build for the other targets. The index.html target does not use sphinx-build so we must manually create the directory to avoid the following error: GEN docs/built/index.html /bin/sh: docs/built/index.html: No such file or directory Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 20200120163400.603449-1-stefanha@redhat.com Reviewed-by: Miroslav Rezanina <mrezanin@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-20Merge remote-tracking branch 'remotes/gkurz/tags/9p-next-2020-01-20' into ↵Peter Maydell6-39/+49
staging Assorted fixes and cleanups. v2: - fix 32-bit build # gpg: Signature made Mon 20 Jan 2020 14:14:11 GMT # gpg: using RSA key B4828BAF943140CEF2A3491071D4D5E5822F73D6 # gpg: Good signature from "Greg Kurz <groug@kaod.org>" [full] # gpg: aka "Gregory Kurz <gregory.kurz@free.fr>" [full] # gpg: aka "[jpeg image of size 3330]" [full] # Primary key fingerprint: B482 8BAF 9431 40CE F2A3 4910 71D4 D5E5 822F 73D6 * remotes/gkurz/tags/9p-next-2020-01-20: 9pfs/9p.c: remove unneeded labels virtfs-proxy-helper.c: remove 'err_out' label in setugid() 9p: init_in_iov_from_pdu can truncate the size 9p: local: always return -1 on error in local_unlinkat_common 9pfs: local: Fix possible memory leak in local_link() Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-209pfs/9p.c: remove unneeded labelsDaniel Henrique Barboza1-6/+3
'out' label in v9fs_xattr_write() and 'out_nofid' label in v9fs_complete_rename() can be replaced by appropriate return calls. CC: Greg Kurz <groug@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Acked-by: Greg Kurz <groug@kaod.org> Signed-off-by: Greg Kurz <groug@kaod.org>
2020-01-20virtfs-proxy-helper.c: remove 'err_out' label in setugid()Daniel Henrique Barboza1-3/+1
'err_out' can be removed and be replaced by 'return -errno' in its only instance in the function. CC: Greg Kurz <groug@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Acked-by: Greg Kurz <groug@kaod.org> Signed-off-by: Greg Kurz <groug@kaod.org>
2020-01-209p: init_in_iov_from_pdu can truncate the sizeGreg Kurz4-21/+38
init_in_iov_from_pdu might not be able to allocate the full buffer size requested, which comes from the client and could be larger than the transport has available at the time of the request. Specifically, this can happen with read operations, with the client requesting a read up to the max allowed, which might be more than the transport has available at the time. Today the implementation of init_in_iov_from_pdu throws an error, both Xen and Virtio. Instead, change the V9fsTransport interface so that the size becomes a pointer and can be limited by the implementation of init_in_iov_from_pdu. Change both the Xen and Virtio implementations to set the size to the size of the buffer they managed to allocate, instead of throwing an error. However, if the allocated buffer size is less than P9_IOHDRSZ (the size of the header) still throw an error as the case is unhandable. Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com> CC: groug@kaod.org CC: anthony.perard@citrix.com CC: roman@zededa.com CC: qemu_oss@crudebyte.com [groug: fix 32-bit build] Signed-off-by: Greg Kurz <groug@kaod.org>
2020-01-209p: local: always return -1 on error in local_unlinkat_commonDaniel Henrique Barboza1-8/+6
local_unlinkat_common() is supposed to always return -1 on error. This is being done by jumps to the 'err_out' label, which is a 'return ret' call, and 'ret' is initialized with -1. Unfortunately there is a condition in which the function will return 0 on error: in a case where flags == AT_REMOVEDIR, 'ret' will be 0 when reaching map_dirfd = openat_dir(...) And, if map_dirfd == -1 and errno != ENOENT, the existing 'err_out' jump will execute 'return ret', when ret is still set to zero at that point. This patch fixes it by changing all 'err_out' labels by 'return -1' calls, ensuring that the function will always return -1 on error conditions. 'ret' can be left unintialized since it's now being used just to store the result of 'unlinkat' calls. CC: Greg Kurz <groug@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> [groug: changed prefix in title to be "9p: local:"] Signed-off-by: Greg Kurz <groug@kaod.org>
2020-01-209pfs: local: Fix possible memory leak in local_link()Jiajun Chen1-1/+1
There is a possible memory leak while local_link return -1 without free odirpath and oname. Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Jaijun Chen <chenjiajun8@huawei.com> Signed-off-by: Xiang Zheng <zhengxiang9@huawei.com> Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Greg Kurz <groug@kaod.org>
2020-01-20qapi: Fix code generation with Python 3.5Markus Armbruster1-1/+1
Recent commit 3e7fb5811b "qapi: Fix code generation for empty modules" modules" switched QAPISchema.visit() from for entity in self._entity_list: effectively to for mod in self._module_dict.values(): for entity in mod._entity_list: Visits in the same order as long as .values() is in insertion order. That's the case only for Python 3.6 and later. Before, it's in some arbitrary order, which results in broken generated code. Fix by making self._module_dict an OrderedDict rather than a dict. Fixes: 3e7fb5811baab213dcc7149c3aa69442d683c26c Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Thomas Huth <thuth@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: BALATON Zoltan <balaton@eik.bme.hu> Tested-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20200116202558.31473-1-armbru@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-20Merge remote-tracking branch ↵Peter Maydell27-132/+659
'remotes/juanquintela/tags/migration-pull-pull-request' into staging Migration pull request # gpg: Signature made Mon 20 Jan 2020 10:29:53 GMT # gpg: using RSA key 1899FF8EDEBF58CCEE034B82F487EF185872D723 # gpg: Good signature from "Juan Quintela <quintela@redhat.com>" [full] # gpg: aka "Juan Quintela <quintela@trasno.org>" [full] # Primary key fingerprint: 1899 FF8E DEBF 58CC EE03 4B82 F487 EF18 5872 D723 * remotes/juanquintela/tags/migration-pull-pull-request: (29 commits) multifd: Be consistent about using uint64_t migration: Support QLIST migration apic: Use 32bit APIC ID for migration instance ID migration: Change SaveStateEntry.instance_id into uint32_t migration: Define VMSTATE_INSTANCE_ID_ANY Bug #1829242 correction. migration/multifd: fix destroyed mutex access in terminating multifd threads migration/multifd: fix nullptr access in terminating multifd threads migration/multifd: not use multifd during postcopy migration/multifd: clean pages after filling packet migration/postcopy: enable compress during postcopy migration/postcopy: enable random order target page arrival migration/postcopy: set all_zero to true on the first target page migration/postcopy: count target page number to decide the place_needed migration/postcopy: wait for decompress thread in precopy migration/postcopy: reduce memset when it is zero page and matches_target_page_size migration/ram: Yield periodically to the main loop migration: savevm_state_handler_insert: constant-time element insertion migration: add savevm_state_handler_remove() misc: use QEMU_IS_ALIGNED ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-01-20multifd: Be consistent about using uint64_tJuan Quintela1-5/+8
We transmit ram_addr_t always as uint64_t. Be consistent in its use (on 64bit system, it is always uint64_t problem is 32bits). Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-01-20migration: Support QLIST migrationEric Auger5-0/+305
Support QLIST migration using the same principle as QTAILQ: 94869d5c52 ("migration: migrate QTAILQ"). The VMSTATE_QLIST_V macro has the same proto as VMSTATE_QTAILQ_V. The change mainly resides in QLIST RAW macros: QLIST_RAW_INSERT_HEAD and QLIST_RAW_REVERSE. Tests also are provided. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2020-01-20apic: Use 32bit APIC ID for migration instance IDPeter Xu1-1/+4
Migration is silently broken now with x2apic config like this: -smp 200,maxcpus=288,sockets=2,cores=72,threads=2 \ -device intel-iommu,intremap=on,eim=on After migration, the guest kernel could hang at anything, due to x2apic bit not migrated correctly in IA32_APIC_BASE on some vcpus, so any operations related to x2apic could be broken then (e.g., RDMSR on x2apic MSRs could fail because KVM would think that the vcpu hasn't enabled x2apic at all). The issue is that the x2apic bit was never applied correctly for vcpus whose ID > 255 when migrate completes, and that's because when we migrate APIC we use the APICCommonState.id as instance ID of the migration stream, while that's too short for x2apic. Let's use the newly introduced initial_apic_id for that. Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2020-01-20migration: Change SaveStateEntry.instance_id into uint32_tPeter Xu5-12/+14
It was always used as 32bit, so define it as used to be clear. Instead of using -1 as the auto-gen magic value, we switch to UINT32_MAX. We also make sure that we don't auto-gen this value to avoid overflowed instance IDs without being noticed. Suggested-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2020-01-20migration: Define VMSTATE_INSTANCE_ID_ANYPeter Xu15-17/+25
Define the new macro VMSTATE_INSTANCE_ID_ANY for callers who wants to auto-generate the vmstate instance ID. Previously it was hard coded as -1 instead of this macro. It helps to change this default value in the follow up patches. No functional change. Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2020-01-20Bug #1829242 correction.Alexey Romko1-11/+18
Added type conversions to ram_addr_t before all left shifts of page indexes to TARGET_PAGE_BITS, to correct overflows when the page address was 4Gb and more. Signed-off-by: Alexey Romko <nevilad@yahoo.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2020-01-20migration/multifd: fix destroyed mutex access in terminating multifd threadsJiahui Cen1-0/+8
One multifd will lock all the other multifds' IOChannel mutex to inform them to quit by setting p->quit or shutting down p->c. In this senario, if some multifds had already been terminated and multifd_load_cleanup/multifd_save_cleanup had destroyed their mutex, it could cause destroyed mutex access when trying lock their mutex. Here is the coredump stack: #0 0x00007f81a2794437 in raise () from /usr/lib64/libc.so.6 #1 0x00007f81a2795b28 in abort () from /usr/lib64/libc.so.6 #2 0x00007f81a278d1b6 in __assert_fail_base () from /usr/lib64/libc.so.6 #3 0x00007f81a278d262 in __assert_fail () from /usr/lib64/libc.so.6 #4 0x000055eb1bfadbd3 in qemu_mutex_lock_impl (mutex=0x55eb1e2d1988, file=<optimized out>, line=<optimized out>) at util/qemu-thread-posix.c:64 #5 0x000055eb1bb4564a in multifd_send_terminate_threads (err=<optimized out>) at migration/ram.c:1015 #6 0x000055eb1bb4bb7f in multifd_send_thread (opaque=0x55eb1e2d19f8) at migration/ram.c:1171 #7 0x000055eb1bfad628 in qemu_thread_start (args=0x55eb1e170450) at util/qemu-thread-posix.c:502 #8 0x00007f81a2b36df5 in start_thread () from /usr/lib64/libpthread.so.0 #9 0x00007f81a286048d in clone () from /usr/lib64/libc.so.6 To fix it up, let's destroy the mutex after all the other multifd threads had been terminated. Signed-off-by: Jiahui Cen <cenjiahui@huawei.com> Signed-off-by: Ying Fang <fangying1@huawei.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2020-01-20migration/multifd: fix nullptr access in terminating multifd threadsJiahui Cen1-1/+3
One multifd channel will shutdown all the other multifd's IOChannel when it fails to receive an IOChannel. In this senario, if some multifds had not received its IOChannel yet, it would try to shutdown its IOChannel which could cause nullptr access at qio_channel_shutdown. Here is the coredump stack: #0 object_get_class (obj=obj@entry=0x0) at qom/object.c:908 #1 0x00005563fdbb8f4a in qio_channel_shutdown (ioc=0x0, how=QIO_CHANNEL_SHUTDOWN_BOTH, errp=0x0) at io/channel.c:355 #2 0x00005563fd7b4c5f in multifd_recv_terminate_threads (err=<optimized out>) at migration/ram.c:1280 #3 0x00005563fd7bc019 in multifd_recv_new_channel (ioc=ioc@entry=0x556400255610, errp=errp@entry=0x7ffec07dce00) at migration/ram.c:1478 #4 0x00005563fda82177 in migration_ioc_process_incoming (ioc=ioc@entry=0x556400255610, errp=errp@entry=0x7ffec07dce30) at migration/migration.c:605 #5 0x00005563fda8567d in migration_channel_process_incoming (ioc=0x556400255610) at migration/channel.c:44 #6 0x00005563fda83ee0 in socket_accept_incoming_migration (listener=0x5563fff6b920, cioc=0x556400255610, opaque=<optimized out>) at migration/socket.c:166 #7 0x00005563fdbc25cd in qio_net_listener_channel_func (ioc=<optimized out>, condition=<optimized out>, opaque=<optimized out>) at io/net-listener.c:54 #8 0x00007f895b6fe9a9 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 #9 0x00005563fdc18136 in glib_pollfds_poll () at util/main-loop.c:218 #10 0x00005563fdc181b5 in os_host_main_loop_wait (timeout=1000000000) at util/main-loop.c:241 #11 0x00005563fdc183a2 in main_loop_wait (nonblocking=nonblocking@entry=0) at util/main-loop.c:517 #12 0x00005563fd8edb37 in main_loop () at vl.c:1791 #13 0x00005563fd74fd45 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4473 To fix it up, let's check p->c before calling qio_channel_shutdown. Signed-off-by: Jiahui Cen <cenjiahui@huawei.com> Signed-off-by: Ying Fang <fangying1@huawei.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2020-01-20migration/multifd: not use multifd during postcopyWei Yang1-3/+6
We don't support multifd during postcopy, but user still could enable both multifd and postcopy. This leads to migration failure. Skip multifd during postcopy. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2020-01-20migration/multifd: clean pages after filling packetWei Yang1-2/+4
This is a preparation for the next patch: not use multifd during postcopy. Without enabling postcopy, everything looks good. While after enabling postcopy, migration may fail even not use multifd during postcopy. The reason is the pages is not properly cleared and *old* target page will continue to be transferred. After clean pages, migration succeeds. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2020-01-20migration/postcopy: enable compress during postcopyWei Yang2-12/+27
postcopy requires to place a whole host page, while migration thread migrate memory in target page size. This makes postcopy need to collect all target pages in one host page before placing via userfaultfd. To enable compress during postcopy, there are two problems to solve: 1. Random order for target page arrival 2. Target pages in one host page arrives without interrupt by target page from other host page The first one is handled by previous cleanup patch. This patch handles the second one by: 1. Flush compress thread for each host page 2. Wait for decompress thread for before placing host page Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2020-01-20migration/postcopy: enable random order target page arrivalWei Yang1-8/+10
After using number of target page received to track one host page, we could have the capability to handle random order target page arrival in one host page. This is a preparation for enabling compress during postcopy. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2020-01-20migration/postcopy: set all_zero to true on the first target pageWei Yang1-1/+1
For the first target page, all_zero is set to true for this round check. After target_pages introduced, we could leverage this variable instead of checking the address offset. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2020-01-20migration/postcopy: count target page number to decide the place_neededWei Yang1-2/+6
In postcopy, it requires to place whole host page instead of target page. Currently, it relies on the page offset to decide whether this is the last target page. We also can count the target page number during the iteration. When the number of target page equals (host page size / target page size), this means it is the last target page in the host page. This is a preparation for non-ordered target page transmission. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2020-01-20migration/postcopy: wait for decompress thread in precopyWei Yang1-2/+1
Compress is not supported with postcopy, it is safe to wait for decompress thread just in precopy. This is a preparation for later patch. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2020-01-20migration/postcopy: reduce memset when it is zero page and ↵Wei Yang1-1/+7
matches_target_page_size In this case, page_buffer content would not be used. Skip this to save some time. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2020-01-20migration/ram: Yield periodically to the main loopYury Kotov1-1/+12
Usually, incoming migration coroutine yields to the main loop while its IO-channel is waiting for data to receive. But there is a case when RAM migration and data receive have the same speed: VM with huge zeroed RAM. In this case, IO-channel won't read and thus the main loop is stuck and for instance, it doesn't respond to QMP commands. For this case, yield periodically, but not too often, so as not to affect the speed of migration. Signed-off-by: Yury Kotov <yury-kotov@yandex-team.ru> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2020-01-20migration: savevm_state_handler_insert: constant-time element insertionScott Cheloha1-3/+23
savevm_state's SaveStateEntry TAILQ is a priority queue. Priority sorting is maintained by searching from head to tail for a suitable insertion spot. Insertion is thus an O(n) operation. If we instead keep track of the head of each priority's subqueue within that larger queue we can reduce this operation to O(1) time. savevm_state_handler_remove() becomes slightly more complex to accomodate these gains: we need to replace the head of a priority's subqueue when removing it. With O(1) insertion, booting VMs with many SaveStateEntry objects is more plausible. For example, a ppc64 VM with maxmem=8T has 40000 such objects to insert. Signed-off-by: Scott Cheloha <cheloha@linux.vnet.ibm.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2020-01-20migration: add savevm_state_handler_remove()Scott Cheloha1-2/+7
Create a function to abstract common logic needed when removing a SaveStateEntry element from the savevm_state.handlers queue. For now we just remove the element. Soon it will involve additional cleanup. Signed-off-by: Scott Cheloha <cheloha@linux.vnet.ibm.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2020-01-20misc: use QEMU_IS_ALIGNEDMarc-André Lureau1-2/+2
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2020-01-20migration: Fix the re-run check of the migrate-incoming commandYury Kotov1-0/+1
The current check sets an error but doesn't fail the command. This may cause a problem if new connection attempt by the same URI affects the first connection. Signed-off-by: Yury Kotov <yury-kotov@yandex-team.ru> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Signed-off-by: Juan Quintela <quintela@redhat.com>