aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-10-26linux/fuse.h: Pull in from LinuxMax Reitz
Update the linux/fuse.h standard header from the kernel development tree that implements FUSE submounts. This adds the fuse_attr.flags field, the FUSE_ATTR_FLAGS INIT flag, and the FUSE_ATTR_SUBMOUNT flag for fuse_attr.flags. Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200909184028.262297-2-mreitz@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-10-26tools/virtiofsd: xattr name mappings: Simple 'map'Dr. David Alan Gilbert
The mapping rule system implemented in the last few patches is extremely flexible, but not easy to use. Add a simple 'map' type as a sprinkling of sugar to make it easy. e.g. -o xattrmap=":map::user.virtiofs.:" would be sufficient to prefix all xattr's or -o xattrmap=":map:trusted.:user.virtiofs.:" would just prefix 'trusted.' xattr's and leave everything else alone. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20201023165812.36028-6-dgilbert@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-10-26tools/virtiofsd: xattr name mapping examplesDr. David Alan Gilbert
Add a few examples of xattrmaps to the documentation. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20201023165812.36028-5-dgilbert@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-10-26tools/virtiofsd: xattr name mappings: Map server xattr namesDr. David Alan Gilbert
Map xattr names coming from the server, i.e. the host filesystem; currently this is only from listxattr. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20201023165812.36028-4-dgilbert@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-10-26tools/virtiofsd: xattr name mappings: Map client xattr namesDr. David Alan Gilbert
Map xattr names originating at the client; from get/set/remove xattr. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20201023165812.36028-3-dgilbert@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-10-26tools/virtiofsd: xattr name mappings: Add optionDr. David Alan Gilbert
Add an option to define mappings of xattr names so that the client and server filesystems see different views. This can be used to have different SELinux mappings as seen by the guest, to run the virtiofsd with less privileges (e.g. in a case where it can't set trusted/system/security xattrs but you want the guest to be able to), or to isolate multiple users of the same name; e.g. trusted attributes used by stacking overlayfs. A mapping engine is used with 3 simple rules; the rules can be combined to allow most useful mapping scenarios. The ruleset is defined by -o xattrmap='rules...'. This patch doesn't use the rule maps yet. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20201023165812.36028-2-dgilbert@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-10-26virtiofsd: add container-friendly -o sandbox=chroot optionStefan Hajnoczi
virtiofsd cannot run in a container because CAP_SYS_ADMIN is required to create namespaces. Introduce a weaker sandbox mode that is sufficient in container environments because the container runtime already sets up namespaces. Use chroot to restrict path traversal to the shared directory. virtiofsd loses the following: 1. Mount namespace. The process chroots to the shared directory but leaves the mounts in place. Seccomp rejects mount(2)/umount(2) syscalls. 2. Pid namespace. This should be fine because virtiofsd is the only process running in the container. 3. Network namespace. This should be fine because seccomp already rejects the connect(2) syscall, but an additional layer of security is lost. Container runtime-specific network security policies can be used drop network traffic (except for the vhost-user UNIX domain socket). Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20201008085534.16070-1-stefanha@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-10-26virtiofsd: passthrough_ll: set FUSE_LOG_INFO as default log_levelMisono Tomohiro
Just noticed that although help message says default log level is INFO, it is actually 0 (EMRGE) and no mesage will be shown when error occurs. It's better to follow help message. Signed-off-by: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com> Message-Id: <20201008110148.2757734-1-misono.tomohiro@jp.fujitsu.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-10-26configure: add option for virtiofsdMisono Tomohiro
Currently it is unknown whether virtiofsd will be built at configuration time. It will be automatically built when dependency is met. Also, required libraries are not clear. To make this clear, add configure option --{enable,disable}-virtiofsd. The default is the same as current (enabled if available) like many other options. When --enable-virtiofsd is given and dependency is not met, we get: ERROR: Problem encountered: virtiofsd requires libcap-ng-devel and seccomp-devel or ERROR: Problem encountered: virtiofsd needs tools and vhost-user support In addition, configuration summary now includes virtiofsd entry: build virtiofs daemon: YES/NO Signed-off-by: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com> Message-Id: <20201008103133.2722903-1-misono.tomohiro@jp.fujitsu.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Manual merge
2020-10-26docs/devel/testing.rst: Update outdated Avocado URLsPhilippe Mathieu-Daudé
Avocado documentation referred returns 404 error. Update the broken links. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Message-Id: <20201010080741.2932406-1-philmd@redhat.com>
2020-10-26tests/acceptance: Allow running Orange Pi test using cached artifactsPhilippe Mathieu-Daudé
Unfortunately the Armbian 19.11.3 image has been removed from the dl.armbian.com file server. Developers having the artifact cached can still run the test. Allow them to, until we find a proper solution to share binaries with the whole community. This avoids (when file manually added to cache): BootLinuxConsole.test_arm_orangepi_bionic_19_11: CANCEL: Missing asset https://dl.armbian.com/orangepipc/archive/Armbian_19.11.3_Orangepipc_bionic_current_5.3.9.7z (1.06 s) Reported-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: Bin Meng <bin.meng@windriver.com> Tested-by: Niek Linnenbank <nieklinnenbank@gmail.com> Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com> Message-Id: <20201023131808.3198005-3-f4bug@amsat.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-10-26tests/acceptance: Add a 'virt_kvm' test using the GICv3Philippe Mathieu-Daudé
The current 'virt_kvm' test is restricted to GICv2, but can also work with a GICv3. Duplicate it but add a GICv3 test which can be tested on some hardware. Noticed while running: $ avocado --show=app run -t machine:virt tests/acceptance/ ... (2/6) tests/acceptance/boot_linux.py:BootLinuxAarch64.test_virt_kvm: ERROR: Unexpected empty reply from server (1.82 s) The job.log content is: L0351 DEBUG| Output: 'qemu-system-aarch64: host does not support in-kernel GICv2 emulation\n' With this patch: $ avocado --show=app run -t device:gicv3 tests/acceptance/ (1/1) tests/acceptance/boot_linux.py:BootLinuxAarch64.test_virt_kvm_gicv3: PASS (55.10 s) Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Message-Id: <20200929224857.1225107-1-philmd@redhat.com>
2020-10-26tests/boot_linux_console: Boot Trusted Firmware-A on the Raspberry Pi 3Philippe Mathieu-Daudé
This test runs Trusted Firmware-A on the Raspberry Pi 3. We deliberately stop the boot process when the EDK2 UEFI version is displayed. The binary is build on AppVeyor CI using Pete Batard repository [1]. ATF v2.1 binary are used (see [2]). It is very simple and fast: $ avocado --show=app,console run -t atf tests/acceptance JOB ID : 1e748d7c9e9011cf0af3250ddc8ebf2389d6204e JOB LOG : avocado/job-results/job-2020-02-16T18.08-1e748d7/job.log (1/1) tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_aarch64_raspi3_atf: console: NOTICE: Booting Trusted Firmware console: NOTICE: BL1: v2.1(release):v2.1 console: NOTICE: BL1: Built : 15:26:06, May 13 2019 console: NOTICE: rpi3: Detected: Raspberry Pi 3 Model B (1GB, Sony, UK) [0x00a02082] console: NOTICE: BL1: Booting BL2 console: ERROR: rpi3_sdhost: timeout status 0x40 console: NOTICE: BL2: v2.1(release):v2.1 console: NOTICE: BL2: Built : 15:26:01, May 13 2019 console: NOTICE: BL1: Booting BL31 console: NOTICE: BL31: v2.1(release):v2.1 console: NOTICE: BL31: Built : 15:26:04, May 13 2019 console: =UEFI firmware (version UEFI Firmware v1.15 built at 11:58:44 on Feb 14 2020) PASS (1.54 s) RESULTS : PASS 1 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 | CANCEL 0 JOB TIME : 1.88 s [1] https://github.com/pbatard/RPi3#summary [2] https://github.com/ARM-software/arm-trusted-firmware/blob/v2.1/docs/plat/rpi3.rst Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Luc Michel <luc.michel@greensocs.com> Message-Id: <20200217103442.30318-1-f4bug@amsat.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-10-26Merge remote-tracking branch 'remotes/philmd-gitlab/tags/sd-next-20201026' ↵Peter Maydell
into staging SD/MMC patches - Fix a bug in CMD6/SWITCH_FUNCTION (Bin Meng) - Minor housekeeping patches CI jobs result: . https://cirrus-ci.com/build/5461987880599552 . https://gitlab.com/philmd/qemu/-/pipelines/207532287 . https://travis-ci.org/github/philmd/qemu/builds/738901111 . https://app.shippable.com/github/philmd/qemu/runs/888/summary/console # gpg: Signature made Mon 26 Oct 2020 11:02:22 GMT # gpg: using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE # gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.org>" [full] # Primary key fingerprint: FAAB E75E 1291 7221 DCFD 6BB2 E3E3 2C2C DEAD C0DE * remotes/philmd-gitlab/tags/sd-next-20201026: hw/sd/sdcard: Zero out function selection fields before being populated hw/sd/sdcard: Make iolen unsigned hw/sd/sdcard: Constify sd_crc*()'s message argument hw/sd/sdcard: Simplify cmd_valid_while_locked() hw/sd/sdcard: Update the SDState documentation Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-10-26Add execute bit back to scripts/tracetool.pyAnthony PERARD
Commit a81df1b68b65 ("libqemuutil, qapi, trace: convert to meson") removed it without explanation and it is useful to be able to run a script without having to figure out which interpreter to use. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20200923103620.1980151-1-anthony.perard@citrix.com>
2020-10-26trace/simple: Enable tracing on startup only if the user specifies a trace ↵Josh DuBois
option Tracing can be enabled at the command line or via the monitor. Command-line trace options are recorded during trace_opt_parse(), but tracing is not enabled until the various front-ends later call trace_init_file(). If the user passes a trace option on the command-line, remember that and enable tracing during trace_init_file(). Otherwise, trace_init_file() should record the trace file specified by the frontend and avoid enabling traces until the user requests them via the monitor. This fixes 1b7157be3a8c4300fc8044d40f4b2e64a152a1b4 and also db25d56c014aa1a96319c663e0a60346a223b31e, by allowing the user to enable traces on the command line and also avoiding unwanted trace-<pid> files when the user has not asked for them. Fixes: 1b7157be3a8c4300fc8044d40f4b2e64a152a1b4 Signed-off-by: Josh DuBois <josh@joshdubois.com> Message-id: 20200816174610.20253-1-josh@joshdubois.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2020-10-26migration-test: Only hide error if !QTEST_LOGPeter Xu
The errors are very useful when debugging qtest failures, especially when QTEST_LOG=1 is set. Let's allow override MigrateStart.hide_stderr when QTEST_LOG=1 is specified, because that means the user wants to be verbose. Not very nice to introduce the first QTEST_LOG env access in migration-test.c, however it should be handy. Without this patch, I was hacking error_report() when debugging such errors. Let's make things easier. Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20201021212721.440373-7-peterx@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-10-26migration/postcopy: Release fd before going into 'postcopy-pause'Peter Xu
Logically below race could trigger with the old code: test program migration thread ------------ ---------------- wait_until('postcopy-pause') postcopy_pause() set_state('postcopy-pause') do_postcopy_recover() arm s->to_dst_file with new fd release s->to_dst_file [1] Here [1] could have released the just-installed recoverying channel. Then the migration could hang without really resuming. Instead, it should be very safe to release the fd before setting the state into 'postcopy-pause', because there's no reason for any other thread to touch it during 'postcopy-active'. Dave reported a very rare postcopy recovery hang that the migration-test program waited for the migration to complete in migrate_postcopy_complete(). We do suspect it's the same thing that we're gonna fix here. Hard to tell. However since we've noticed this, fix this irrelevant of the hang report. Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Cc: Juan Quintela <quintela@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20201021212721.440373-6-peterx@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-10-26migration: Sync requested pages after postcopy recoveryPeter Xu
We synchronize the requested pages right after a postcopy recovery happens. This helps to synchronize the prioritized pages on source so that the faulted threads can be served faster. Reported-by: Xiaohui Li <xiaohli@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20201021212721.440373-5-peterx@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-10-26migration: Maintain postcopy faulted addressesPeter Xu
Maintain a list of faulted addresses on the destination host for which we're waiting on. This is implemented using a GTree rather than a real list to make sure even there're plenty of vCPUs/threads that are faulting, the lookup will still be fast with O(log(N)) (because we'll do that after placing each page). It should bring a slight overhead, but ideally that shouldn't be a big problem simply because in most cases the requested page list will be short. Actually we did similar things for postcopy blocktime measurements. This patch didn't use that simply because: (1) blocktime measurement is towards vcpu threads only, but here we need to record all faulted addresses, including main thread and external thread (like, DPDK via vhost-user). (2) blocktime measurement will require UFFD_FEATURE_THREAD_ID, but here we don't want to add that extra dependency on the kernel version since not necessary. E.g., we don't need to know which thread faulted on which page, we also don't care about multiple threads faulting on the same page. But we only care about what addresses are faulted so waiting for a page copying from src. (3) blocktime measurement is not enabled by default. However we need this by default especially for postcopy recover. Another thing to mention is that this patch introduced a new mutex to serialize the receivedmap and the page_requested tree, however that serialization does not cover other procedures like UFFDIO_COPY. Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20201021212721.440373-4-peterx@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-10-26migration: Introduce migrate_send_rp_message_req_pages()Peter Xu
This is another layer wrapper for sending a page request to the source VM. The new migrate_send_rp_message_req_pages() will be used elsewhere in coming patches. Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20201021212721.440373-3-peterx@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-10-26migration: Pass incoming state into qemu_ufd_copy_ioctl()Peter Xu
It'll be used in follow up patches to access more fields out of it. Meanwhile fetch the userfaultfd inside the function. Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20201021212721.440373-2-peterx@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-10-26migration: using trace_ to replace DPRINTFBihong Yu
Signed-off-by: Bihong Yu <yubihong@huawei.com> Message-Id: <1603179176-5360-1-git-send-email-yubihong@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-10-26migration: Delete redundant spacesBihong Yu
Signed-off-by: Bihong Yu <yubihong@huawei.com> Reviewed-by: Chuan Zheng <zhengchuan@huawei.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <1603163448-27122-9-git-send-email-yubihong@huawei.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-10-26migration: Open brace '{' following function declarations go on the next lineBihong Yu
Signed-off-by: Bihong Yu <yubihong@huawei.com> Reviewed-by: Chuan Zheng <zhengchuan@huawei.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <1603163448-27122-8-git-send-email-yubihong@huawei.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-10-26migration: Do not initialise statics and globals to 0 or NULLBihong Yu
Signed-off-by: Bihong Yu <yubihong@huawei.com> Reviewed-by: Chuan Zheng <zhengchuan@huawei.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <1603163448-27122-7-git-send-email-yubihong@huawei.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-10-26migration: Add braces {} for if statementBihong Yu
Signed-off-by: Bihong Yu <yubihong@huawei.com> Reviewed-by: Chuan Zheng <zhengchuan@huawei.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <1603163448-27122-6-git-send-email-yubihong@huawei.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-10-26migration: Open brace '{' following struct go on the same lineBihong Yu
Signed-off-by: Bihong Yu <yubihong@huawei.com> Reviewed-by: Chuan Zheng <zhengchuan@huawei.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <1603163448-27122-5-git-send-email-yubihong@huawei.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-10-26migration: Add spaces around operatorBihong Yu
Signed-off-by: Bihong Yu <yubihong@huawei.com> Reviewed-by: Chuan Zheng <zhengchuan@huawei.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <1603163448-27122-4-git-send-email-yubihong@huawei.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-10-26migration: Don't use '#' flag of printf formatBihong Yu
Signed-off-by: Bihong Yu <yubihong@huawei.com> Reviewed-by: Chuan Zheng <zhengchuan@huawei.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <1603163448-27122-3-git-send-email-yubihong@huawei.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-10-26migration: Do not use C99 // commentsBihong Yu
Signed-off-by: Bihong Yu <yubihong@huawei.com> Reviewed-by: Chuan Zheng <zhengchuan@huawei.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <1603163448-27122-2-git-send-email-yubihong@huawei.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-10-26migration: Drop unused VMSTATE_FLOAT64 supportPeter Maydell
Commit ef96e3ae9698d6 in January 2019 removed the last user of the VMSTATE_FLOAT64* macros. These were used by targets which defined their floating point register file as an array of 'float64'. We used to try to maintain a stricter distinction between 'float64' (a type for holding an integer representing an IEEE float) and 'uint64_t', including having a debug option for 'float64' being a struct and supposedly mandatory macros for converting between float64 and uint64_t. We no longer think that's a usefully strong distinction to draw and we allow ourselves to freely assume that float64 really is just a 64-bit integer type, so for new targets we would simply recommend use of the uint64_t type for a floating point register file. The float64 type remains as a useful way of documenting in the type signature of helper functions and the like that they expect to receive an IEEE float from the TCG generated code rather than an arbitrary integer. Since the VMSTATE_FLOAT64* macros have no remaining users and we don't recommend new code uses them, delete them. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20201022120830.5938-1-peter.maydell@linaro.org> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2020-10-26Merge remote-tracking branch 'remotes/bonzini-gitlab/tags/for-upstream' into ↵Peter Maydell
staging * fix --disable-tcg builds (Claudio) * Fixes for macOS --enable-modules build and OpenBSD curses/iconv detection (myself) * Start preparing for meson 0.56 (myself) * Move directory configuration to meson (myself) * Start untangling qemu_init (myself) * Windows fixes (Sunil) * Remove -no-kbm (Thomas) # gpg: Signature made Mon 26 Oct 2020 11:12:17 GMT # gpg: using RSA key F13338574B662389866C7682BFFBD25F78C7AE83 # gpg: issuer "pbonzini@redhat.com" # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full] # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full] # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini-gitlab/tags/for-upstream: machine: move SMP initialization from vl.c machine: move UP defaults to class_base_init machine: remove deprecated -machine enforce-config-section option win32: boot broken when bind & data dir are the same WHPX: Fix WHPX build break configure: move install_blobs from configure to meson configure: remove unused variable from config-host.mak configure: move directory options from config-host.mak to meson configure: allow configuring localedir Makefile: separate meson rerun from the rest of the ninja invocation Remove deprecated -no-kvm option replay: do not build if TCG is not available qtest: unbreak non-TCG builds in bios-tables-test hw/core/qdev-clock: add a reference on aliased clocks do not use colons in test names meson: rewrite curses/iconv test build: fix macOS --enable-modules build Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-10-26Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20201026' into stagingPeter Maydell
some s390x fixes # gpg: Signature made Mon 26 Oct 2020 10:46:50 GMT # gpg: using RSA key C3D0D66DC3624FF6A8C018CEDECF6B93C6F02FAF # gpg: issuer "cohuck@redhat.com" # gpg: Good signature from "Cornelia Huck <conny@cornelia-huck.de>" [unknown] # gpg: aka "Cornelia Huck <huckc@linux.vnet.ibm.com>" [full] # gpg: aka "Cornelia Huck <cornelia.huck@de.ibm.com>" [full] # gpg: aka "Cornelia Huck <cohuck@kernel.org>" [unknown] # gpg: aka "Cornelia Huck <cohuck@redhat.com>" [unknown] # Primary key fingerprint: C3D0 D66D C362 4FF6 A8C0 18CE DECF 6B93 C6F0 2FAF * remotes/cohuck/tags/s390x-20201026: s390x: pv: Fix diag318 PV fencing s390x: pv: Remove sclp boundary checks s390x/s390-virtio-ccw: Reset PCI devices during subsystem reset Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-10-26Merge remote-tracking branch ↵Peter Maydell
'remotes/huth-gitlab/tags/pull-request-2020-10-26' into staging * qtest fixes (e.g. memory leaks) * Fix for Xen dummy cpu loop (which happened due to qtest accel rework) * Introduction of the generic device fuzzer * Run more check-acceptance tests in the gitlab-CI # gpg: Signature made Mon 26 Oct 2020 09:34:04 GMT # gpg: using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5 # gpg: issuer "thuth@redhat.com" # gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full] # gpg: aka "Thomas Huth <thuth@redhat.com>" [full] # gpg: aka "Thomas Huth <huth@tuxfamily.org>" [full] # gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown] # Primary key fingerprint: 27B8 8847 EEE0 2501 18F3 EAB9 2ED9 D774 FE70 2DB5 * remotes/huth-gitlab/tags/pull-request-2020-10-26: (31 commits) tests/acceptance: Use .ppm extention for Portable PixMap files tests/acceptance: Remove unused import test/docker/dockerfiles: Add missing packages for acceptance tests tests/acceptance: Enable AVOCADO_ALLOW_UNTRUSTED_CODE in the gitlab-CI test/acceptance: Remove the CONTINUOUS_INTEGRATION tags tests/acceptance/ppc_prep_40p: Fix the URL to the NetBSD-4.0 archive scripts/oss-fuzz: ignore the generic-fuzz target scripts/oss-fuzz: use hardlinks instead of copying fuzz: register predefined generic-fuzz configs fuzz: add generic-fuzz configs for oss-fuzz fuzz: add an "opaque" to the FuzzTarget struct fuzz: Add instructions for using generic-fuzz scripts/oss-fuzz: Add crash trace minimization script scripts/oss-fuzz: Add script to reorder a generic-fuzzer trace fuzz: add a crossover function to generic-fuzzer fuzz: add a DISABLE_PCI op to generic-fuzzer fuzz: Add support for custom crossover functions fuzz: Add fuzzer callbacks to DMA-read functions fuzz: Declare DMA Read callback function fuzz: Add DMA support to the generic-fuzzer ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-10-26hw/arm/tosa: Replace fprintf() calls by LED devicesPhilippe Mathieu-Daudé
The recently added LED device reports LED status changes with the 'led_set_intensity' trace event. It is less invasive than the fprintf() calls. We need however to have a binary built with tracing support. Reviewed-by: Luc Michel <luc.michel@greensocs.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20200912134041.946260-8-f4bug@amsat.org>
2020-10-26hw/misc/mps2-scc: Use the LED devicePhilippe Mathieu-Daudé
Per the 'ARM MPS2 and MPS2+ FPGA Prototyping Boards Technical Reference Manual' (100112_0200_07_en): 2.1 Overview of the MPS2 and MPS2+ hardware The MPS2 and MPS2+ FPGA Prototyping Boards contain the following components and interfaces: * User switches and user LEDs: - Two green LEDs and two push buttons that connect to the FPGA. - Eight green LEDs and one 8-way dip switch that connect to the MCC. Add the 8 LEDs connected to the MCC. This replaces the 'mps2_scc_leds' trace events by the generic 'led_set_intensity' event. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Luc Michel <luc.michel@greensocs.com> Message-Id: <20200912134041.946260-7-f4bug@amsat.org>
2020-10-26hw/misc/mps2-fpgaio: Use the LED devicePhilippe Mathieu-Daudé
Per the 'ARM MPS2 and MPS2+ FPGA Prototyping Boards Technical Reference Manual' (100112_0200_07_en): 2.1 Overview of the MPS2 and MPS2+ hardware The MPS2 and MPS2+ FPGA Prototyping Boards contain the following components and interfaces: * User switches and user LEDs: - Two green LEDs and two push buttons that connect to the FPGA. - Eight green LEDs and one 8-way dip switch that connect to the MCC. Add the 2 LEDs connected to the FPGA. This replaces the 'mps2_fpgaio_leds' trace events by the generic 'led_set_intensity' event. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Luc Michel <luc.michel@greensocs.com> Message-Id: <20200912134041.946260-6-f4bug@amsat.org>
2020-10-26hw/arm/aspeed: Add the 3 front LEDs drived by the PCA9552 #1Philippe Mathieu-Daudé
The Witherspoon has 3 LEDs connected to a PCA9552. Add them. The names and reset values are taken from: https://github.com/open-power/witherspoon-xml/blob/master/witherspoon.xml Example booting obmc-phosphor-image: $ qemu-system-arm -M witherspoon-bmc -trace led_change_intensity 1592693373.997015:led_change_intensity LED desc:'front-fault-4' color:green intensity 0% -> 100% 1592693373.997632:led_change_intensity LED desc:'front-power-3' color:green intensity 0% -> 100% 1592693373.998239:led_change_intensity LED desc:'front-id-5' color:green intensity 0% -> 100% 1592693500.291805:led_change_intensity LED desc:'front-power-3' color:green intensity 100% -> 0% 1592693500.312041:led_change_intensity LED desc:'front-power-3' color:green intensity 0% -> 100% 1592693500.821254:led_change_intensity LED desc:'front-power-3' color:green intensity 100% -> 0% 1592693501.331517:led_change_intensity LED desc:'front-power-3' color:green intensity 0% -> 100% 1592693501.841367:led_change_intensity LED desc:'front-power-3' color:green intensity 100% -> 0% 1592693502.350839:led_change_intensity LED desc:'front-power-3' color:green intensity 0% -> 100% 1592693502.861134:led_change_intensity LED desc:'front-power-3' color:green intensity 100% -> 0% 1592693503.371090:led_change_intensity LED desc:'front-power-3' color:green intensity 0% -> 100% We notice the front-power LED starts to blink at a ~2Hz rate. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Luc Michel <luc.michel@greensocs.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200912134041.946260-5-f4bug@amsat.org>
2020-10-26hw/misc/led: Emit a trace event when LED intensity has changedPhilippe Mathieu-Daudé
Track the LED intensity, and emit a trace event when it changes. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Luc Michel <luc.michel@greensocs.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20200912134041.946260-4-f4bug@amsat.org>
2020-10-26hw/misc/led: Allow connecting from GPIO outputPhilippe Mathieu-Daudé
Some devices expose GPIO lines. Add a GPIO qdev input to our LED device, so we can connect a GPIO output using qdev_connect_gpio_out(). When used with GPIOs, the intensity can only be either minium or maximum. This depends of the polarity of the GPIO (which can be inverted). Declare the GpioPolarity type to model the polarity. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Luc Michel <luc.michel@greensocs.com> Message-Id: <20200912134041.946260-3-f4bug@amsat.org>
2020-10-26hw/misc/led: Add a LED devicePhilippe Mathieu-Daudé
Add a LED device which can be connected to a GPIO output. They can also be dimmed with PWM devices. For now we do not implement the dimmed mode, but in preparation of a future implementation, we start using the LED intensity. LEDs are limited to a fixed set of colors. Reviewed-by: Luc Michel <luc.michel@greensocs.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20200912134041.946260-2-f4bug@amsat.org>
2020-10-26migration/block-dirty-bitmap: fix uninitialized variable warningChen Qun
A default value is provided for the variable 'bitmap_name' to avoid a compiler warning. The compiler showed the warning: migration/block-dirty-bitmap.c:1090:13: warning: ‘bitmap_name’ may be used uninitialized in this function [-Wmaybe-uninitialized] g_strlcpy(s->bitmap_name, bitmap_name, sizeof(s->bitmap_name)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com> Message-Id: <20201014114430.1898684-1-kuhn.chenqun@huawei.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> [eblake: commit message grammar tweaks] Signed-off-by: Eric Blake <eblake@redhat.com>
2020-10-26migration/block-dirty-bitmap: fix larger granularity bitmapsStefan Reiter
sectors_per_chunk is a 64 bit integer, but the calculation is done in 32 bits, leading to an overflow for coarse bitmap granularities. If that results in the value 0, it leads to a hang where no progress is made but send_bitmap_bits is constantly called with nr_sectors being 0. Signed-off-by: Stefan Reiter <s.reiter@proxmox.com> Message-Id: <20201021144456.1072-1-s.reiter@proxmox.com> Fixes: b35ebdf07 migration: add postcopy migration of dirty bitmaps Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> [eblake: Use correct type for 8ULL, use () to avoid overflow] Signed-off-by: Eric Blake <eblake@redhat.com>
2020-10-26Merge remote-tracking branch ↵Peter Maydell
'remotes/alistair/tags/pull-riscv-to-apply-20201023' into staging A collection of RISC-V fixes for the next QEMU release. This includes: - Improvements to logging output - Hypervisor instruction fixups - The ability to load a noMMU kernel - SiFive OTP support # gpg: Signature made Fri 23 Oct 2020 16:13:57 BST # gpg: using RSA key F6C4AC46D4934868D3B8CE8F21E10D29DF977054 # gpg: Good signature from "Alistair Francis <alistair@alistair23.me>" [full] # Primary key fingerprint: F6C4 AC46 D493 4868 D3B8 CE8F 21E1 0D29 DF97 7054 * remotes/alistair/tags/pull-riscv-to-apply-20201023: hw/misc/sifive_u_otp: Add backend drive support hw/misc/sifive_u_otp: Add write function and write-once protection target/riscv: raise exception to HS-mode at get_physical_address hw/riscv: Load the kernel after the firmware hw/riscv: Add a riscv_is_32_bit() function hw/riscv: Return the end address of the loaded firmware hw/riscv: sifive_u: Allow specifying the CPU target/riscv: Fix implementation of HLVX.WU instruction target/riscv: Fix update of hstatus.GVA in riscv_cpu_do_interrupt target/riscv: Fix update of hstatus.SPVP hw/intc: Move sifive_plic.h to the include directory riscv: Convert interrupt logs to use qemu_log_mask() Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-10-26machine: move SMP initialization from vl.cPaolo Bonzini
Initialize the object's values from the class when the object is created, no need to have vl.c do it for us. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-10-26machine: move UP defaults to class_base_initPaolo Bonzini
Clean up vl.c, default min/max/default_cpus to uniprocessor directly in the QOM class initialization code. Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-10-26machine: remove deprecated -machine enforce-config-section optionPaolo Bonzini
Deprecated since 3.1 and complicates the initialization sequence, remove it. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-10-26win32: boot broken when bind & data dir are the sameSunil Muthuswamy
With upstream commit#ea1edcd7da1a "vl: relocate paths to data directories", the data dir logic was unified between POSIX & Win32. That patch moved to using 'get_relocated_path()', to find the data dir. There is a latent bug in get_relocated_path which can cause it to spin indefinitely, when the bind dir is the same as the passed in dir (in this case, it was the data dir). Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com> Message-Id: <SN4PR2101MB08802BF242C429A15DDB32ACC01B0@SN4PR2101MB0880.namprd21.prod.outlook.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-10-26WHPX: Fix WHPX build breakSunil Muthuswamy
With upstream commit#8a19980e3fc4, logic was introduced to only allow WHPX build on x64. But, the logic checks for the cpu family and not the cpu. On my fedora container build, the cpu family is x86 and the cpu is x86_64. Fixing the build break by checking for the cpu, instead of the cpu family. Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com> Message-Id: <SN4PR2101MB0880D706A85793DDFC411304C01D0@SN4PR2101MB0880.namprd21.prod.outlook.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-17 11:43:51 +0000