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>
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>
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>
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>
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>
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>
Utkarsh Tripathi [Thu, 31 Dec 2020 13:13:04 +0000 (13:13 +0000)]
cpu-throttle: Remove timer_mod() from cpu_throttle_set()
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:
Pavel Dovgalyuk [Wed, 3 Feb 2021 06:00:12 +0000 (09:00 +0300)]
replay: rng-builtin support
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>
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).
Pavel Dovgalyuk [Mon, 1 Feb 2021 07:05:27 +0000 (10:05 +0300)]
replay: fix replay of the interrupts
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>
Thomas Huth [Fri, 29 Jan 2021 08:43:54 +0000 (09:43 +0100)]
accel/kvm/kvm-all: Fix wrong return code handling in dirty log code
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 tools
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>
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>
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 emulation
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>
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 emulation
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>
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 emulation
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 selected
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 available
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>
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>
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>
Paolo Bonzini [Wed, 27 Jan 2021 08:28:49 +0000 (09:28 +0100)]
target/i86: implement PKS
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>
David Greenaway [Thu, 14 Jan 2021 06:39:58 +0000 (17:39 +1100)]
target/i386: Fix decoding of certain BMI instructions
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.
Stefan Reiter [Thu, 28 Jan 2021 14:58:01 +0000 (15:58 +0100)]
docs: don't install corresponding man page if guest agent is disabled
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>
Qiuhao Li [Thu, 28 Jan 2021 03:59:28 +0000 (11:59 +0800)]
fuzz: fix wrong index in clear_bits
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>
Wei Huang [Tue, 26 Jan 2021 20:24:56 +0000 (14:24 -0600)]
x86/cpu: Populate SVM CPUID feature bits
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>
Paolo Bonzini [Tue, 26 Jan 2021 10:15:33 +0000 (11:15 +0100)]
meson: accept either shared or static libraries if --disable-static
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>
Igor Mammedov [Thu, 21 Jan 2021 16:15:04 +0000 (11:15 -0500)]
machine: add missing doc for memory-backend option
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>
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>
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 configs
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>
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>
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>
Peter Maydell [Mon, 8 Feb 2021 11:11:26 +0000 (11:11 +0000)]
Merge remote-tracking branch 'remotes/dg-gitlab/tags/cgs-pull-request' into 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
David Gibson [Thu, 23 Jul 2020 04:36:45 +0000 (14:36 +1000)]
s390: Recognize confidential-guest-support option
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>
David Gibson [Thu, 4 Jun 2020 04:20:24 +0000 (14:20 +1000)]
confidential guest support: Alter virtio default properties for protected guests
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>
David Gibson [Thu, 4 Jun 2020 05:24:27 +0000 (15:24 +1000)]
spapr: PEF: prevent migration
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>
David Gibson [Wed, 8 Apr 2020 05:10:03 +0000 (15:10 +1000)]
spapr: Add PEF based confidential guest support
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>
David Gibson [Fri, 8 Jan 2021 02:23:09 +0000 (13:23 +1100)]
confidential guest support: Update documentation
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>
David Gibson [Fri, 16 Oct 2020 03:52:30 +0000 (14:52 +1100)]
confidential guest support: Move SEV initialization into arch specific code
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>
David Gibson [Tue, 20 Oct 2020 06:01:19 +0000 (17:01 +1100)]
confidential guest support: Introduce cgs "ready" flag
The platform specific details of mechanisms for implementing
confidential guest support may require setup at various points during
initialization. Thus, it's not really feasible to have a single cgs
initialization hook, but instead each mechanism needs its own
initialization calls in arch or machine specific code.
However, to make it harder to have a bug where a mechanism isn't
properly initialized under some circumstances, we want to have a
common place, late in boot, where we verify that cgs has been
initialized if it was requested.
This patch introduces a ready flag to the ConfidentialGuestSupport
base type to accomplish this, which we verify in
qemu_machine_creation_done().
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>
David Gibson [Fri, 4 Dec 2020 01:51:51 +0000 (12:51 +1100)]
confidential guest support: Rework the "memory-encryption" property
Currently the "memory-encryption" property is only looked at once we
get to kvm_init(). Although protection of guest memory from the
hypervisor isn't something that could really ever work with TCG, it's
not conceptually tied to the KVM accelerator.
In addition, the way the string property is resolved to an object is
almost identical to how a QOM link property is handled.
So, create a new "confidential-guest-support" link property which sets
this QOM interface link directly in the machine. For compatibility we
keep the "memory-encryption" property, but now implemented in terms of
the new property.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
David Gibson [Fri, 24 Jul 2020 02:57:37 +0000 (12:57 +1000)]
confidential guest support: Move side effect out of machine_set_memory_encryption()
When the "memory-encryption" property is set, we also disable KSM
merging for the guest, since it won't accomplish anything.
We want that, but doing it in the property set function itself is
thereoretically incorrect, in the unlikely event of some configuration
environment that set the property then cleared it again before
constructing the guest.
More importantly, it makes some other cleanups we want more difficult.
So, instead move this logic to machine_run_board_init() conditional on
the final value of the property.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
David Gibson [Tue, 12 Jan 2021 00:58:04 +0000 (11:58 +1100)]
sev: Remove false abstraction of flash encryption
When AMD's SEV memory encryption is in use, flash memory banks (which are
initialed by pc_system_flash_map()) need to be encrypted with the guest's
key, so that the guest can read them.
That's abstracted via the kvm_memcrypt_encrypt_data() callback in the KVM
state.. except, that it doesn't really abstract much at all.
For starters, the only call site is in code specific to the 'pc'
family of machine types, so it's obviously specific to those and to
x86 to begin with. But it makes a bunch of further assumptions that
need not be true about an arbitrary confidential guest system based on
memory encryption, let alone one based on other mechanisms:
* it assumes that the flash memory is defined to be encrypted with the
guest key, rather than being shared with hypervisor
* it assumes that that hypervisor has some mechanism to encrypt data into
the guest, even though it can't decrypt it out, since that's the whole
point
* the interface assumes that this encrypt can be done in place, which
implies that the hypervisor can write into a confidential guests's
memory, even if what it writes isn't meaningful
So really, this "abstraction" is actually pretty specific to the way SEV
works. So, this patch removes it and instead has the PC flash
initialization code call into a SEV specific callback.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
David Gibson [Tue, 5 May 2020 07:00:30 +0000 (17:00 +1000)]
confidential guest support: Introduce new confidential guest support class
Several architectures have mechanisms which are designed to protect
guest memory from interference or eavesdropping by a compromised
hypervisor. AMD SEV does this with in-chip memory encryption and
Intel's TDX can do similar things. POWER's Protected Execution
Framework (PEF) accomplishes a similar goal using an ultravisor and
new memory protection features, instead of encryption.
To (partially) unify handling for these, this introduces a new
ConfidentialGuestSupport QOM base class. "Confidential" is kind of vague,
but "confidential computing" seems to be the buzzword about these schemes,
and "secure" or "protected" are often used in connection to unrelated
things (such as hypervisor-from-guest or guest-from-guest security).
The "support" in the name is significant because in at least some of the
cases it requires the guest to take specific actions in order to protect
itself from hypervisor eavesdropping.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Greg Kurz [Fri, 14 Aug 2020 07:24:50 +0000 (09:24 +0200)]
qom: Allow optional sugar props
Global properties have an @optional field, which allows to apply a given
property to a given type even if one of its subclasses doesn't support
it. This is especially used in the compat code when dealing with the
"disable-modern" and "disable-legacy" properties and the "virtio-pci"
type.
Allow object_register_sugar_prop() to set this field as well.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <159738953558.377274.16617742952571083440.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Mark Cave-Ayland [Thu, 28 Jan 2021 22:17:28 +0000 (22:17 +0000)]
utils/fifo8: add VMSTATE_FIFO8_TEST macro
Rewrite the existing VMSTATE_FIFO8 macro to use VMSTATE_FIFO8_TEST as per the
standard pattern in include/migration/vmstate.h.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210128221728.14887-3-mark.cave-ayland@ilande.co.uk>
Mark Cave-Ayland [Thu, 28 Jan 2021 22:17:27 +0000 (22:17 +0000)]
utils/fifo8: change fatal errors from abort() to assert()
Developer errors are better represented with assert() rather than abort(). Also
improve the strictness of the checks by using range checks within the assert()
rather than converting the existing equality checks to inequality checks.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Claudio Fontana <cfontana@suse.de> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210121102518.20112-1-mark.cave-ayland@ilande.co.uk>
# gpg: Signature made Fri 05 Feb 2021 22:55:10 GMT
# gpg: using RSA key 7A481E78868B4DB6A85A05C064DF38E8AF7E215F
# gpg: issuer "richard.henderson@linaro.org"
# gpg: Good signature from "Richard Henderson <richard.henderson@linaro.org>" [full]
# Primary key fingerprint: 7A48 1E78 868B 4DB6 A85A 05C0 64DF 38E8 AF7E 215F
* remotes/rth-gitlab/tags/pull-tcg-20210205: (46 commits)
accel: introduce AccelCPUClass extending CPUClass
accel: replace struct CpusAccel with AccelOpsClass
accel: extend AccelState and AccelClass to user-mode
cpu: tcg_ops: move to tcg-cpu-ops.h, keep a pointer in CPUClass
cpu: move debug_check_watchpoint to tcg_ops
cpu: move adjust_watchpoint_address to tcg_ops
physmem: make watchpoint checking code TCG-only
cpu: move do_unaligned_access to tcg_ops
cpu: move cc->transaction_failed to tcg_ops
cpu: move cc->do_interrupt to tcg_ops
target/arm: do not use cc->do_interrupt for KVM directly
cpu: Move debug_excp_handler to tcg_ops
cpu: Move tlb_fill to tcg_ops
cpu: Move cpu_exec_* to tcg_ops
cpu: Move synchronize_from_tb() to tcg_ops
accel/tcg: split TCG-only code from cpu_exec_realizefn
target/riscv: remove CONFIG_TCG, as it is always TCG
cpu: Introduce TCGCpuOperations struct
tcg/tci: Remove TCG_CONST
tcg/tci: Fix TCG_REG_R4 misusage
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Claudio Fontana [Thu, 4 Feb 2021 16:39:26 +0000 (17:39 +0100)]
accel: introduce AccelCPUClass extending CPUClass
add a new optional interface to CPUClass, which allows accelerators
to extend the CPUClass with additional accelerator-specific
initializations.
This will allow to separate the target cpu code that is specific
to each accelerator, and register it automatically with object
hierarchy lookup depending on accelerator code availability,
as part of the accel_init_interfaces() initialization step.
Signed-off-by: Claudio Fontana <cfontana@suse.de>
Message-Id: <20210204163931.7358-19-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Claudio Fontana [Thu, 4 Feb 2021 16:39:25 +0000 (17:39 +0100)]
accel: replace struct CpusAccel with AccelOpsClass
This will allow us to centralize the registration of
the cpus.c module accelerator operations (in accel/accel-softmmu.c),
and trigger it automatically using object hierarchy lookup from the
new accel_init_interfaces() initialization step, depending just on
which accelerators are available in the code.
Rename all tcg-cpus.c, kvm-cpus.c, etc to tcg-accel-ops.c,
kvm-accel-ops.c, etc, matching the object type names.
Signed-off-by: Claudio Fontana <cfontana@suse.de>
Message-Id: <20210204163931.7358-18-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Claudio Fontana [Thu, 4 Feb 2021 16:39:23 +0000 (17:39 +0100)]
cpu: tcg_ops: move to tcg-cpu-ops.h, keep a pointer in CPUClass
we cannot in principle make the TCG Operations field definitions
conditional on CONFIG_TCG in code that is included by both common_ss
and specific_ss modules.
Therefore, what we can do safely to restrict the TCG fields to TCG-only
builds, is to move all tcg cpu operations into a separate header file,
which is only included by TCG, target-specific code.
This leaves just a NULL pointer in the cpu.h for the non-TCG builds.
This also tidies up the code in all targets a bit, having all TCG cpu
operations neatly contained by a dedicated data struct.
Signed-off-by: Claudio Fontana <cfontana@suse.de>
Message-Id: <20210204163931.7358-16-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Claudio Fontana [Thu, 4 Feb 2021 16:39:22 +0000 (17:39 +0100)]
cpu: move debug_check_watchpoint to tcg_ops
commit 568496c0c0f1 ("cpu: Add callback to check architectural") and
commit 3826121d9298 ("target-arm: Implement checking of fired")
introduced an ARM-specific hack for cpu_check_watchpoint.
Make debug_check_watchpoint optional, and move it to tcg_ops.
Signed-off-by: Claudio Fontana <cfontana@suse.de> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20210204163931.7358-15-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Claudio Fontana [Thu, 4 Feb 2021 16:39:19 +0000 (17:39 +0100)]
cpu: move do_unaligned_access to tcg_ops
make it consistently SOFTMMU-only.
Signed-off-by: Claudio Fontana <cfontana@suse.de> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
[claudio: make the field presence in cpu.h unconditional, removing the ifdefs]
Message-Id: <20210204163931.7358-12-cfontana@suse.de>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Claudio Fontana [Thu, 4 Feb 2021 16:39:18 +0000 (17:39 +0100)]
cpu: move cc->transaction_failed to tcg_ops
Signed-off-by: Claudio Fontana <cfontana@suse.de> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
[claudio: wrap target code around CONFIG_TCG and !CONFIG_USER_ONLY]
avoiding its use in headers used by common_ss code (should be poisoned).
Note: need to be careful with the use of CONFIG_USER_ONLY,
Message-Id: <20210204163931.7358-11-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Claudio Fontana [Thu, 4 Feb 2021 16:39:16 +0000 (17:39 +0100)]
target/arm: do not use cc->do_interrupt for KVM directly
cc->do_interrupt is in theory a TCG callback used in accel/tcg only,
to prepare the emulated architecture to take an interrupt as defined
in the hardware specifications,
but in reality the _do_interrupt style of functions in targets are
also occasionally reused by KVM to prepare the architecture state in a
similar way where userspace code has identified that it needs to
deliver an exception to the guest.
In the case of ARM, that includes:
1) the vcpu thread got a SIGBUS indicating a memory error,
and we need to deliver a Synchronous External Abort to the guest to
let it know about the error.
2) the kernel told us about a debug exception (breakpoint, watchpoint)
but it is not for one of QEMU's own gdbstub breakpoints/watchpoints
so it must be a breakpoint the guest itself has set up, therefore
we need to deliver it to the guest.
So in order to reuse code, the same arm_do_interrupt function is used.
This is all fine, but we need to avoid calling it using the callback
registered in CPUClass, since that one is now TCG-only.
Fortunately this is easily solved by replacing calls to
CPUClass::do_interrupt() with explicit calls to arm_do_interrupt().
Signed-off-by: Claudio Fontana <cfontana@suse.de> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Cc: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20210204163931.7358-9-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Claudio Fontana [Thu, 4 Feb 2021 16:39:11 +0000 (17:39 +0100)]
accel/tcg: split TCG-only code from cpu_exec_realizefn
move away TCG-only code, make it compile only on TCG.
Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
[claudio: moved the prototypes from hw/core/cpu.h to exec/cpu-all.h] Signed-off-by: Claudio Fontana <cfontana@suse.de>
Message-Id: <20210204163931.7358-4-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Eduardo Habkost [Thu, 4 Feb 2021 16:39:09 +0000 (17:39 +0100)]
cpu: Introduce TCGCpuOperations struct
The TCG-specific CPU methods will be moved to a separate struct,
to make it easier to move accel-specific code outside generic CPU
code in the future. Start by moving tcg_initialize().
The new CPUClass.tcg_opts field may eventually become a pointer,
but keep it an embedded struct for now, to make code conversion
easier.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
[claudio: move TCGCpuOperations inside include/hw/core/cpu.h] Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20210204163931.7358-2-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Restrict all operands to registers. All constants will be forced
into registers by the middle-end. Removing the difference in how
immediate integers were encoded will allow more code to be shared
between 32-bit and 64-bit operations.
Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
This was removed from tcg_target_reg_alloc_order and
tcg_target_call_iarg_regs on the assumption that it
was the stack. This was incorrectly copied from i386.
For tci, the stack is R15.
By adding R4 back to tcg_target_call_iarg_regs, adjust the other
entries so that 6 (or 12) entries are still present in the array,
and adjust the numbers in the interpreter.
Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
As noted in several comments, 8 regs is not enough for 32-bit
to perform calls, as currently implemented. Shortly, we will
rearrange the encoding which will make 32 regs impossible.
Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Trivially implemented like other arithmetic.
Tested via check-tcg and the ppc64 target.
Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
tcg/tci: Remove dead code for TCG_TARGET_HAS_div2_*
We do not simultaneously support div and div2 -- it's one
or the other. TCI is already using div, so remove div2.
Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Three TODO instances are never happen cases.
Other uses of tcg_abort are also indicating unreachable cases.
Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Stefan Weil <sw@weilnetz.de> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
The existing check was incomplete:
(1) Only applied to two of the 7 stores, and not to the loads at all.
(2) Only checked the upper, but not the lower bound of the stack.
Doing this at compile time means that we don't need to do it
at runtime as well.
Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
tcg/tci: Inline tci_write_reg64 into 64-bit callers
Note that we had two functions of the same name: a 32-bit version
which took two register numbers and a 64-bit version which was a
no-op wrapper for tcg_write_reg. After this, we are left with
only the 32-bit version.
Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
For a 64-bit TCI, the upper bits of a 32-bit operation are
undefined (much like a native ppc64 32-bit operation). It
simplifies everything if we don't force-extend the result.
Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
tcg/tci: Inline tci_write_reg16 into the only caller
Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
projects / mirror_qemu.git / log