summary refs log tree commit diff stats
path: root/hw/misc/mst_fpga.c (unfollow)
Commit message (Collapse)AuthorFilesLines
2022-05-14qga-vss: Use the proper operator to free memoryKonstantin Kostiuk1-2/+2
volume_name_wchar is allocated by 'void* operator new [](long long unsigned int) Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20220512154909.331481-1-kkostiuk@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-14qga-vss: Add auto generated headers to dependenciesKonstantin Kostiuk1-1/+1
Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com> Message-Id: <20220512154906.331399-1-kkostiuk@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-14WHPX: fixed TPR/CR8 translation issues affecting VM debuggingIvan Shcherbakov1-3/+10
This patch fixes the following error that would occur when trying to resume a WHPX-accelerated VM from a breakpoint: qemu: WHPX: Failed to set interrupt state registers, hr=c0350005 The error arises from an incorrect CR8 value being passed to WHvSetVirtualProcessorRegisters() that doesn't match the value set via WHvSetVirtualProcessorInterruptControllerState2(). Signed-off-by: Ivan Shcherbakov <ivan@sysprogs.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-13linux-headers: Update to v5.18-rc6Alex Williamson13-235/+383
Update to c5eb0a61238d ("Linux 5.18-rc6"). Mechanical search and replace of vfio defines with white space massaging. Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2022-05-12qemu-iotests: inline common.config into common.rcPaolo Bonzini2-53/+19
common.rc has some complicated logic to find the common.config that dates back to xfstests and is completely unnecessary now. Just include the contents of the file. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20220505094723.732116-1-pbonzini@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-05-12vmxcap: add tertiary execution controlsPaolo Bonzini1-0/+17
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-12vl: make machine type deprecation a warningPaolo Bonzini1-1/+1
error_report should generally be followed by a failure; if we can proceed anyway, that is just a warning and should be communicated properly to the user with warn_report. Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20220511175043.27327-1-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-12nbd/server: Allow MULTI_CONN for shared writable exportsEric Blake10-11/+172
According to the NBD spec, a server that advertises NBD_FLAG_CAN_MULTI_CONN promises that multiple client connections will not see any cache inconsistencies: when properly separated by a single flush, actions performed by one client will be visible to another client, regardless of which client did the flush. We always satisfy these conditions in qemu - even when we support multiple clients, ALL clients go through a single point of reference into the block layer, with no local caching. The effect of one client is instantly visible to the next client. Even if our backend were a network device, we argue that any multi-path caching effects that would cause inconsistencies in back-to-back actions not seeing the effect of previous actions would be a bug in that backend, and not the fault of caching in qemu. As such, it is safe to unconditionally advertise CAN_MULTI_CONN for any qemu NBD server situation that supports parallel clients. Note, however, that we don't want to advertise CAN_MULTI_CONN when we know that a second client cannot connect (for historical reasons, qemu-nbd defaults to a single connection while nbd-server-add and QMP commands default to unlimited connections; but we already have existing means to let either style of NBD server creation alter those defaults). This is visible by no longer advertising MULTI_CONN for 'qemu-nbd -r' without -e, as in the iotest nbd-qemu-allocation. The harder part of this patch is setting up an iotest to demonstrate behavior of multiple NBD clients to a single server. It might be possible with parallel qemu-io processes, but I found it easier to do in python with the help of libnbd, and help from Nir and Vladimir in writing the test. Signed-off-by: Eric Blake <eblake@redhat.com> Suggested-by: Nir Soffer <nsoffer@redhat.com> Suggested-by: Vladimir Sementsov-Ogievskiy <v.sementsov-og@mail.ru> Message-Id: <20220512004924.417153-3-eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-05-12qemu-nbd: Pass max connections to blockdev layerEric Blake3-6/+6
The next patch wants to adjust whether the NBD server code advertises MULTI_CONN based on whether it is known if the server limits to exactly one client. For a server started by QMP, this information is obtained through nbd_server_start (which can support more than one export); but for qemu-nbd (which supports exactly one export), it is controlled only by the command-line option -e/--shared. Since we already have a hook function used by qemu-nbd, it's easiest to just alter its signature to fit our needs. Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20220512004924.417153-2-eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-05-12tests/qtest/fdc-test: Add a regression test for CVE-2021-3507Philippe Mathieu-Daudé1-0/+21
Add the reproducer from https://gitlab.com/qemu-project/qemu/-/issues/339 Without the previous commit, when running 'make check-qtest-i386' with QEMU configured with '--enable-sanitizers' we get: ==4028352==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x619000062a00 at pc 0x5626d03c491a bp 0x7ffdb4199410 sp 0x7ffdb4198bc0 READ of size 786432 at 0x619000062a00 thread T0 #0 0x5626d03c4919 in __asan_memcpy (qemu-system-i386+0x1e65919) #1 0x5626d1c023cc in flatview_write_continue softmmu/physmem.c:2787:13 #2 0x5626d1bf0c0f in flatview_write softmmu/physmem.c:2822:14 #3 0x5626d1bf0798 in address_space_write softmmu/physmem.c:2914:18 #4 0x5626d1bf0f37 in address_space_rw softmmu/physmem.c:2924:16 #5 0x5626d1bf14c8 in cpu_physical_memory_rw softmmu/physmem.c:2933:5 #6 0x5626d0bd5649 in cpu_physical_memory_write include/exec/cpu-common.h:82:5 #7 0x5626d0bd0a07 in i8257_dma_write_memory hw/dma/i8257.c:452:9 #8 0x5626d09f825d in fdctrl_transfer_handler hw/block/fdc.c:1616:13 #9 0x5626d0a048b4 in fdctrl_start_transfer hw/block/fdc.c:1539:13 #10 0x5626d09f4c3e in fdctrl_write_data hw/block/fdc.c:2266:13 #11 0x5626d09f22f7 in fdctrl_write hw/block/fdc.c:829:9 #12 0x5626d1c20bc5 in portio_write softmmu/ioport.c:207:17 0x619000062a00 is located 0 bytes to the right of 512-byte region [0x619000062800,0x619000062a00) allocated by thread T0 here: #0 0x5626d03c66ec in posix_memalign (qemu-system-i386+0x1e676ec) #1 0x5626d2b988d4 in qemu_try_memalign util/oslib-posix.c:210:11 #2 0x5626d2b98b0c in qemu_memalign util/oslib-posix.c:226:27 #3 0x5626d09fbaf0 in fdctrl_realize_common hw/block/fdc.c:2341:20 #4 0x5626d0a150ed in isabus_fdc_realize hw/block/fdc-isa.c:113:5 #5 0x5626d2367935 in device_set_realized hw/core/qdev.c:531:13 SUMMARY: AddressSanitizer: heap-buffer-overflow (qemu-system-i386+0x1e65919) in __asan_memcpy Shadow bytes around the buggy address: 0x0c32800044f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c3280004500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c3280004510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c3280004520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c3280004530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c3280004540:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c3280004550: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c3280004560: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c3280004570: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c3280004580: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c3280004590: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Heap left redzone: fa Freed heap region: fd ==4028352==ABORTING [ kwolf: Added snapshot=on to prevent write file lock failure ] Reported-by: Alexander Bulekov <alxndr@bu.edu> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alexander Bulekov <alxndr@bu.edu> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-05-12hw/block/fdc: Prevent end-of-track overrun (CVE-2021-3507)Philippe Mathieu-Daudé1-0/+8
Per the 82078 datasheet, if the end-of-track (EOT byte in the FIFO) is more than the number of sectors per side, the command is terminated unsuccessfully: * 5.2.5 DATA TRANSFER TERMINATION The 82078 supports terminal count explicitly through the TC pin and implicitly through the underrun/over- run and end-of-track (EOT) functions. For full sector transfers, the EOT parameter can define the last sector to be transferred in a single or multisector transfer. If the last sector to be transferred is a par- tial sector, the host can stop transferring the data in mid-sector, and the 82078 will continue to complete the sector as if a hardware TC was received. The only difference between these implicit functions and TC is that they return "abnormal termination" result status. Such status indications can be ignored if they were expected. * 6.1.3 READ TRACK This command terminates when the EOT specified number of sectors have been read. If the 82078 does not find an I D Address Mark on the diskette after the second· occurrence of a pulse on the INDX# pin, then it sets the IC code in Status Regis- ter 0 to "01" (Abnormal termination), sets the MA bit in Status Register 1 to "1", and terminates the com- mand. * 6.1.6 VERIFY Refer to Table 6-6 and Table 6-7 for information concerning the values of MT and EC versus SC and EOT value. * Table 6·6. Result Phase Table * Table 6-7. Verify Command Result Phase Table Fix by aborting the transfer when EOT > # Sectors Per Side. Cc: qemu-stable@nongnu.org Cc: Hervé Poussineau <hpoussin@reactos.org> Fixes: baca51faff0 ("floppy driver: disk geometry auto detect") Reported-by: Alexander Bulekov <alxndr@bu.edu> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/339 Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20211118115733.4038610-2-philmd@redhat.com> Reviewed-by: Hanna Reitz <hreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-05-12meson: link libpng independent of vncKshitij Suri1-1/+2
Currently png support is dependent on vnc for linking object file to libpng. This commit makes the parameter independent of vnc as it breaks system emulator with --disable-vnc unless --disable-png is added. Fixes: 9a0a119a38 ("Added parameter to take screenshot with screendump as PNG", 2022-04-27) Signed-off-by: Kshitij Suri <kshitij.suri@nutanix.com> Message-Id: <20220510161932.228481-1-kshitij.suri@nutanix.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-12vhost-backend: do not depend on CONFIG_VHOST_VSOCKPaolo Bonzini1-4/+0
The vsock callbacks .vhost_vsock_set_guest_cid and .vhost_vsock_set_running are the only ones to be conditional on #ifdef CONFIG_VHOST_VSOCK. This is different from any other device-dependent callbacks like .vhost_scsi_set_endpoint, and it also broke when CONFIG_VHOST_VSOCK was changed to a per-target symbol. It would be possible to also use the CONFIG_DEVICES include, but really there is no reason for most virtio files to be per-target so just remove the #ifdef to fix the issue. Reported-by: Dov Murik <dovmurik@linux.ibm.com> Fixes: 9972ae314f ("build: move vhost-vsock configuration to Kconfig") Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-12coroutine-lock: qemu_co_queue_restart_all is a coroutine-only qemu_co_enter_allPaolo Bonzini3-19/+11
qemu_co_queue_restart_all is basically the same as qemu_co_enter_all but without a QemuLockable argument. That's perfectly fine, but only as long as the function is marked coroutine_fn. If used outside coroutine context, qemu_co_queue_wait will attempt to take the lock and that is just broken: if you are calling qemu_co_queue_restart_all outside coroutine context, the lock is going to be a QemuMutex which cannot be taken twice by the same thread. The patch adds the marker to qemu_co_queue_restart_all and to its sole non-coroutine_fn caller; it then reimplements the function in terms of qemu_co_enter_all_impl, to remove duplicated code and to clarify that the latter also works in coroutine context. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20220427130830.150180-4-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-12coroutine-lock: introduce qemu_co_queue_enter_allPaolo Bonzini3-1/+21
Because qemu_co_queue_restart_all does not release the lock, it should be used only in coroutine context. Introduce a new function that, like qemu_co_enter_next, does release the lock, and use it whenever qemu_co_queue_restart_all was used outside coroutine context. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20220427130830.150180-3-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-12coroutine-lock: qemu_co_queue_next is a coroutine-only qemu_co_enter_nextPaolo Bonzini2-17/+11
qemu_co_queue_next is basically the same as qemu_co_enter_next but without a QemuLockable argument. That's perfectly fine, but only as long as the function is marked coroutine_fn. If used outside coroutine context, qemu_co_queue_wait will attempt to take the lock and that is just broken: if you are calling qemu_co_queue_next outside coroutine context, the lock is going to be a QemuMutex which cannot be taken twice by the same thread. The patch adds the marker and reimplements qemu_co_queue_next in terms of qemu_co_enter_next_impl, to remove duplicated code and to clarify that the latter also works in coroutine context. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20220427130830.150180-2-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-12net: slirp: allow CFI with libslirp >= 4.7Paolo Bonzini1-14/+17
slirp 4.7 introduces a new CFI-friendly timer callback that does not pass function pointers within libslirp as callbacks for timers. Check the version number and, if it is new enough, allow using CFI even with a system libslirp. Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Reviewed-by: Marc-André Lureau <malureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-12net: slirp: add support for CFI-friendly timer APIPaolo Bonzini1-1/+40
libslirp 4.7 introduces a CFI-friendly version of the .timer_new callback. The new callback replaces the function pointer with an enum; invoking the callback is done with a new function slirp_handle_timer. Support the new API so that CFI can be made compatible with using a system libslirp. Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Reviewed-by: Marc-André Lureau <malureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-12net: slirp: switch to slirp_newPaolo Bonzini2-7/+22
Replace slirp_init with slirp_new, so that a more recent cfg.version can be specified. The function appeared in version 4.1.0. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-12net: slirp: introduce a wrapper struct for QemuTimerPaolo Bonzini1-5/+14
This struct will be extended in the next few patches to support the new slirp_handle_timer() call. For that we need to store an additional "int" for each SLIRP timer, in addition to the cb_opaque. Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Reviewed-by: Marc-André Lureau <malureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-12slirp: bump submodule past 4.7 releasePaolo Bonzini1-0/+0
Version 4.7 of slirp provides a new timer API that works better with CFI, together with several other improvements: * Allow disabling the internal DHCP server !22 * Support Unix sockets in hostfwd !103 * IPv6 DNS proxying support !110 * bootp: add support for UEFI HTTP boot !111 and bugfixes. The submodule update also includes 2 commits to fix warnings in the Win32 build. Reviewed-by: Marc-André Lureau <malureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-12machine: move more memory validation to Machine objectPaolo Bonzini2-16/+22
This allows setting memory properties without going through vl.c, and have them validated just the same. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20220414165300.555321-6-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-12machine: make memory-backend a link propertyPaolo Bonzini5-69/+74
Handle HostMemoryBackend creation and setting of ms->ram entirely in machine_run_board_init. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20220414165300.555321-5-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-12machine: add mem compound propertyPaolo Bonzini3-83/+138
Make -m syntactic sugar for a compound property "-machine mem.{size,max-size,slots}". The new property does not have the magic conversion to megabytes of unsuffixed arguments, and also does not understand that "0" means the default size (you have to leave it out to get the default). This means that we need to convert the QemuOpts by hand to a QDict. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20220414165300.555321-4-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-12machine: add boot compound propertyPaolo Bonzini3-58/+57
Make -boot syntactic sugar for a compound property "-machine boot.{order,menu,...}". machine_boot_parse is replaced by the setter for the property. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20220414165300.555321-3-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-12machine: use QAPI struct for boot configurationPaolo Bonzini18-82/+127
As part of converting -boot to a property with a QAPI type, define the struct and use it throughout QEMU to access boot configuration. machine_boot_parse takes care of doing the QemuOpts->QAPI conversion by hand, for now. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20220414165300.555321-2-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-12.gitlab-ci.d: export meson testlog.txt as an artifactDaniel P. Berrangé1-2/+10
When running 'make check' we only get a summary of progress on the console. Fortunately meson/ninja have saved the raw test output to a logfile. Exposing this log will make it easier to debug failures that happen in CI. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20220509124134.867431-3-berrange@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-05-12tests/qemu-iotests: print intent to run a test in TAP modeDaniel P. Berrangé1-0/+3
When running I/O tests using TAP output mode, we get a single TAP test with a sub-test reported for each I/O test that is run. The output looks something like this: 1..123 ok qcow2 011 ok qcow2 012 ok qcow2 013 ok qcow2 217 ... If everything runs or fails normally this is fine, but periodically we have been seeing the test harness abort early before all 123 tests have been run, just leaving a fairly useless message like TAP parsing error: Too few tests run (expected 123, got 107) we have no idea which tests were running at the time the test harness abruptly exited. This change causes us to print a message about our intent to run each test, so we have a record of what is active at the time the harness exits abnormally. 1..123 # running qcow2 011 ok qcow2 011 # running qcow2 012 ok qcow2 012 # running qcow2 013 ok qcow2 013 # running qcow2 217 ok qcow2 217 ... Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20220509124134.867431-2-berrange@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-05-12iotests/testrunner: Flush after run_test()Hanna Reitz1-0/+1
When stdout is not a terminal, the buffer may not be flushed at each end of line, so we should flush after each test is done. This is especially apparent when run by check-block, in two ways: First, when running make check-block -jX with X > 1, progress indication was missing, even though testrunner.py does theoretically print each test's status once it has been run, even in multi-processing mode. Flushing after each test restores this progress indication. Second, sometimes make check-block failed altogether, with an error message that "too few tests [were] run". I presume that's because one worker process in the job pool did not get to flush its stdout before the main process exited, and so meson did not get to see that worker's test results. In any case, by flushing at the end of run_test(), the problem has disappeared for me. Signed-off-by: Hanna Reitz <hreitz@redhat.com> Message-Id: <20220506134215.10086-1-hreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-05-12coroutine: Revert to constant batch sizeKevin Wolf1-8/+14
Commit 4c41c69e changed the way the coroutine pool is sized because for virtio-blk devices with a large queue size and heavy I/O, it was just too small and caused coroutines to be deleted and reallocated soon afterwards. The change made the size dynamic based on the number of queues and the queue size of virtio-blk devices. There are two important numbers here: Slightly simplified, when a coroutine terminates, it is generally stored in the global release pool up to a certain pool size, and if the pool is full, it is freed. Conversely, when allocating a new coroutine, the coroutines in the release pool are reused if the pool already has reached a certain minimum size (the batch size), otherwise we allocate new coroutines. The problem after commit 4c41c69e is that it not only increases the maximum pool size (which is the intended effect), but also the batch size for reusing coroutines (which is a bug). It means that in cases with many devices and/or a large queue size (which defaults to the number of vcpus for virtio-blk-pci), many thousand coroutines could be sitting in the release pool without being reused. This is not only a waste of memory and allocations, but it actually makes the QEMU process likely to hit the vm.max_map_count limit on Linux because each coroutine requires two mappings (its stack and the guard page for the stack), causing it to abort() in qemu_alloc_stack() because when the limit is hit, mprotect() starts to fail with ENOMEM. In order to fix the problem, change the batch size back to 64 to avoid uselessly accumulating coroutines in the release pool, but keep the dynamic maximum pool size so that coroutines aren't freed too early in heavy I/O scenarios. Note that this fix doesn't strictly make it impossible to hit the limit, but this would only happen if most of the coroutines are actually in use at the same time, not just sitting in a pool. This is the same behaviour as we already had before commit 4c41c69e. Fully preventing this would require allowing qemu_coroutine_create() to return an error, but it doesn't seem to be a scenario that people hit in practice. Cc: qemu-stable@nongnu.org Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2079938 Fixes: 4c41c69e05fe28c0f95f8abd2ebf407e95a4f04b Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20220510151020.105528-3-kwolf@redhat.com> Tested-by: Hiroki Narukawa <hnarukaw@yahoo-corp.jp> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-05-12coroutine: Rename qemu_coroutine_inc/dec_pool_size()Kevin Wolf3-9/+7
It's true that these functions currently affect the batch size in which coroutines are reused (i.e. moved from the global release pool to the allocation pool of a specific thread), but this is a bug and will be fixed in a separate patch. In fact, the comment in the header file already just promises that it influences the pool size, so reflect this in the name of the functions. As a nice side effect, the shorter function name makes some line wrapping unnecessary. Cc: qemu-stable@nongnu.org Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20220510151020.105528-2-kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-05-12tests/qtest/libqos: Add generic pci host bridge in arm-virt machineEric Auger4-4/+301
Up to now the virt-machine node contains a virtio-mmio node. However no driver produces any PCI interface node. Hence, PCI tests cannot be run with aarch64 binary. Add a GPEX driver node that produces a pci interface node. This latter then can be consumed by all the pci tests. One of the first motivation was to be able to run the virtio-iommu-pci tests. We still face an issue with pci hotplug tests as hotplug cannot happen on the pcie root bus and require a generic root port. This will be addressed later on. We force cpu=max along with aarch64/virt machine as some PCI tests require high MMIO regions to be available. Signed-off-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20220504152025.1785704-4-eric.auger@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-12tests/qtest/libqos: Skip hotplug tests if pci root bus is not hotpluggableEric Auger6-0/+32
ARM does not not support hotplug on pcie.0. Add a flag on the bus which tells if devices can be hotplugged and skip hotplug tests if the bus cannot be hotplugged. This is a temporary solution to enable the other pci tests on aarch64. Signed-off-by: Eric Auger <eric.auger@redhat.com> Acked-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20220504152025.1785704-3-eric.auger@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-12tests/qtest/libqos/pci: Introduce pio_limitEric Auger4-31/+54
At the moment the IO space limit is hardcoded to QPCI_PIO_LIMIT = 0x10000. When accesses are performed to a bar, the base address of this latter is compared against the limit to decide whether we perform an IO or a memory access. On ARM, we cannot keep this PIO limit as the arm-virt machine uses [0x3eff0000, 0x3f000000 ] for the IO space map and we are mandated to allocate at 0x0. Add a new flag in QPCIBar indicating whether it is an IO bar or a memory bar. This flag is set on QPCIBar allocation and provisionned based on the BAR configuration. Then the new flag is used in access functions and in iomap() function. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20220504152025.1785704-2-eric.auger@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-12hw/xen/xen_pt: Resolve igd_passthrough_isa_bridge_create() indirectionBernhard Beschow3-13/+6
Now that igd_passthrough_isa_bridge_create() is implemented within the xen context it may use Xen* data types directly and become xen_igd_passthrough_isa_bridge_create(). This resolves an indirection. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20220326165825.30794-3-shentey@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-12hw/xen/xen_pt: Confine igd-passthrough-isa-bridge to XENBernhard Beschow5-120/+120
igd-passthrough-isa-bridge is only requested in xen_pt but was implemented in pc_piix.c. This caused xen_pt to dependend on i386/pc which is hereby resolved. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20220326165825.30794-2-shentey@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-12meson: Make mremap() detecting works correctlyJuan Quintela1-2/+3
Without this (at least in Fedora 35) it don't detect mremap() correctly. Signed-off-by: Juan Quintela <quintela@redhat.com> Message-Id: <20220502131119.2345-1-quintela@redhat.com> [Also switch the LEGACY_RDMA_REG_MR test to cc.links, otherwise Debian fails to build. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-12checkpatch: fix g_malloc checkPaolo Bonzini1-2/+2
Use the string equality operator "eq", and ensure that $1 is defined by using "(try|)" instead of "(try)?". The alternative "((?:try)?)" is longer and less readable. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-12target/i386: do not consult nonexistent host leavesPaolo Bonzini1-5/+36
When cache_info_passthrough is requested, QEMU passes the host values of the cache information CPUID leaves down to the guest. However, it blindly assumes that the CPUID leaf exists on the host, and this cannot be guaranteed: for example, KVM has recently started to synthesize AMD leaves up to 0x80000021 in order to provide accurate CPU bug information to guests. Querying a nonexistent host leaf fills the output arguments of host_cpuid with data that (albeit deterministic) is nonsensical as cache information, namely the data in the highest Intel CPUID leaf. If said highest leaf is not ECX-dependent, this can even cause an infinite loop when kvm_arch_init_vcpu prepares the input to KVM_SET_CPUID2. The infinite loop is only terminated by an abort() when the array gets full. Reported-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-12pc-bios/optionrom: compile with -Wno-array-boundsPaolo Bonzini1-0/+1
Avoids the following bogus warning: pvh_main.c: In function ‘pvh_load_kernel’: pvh_main.c:101:42: warning: array subscript 0 is outside array bounds of ‘uint16_t[0]’ {aka ‘short unsigned int[]’} [-Warray-bounds] 101 | uint32_t ebda_paddr = ((uint32_t)*((uint16_t *)EBDA_BASE_ADDR)) << 4; | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Cc: qemu-stable@nongnu.org Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-12pc-bios/optionrom: detect -fno-piePaolo Bonzini2-2/+2
Do not rely on the detection that was done in the configure script, since in the future we may want to cross-compile this file. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-05-11Clean up decorations and whitespace around header guardsMarkus Armbruster22-26/+24
Cleaned up with scripts/clean-header-guards.pl. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20220506134911.2856099-5-armbru@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2022-05-11Normalize header guard symbol definitionMarkus Armbruster20-20/+20
We commonly define the header guard symbol without an explicit value. Normalize the exceptions. Done with scripts/clean-header-guards.pl. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20220506134911.2856099-4-armbru@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2022-05-11Clean up ill-advised or unusual header guardsMarkus Armbruster72-209/+232
Leading underscores are ill-advised because such identifiers are reserved. Trailing underscores are merely ugly. Strip both. Our header guards commonly end in _H. Normalize the exceptions. Macros should be ALL_CAPS. Normalize the exception. Done with scripts/clean-header-guards.pl. include/hw/xen/interface/ and tools/virtiofsd/ left alone, because these were imported from Xen and libfuse respectively. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20220506134911.2856099-3-armbru@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2022-05-11Clean up header guards that don't match their file nameMarkus Armbruster58-151/+148
Header guard symbols should match their file name to make guard collisions less likely. Cleaned up with scripts/clean-header-guards.pl, followed by some renaming of new guard symbols picked by the script to better ones. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20220506134911.2856099-2-armbru@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> [Change to generated file ebpf/rss.bpf.skeleton.h backed out]
2022-05-09hw/acpi/aml-build: Use existing CPU topology to build PPTT tableGavin Shan1-63/+48
When the PPTT table is built, the CPU topology is re-calculated, but it's unecessary because the CPU topology has been populated in virt_possible_cpu_arch_ids() on arm/virt machine. This reworks build_pptt() to avoid by reusing the existing IDs in ms->possible_cpus. Currently, the only user of build_pptt() is arm/virt machine. Signed-off-by: Gavin Shan <gshan@redhat.com> Tested-by: Yanan Wang <wangyanan55@huawei.com> Reviewed-by: Yanan Wang <wangyanan55@huawei.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-id: 20220503140304.855514-7-gshan@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-05-09hw/arm/virt: Fix CPU's default NUMA node IDGavin Shan1-1/+3
When CPU-to-NUMA association isn't explicitly provided by users, the default one is given by mc->get_default_cpu_node_id(). However, the CPU topology isn't fully considered in the default association and this causes CPU topology broken warnings on booting Linux guest. For example, the following warning messages are observed when the Linux guest is booted with the following command lines. /home/gavin/sandbox/qemu.main/build/qemu-system-aarch64 \ -accel kvm -machine virt,gic-version=host \ -cpu host \ -smp 6,sockets=2,cores=3,threads=1 \ -m 1024M,slots=16,maxmem=64G \ -object memory-backend-ram,id=mem0,size=128M \ -object memory-backend-ram,id=mem1,size=128M \ -object memory-backend-ram,id=mem2,size=128M \ -object memory-backend-ram,id=mem3,size=128M \ -object memory-backend-ram,id=mem4,size=128M \ -object memory-backend-ram,id=mem4,size=384M \ -numa node,nodeid=0,memdev=mem0 \ -numa node,nodeid=1,memdev=mem1 \ -numa node,nodeid=2,memdev=mem2 \ -numa node,nodeid=3,memdev=mem3 \ -numa node,nodeid=4,memdev=mem4 \ -numa node,nodeid=5,memdev=mem5 : alternatives: patching kernel code BUG: arch topology borken the CLS domain not a subset of the MC domain <the above error log repeats> BUG: arch topology borken the DIE domain not a subset of the NODE domain With current implementation of mc->get_default_cpu_node_id(), CPU#0 to CPU#5 are associated with NODE#0 to NODE#5 separately. That's incorrect because CPU#0/1/2 should be associated with same NUMA node because they're seated in same socket. This fixes the issue by considering the socket ID when the default CPU-to-NUMA association is provided in virt_possible_cpu_arch_ids(). With this applied, no more CPU topology broken warnings are seen from the Linux guest. The 6 CPUs are associated with NODE#0/1, but there are no CPUs associated with NODE#2/3/4/5. Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Yanan Wang <wangyanan55@huawei.com> Message-id: 20220503140304.855514-6-gshan@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-05-09qtest/numa-test: Correct CPU and NUMA association in aarch64_numa_cpu()Gavin Shan1-6/+12
In aarch64_numa_cpu(), the CPU and NUMA association is something like below. Two threads in the same core/cluster/socket are associated with two individual NUMA nodes, which is unreal as Igor Mammedov mentioned. We don't expect the association to break NUMA-to-socket boundary, which matches with the real world. NUMA-node socket cluster core thread ------------------------------------------ 0 0 0 0 0 1 0 0 0 1 This corrects the topology for CPUs and their association with NUMA nodes. After this patch is applied, the CPU and NUMA association becomes something like below, which looks real. Besides, socket/cluster/core/thread IDs are all checked when the NUMA node IDs are verified. It helps to check if the CPU topology is properly populated or not. NUMA-node socket cluster core thread ------------------------------------------ 0 1 0 0 0 1 0 0 0 0 Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Gavin Shan <gshan@redhat.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20220503140304.855514-5-gshan@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-05-09hw/arm/virt: Consider SMP configuration in CPU topologyGavin Shan1-1/+14
Currently, the SMP configuration isn't considered when the CPU topology is populated. In this case, it's impossible to provide the default CPU-to-NUMA mapping or association based on the socket ID of the given CPU. This takes account of SMP configuration when the CPU topology is populated. The die ID for the given CPU isn't assigned since it's not supported on arm/virt machine. Besides, the used SMP configuration in qtest/numa-test/aarch64_numa_cpu() is corrcted to avoid testing failure Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Yanan Wang <wangyanan55@huawei.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20220503140304.855514-4-gshan@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2022-05-09qtest/numa-test: Specify CPU topology in aarch64_numa_cpu()Gavin Shan1-1/+2
The CPU topology isn't enabled on arm/virt machine yet, but we're going to do it in next patch. After the CPU topology is enabled by next patch, "thread-id=1" becomes invalid because the CPU core is preferred on arm/virt machine. It means these two CPUs have 0/1 as their core IDs, but their thread IDs are all 0. It will trigger test failure as the following message indicates: [14/21 qemu:qtest+qtest-aarch64 / qtest-aarch64/numa-test ERROR 1.48s killed by signal 6 SIGABRT >>> G_TEST_DBUS_DAEMON=/home/gavin/sandbox/qemu.main/tests/dbus-vmstate-daemon.sh \ QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon \ QTEST_QEMU_BINARY=./qemu-system-aarch64 \ QTEST_QEMU_IMG=./qemu-img MALLOC_PERTURB_=83 \ /home/gavin/sandbox/qemu.main/build/tests/qtest/numa-test --tap -k ―――――――――――――――――――――――――――――――――――――――――――――― stderr: qemu-system-aarch64: -numa cpu,node-id=0,thread-id=1: no match found This fixes the issue by providing comprehensive SMP configurations in aarch64_numa_cpu(). The SMP configurations aren't used before the CPU topology is enabled in next patch. Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Yanan Wang <wangyanan55@huawei.com> Message-id: 20220503140304.855514-3-gshan@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>