summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* tz-ppc: add dummy read/write methodsPrasad J Pandit2021-02-081-0/+14
| | | | | | | | | | | Add tz-ppc-dummy mmio read/write methods to avoid assert failure during initialisation. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> Reviewed-by: Li Qiang <liq3ea@gmail.com> Message-Id: <20200811114133.672647-8-ppandit@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* spapr_pci: add spapr msi read methodPrasad J Pandit2021-02-081-2/+12
| | | | | | | | | | | | Add spapr msi mmio read method to avoid NULL pointer dereference issue. Reported-by: Lei Sun <slei.casper@gmail.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Li Qiang <liq3ea@gmail.com> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> Message-Id: <20200811114133.672647-7-ppandit@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* nvram: add nrf51_soc flash read methodPrasad J Pandit2021-02-081-0/+10
| | | | | | | | | | | | Add nrf51_soc mmio read method to avoid NULL pointer dereference issue. Reported-by: Lei Sun <slei.casper@gmail.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> Reviewed-by: Li Qiang <liq3ea@gmail.com> Message-Id: <20200811114133.672647-6-ppandit@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* prep: add ppc-parity write methodPrasad J Pandit2021-02-081-0/+8
| | | | | | | | | | | | Add ppc-parity mmio write method to avoid NULL pointer dereference issue. Reported-by: Lei Sun <slei.casper@gmail.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> Reviewed-by: Li Qiang <liq3ea@gmail.com> Message-Id: <20200811114133.672647-5-ppandit@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* vfio: add quirk device write methodPrasad J Pandit2021-02-081-0/+8
| | | | | | | | | | | | | Add vfio quirk device mmio write method to avoid NULL pointer dereference issue. Reported-by: Lei Sun <slei.casper@gmail.com> Reviewed-by: Li Qiang <liq3ea@gmail.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> Message-Id: <20200811114133.672647-4-ppandit@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* pci-host: designware: add pcie-msi read methodPrasad J Pandit2021-02-081-0/+19
| | | | | | | | | | | | Add pcie-msi mmio read method to avoid NULL pointer dereference issue. Reported-by: Lei Sun <slei.casper@gmail.com> Reviewed-by: Li Qiang <liq3ea@gmail.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> Message-Id: <20200811114133.672647-3-ppandit@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* hw/pci-host: add pci-intack write methodPrasad J Pandit2021-02-081-0/+8
| | | | | | | | | | | | Add pci-intack mmio write method to avoid NULL pointer dereference issue. Reported-by: Lei Sun <slei.casper@gmail.com> Reviewed-by: Li Qiang <liq3ea@gmail.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> Message-Id: <20200811114133.672647-2-ppandit@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* cpu-throttle: Remove timer_mod() from cpu_throttle_set()Utkarsh Tripathi2021-02-081-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During migrations, after each iteration, cpu_throttle_set() is called, which irrespective of input, re-arms the timer according to value of new_throttle_pct. This causes cpu_throttle_thread() to be delayed in getting scheduled and consqeuntly lets guest run for more time than what the throttle value should allow. This leads to spikes in guest throughput at high cpu-throttle percentage whenever cpu_throttle_set() is called. A solution would be not to modify the timer immediately in cpu_throttle_set(), instead, only modify throttle_percentage so that the throttle would automatically adjust to the required percentage when cpu_throttle_timer_tick() is invoked. Manually tested the patch using following configuration: Guest: Centos7 (3.10.0-123.el7.x86_64) Total Memory - 64GB , CPUs - 16 Tool used - stress (1.0.4) Workload - stress --vm 32 --vm-bytes 1G --vm-keep Migration Parameters: Network Bandwidth - 500MBPS cpu-throttle-initial - 99 Results: With timer_mod(): fails to converge, continues indefinitely Without timer_mod(): converges in 249 sec Signed-off-by: Utkarsh Tripathi <utkarsh.tripathi@nutanix.com> Message-Id: <1609420384-119407-1-git-send-email-utkarsh.tripathi@nutanix.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* replay: rng-builtin supportPavel Dovgalyuk2021-02-081-1/+2
| | | | | | | | | This patch enables using rng-builtin with record/replay by making the callbacks deterministic. Signed-off-by: Pavel Dovgalyuk <Pavel.Dovgalyuk@ispras.ru> Message-Id: <161233201286.170686.7858208964037376305.stgit@pasha-ThinkPad-X280> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* pc-bios/descriptors: fix paths in json filesSergei Trofimovich2021-02-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Before the change /usr/share/qemu/firmware/50-edk2-x86_64-secure.json contained the relative path: "filename": "share/qemu/edk2-x86_64-secure-code.fd", "filename": "share/qemu/edk2-i386-vars.fd", After then change the paths are absolute: "filename": "/usr/share/qemu/edk2-x86_64-secure-code.fd", "filename": "/usr/share/qemu/edk2-i386-vars.fd", The regression appeared in qemu-5.2.0 (seems to be related to meson port). CC: Paolo Bonzini <pbonzini@redhat.com> CC: "Marc-André Lureau" <marcandre.lureau@redhat.com> CC: "Philippe Mathieu-Daudé" <philmd@redhat.com> Bug: https://bugs.gentoo.org/766743 Bug: https://bugs.launchpad.net/qemu/+bug/1913012 Signed-off-by: Jannik Glückert <jannik.glueckert@gmail.com> Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> Message-Id: <20210131143434.2513363-1-slyfox@gentoo.org> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* replay: fix replay of the interruptsPavel Dovgalyuk2021-02-081-1/+7
| | | | | | | | | | | | | | | Sometimes interrupt event comes at the same time with the virtual timers. In this case replay tries to proceed the timers, because deadline for them is zero. This patch allows processing interrupts and exceptions by entering the vCPU execution loop, when deadline is zero, but checkpoint associated with virtual timers is not ready to be replayed. Signed-off-by: Pavel Dovgalyuk <Pavel.Dovgalyuk@ispras.ru> Message-Id: <161216312794.2030770.1709657858900983160.stgit@pasha-ThinkPad-X280> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* accel/kvm/kvm-all: Fix wrong return code handling in dirty log codeThomas Huth2021-02-081-9/+12
| | | | | | | | | | | | | | | | | | | The kvm_vm_ioctl() wrapper already returns -errno if the ioctl itself returned -1, so the callers of kvm_vm_ioctl() should not check for -1 but for a value < 0 instead. This problem has been fixed once already in commit b533f658a98325d0e4 but that commit missed that the ENOENT error code is not fatal for this ioctl, so the commit has been reverted in commit 50212d6346f33d6e since the problem occurred close to a pending release at that point in time. The plan was to fix it properly after the release, but it seems like this has been forgotten. So let's do it now finally instead. Resolves: https://bugs.launchpad.net/qemu/+bug/1294227 Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210129084354.42928-1-thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* qapi/meson: Restrict UI module to system emulation and toolsPhilippe Mathieu-Daudé2021-02-081-1/+5
| | | | | | | Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20210122204441.2145197-13-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* qapi/meson: Restrict system-mode specific modulesPhilippe Mathieu-Daudé2021-02-081-6/+6
| | | | | | | Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20210122204441.2145197-12-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* qapi/meson: Remove QMP from user-mode emulationPhilippe Mathieu-Daudé2021-02-082-4/+13
| | | | | | | Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20210122204441.2145197-11-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* qapi/meson: Restrict qdev code to system-mode emulationPhilippe Mathieu-Daudé2021-02-084-1/+31
| | | | | | | | | | | | Beside a CPU device, user-mode emulation doesn't access anything else from qdev subsystem. Tools don't need anything from qdev. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20210122204441.2145197-10-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* meson: Restrict emulation codePhilippe Mathieu-Daudé2021-02-081-5/+7
| | | | | | | Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20210122204441.2145197-9-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* meson: Restrict some trace event directories to user/system emulationPhilippe Mathieu-Daudé2021-02-081-12/+16
| | | | | | | Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20210122204441.2145197-8-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* meson: Merge trace_events_subdirs arrayPhilippe Mathieu-Daudé2021-02-081-15/+13Star
| | | | | | | | | | | The trace_events_subdirs array is split in two different locations, merge it as one. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Claudio Fontana <cfontana@suse.de> Message-Id: <20210122204441.2145197-7-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* meson: Restrict block subsystem processingPhilippe Mathieu-Daudé2021-02-081-23/+25
| | | | | | | | | | | Avoid generating module_block.h and block-gen.c if we are not going to use them. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20210122204441.2145197-6-philmd@redhat.com> [Extend to nearby files and directories. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* pc-bios/meson: Only install EDK2 blob firmwares with system emulationPhilippe Mathieu-Daudé2021-02-081-0/+1
| | | | | | | Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20210122204441.2145197-4-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* tests/meson: Only build softfloat objects if TCG is selectedPhilippe Mathieu-Daudé2021-02-081-1/+3
| | | | | | | | | Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20210122204441.2145197-3-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* meson: Warn when TCI is selected but TCG backend is availablePhilippe Mathieu-Daudé2021-02-081-0/+7
| | | | | | | | | | | | | | | Some new users get confused with 'TCG' and 'TCI', and enable TCI support expecting to enable TCG. Emit a warning when native TCG backend is available on the host architecture, mentioning this is a suboptimal configuration. Reviewed-by: Thomas Huth <thuth@redhat.com> Suggested-by: Daniel Berrangé <berrange@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210125144530.2837481-5-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* meson: Explicit TCG backend usedPhilippe Mathieu-Daudé2021-02-081-2/+6
| | | | | | | | | Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Stefan Weil <sw@weilnetz.de> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210125144530.2837481-4-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* configure: Improve TCI feature descriptionPhilippe Mathieu-Daudé2021-02-082-2/+2
| | | | | | | | | | | | Users might want to enable all features, without realizing some features have negative effect. Mention the TCI feature is slow and experimental, hoping it will be selected knowingly. Suggested-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210125144530.2837481-3-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* target/i86: implement PKSPaolo Bonzini2021-02-086-18/+64
| | | | | | | | | | | | | | | Protection Keys for Supervisor-mode pages is a simple extension of the PKU feature that QEMU already implements. For supervisor-mode pages, protection key restrictions come from a new MSR. The MSR has no XSAVE state associated to it. PKS is only respected in long mode. However, in principle it is possible to set the MSR even outside long mode, and in fact even the XSAVE state for PKRU could be set outside long mode using XRSTOR. So do not limit the migration subsections for PKRU and PKRS to long mode. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* target/i386: Fix decoding of certain BMI instructionsDavid Greenaway2021-02-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes a translation bug for a subset of x86 BMI instructions such as the following: c4 e2 f9 f7 c0 shlxq %rax, %rax, %rax Currently, these incorrectly generate an undefined instruction exception when SSE is disabled via CR4, while instructions like "shrxq" work fine. The problem appears to be related to BMI instructions encoded using VEX and with a mandatory prefix of "0x66" (data). Instructions with this data prefix (such as shlxq) are currently rejected. Instructions with other mandatory prefixes (such as shrxq) translate as expected. This patch removes the incorrect check in "gen_sse" that causes the exception to be generated. For the non-BMI cases, the check is redundant: prefixes are already checked at line 3696. Buglink: https://bugs.launchpad.net/qemu/+bug/1748296 Signed-off-by: David Greenaway <dgreenaway@google.com> Message-Id: <20210114063958.1508050-1-dgreenaway@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* event_notifier: handle initialization failure betterMaxim Levitsky2021-02-082-0/+17
| | | | | | | | | | | | Add 'initialized' field and use it to avoid touching event notifiers which are either not initialized or if their initialization failed. This is somewhat a hack, but it seems the less intrusive way to make virtio code deal with event notifiers that failed initialization. Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Message-Id: <20201217150040.906961-4-mlevitsk@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* virtio-scsi: don't uninitialize queues that we didn't initializeMaxim Levitsky2021-02-081-1/+7
| | | | | | | | | Count number of queues that we initialized and only deinitialize these that we initialized successfully. Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Message-Id: <20201217150040.906961-3-mlevitsk@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* docs: don't install corresponding man page if guest agent is disabledStefan Reiter2021-02-081-2/+4
| | | | | | | | | | No sense outputting the qemu-ga and qemu-ga-ref man pages when the guest agent binary itself is disabled. This mirrors behaviour from before the meson switch. Signed-off-by: Stefan Reiter <s.reiter@proxmox.com> Message-Id: <20210128145801.14384-1-s.reiter@proxmox.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* fuzz: fix wrong index in clear_bitsQiuhao Li2021-02-081-1/+1
| | | | | | Signed-off-by: Qiuhao Li <Qiuhao.Li@outlook.com> Message-Id: <SYCPR01MB3502E9F6EB06DEDCD484F738FCBA9@SYCPR01MB3502.ausprd01.prod.outlook.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* x86/cpu: Populate SVM CPUID feature bitsWei Huang2021-02-082-13/+17
| | | | | | | | | | | | | | Newer AMD CPUs will add CPUID_0x8000000A_EDX[28] bit, which indicates that SVM instructions (VMRUN/VMSAVE/VMLOAD) will trigger #VMEXIT before CPU checking their EAX against reserved memory regions. This change will allow the hypervisor to avoid intercepting #GP and emulating SVM instructions. KVM turns on this CPUID bit for nested VMs. In order to support it, let us populate this bit, along with other SVM feature bits, in FEAT_SVM. Signed-off-by: Wei Huang <wei.huang2@amd.com> Message-Id: <20210126202456.589932-1-wei.huang2@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* meson: honor --enable-rbd if cc.links test failsPaolo Bonzini2021-02-081-9/+15
| | | | | | | | If the link test failed, compilation proceeded with RBD disabled, even if --enable-rbd was used on the configure command line. Fix that. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* meson: accept either shared or static libraries if --disable-staticPaolo Bonzini2021-02-082-39/+42
| | | | | | | | | | | | | | | | | Meson's "static" argument to cc.find_library is a tri-state. By default Meson *prefers* a shared library, which basically means using -l to look for it; instead, "static: false" *requires* a shared library. Of course, "static: true" requires a static library, which is all good for --enable-static builds. For --disable-static, "static: false" is rarely desirable; it does not match what the configure script used to do and the test is more complex (and harder to debug if it fails, which was reported by Peter Lieven for librbd). Reported-by: Peter Lieven <pl@kamp.de> Tested-by: Peter Lieven <pl@kamp.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* machine: add missing doc for memory-backend optionIgor Mammedov2021-02-082-1/+35
| | | | | | | | | | | | | | | | | | Add documentation for '-machine memory-backend' CLI option and how to use it. And document that x-use-canonical-path-for-ramblock-id, is considered to be stable to make sure it won't go away by accident. x- was intended for unstable/iternal properties, and not supposed to be stable option. However it's too late to rename (drop x-) it as it would mean that users will have to mantain both x-use-canonical-path-for-ramblock-id (for QEMU 5.0-5.2) versions and prefix-less for later versions. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20210121161504.1007247-1-imammedo@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* target/i386: do not set LM for 32-bit emulation "-cpu host/max"Paolo Bonzini2021-02-081-0/+5
| | | | | | | | | | | | | | | | | | | 32-bit targets by definition do not support long mode; therefore, the bit must be masked in the features supported by the accelerator. As a side effect, this avoids setting up the 0x80000008 CPUID leaf for qemu-system-i386 -cpu host which since commit 5a140b255d ("x86/cpu: Use max host physical address if -cpu max option is applied") would have printed this error: qemu-system-i386: phys-bits should be between 32 and 36 (but is 48) Reported-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* fuzz: add virtio-9p configurations for fuzzingAlexander Bulekov2021-02-081-0/+20
| | | | | | | | | | | | | | | | virtio-9p devices are often used to expose a virtual-filesystem to the guest. There have been some bugs reported in this device, such as CVE-2018-19364, and CVE-2021-20181. We should fuzz this device This patch adds two virtio-9p configurations: * One with the widely used -fsdev local driver. This driver leaks some state in the form of files/directories created in the shared dir. * One with the synth driver. While it is not used in the real world, this driver won't leak leak state between fuzz inputs. Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Message-Id: <20210117230924.449676-4-alxndr@bu.edu>
* docs/fuzz: add some information about OSS-FuzzAlexander Bulekov2021-02-081-0/+30
| | | | | | Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Message-Id: <20210117230924.449676-3-alxndr@bu.edu>
* fuzz: enable dynamic args for generic-fuzz configsAlexander Bulekov2021-02-082-1/+10
| | | | | | | | | | | | | | | | For some device configurations, it is useful to configure some resources, and adjust QEMU arguments at runtime, prior to fuzzing. This patch adds an "argfunc" to generic the generic_fuzz_config. When specified, it is responsible for configuring the resources and returning a string containing the corresponding QEMU arguments. This can be useful for targets that rely on e.g.: * a temporary qcow2 image * a temporary directory * an unused TCP port used to bind the VNC server Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210117230924.449676-2-alxndr@bu.edu>
* fuzz: log the arguments used to initialize QEMUAlexander Bulekov2021-02-081-1/+10
| | | | | | | | | This is useful for building reproducers. Instead checking the code or the QEMU_FUZZ_ARGS, the arguments are at the top of the crash log. Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210117201014.271610-3-alxndr@bu.edu>
* docs/fuzz: fix pre-meson pathAlexander Bulekov2021-02-081-3/+2Star
| | | | | | Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20210117201014.271610-2-alxndr@bu.edu>
* fuzz: refine the ide/ahci fuzzer configsAlexander Bulekov2021-02-081-1/+19
| | | | | | | | | | | | | Disks work differently depending on the x86 machine type (SATA vs PATA). Additionally, we should fuzz the atapi code paths, which might contain vulnerabilities such as CVE-2020-29443. This patch adds hard-disk and cdrom generic-fuzzer configs for both the pc (PATA) and q35 (SATA) machine types. Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Acked-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Message-Id: <20210120152211.109782-1-alxndr@bu.edu>
* fuzz: ignore address_space_map is_write flagAlexander Bulekov2021-02-086-23/+17Star
| | | | | | | | | | | | | | | | | | | | | We passed an is_write flag to the fuzz_dma_read_cb function to differentiate between the mapped DMA regions that need to be populated with fuzzed data, and those that don't. We simply passed through the address_space_map is_write parameter. The goal was to cut down on unnecessarily populating mapped DMA regions, when they are not read from. Unfortunately, nothing precludes code from reading from regions mapped with is_write=true. For example, see: https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg04729.html This patch removes the is_write parameter to fuzz_dma_read_cb. As a result, we will fill all mapped DMA regions with fuzzed data, ignoring the specified transfer direction. Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Message-Id: <20210120060255.558535-1-alxndr@bu.edu>
* Merge remote-tracking branch 'remotes/dg-gitlab/tags/cgs-pull-request' into ↵Peter Maydell2021-02-0832-191/+595
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | staging Generalize memory encryption models A number of hardware platforms are implementing mechanisms whereby the hypervisor does not have unfettered access to guest memory, in order to mitigate the security impact of a compromised hypervisor. AMD's SEV implements this with in-cpu memory encryption, and Intel has its own memory encryption mechanism. POWER has an upcoming mechanism to accomplish this in a different way, using a new memory protection level plus a small trusted ultravisor. s390 also has a protected execution environment. The current code (committed or draft) for these features has each platform's version configured entirely differently. That doesn't seem ideal for users, or particularly for management layers. AMD SEV introduces a notionally generic machine option "machine-encryption", but it doesn't actually cover any cases other than SEV. This series is a proposal to at least partially unify configuration for these mechanisms, by renaming and generalizing AMD's "memory-encryption" property. It is replaced by a "confidential-guest-support" property pointing to a platform specific object which configures and manages the specific details. Note to Ram Pai: the documentation I've included for PEF is very minimal. If you could send a patch expanding on that, it would be very helpful. Changes since v8: * Rebase * Fixed some cosmetic typos Changes since v7: * Tweaked and clarified meaning of the 'ready' flag * Polished the interface to the PEF internals * Shifted initialization for s390 PV later (I hope I've finally got this after apply_cpu_model() where it needs to be) Changes since v6: * Moved to using OBJECT_DECLARE_TYPE and OBJECT_DEFINE_TYPE macros * Assorted minor fixes Changes since v5: * Renamed from "securable guest memory" to "confidential guest support" * Simpler reworking of x86 boot time flash encryption * Added a bunch of documentation * Fixed some compile errors on POWER Changes since v4: * Renamed from "host trust limitation" to "securable guest memory", which I think is marginally more descriptive * Re-organized initialization, because the previous model called at kvm_init didn't work for s390 * Assorted fixes to the s390 implementation; rudimentary testing (gitlab CI) only Changes since v3: * Rebased * Added first cut at handling of s390 protected virtualization Changes since RFCv2: * Rebased * Removed preliminary SEV cleanups (they've been merged) * Changed name to "host trust limitation" * Added migration blocker to the PEF code (based on SEV's version) Changes since RFCv1: * Rebased * Fixed some errors pointed out by Dave Gilbert # gpg: Signature made Mon 08 Feb 2021 06:07:27 GMT # 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/cgs-pull-request: s390: Recognize confidential-guest-support option confidential guest support: Alter virtio default properties for protected guests spapr: PEF: prevent migration spapr: Add PEF based confidential guest support confidential guest support: Update documentation confidential guest support: Move SEV initialization into arch specific code confidential guest support: Introduce cgs "ready" flag sev: Add Error ** to sev_kvm_init() confidential guest support: Rework the "memory-encryption" property confidential guest support: Move side effect out of machine_set_memory_encryption() sev: Remove false abstraction of flash encryption confidential guest support: Introduce new confidential guest support class qom: Allow optional sugar props Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * s390: Recognize confidential-guest-support optionDavid Gibson2021-02-085-6/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At least some s390 cpu models support "Protected Virtualization" (PV), a mechanism to protect guests from eavesdropping by a compromised hypervisor. This is similar in function to other mechanisms like AMD's SEV and POWER's PEF, which are controlled by the "confidential-guest-support" machine option. s390 is a slightly special case, because we already supported PV, simply by using a CPU model with the required feature (S390_FEAT_UNPACK). To integrate this with the option used by other platforms, we implement the following compromise: - When the confidential-guest-support option is set, s390 will recognize it, verify that the CPU can support PV (failing if not) and set virtio default options necessary for encrypted or protected guests, as on other platforms. i.e. if confidential-guest-support is set, we will either create a guest capable of entering PV mode, or fail outright. - If confidential-guest-support is not set, guests might still be able to enter PV mode, if the CPU has the right model. This may be a little surprising, but shouldn't actually be harmful. To start a guest supporting Protected Virtualization using the new option use the command line arguments: -object s390-pv-guest,id=pv0 -machine confidential-guest-support=pv0 Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
| * confidential guest support: Alter virtio default properties for protected guestsDavid Gibson2021-02-081-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The default behaviour for virtio devices is not to use the platforms normal DMA paths, but instead to use the fact that it's running in a hypervisor to directly access guest memory. That doesn't work if the guest's memory is protected from hypervisor access, such as with AMD's SEV or POWER's PEF. So, if a confidential guest mechanism is enabled, then apply the iommu_platform=on option so it will go through normal DMA mechanisms. Those will presumably have some way of marking memory as shared with the hypervisor or hardware so that DMA will work. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org>
| * spapr: PEF: prevent migrationDavid Gibson2021-02-081-0/+7
| | | | | | | | | | | | | | | | | | | | | | We haven't yet implemented the fairly involved handshaking that will be needed to migrate PEF protected guests. For now, just use a migration blocker so we get a meaningful error if someone attempts this (this is the same approach used by AMD SEV). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org>
| * spapr: Add PEF based confidential guest supportDavid Gibson2021-02-088-25/+191
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some upcoming POWER machines have a system called PEF (Protected Execution Facility) which uses a small ultravisor to allow guests to run in a way that they can't be eavesdropped by the hypervisor. The effect is roughly similar to AMD SEV, although the mechanisms are quite different. Most of the work of this is done between the guest, KVM and the ultravisor, with little need for involvement by qemu. However qemu does need to tell KVM to allow secure VMs. Because the availability of secure mode is a guest visible difference which depends on having the right hardware and firmware, we don't enable this by default. In order to run a secure guest you need to create a "pef-guest" object and set the confidential-guest-support property to point to it. Note that this just *allows* secure guests, the architecture of PEF is such that the guest still needs to talk to the ultravisor to enter secure mode. Qemu has no direct way of knowing if the guest is in secure mode, and certainly can't know until well after machine creation time. To start a PEF-capable guest, use the command line options: -object pef-guest,id=pef0 -machine confidential-guest-support=pef0 Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org>
| * confidential guest support: Update documentationDavid Gibson2021-02-082-1/+44
| | | | | | | | | | | | | | | | | | | | | | | | Now that we've implemented a generic machine option for configuring various confidential guest support mechanisms: 1. Update docs/amd-memory-encryption.txt to reference this rather than the earlier SEV specific option 2. Add a docs/confidential-guest-support.txt to cover the generalities of the confidential guest support scheme Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org>
| * confidential guest support: Move SEV initialization into arch specific codeDavid Gibson2021-02-084-17/+28
| | | | | | | | | | | | | | | | | | | | | | While we've abstracted some (potential) differences between mechanisms for securing guest memory, the initialization is still specific to SEV. Given that, move it into x86's kvm_arch_init() code, rather than the generic kvm_init() code. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-12-22 14:48:29 +0100