aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-07-14tests/docker: use project specific container registriesDaniel P. Berrangé
Since Docker Hub has started to enforce pull rate limits on clients, it is preferrable to use project specific container registries where they are available. Fedora and OpenSUSE projects provide registries. The images in these registries are also refreshed on a more regular basis than the ones in docker hub, so the package update should generally be faster. While CentOS also has a registry it is considerably outdated compared to docker.io, and also only provides x86 images, while docker.io images are multi-arch. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20210623142245.307776-4-berrange@redhat.com> Message-Id: <20210709143005.1554-12-alex.bennee@linaro.org>
2021-07-14tests/docker: don't use BUILDKIT in GitLab eitherDaniel P. Berrangé
Using BUILDKIT breaks with certain container registries such as CentOS, with docker build reporting an error such as failed to solve with frontend dockerfile.v0: failed to build LLB: failed to load cache key: unexpected status code https://registry.centos.org/v2/centos/manifests/7: 403 Forbidden Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Message-Id: <20210623142245.307776-3-berrange@redhat.com> Message-Id: <20210709143005.1554-11-alex.bennee@linaro.org>
2021-07-14hw/usb/ccid: remove references to NSSDaniel P. Berrangé
The NSS package was previously pre-requisite for building CCID related features, however, this became obsolete when the libcacard library was spun off to a separate project: commit 7b02f5447c64d1854468f758398c9f6fe9e5721f Author: Marc-André Lureau <marcandre.lureau@redhat.com> Date: Sun Aug 30 11:48:40 2015 +0200 libcacard: use the standalone project Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20210623142245.307776-2-berrange@redhat.com> Message-Id: <20210709143005.1554-10-alex.bennee@linaro.org>
2021-07-14cirrus: delete FreeBSD and macOS jobsDaniel P. Berrangé
The builds for these two platforms can now be performed from GitLab CI using cirrus-run. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com> Message-Id: <20210625172211.451010-4-berrange@redhat.com> Message-Id: <20210709143005.1554-9-alex.bennee@linaro.org>
2021-07-14gitlab: support for FreeBSD 12, 13 and macOS 11 via cirrus-runDaniel P. Berrangé
This adds support for running 4 jobs via Cirrus CI runners: * FreeBSD 12 * FreeBSD 13 * macOS 11 with default XCode * macOS 11 with latest XCode The gitlab job uses a container published by the libvirt-ci project (https://gitlab.com/libvirt/libvirt-ci) that contains the 'cirrus-run' command. This accepts a short yaml file that describes a single Cirrus CI job, runs it using the Cirrus CI REST API, and reports any output to the console. In this way Cirrus CI is effectively working as an indirect custom runner for GitLab CI pipelines. The key benefit is that Cirrus CI job results affect the GitLab CI pipeline result and so the user only has look at one CI dashboard. [AJB: remove $TEMPORARILY_DISABLED condition, s/py37/py38/] Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20210625172211.451010-3-berrange@redhat.com> Message-Id: <20210709143005.1554-8-alex.bennee@linaro.org>
2021-07-14build: validate that system capstone works before using itDaniel P. Berrangé
Some versions of capstone have shipped a broken pkg-config file which puts the -I path without the trailing '/capstone' suffix. This breaks the ability to "#include <capstone.h>". Upstream and most distros have fixed this, but a few stragglers remain, notably FreeBSD. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210625172211.451010-2-berrange@redhat.com> Message-Id: <20210709143005.1554-7-alex.bennee@linaro.org>
2021-07-14disable modular TCG on DarwinPaolo Bonzini
Accelerator modularity does not work on Darwin: ld: illegal thread local variable reference to regular symbol _current_cpu for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) Fix by avoiding modular TCG builds. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20210712122208.456264-1-pbonzini@redhat.com> [AJB: manually merged typo fix] Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
2021-07-14meson: fix condition for io_uring stubsPaolo Bonzini
CONFIG_LINUX_IO_URING is not included in config-host.mak and therefore is not usable in "when" clauses. Check the availability of the library, which matches the condition for the non-stubbed version block/io_uring.c. At this point, the difference between libraries that have config-host.mak entries and those that do not is quite confusing. The remaining ~dozen should be converted in 6.2. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210712151810.508249-1-pbonzini@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
2021-07-14tests/tcg: also disable the signals test for pluginsAlex Bennée
This will be more important when plugins is enabled by default. Fixes: eba61056e4 ("tests/tcg: generalise the disabling of the signals test") Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210709143005.1554-6-alex.bennee@linaro.org>
2021-07-14Jobs based on custom runners: add job definitions for QEMU's machinesCleber Rosa
The QEMU project has two machines (aarch64 and s390x) that can be used for jobs that do build and run tests. This introduces those jobs, which are a mapping of custom scripts used for the same purpose. Signed-off-by: Cleber Rosa <crosa@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com> Message-Id: <20210630012619.115262-5-crosa@redhat.com> Message-Id: <20210709143005.1554-5-alex.bennee@linaro.org>
2021-07-14Jobs based on custom runners: docs and gitlab-runner setup playbookCleber Rosa
To have the jobs dispatched to custom runners, gitlab-runner must be installed, active as a service and properly configured. The variables file and playbook introduced here should help with those steps. The playbook introduced here covers the Linux distributions and has been primarily tested on OS/machines that the QEMU project has available to act as runners, namely: * Ubuntu 20.04 on aarch64 * Ubuntu 18.04 on s390x But, it should work on all other Linux distributions. Earlier versions were tested on FreeBSD too, so chances of success are high. Signed-off-by: Cleber Rosa <crosa@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Willian Rampazzo <willianr@redhat.com> Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20210630012619.115262-4-crosa@redhat.com> Message-Id: <20210709143005.1554-4-alex.bennee@linaro.org>
2021-07-14Jobs based on custom runners: build environment docs and playbookCleber Rosa
To run basic jobs on custom runners, the environment needs to be properly set up. The most common requirement is having the right packages installed. The playbook introduced here covers the QEMU's project s390x and aarch64 machines. At the time this is being proposed, those machines have already had this playbook applied to them. Signed-off-by: Cleber Rosa <crosa@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Willian Rampazzo <willianr@redhat.com> Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20210630012619.115262-3-crosa@redhat.com> Message-Id: <20210709143005.1554-3-alex.bennee@linaro.org>
2021-07-14Jobs based on custom runners: documentation and configuration placeholderCleber Rosa
As described in the included documentation, the "custom runner" jobs extend the GitLab CI jobs already in place. One of their primary goals of catching and preventing regressions on a wider number of host systems than the ones provided by GitLab's shared runners. This sets the stage in which other community members can add their own machine configuration documentation/scripts, and accompanying job definitions. As a general rule, those newly added contributed jobs should run as "non-gating", until their reliability is verified (AKA "allow_failure: true"). Signed-off-by: Cleber Rosa <crosa@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com> Message-Id: <20210630012619.115262-2-crosa@redhat.com> Message-Id: <20210709143005.1554-2-alex.bennee@linaro.org>
2021-07-14Merge remote-tracking branch ↵Peter Maydell
'remotes/ehabkost-gl/tags/x86-next-pull-request' into staging x86 queue, 2021-07-13 Bug fixes: * numa: Parse initiator= attribute before cpus= attribute (Michal Privoznik) * Fix CPUID level for AMD (Zhenwei Pi) * Suppress CPUID leaves not defined by the CPU vendor (Michael Roth) Cleanup: * Hyper-V feature handling cleanup (Vitaly Kuznetsov) # gpg: Signature made Tue 13 Jul 2021 17:09:01 BST # gpg: using RSA key 5A322FD5ABC4D3DBACCFD1AA2807936F984DC5A6 # gpg: issuer "ehabkost@redhat.com" # gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" [full] # Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6 * remotes/ehabkost-gl/tags/x86-next-pull-request: numa: Parse initiator= attribute before cpus= attribute numa: Report expected initiator target/i386: Fix cpuid level for AMD target/i386: suppress CPUID leaves not defined by the CPU vendor i386: Hyper-V SynIC requires POST_MESSAGES/SIGNAL_EVENTS privileges i386: HV_HYPERCALL_AVAILABLE privilege bit is always needed i386: kill off hv_cpuid_check_and_set() i386: expand Hyper-V features during CPU feature expansion time i386: make hyperv_expand_features() return bool i386: hardcode supported eVMCS version to '1' i386: clarify 'hv-passthrough' behavior Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-07-13Merge remote-tracking branch ↵Peter Maydell
'remotes/dgilbert-gitlab/tags/pull-migration-20210713a' into staging Migration pull 2021-07-13 # gpg: Signature made Tue 13 Jul 2021 16:22:28 BST # 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-gitlab/tags/pull-migration-20210713a: migration: Move bitmap_mutex out of migration_bitmap_clear_dirty() migration: Clear error at entry of migrate_fd_connect() migration: Don't do migrate cleanup if during postcopy resume migration: Release return path early for paused postcopy migration: failover: emit a warning when the card is not fully unplugged migration/rdma: prevent from double free the same mr Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-07-13Merge remote-tracking branch ↵Peter Maydell
'remotes/vivier2/tags/linux-user-for-6.1-pull-request' into staging Linux-user pull request 20210713 Update headers to linux v5.13 cleanup errno target headers Fix race condition on fd translation table # gpg: Signature made Tue 13 Jul 2021 14:41:25 BST # 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/vivier2/tags/linux-user-for-6.1-pull-request: linux-user: update syscall.tbl to Linux v5.13 linux-user, mips: update syscall-args-o32.c.inc to Linux v5.13 linux-user: update syscall_nr.h to Linux v5.13 fd-trans: Fix race condition on reallocation of the translation table. linux-user/syscall: Remove ERRNO_TABLE_SIZE check linux-user: Simplify host <-> target errno conversion using macros linux-user/mips: Move errno definitions to 'target_errno_defs.h' linux-user/hppa: Move errno definitions to 'target_errno_defs.h' linux-user/alpha: Move errno definitions to 'target_errno_defs.h' linux-user: Extract target errno to 'target_errno_defs.h' linux-user/sparc: Rename target_errno.h -> target_errno_defs.h linux-user/syscall: Fix RF-kill errno (typo in ERFKILL) Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-07-13Merge remote-tracking branch 'remotes/dg-gitlab/tags/ppc-for-6.1-20210713' ↵Peter Maydell
into staging ppc patch queue 2021-07-13 I thought I'd sent the last PR before the 6.1 soft freeze, but unfortunately I need one more. This last minute one puts in a SLOF update, along with a couple of bugfixes. # gpg: Signature made Tue 13 Jul 2021 03:07:20 BST # gpg: using RSA key 75F46586AE61A66CC44E87DC6C38CACA20D9B392 # gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" [full] # gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" [full] # gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" [full] # gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" [unknown] # Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392 * remotes/dg-gitlab/tags/ppc-for-6.1-20210713: mv64361: Remove extra break from a switch case pseries: Update SLOF firmware image ppc/pegasos2: Allow setprop in VOF Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-07-13migration: Move bitmap_mutex out of migration_bitmap_clear_dirty()Peter Xu
Taking the mutex every time for each dirty bit to clear is too slow, especially we'll take/release even if the dirty bit is cleared. So far it's only used to sync with special cases with qemu_guest_free_page_hint() against migration thread, nothing really that serious yet. Let's move the lock to be upper. There're two callers of migration_bitmap_clear_dirty(). For migration, move it into ram_save_iterate(). With the help of MAX_WAIT logic, we'll only run ram_save_iterate() for no more than 50ms-ish time, so taking the lock once there at the entry. It also means any call sites to qemu_guest_free_page_hint() can be delayed; but it should be very rare, only during migration, and I don't see a problem with it. For COLO, move it up to colo_flush_ram_cache(). I think COLO forgot to take that lock even when calling ramblock_sync_dirty_bitmap(), where another example is migration_bitmap_sync() who took it right. So let the mutex cover both the ramblock_sync_dirty_bitmap() and migration_bitmap_clear_dirty() calls. It's even possible to drop the lock so we use atomic operations upon rb->bmap and the variable migration_dirty_pages. I didn't do it just to still be safe, also not predictable whether the frequent atomic ops could bring overhead too e.g. on huge vms when it happens very often. When that really comes, we can keep a local counter and periodically call atomic ops. Keep it simple for now. Cc: Wei Wang <wei.w.wang@intel.com> Cc: David Hildenbrand <david@redhat.com> Cc: Hailiang Zhang <zhang.zhanghailiang@huawei.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Juan Quintela <quintela@redhat.com> Cc: Leonardo Bras Soares Passos <lsoaresp@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20210630200805.280905-1-peterx@redhat.com> Reviewed-by: Wei Wang <wei.w.wang@intel.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2021-07-13migration: Clear error at entry of migrate_fd_connect()Peter Xu
For each "migrate" command, remember to clear the s->error before going on. For one reason, when there's a new error it'll be still remembered; see migrate_set_error() who only sets the error if error==NULL. Meanwhile if a failed migration completes (e.g., postcopy recovered and finished), we shouldn't dump an error when calling migrate_fd_cleanup() at last. Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20210708190653.252961-4-peterx@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2021-07-13migration: Don't do migrate cleanup if during postcopy resumePeter Xu
Below process could crash qemu with postcopy recovery: 1. (hmp) migrate -d .. 2. (hmp) migrate_start_postcopy 3. [network down, postcopy paused] 4. (hmp) migrate -r $WRONG_PORT when try the recover on an invalid $WRONG_PORT, cleanup_bh will be cleared 5. (hmp) migrate -r $RIGHT_PORT [qemu crash on assert(cleanup_bh)] The thing is we shouldn't cleanup if it's postcopy resume; the error is set mostly because the channel is wrong, so we return directly waiting for the user to retry. migrate_fd_cleanup() should only be called when migration is cancelled or completed. Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20210708190653.252961-3-peterx@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2021-07-13migration: Release return path early for paused postcopyPeter Xu
When postcopy pause triggered, we rely on the migration thread to cleanup the to_dst_file handle, and the return path thread to cleanup the from_dst_file handle (which is stored in the local variable "rp"). Within the process, from_dst_file cleanup (qemu_fclose) is postponed until it's setup again due to a postcopy recovery. It used to work before yank was born; after yank is introduced we rely on the refcount of IOC to correctly unregister yank function in channel_close(). If without the early and on-time release of from_dst_file handle the yank function will be leftover during paused postcopy. Without this patch, below steps (quoted from Xiaohui) could trigger qemu src crash: 1.Boot vm on src host 2.Boot vm on dst host 3.Enable postcopy on src&dst host 4.Load stressapptest in vm and set postcopy speed to 50M 5.Start migration from src to dst host, change into postcopy mode when migration is active. 6.When postcopy is active, down the network card(do migration via this network) on dst host. 7.Wait untill postcopy is paused on src&dst host. 8.Before up network card, recover migration on dst host, will get error like following. 9.Ignore the error of step 8, go on recovering migration on src host: After step 9, qemu on src host will core dump after some seconds: qemu-kvm: ../util/yank.c:107: yank_unregister_instance: Assertion `QLIST_EMPTY(&entry->yankfns)' failed. 1.sh: line 38: 44662 Aborted (core dumped) Reported-by: Li Xiaohui <xiaohli@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20210708190653.252961-2-peterx@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2021-07-13migration: failover: emit a warning when the card is not fully unpluggedLaurent Vivier
When the migration fails or is canceled we wait the end of the unplug operation to be able to plug it back. But if the unplug operation is never finished we stop to wait and QEMU emits a warning to inform the user. Based-on: 20210629155007.629086-1-lvivier@redhat.com Signed-off-by: Laurent Vivier <lvivier@redhat.com> Message-Id: <20210701131458.112036-1-lvivier@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2021-07-13migration/rdma: prevent from double free the same mrLi Zhijian
backtrace: '0x00007ffff5f44ec2 in __ibv_dereg_mr_1_1 (mr=0x7fff1007d390) at /home/lizhijian/rdma-core/libibverbs/verbs.c:478 478 void *addr = mr->addr; (gdb) bt #0 0x00007ffff5f44ec2 in __ibv_dereg_mr_1_1 (mr=0x7fff1007d390) at /home/lizhijian/rdma-core/libibverbs/verbs.c:478 #1 0x0000555555891fcc in rdma_delete_block (block=<optimized out>, rdma=0x7fff38176010) at ../migration/rdma.c:691 #2 qemu_rdma_cleanup (rdma=0x7fff38176010) at ../migration/rdma.c:2365 #3 0x00005555558925b0 in qio_channel_rdma_close_rcu (rcu=0x555556b8b6c0) at ../migration/rdma.c:3073 #4 0x0000555555d652a3 in call_rcu_thread (opaque=opaque@entry=0x0) at ../util/rcu.c:281 #5 0x0000555555d5edf9 in qemu_thread_start (args=0x7fffe88bb4d0) at ../util/qemu-thread-posix.c:541 #6 0x00007ffff54c73f9 in start_thread () at /lib64/libpthread.so.0 #7 0x00007ffff53f3b03 in clone () at /lib64/libc.so.6 ' Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com> Message-Id: <20210708144521.1959614-1-lizhijian@cn.fujitsu.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2021-07-13Merge remote-tracking branch 'remotes/ericb/tags/pull-nbd-2021-07-09-v2' ↵Peter Maydell
into staging nbd patches for 2021-07-09 - enhance 'qemu-img map --output=json' to make it easier to duplicate backing chain allocation patterns - fix a race in the 'yank' QMP command in relation to NBD requests # gpg: Signature made Mon 12 Jul 2021 18:43:37 BST # gpg: using RSA key 71C2CC22B1C4602927D2F3AAA7A16B4A2527436A # gpg: Good signature from "Eric Blake <eblake@redhat.com>" [full] # gpg: aka "Eric Blake (Free Software Programmer) <ebb9@byu.net>" [full] # gpg: aka "[jpeg image of size 6874]" [full] # Primary key fingerprint: 71C2 CC22 B1C4 6029 27D2 F3AA A7A1 6B4A 2527 436A * remotes/ericb/tags/pull-nbd-2021-07-09-v2: nbd: register yank function earlier qemu-img: Reword 'qemu-img map --output=json' docs qemu-img: Make unallocated part of backing chain obvious in map iotests: Improve and rename test 309 to nbd-qemu-allocation Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-07-13numa: Parse initiator= attribute before cpus= attributeMichal Privoznik
When parsing cpus= attribute of -numa object couple of checks is performed, such as correct initiator setting (see the if() statement at the end of for() loop in machine_set_cpu_numa_node()). However, with the current code cpus= attribute is parsed before initiator= attribute and thus the check may fail even though it is not obvious why. But since parsing the initiator= attribute does not depend on the cpus= attribute we can swap the order of the two. It's fairly easy to reproduce with the following command line (snippet of an actual cmd line): -smp 4,sockets=4,cores=1,threads=1 \ -object '{"qom-type":"memory-backend-ram","id":"ram-node0","size":2147483648}' \ -numa node,nodeid=0,cpus=0-1,initiator=0,memdev=ram-node0 \ -object '{"qom-type":"memory-backend-ram","id":"ram-node1","size":2147483648}' \ -numa node,nodeid=1,cpus=2-3,initiator=1,memdev=ram-node1 \ -numa hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-latency,latency=5 \ -numa hmat-lb,initiator=0,target=0,hierarchy=first-level,data-type=access-latency,latency=10 \ -numa hmat-lb,initiator=1,target=1,hierarchy=memory,data-type=access-latency,latency=5 \ -numa hmat-lb,initiator=1,target=1,hierarchy=first-level,data-type=access-latency,latency=10 \ -numa hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=204800K \ -numa hmat-lb,initiator=0,target=0,hierarchy=first-level,data-type=access-bandwidth,bandwidth=208896K \ -numa hmat-lb,initiator=1,target=1,hierarchy=memory,data-type=access-bandwidth,bandwidth=204800K \ -numa hmat-lb,initiator=1,target=1,hierarchy=first-level,data-type=access-bandwidth,bandwidth=208896K \ -numa hmat-cache,node-id=0,size=10K,level=1,associativity=direct,policy=write-back,line=8 \ -numa hmat-cache,node-id=1,size=10K,level=1,associativity=direct,policy=write-back,line=8 \ Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <b27a6a88986d63e3f610a728c845e01ff8d92e2e.1625662776.git.mprivozn@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-07-13numa: Report expected initiatorMichal Privoznik
When setting up NUMA with HMAT enabled there's a check performed in machine_set_cpu_numa_node() that reports an error when a NUMA node has a CPU but the node's initiator is not itself. The error message reported contains only the expected value and not the actual value (which is different because an error is being reported). Report both values in the error message. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com> Message-Id: <ebdf871551ea995bafa7a858899a26aa9bc153d3.1625662776.git.mprivozn@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-07-13target/i386: Fix cpuid level for AMDzhenwei pi
A AMD server typically has cpuid level 0x10(test on Rome/Milan), it should not be changed to 0x1f in multi-dies case. * to maintain compatibility with older machine types, only implement this change when the CPU's "x-vendor-cpuid-only" property is false Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: zhenwei pi <pizhenwei@bytedance.com> Fixes: a94e1428991 (target/i386: Add CPUID.1F generation support for multi-dies PCMachine) Signed-off-by: zhenwei pi <pizhenwei@bytedance.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Message-Id: <20210708170641.49410-1-michael.roth@amd.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-07-13target/i386: suppress CPUID leaves not defined by the CPU vendorMichael Roth
Currently all built-in CPUs report cache information via CPUID leaves 2 and 4, but these have never been defined for AMD. In the case of SEV-SNP this can cause issues with CPUID enforcement. Address this by allowing CPU types to suppress these via a new "x-vendor-cpuid-only" CPU property, which is true by default, but switched off for older machine types to maintain compatibility. Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: zhenwei pi <pizhenwei@bytedance.com> Suggested-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Message-Id: <20210708003623.18665-1-michael.roth@amd.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-07-13i386: Hyper-V SynIC requires POST_MESSAGES/SIGNAL_EVENTS privilegesVitaly Kuznetsov
When Hyper-V SynIC is enabled, we may need to allow Windows guests to make hypercalls (POST_MESSAGES/SIGNAL_EVENTS). No issue is currently observed because KVM is very permissive, allowing these hypercalls regarding of guest visible CPUid bits. Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20210608120817.1325125-9-vkuznets@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-07-13i386: HV_HYPERCALL_AVAILABLE privilege bit is always neededVitaly Kuznetsov
According to TLFS, Hyper-V guest is supposed to check HV_HYPERCALL_AVAILABLE privilege bit before accessing HV_X64_MSR_GUEST_OS_ID/HV_X64_MSR_HYPERCALL MSRs but at least some Windows versions ignore that. As KVM is very permissive and allows accessing these MSRs unconditionally, no issue is observed. We may, however, want to tighten the checks eventually. Conforming to the spec is probably also a good idea. Enable HV_HYPERCALL_AVAILABLE bit unconditionally. Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20210608120817.1325125-8-vkuznets@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-07-13i386: kill off hv_cpuid_check_and_set()Vitaly Kuznetsov
hv_cpuid_check_and_set() does too much: - Checks if the feature is supported by KVM; - Checks if all dependencies are enabled; - Sets the feature bit in cpu->hyperv_features for 'passthrough' mode. To reduce the complexity, move all the logic except for dependencies check out of it. Also, in 'passthrough' mode we don't really need to check dependencies because KVM is supposed to provide a consistent set anyway. Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20210608120817.1325125-7-vkuznets@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-07-13i386: expand Hyper-V features during CPU feature expansion timeVitaly Kuznetsov
To make Hyper-V features appear in e.g. QMP query-cpu-model-expansion we need to expand and set the corresponding CPUID leaves early. Modify x86_cpu_get_supported_feature_word() to call newly intoduced Hyper-V specific kvm_hv_get_supported_cpuid() instead of kvm_arch_get_supported_cpuid(). We can't use kvm_arch_get_supported_cpuid() as Hyper-V specific CPUID leaves intersect with KVM's. Note, early expansion will only happen when KVM supports system wide KVM_GET_SUPPORTED_HV_CPUID ioctl (KVM_CAP_SYS_HYPERV_CPUID). Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20210608120817.1325125-6-vkuznets@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-07-13i386: make hyperv_expand_features() return boolVitaly Kuznetsov
Return 'false' when hyperv_expand_features() sets an error. No functional change intended. Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20210608120817.1325125-5-vkuznets@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-07-13i386: hardcode supported eVMCS version to '1'Vitaly Kuznetsov
Currently, the only eVMCS version, supported by KVM (and described in TLFS) is '1'. When Enlightened VMCS feature is enabled, QEMU takes the supported eVMCS version range (from KVM_CAP_HYPERV_ENLIGHTENED_VMCS enablement) and puts it to guest visible CPUIDs. When (and if) eVMCS ver.2 appears a problem on migration is expected: it doesn't seem to be possible to migrate from a host supporting eVMCS ver.2 to a host, which only support eVMCS ver.1. Hardcode eVMCS ver.1 as the result of 'hv-evmcs' enablement for now. Newer eVMCS versions will have to have their own enablement options (e.g. 'hv-evmcs=2'). Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20210608120817.1325125-4-vkuznets@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-07-13i386: clarify 'hv-passthrough' behaviorVitaly Kuznetsov
Clarify the fact that 'hv-passthrough' only enables features which are already known to QEMU and that it overrides all other 'hv-*' settings. Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20210608120817.1325125-3-vkuznets@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-07-13linux-user: update syscall.tbl to Linux v5.13Laurent Vivier
Updated running scripts/update-syscalltbl.sh Signed-off-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20210708215756.268805-4-laurent@vivier.eu> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-07-13linux-user, mips: update syscall-args-o32.c.inc to Linux v5.13Laurent Vivier
Updated running scripts/update-mips-syscall-args.sh scripts/update-mips-syscall-args.sh has been updated to reflect file directory changes in strace repository. Signed-off-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20210708215756.268805-3-laurent@vivier.eu> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-07-13linux-user: update syscall_nr.h to Linux v5.13Laurent Vivier
Automatically generated using scripts/gensyscalls.sh Signed-off-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Taylor Simpson <tsimpson@quicinc.com> Message-Id: <20210708215756.268805-2-laurent@vivier.eu> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-07-13Merge remote-tracking branch ↵Peter Maydell
'remotes/stefanha-gitlab/tags/tracing-pull-request' into staging Pull request # gpg: Signature made Mon 12 Jul 2021 17:49:46 BST # gpg: using RSA key 8695A8BFD3F97CDAAC35775A9CA4ABB381AB73C8 # gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>" [full] # gpg: aka "Stefan Hajnoczi <stefanha@gmail.com>" [full] # Primary key fingerprint: 8695 A8BF D3F9 7CDA AC35 775A 9CA4 ABB3 81AB 73C8 * remotes/stefanha-gitlab/tags/tracing-pull-request: trace, lttng: require .pc files trace/simple: add st_init_group trace/simple: pass iter to st_write_event_mapping trace: add trace_event_iter_init_group trace: iter init tweaks qemu-trace-stap: changing SYSTEMTAP_TAPSET considered harmful. Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-07-13mv64361: Remove extra break from a switch caseBALATON Zoltan
The switch case of writing PCI 1 IO base address had an extra break statement that made part of the code unreachable. This did not cause a problem as guests ususally leave this register at its default value. Fixes: dcdf98a9015 ("Add emulation of Marvell MV64361 PPC system controller") Reported-by: Coverity (CID 1458135) Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <20210712131259.B705B7456E3@zero.eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-07-13pseries: Update SLOF firmware imageAlexey Kardashevskiy
This is all about TPM fixes and improvements. The change log is: Alexey Kardashevskiy (2): tcgbios: Fix warnings version: update to 20210711 Stefan Berger (9): tcgbios: Fix details in log entries tcgbios: Fix a typo in the sha256 algo description tcgbios: Add implementations for sha1, sha384, and sha512 tpm: Add firmware API call 2HASH-EXT-LOG tcgbios: Change format of S_CRTM_VERSION string to ucs-2 tcgbios: Use assembly for 32 bit rotr in sha256 tcgbios: Use The proper sha function for each PCR bank tcgbios: Add test cases and test script to run them Travis: Add script for running tests on Travis Thomas Huth (1): Fix bad header guard in version.h Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-07-13ppc/pegasos2: Allow setprop in VOFBALATON Zoltan
Linux needs setprop to fix up the device tree, otherwise it's not finding devices and cannot boot. Since recent VOF change now we need to add a callback to allow this which is what this patch does. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <20210709132920.6544E7457EF@zero.eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-07-12Merge remote-tracking branch 'remotes/philmd/tags/sdmmc-20210712' into stagingPeter Maydell
SD/MMC patches queue - sdcard: Check for valid address range in SEND_WRITE_PROT (CMD30) # gpg: Signature made Mon 12 Jul 2021 11:28:13 BST # 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/tags/sdmmc-20210712: hw/sd/sdcard: Check for valid address range in SEND_WRITE_PROT (CMD30) hw/sd/sdcard: Extract address_in_range() helper, log invalid accesses hw/sd/sdcard: When card is in wrong state, log which state it is Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-07-12fd-trans: Fix race condition on reallocation of the translation table.Owen Anderson
The mapping from file-descriptors to translator functions is not guarded on realloc which may cause invalid function pointers to be read from a previously deallocated mapping. Signed-off-by: Owen Anderson <oanderso@google.com> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20210701221255.107976-1-oanderso@google.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-07-12linux-user/syscall: Remove ERRNO_TABLE_SIZE checkPhilippe Mathieu-Daudé
Now than target_to_host_errno() always return an errno, we can remove the unused and arbitrary ERRNO_TABLE_SIZE definition. Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210708170550.1846343-9-f4bug@amsat.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-07-12linux-user: Simplify host <-> target errno conversion using macrosPhilippe Mathieu-Daudé
Convert the host_to_target_errno_table[] array to a switch case to allow compiler optimizations (such noticing the identity function when host and guest errnos match). Extract the errnos list as to a new includible unit, using a generic macro. Remove the code related to target_to_host_errno_table[] initialization. Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210708170550.1846343-8-f4bug@amsat.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-07-12linux-user/mips: Move errno definitions to 'target_errno_defs.h'Philippe Mathieu-Daudé
Suggested-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210708170550.1846343-7-f4bug@amsat.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-07-12linux-user/hppa: Move errno definitions to 'target_errno_defs.h'Philippe Mathieu-Daudé
Reviewed-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210708170550.1846343-6-f4bug@amsat.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-07-12linux-user/alpha: Move errno definitions to 'target_errno_defs.h'Philippe Mathieu-Daudé
Reviewed-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210708170550.1846343-5-f4bug@amsat.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-07-12linux-user: Extract target errno to 'target_errno_defs.h'Philippe Mathieu-Daudé
We want to access the target errno indepently of the rest of the linux-user code. Move the header containing the generic errno definitions ('errno_defs.h') to 'generic/target_errno_defs.h', create a new 'target_errno_defs.h' in each target which itself includes 'generic/target_errno_defs.h'. Suggested-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210708170550.1846343-4-f4bug@amsat.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
generated by cgit v1.2.3 (git 2.26.2) at 2025-01-03 20:06:29 +0000