aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-03-17lockable: add lock guardsStefan Hajnoczi2-12/+76
This patch introduces two lock guard macros that automatically unlock a lock object (QemuMutex and others): void f(void) { QEMU_LOCK_GUARD(&mutex); if (!may_fail()) { return; /* automatically unlocks mutex */ } ... } and: WITH_QEMU_LOCK_GUARD(&mutex) { if (!may_fail()) { return; /* automatically unlocks mutex */ } } /* automatically unlocks mutex here */ ... Convert qemu-timer.c functions that benefit from these macros as an example. Manual qemu_mutex_lock/unlock() callers are left unmodified in cases where clarity would not improve by switching to the macros. Many other QemuMutex users remain in the codebase that might benefit from lock guards. Over time they can be converted, if that is desirable. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> [Use QEMU_MAKE_LOCKABLE_NONNULL. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-17lockable: add QEMU_MAKE_LOCKABLE_NONNULLPaolo Bonzini1-2/+15
This will be needed for lock guards, because if the lock is NULL the dummy for loop of the lock guard never runs. This can cause confusion and dummy warnings in the compiler, but even if it did not, aborting with a NULL pointer dereference is a less surprising behavior. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16cpus: avoid pause_all_vcpus getting stuck due to raceLongpeng1-1/+5
We found an issue when repeat reboot in guest during migration, it cause the migration thread never be waken up again. <main loop> |<migration_thread> | LOCK BQL | ... | main_loop_should_exit | pause_all_vcpus | 1. set all cpus ->stop=true | and then kick | 2. return if all cpus is paused | (by '->stopped == true'), else| 3. qemu_cond_wait [BQL UNLOCK] | |LOCK BQL |... |do_vm_stop | pause_all_vcpus | (A)set all cpus ->stop=true | and then kick | (B)return if all cpus is paused | (by '->stopped == true'), else | (C)qemu_cond_wait [BQL UNLOCK] 4. be waken up and LOCK BQL | (D)be waken up BUT wait for BQL 5. goto 2. | (BQL is still LOCKed) | resume_all_vcpus | 1. set all cpus ->stop=false | and ->stopped=false | ... | BQL UNLOCK | (E)LOCK BQL | (F)goto B. [but stopped is false now!] |Finally, sleep at step 3 forever. resume_all_vcpus should notice this race, so we need to move the change of runstate before pause_all_vcpus in do_vm_stop() and ignore the resume request if runstate is not running. Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Richard Henderson <rth@twiddle.net> Signed-off-by: Longpeng <longpeng2@huawei.com> Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200316083732.2010-1-longpeng2@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16exec/rom_reset: Free rom data during inmigrate skipDr. David Alan Gilbert1-9/+16
Commit 355477f8c73e9 skips rom reset when we're an incoming migration so as not to overwrite shared ram in the ignore-shared migration optimisation. However, it's got an unexpected side effect that because it skips freeing the ROM data, when rom_reset gets called later on, after migration (e.g. during a reboot), the ROM does get reset to the original file contents. Because of seabios/x86's weird reboot process this confuses a reboot into hanging after a migration. Fixes: 355477f8c73e9 ("migration: do not rom_reset() during incoming migration") https://bugzilla.redhat.com/show_bug.cgi?id=1809380 Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16Use -isystem for linux-headers dirEduardo Habkost2-2/+2
glibc and Linux-provided headers are known to generate macro redefinition warnings when used together. For example: <linux/mman.h> and <sys/mman.h> duplicate some macro definitions. We normally never see those warnings because GCC suppresses warnings generated by system headers. We carry our own copy of Linux header files, though, and this makes those warnings not be suppressed when glibc headers are included before Linux headers (e.g. if <sys/mman.h> is included before <linux/mman.h>). Use -isystem instead of -I for linux-headers. This makes the compiler treat our linux-headers directory the same way it treats system-provided Linux headers, and suppress warnings generated by them. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16softmmu/vl.c: Handle '-cpu help' and '-device help' before 'no default machine'Peter Maydell1-10/+16
Currently if you try to ask for the list of CPUs for a target architecture which does not specify a default machine type you just get an error: $ qemu-system-arm -cpu help qemu-system-arm: No machine specified, and there is no default Use -machine help to list supported machines Since the list of CPUs doesn't depend on the machine, this is unnecessarily unhelpful. "-device help" has a similar problem. Move the checks for "did the user ask for -cpu help or -device help" up so they precede the select_machine() call which checks that the user specified a valid machine type. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16qemu-cpu-models.rst: Document -noTSX, mds-no, taa-no, and tsx-ctrlKashyap Chamarthy1-2/+55
- Add the '-noTSX' variants for CascadeLake and SkyLake. - Document the three MSR bits: 'mds-no', 'taa-no', and 'tsx-ctrl' Two confusing things about 'mds-no' (and the first point applies to the other two MSRs too): (1) The 'mds-no' bit will _not_ show up in the guest's /proc/cpuinfo. Rather it is used to fill in the guest's sysfs: /sys/devices/system/cpu/vulnerabilities/mds:Not affected Paolo confirmed on IRC as such. (2) There are _three_ variants[+] of CascadeLake CPUs, with different stepping levels: 5, 6, and 7. To quote wikichip.org[*]: "note that while steppings 6 & 7 are fully mitigated, earlier stepping 5 is not protected against MSBDS, MLPDS, nor MDSUM" The above is also indicated in the Intel's document[+], as indicated by "No" under the three columns of MFBDS, MSBDS, and MLPDS. I've expressed this in the docs without belabouring the details. [+] https://software.intel.com/security-software-guidance/insights/processors-affected-microarchitectural-data-sampling [*] https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#Key_changes_from_Skylake Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com> Message-Id: <20200225165618.6571-3-kchamart@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16ui/curses: Move arrays to .heap to save 74KiB of .bssPhilippe Mathieu-Daudé1-2/+6
We only need these arrays when using the curses display. Move them from the .bss to the .heap (sizes reported on x86_64 host: screen[] is 64KiB, vga_to_curses 7KiB). Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16ui/curses: Make control_characters[] array constPhilippe Mathieu-Daudé1-1/+1
As we only use this array as input, make it const. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16hw/usb/quirks: Use smaller types to reduce .rodata by 10KiBPhilippe Mathieu-Daudé2-11/+15
The USB descriptor sizes are specified as 16-bit for idVendor / idProduct, and 8-bit for bInterfaceClass / bInterfaceSubClass / bInterfaceProtocol. Doing so we reduce the usbredir_raw_serial_ids[] and usbredir_ftdi_serial_ids[] arrays from 16KiB to 6KiB (size reported on x86_64 host, building with --extra-cflags=-Os). Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16hw/audio/intel-hda: Use memory region alias to reduce .rodata by 4.34MBPhilippe Mathieu-Daudé1-14/+10
The intel-hda model uses an array of register indexed by the register address. This array also contains a pair of aliased registers at offset 0x2000. This creates a huge hole in the array, which ends up eating 4.6MiB of .rodata (size reported on x86_64 host, building with --extra-cflags=-Os). By using a memory region alias, we reduce this array to 132kB. Before: (qemu) info mtree 00000000febd4000-00000000febd7fff (prio 1, i/o): intel-hda After: (qemu) info mtree 00000000febd4000-00000000febd7fff (prio 1, i/o): intel-hda 00000000febd4000-00000000febd7fff (prio 1, i/o): intel-hda-container 00000000febd4000-00000000febd5fff (prio 0, i/o): intel-hda 00000000febd6000-00000000febd7fff (prio 0, i/o): alias intel-hda-alias @intel-hda 0000000000000000-0000000000001fff Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16hw/audio/fmopl: Move ENV_CURVE to .heap to save 32KiB of .bssPhilippe Mathieu-Daudé1-1/+3
This buffer is only used by the adlib audio device. Move it to the .heap to release 32KiB of .bss (size reported on x86_64 host). Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16Makefile: Let the 'help' target list the tools targetsPhilippe Mathieu-Daudé1-0/+5
List the name of the tool targets when calling 'make help': $ make help [...] Tools targets: qemu-ga - Build qemu-ga tool qemu-keymap - Build qemu-keymap tool elf2dmp - Build elf2dmp tool ivshmem-client - Build ivshmem-client tool ivshmem-server - Build ivshmem-server tool qemu-nbd - Build qemu-nbd tool qemu-img - Build qemu-img tool qemu-io - Build qemu-io tool qemu-edid - Build qemu-edid tool fsdev/virtfs-proxy-helper - Build virtfs-proxy-helper tool scsi/qemu-pr-helper - Build qemu-pr-helper tool Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16Makefile: Align 'help' target outputPhilippe Mathieu-Daudé1-21/+23
The 'help' target is displayed unaligned. Add a print-help function and use it. Now if someone want to change the indentation, there is a single place to modify. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16WHPX: Use proper synchronization primitives while processingSunil Muthuswamy1-10/+7
WHPX wasn't using the proper synchronization primitives while processing async events, which can cause issues with SMP. Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16i386: Fix GCC warning with snprintf when HAX is enabledJulio Faracco2-62/+4
When HAX is enabled (--enable-hax), GCC 9.2.1 reports issues with snprintf(). Replacing old snprintf() by g_strdup_printf() fixes the problem with boundary checks of vm_id and vcpu_id and finally the warnings produced by GCC. For more details, one example of warning: CC i386-softmmu/target/i386/hax-posix.o qemu/target/i386/hax-posix.c: In function ‘hax_host_open_vm’: qemu/target/i386/hax-posix.c:124:56: error: ‘%02d’ directive output may be truncated writing between 2 and 11 bytes into a region of size 3 [-Werror=format-truncation=] 124 | snprintf(name, sizeof HAX_VM_DEVFS, "/dev/hax_vm/vm%02d", vm_id); | ^~~~ qemu/target/i386/hax-posix.c:124:41: note: directive argument in the range [-2147483648, 64] 124 | snprintf(name, sizeof HAX_VM_DEVFS, "/dev/hax_vm/vm%02d", vm_id); | ^~~~~~~~~~~~~~~~~~~~ In file included from /usr/include/stdio.h:867, from qemu/include/qemu/osdep.h:99, from qemu/target/i386/hax-posix.c:14: /usr/include/bits/stdio2.h:67:10: note: ‘__builtin___snprintf_chk’ output between 17 and 26 bytes into a destination of size 17 67 | return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 68 | __bos (__s), __fmt, __va_arg_pack ()); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Julio Faracco <jcfaracco@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16qom/object: Use common get/set uint helpersFelipe Franciosi8-276/+37
Several objects implemented their own uint property getters and setters, despite them being straightforward (without any checks/validations on the values themselves) and identical across objects. This makes use of an enhanced API for object_property_add_uintXX_ptr() which offers default setters. Some of these setters used to update the value even if the type visit failed (eg. because the value being set overflowed over the given type). The new setter introduces a check for these errors, not updating the value if an error occurred. The error is propagated. Signed-off-by: Felipe Franciosi <felipe@nutanix.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16ich9: Simplify ich9_lpc_initfnFelipe Franciosi1-10/+5
Currently, ich9_lpc_initfn simply serves as a caller to ich9_lpc_add_properties. This simplifies the code a bit by eliminating ich9_lpc_add_properties altogether and executing its logic in the parent object initialiser function. Signed-off-by: Felipe Franciosi <felipe@nutanix.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16ich9: fix getter type for sci_int propertyFelipe Franciosi1-4/+2
When QOM APIs were added to ich9 in 6f1426ab, the getter for sci_int was written using uint32_t. However, the object property is uint8_t. This fixes the getter for correctness. Signed-off-by: Felipe Franciosi <felipe@nutanix.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16qom/object: enable setter for uint typesFelipe Franciosi8-48/+246
Traditionally, the uint-specific property helpers only offer getters. When adding object (or class) uint types, one must therefore use the generic property helper if a setter is needed (and probably duplicate some code writing their own getters/setters). This enhances the uint-specific property helper APIs by adding a bitwise-or'd 'flags' field and modifying all clients of that API to set this paramater to OBJ_PROP_FLAG_READ. This maintains the current behaviour whilst allowing others to also set OBJ_PROP_FLAG_WRITE (or use the more convenient OBJ_PROP_FLAG_READWRITE) in the future (which will automatically install a setter). Other flags may be added later. Signed-off-by: Felipe Franciosi <felipe@nutanix.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16memory: Fix start offset for bitmap log_clear hookMatt Borgerson1-4/+5
Currently only the final page offset is being passed to the `log_clear` hook via `memory_region_clear_dirty_bitmap` after it is used as an iterator in `cpu_physical_memory_test_and_clear_dirty`. This patch corrects the start address and size of the region. Signed-off-by: Matt Borgerson <contact@mborgerson.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16tests/docker: Install SASL library to extend code coverage on amd64Philippe Mathieu-Daudé1-0/+1
Install the SASL library to build the VNC SASL auth protocol code. Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200309122454.22551-3-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16configure: Fix building with SASL on WindowsPhilippe Mathieu-Daudé1-1/+3
The Simple Authentication and Security Layer (SASL) library re-defines the struct iovec on Win32 [*]. QEMU also re-defines it in "qemu/osdep.h". The two definitions then clash on a MinGW build. We can avoid the SASL definition by defining STRUCT_IOVEC_DEFINED. Since QEMU already defines 'struct iovec' if it is missing, add the definition to vnc_sasl_cflags to avoid SASL re-defining it. [*] https://github.com/cyrusimap/cyrus-sasl/blob/cyrus-sasl-2.1.27/include/sasl.h#L187 Cc: Alexey Pavlov <alexpux@gmail.com> Cc: Biswapriyo Nath <nathbappai@gmail.com> Reported-by: Youry Metlitsky <winaes@yandex.ru> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200309122454.22551-2-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16modules: load modules from versioned /var/run dirChristian Ehrhardt2-0/+29
On upgrades the old .so files usually are replaced. But on the other hand since a qemu process represents a guest instance it is usually kept around. That makes late addition of dynamic features e.g. 'hot-attach of a ceph disk' fail by trying to load a new version of e.f. block-rbd.so into an old still running qemu binary. This adds a fallback to also load modules from a versioned directory in the temporary /var/run path. That way qemu is providing a way for packaging to store modules of an upgraded qemu package as needed until the next reboot. An example how that can then be used in packaging can be seen in: https://git.launchpad.net/~paelzer/ubuntu/+source/qemu/log/?h=bug-1847361-miss-old-so-on-upgrade-UBUNTU Fixes: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1847361 Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20200310145806.18335-2-christian.ehrhardt@canonical.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16build-sys: do not make qemu-ga link with pixmanMarc-André Lureau2-3/+3
Since commit d52c454aadcdae74506f315ebf8b58bb79a05573 ("contrib: add vhost-user-gpu"), qemu-ga is linking with pixman. This is because the Make-based build-system use a global namespace for variables, and we rely on "main.o-libs" for different linking targets. Note: this kind of variable clashing is hard to fix or prevent currently. meson should help, as declarations have a linear dependency and doesn't rely so much on variables and clever tricks. Note2: we have a lot of main.c (or other duplicated names!) in tree. Imho, it would be annoying and a bad workaroud to rename all those to avoid conflicts like I did here. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1811670 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20200311160923.882474-1-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16oslib-posix: initialize mutex and condition variablePaolo Bonzini1-0/+7
The mutex and condition variable were never initialized, causing -mem-prealloc to abort with an assertion failure. Fixes: 037fb5eb3941c80a2b7c36a843e47207ddb004d4 Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com> Cc: bauerchen <bauerchen@tencent.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16hw/i386/intel_iommu: Fix out-of-bounds access on guest IRTJan Kiszka1-0/+6
vtd_irte_get failed to check the index against the configured table size, causing an out-of-bounds access on guest memory and potentially misinterpreting the result. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Message-Id: <4b15b728-bdfe-3bbe-3a5c-ca3baeef3c5c@siemens.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16MAINTAINERS: Add entry for Guest X86 HAXM CPUsColin Xu1-0/+11
HAXM covers below files: include/sysemu/hax.h target/i386/hax-* V2: Add HAXM github page for wiki and issue tracking. Cc: Wenchao Wang <wenchao.wang@intel.com> Cc: Hang Yuan <hang.yuan@intel.com> Reviewed-by: Hang Yuan <hang.yuan@intel.com> Signed-off-by: Colin Xu <colin.xu@intel.com> Message-Id: <20200228012046.6629-1-colin.xu@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16WHPX: Use QEMU values for trapped CPUIDSunil Muthuswamy1-24/+18
Currently, WHPX is using some default values for the trapped CPUID functions. These were not in sync with the QEMU values because the CPUID values were never set with WHPX during VCPU initialization. Additionally, at the moment, WHPX doesn't support setting CPUID values in the hypervisor at runtime (i.e. after the partition has been setup). That is needed to be able to set the CPUID values in the hypervisor during VCPU init. Until that support comes, use the QEMU values for the trapped CPUIDs. Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com> Message-Id: <SN4PR2101MB0880A8323EAD0CD0E8E2F423C0EB0@SN4PR2101MB0880.namprd21.prod.outlook.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16WHPX: TSC get and set should be dependent on VM stateSunil Muthuswamy3-9/+110
Currently, TSC is set as part of the VM runtime state. Setting TSC at runtime is heavy and additionally can have side effects on the guest, which are not very resilient to variances in the TSC. This patch uses the VM state to determine whether to set TSC or not. Some minor enhancements for getting TSC values as well that considers the VM state. Additionally, while setting the TSC, the partition is suspended to reduce the variance in the TSC value across vCPUs. Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com> Message-Id: <SN4PR2101MB08804D23439166E81FF151F7C0EA0@SN4PR2101MB0880.namprd21.prod.outlook.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16util: add util function buffer_zero_avx512()Robert Hoo2-10/+64
And intialize buffer_is_zero() with it, when Intel AVX512F is available on host. This function utilizes Intel AVX512 fundamental instructions which is faster than its implementation with AVX2 (in my unit test, with 4K buffer, on CascadeLake SP, ~36% faster, buffer_zero_avx512() V.S. buffer_zero_avx2()). Signed-off-by: Robert Hoo <robert.hu@linux.intel.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16configure: add configure option avx512f_optRobert Hoo1-0/+41
If it is enabled, config-host.mak will have CONFIG_AVX512F_OPT defined. AVX512F instruction set is available since Intel Skylake, and can be enabled in compiling with -mavx512f. More info: https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf Signed-off-by: Robert Hoo <robert.hu@linux.intel.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16misc: Replace zero-length arrays with flexible array member (manual)Philippe Mathieu-Daudé10-15/+15
Description copied from Linux kernel commit from Gustavo A. R. Silva (see [3]): --v-- description start --v-- The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member [1], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being unadvertenly introduced [2] to the Linux codebase from now on. --^-- description end --^-- Do the similar housekeeping in the QEMU codebase (which uses C99 since commit 7be41675f7cb). All these instances of code were found with the help of the following command (then manual analysis, without modifying structures only having a single flexible array member, such QEDTable in block/qed.h): git grep -F '[0];' [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76497732932f [3] https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git/commit/?id=17642a2fbd2c1 Inspired-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16misc: Replace zero-length arrays with flexible array member (automatic)Philippe Mathieu-Daudé24-34/+35
Description copied from Linux kernel commit from Gustavo A. R. Silva (see [3]): --v-- description start --v-- The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member [1], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being unadvertenly introduced [2] to the Linux codebase from now on. --^-- description end --^-- Do the similar housekeeping in the QEMU codebase (which uses C99 since commit 7be41675f7cb). All these instances of code were found with the help of the following Coccinelle script: @@ identifier s, m, a; type t, T; @@ struct s { ... t m; - T a[0]; + T a[]; }; @@ identifier s, m, a; type t, T; @@ struct s { ... t m; - T a[0]; + T a[]; } QEMU_PACKED; [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76497732932f [3] https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git/commit/?id=17642a2fbd2c1 Inspired-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16optionrom/pvh: scan entire RSDP AreaJoe Richey1-1/+1
Right now the PVH option rom scans for the RSDP from 0xE0000 to 0xE1FFF. This is probobly a typo, it should scan from 0xE0000 to 0xFFFFF. This is actually an issue on some QEMU versions/machines. For example, when I run QEMU the RSDP is placed at 0xf5ad0 which will not be picked up by the current implementation. This bug still allows a Linux guest to boot (in most configurations) as the kernel will just scan for the RSDP if one isn't provided. Signed-off-by: Joe Richey <joerichey@google.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Fixes: 2785dc7b17 ("optionrom: add new PVH option rom") Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16scsi/qemu-pr-helper: Fix out-of-bounds access to trnptid_list[]Christophe de Dinechin1-7/+10
Compile error reported by gcc 10.0.1: scsi/qemu-pr-helper.c: In function ‘multipath_pr_out’: scsi/qemu-pr-helper.c:523:32: error: array subscript <unknown> is outside array bounds of ‘struct transportid *[0]’ [-Werror=array-bounds] 523 | paramp.trnptid_list[paramp.num_transportid++] = id; | ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from scsi/qemu-pr-helper.c:36: /usr/include/mpath_persist.h:168:22: note: while referencing ‘trnptid_list’ 168 | struct transportid *trnptid_list[]; | ^~~~~~~~~~~~ scsi/qemu-pr-helper.c:424:35: note: defined here ‘paramp’ 424 | struct prout_param_descriptor paramp; | ^~~~~~ This highlights an actual implementation issue in function multipath_pr_out. The variable paramp is declared with type `struct prout_param_descriptor`, which is a struct terminated by an empty array in mpath_persist.h: struct transportid *trnptid_list[]; That empty array was filled with code that looked like that: trnptid_list[paramp.descr.num_transportid++] = id; This is an actual out-of-bounds access. The fix is to malloc `paramp`. Signed-off-by: Christophe de Dinechin <dinechin@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16Merge remote-tracking branch 'remotes/kraxel/tags/vga-20200316-pull-request' ↵Peter Maydell2-6/+6
into staging vga: stdvga/bochs mmio fix. # gpg: Signature made Mon 16 Mar 2020 12:48:10 GMT # gpg: using RSA key 4CB6D8EED3E87138 # gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>" [full] # gpg: aka "Gerd Hoffmann <gerd@kraxel.org>" [full] # gpg: aka "Gerd Hoffmann (private) <kraxel@gmail.com>" [full] # Primary key fingerprint: A032 8CFF B93A 17A7 9901 FE7D 4CB6 D8EE D3E8 7138 * remotes/kraxel/tags/vga-20200316-pull-request: stdvga+bochs-display: add dummy mmio handler Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-16Merge remote-tracking branch ↵Peter Maydell4-27/+39
'remotes/kraxel/tags/audio-20200316-pull-request' into staging audio: float fixes # gpg: Signature made Mon 16 Mar 2020 11:30:00 GMT # gpg: using RSA key 4CB6D8EED3E87138 # gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>" [full] # gpg: aka "Gerd Hoffmann <gerd@kraxel.org>" [full] # gpg: aka "Gerd Hoffmann (private) <kraxel@gmail.com>" [full] # Primary key fingerprint: A032 8CFF B93A 17A7 9901 FE7D 4CB6 D8EE D3E8 7138 * remotes/kraxel/tags/audio-20200316-pull-request: audio: add audiodev format=f32 option documentation audio: fix saturation nonlinearity in clip_* functions audio: change mixing engine float range to [-1.f, 1.f] audio: consistency changes audio: change naming scheme of FLOAT_CONV macros qapi/audio: add documentation for AudioFormat Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-16stdvga+bochs-display: add dummy mmio handlerGerd Hoffmann2-6/+6
The bochs-display mmio bar has some sub-regions with the actual hardware registers. What happens when the guest access something outside those regions depends on the archirecture. On x86 those reads succeed (and return 0xff I think). On risc-v qemu aborts. This patch adds handlers for the parent region, to make the wanted behavior explicit and to make things consistent across architectures. v2: - use existing unassigned_io_ops. - also cover stdvga. Cc: Alistair Francis <alistair23@gmail.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20200309100009.17624-1-kraxel@redhat.com
2020-03-16audio: add audiodev format=f32 option documentationVolker Rümelin1-2/+2
The documentaion for -audiodev format=f32 option was missing. Signed-off-by: Volker Rümelin <vr_qemu@t-online.de> Message-id: 20200308193321.20668-6-vr_qemu@t-online.de Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-03-16audio: fix saturation nonlinearity in clip_* functionsVolker Rümelin1-3/+2
The current positive limit for the saturation nonlinearity is only correct if the type of the result has 8 bits or less. Signed-off-by: Volker Rümelin <vr_qemu@t-online.de> Message-id: 20200308193321.20668-5-vr_qemu@t-online.de Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-03-16audio: change mixing engine float range to [-1.f, 1.f]Volker Rümelin2-11/+10
Currently the internal float range of the mixing engine is [-.5f, .5f]. PulseAudio, SDL2 and libasound use a [-1.f, 1.f] range. This means with float samples the audio playback volume is 6dB too low and audio recording signals will be clipped in most cases. To avoid another scaling factor in the conv_natural_float_* and clip_natural_float_* functions with FLOAT_MIXENG defined this patch changes the mixing engine float range to [-1.f, 1.f]. Signed-off-by: Volker Rümelin <vr_qemu@t-online.de> Message-id: 20200308193321.20668-4-vr_qemu@t-online.de Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-03-16audio: consistency changesVolker Rümelin1-1/+1
Change the clip_natural_float_from_mono() function in audio/mixeng.c to be consistent with the clip_*_from_mono() functions in audio/mixeng_template.h. Signed-off-by: Volker Rümelin <vr_qemu@t-online.de> Message-id: 20200308193321.20668-3-vr_qemu@t-online.de Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-03-16audio: change naming scheme of FLOAT_CONV macrosVolker Rümelin1-11/+11
This patch changes the naming scheme of the FLOAT_CONV_TO and FLOAT_CONV_FROM macros to the scheme used in mixeng_template.h. Signed-off-by: Volker Rümelin <vr_qemu@t-online.de> Message-id: 20200308193321.20668-2-vr_qemu@t-online.de Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-03-16qapi/audio: add documentation for AudioFormatVolker Rümelin1-0/+14
The review for patch ed2a4a7941 "audio: proper support for float samples in mixeng" suggested this would be a good idea. Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Volker Rümelin <vr_qemu@t-online.de> Tested-by: John Arbuckle <programmingkidx@gmail.com> Message-id: 20200308193321.20668-1-vr_qemu@t-online.de Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-03-13Merge remote-tracking branch ↵Peter Maydell7-43/+135
'remotes/dgilbert/tags/pull-migration-20200313a' into staging Migration pull 2020-03-13 zstd build fix A new auto-converge parameter Some COLO improvements # gpg: Signature made Fri 13 Mar 2020 10:29:34 GMT # gpg: using RSA key 45F5C71B4A0CB7FB977A9FA90516331EBC5BFDE7 # gpg: Good signature from "Dr. David Alan Gilbert (RH2) <dgilbert@redhat.com>" [full] # Primary key fingerprint: 45F5 C71B 4A0C B7FB 977A 9FA9 0516 331E BC5B FDE7 * remotes/dgilbert/tags/pull-migration-20200313a: migration: recognize COLO as part of activating process ram/colo: only record bitmap of dirty pages in COLO stage COLO: Optimize memory back-up process migration/throttle: Add throttle-trig-thres migration parameter configure: Improve zstd test Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-03-13migration: recognize COLO as part of activating processzhanghailiang1-0/+1
We will migrate parts of dirty pages backgroud lively during the gap time of two checkpoints, without this modification, it will not work because ram_save_iterate() will check it before send RAM_SAVE_FLAG_EOS at the end of it. Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com> Message-Id: <20200224065414.36524-7-zhang.zhanghailiang@huawei.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-03-13ram/colo: only record bitmap of dirty pages in COLO stagezhanghailiang1-4/+5
It is only need to record bitmap of dirty pages while goes into COLO stage. Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com> Message-Id: <20200224065414.36524-6-zhang.zhanghailiang@huawei.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-03-13COLO: Optimize memory back-up processzhanghailiang3-17/+53
This patch will reduce the downtime of VM for the initial process, Previously, we copied all these memory in preparing stage of COLO while we need to stop VM, which is a time-consuming process. Here we optimize it by a trick, back-up every page while in migration process while COLO is enabled, though it affects the speed of the migration, but it obviously reduce the downtime of back-up all SVM'S memory in COLO preparing stage. Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com> Message-Id: <20200224065414.36524-5-zhang.zhanghailiang@huawei.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> minor typo fixes
2020-03-13migration/throttle: Add throttle-trig-thres migration parameterKeqian Zhu4-23/+76
Currently, if the bytes_dirty_period is more than the 50% of bytes_xfer_period, we start or increase throttling. If we make this percentage higher, then we can tolerate higher dirty rate during migration, which means less impact on guest. The side effect of higher percentage is longer migration time. We can make this parameter configurable to switch between mig- ration time first or guest performance first. The default value is 50 and valid range is 1 to 100. Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com> Message-Id: <20200224023142.39360-1-zhukeqian1@huawei.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
generated by cgit v1.1 at 2024-07-19 11:30:09 +0000