Nitro Enclaves are a confidential compute technology which
allows a parent instance to carve out resources from itself
and spawn a confidential sibling VM next to itself. Similar
to other confidential compute solutions, this sibling is
controlled by an underlying vmm, but still has a higher level
vmm (QEMU) to implement some of its I/O functionality and
lifecycle.
Add an accelerator to drive this interface. In combination with
follow-on patches to enhance the Nitro Enclaves machine model, this
will allow users to run a Nitro Enclave using QEMU.
Signed-off-by: Alexander Graf <graf@amazon.com>
Link: https://lore.kernel.org/r/20260225220807.33092-5-graf@amazon.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add a dedicated bus for Nitro Enclave vsock devices. In Nitro Enclaves,
communication between parent and enclave/hypervisor happens almost
exclusively through vsock. The nitro-vsock-bus models this dependency
in QEMU, which allows devices in this bus to implement individual services
on top of vsock.
The nitro machine spawns this bus by creating the included
nitro-vsock-bridge sysbus device.
The nitro accel then advertises the Enclave's CID to the bus by calling
nitro_vsock_bridge_start_enclave() on the bridge device as soon as it
knows the CID.
Nitro vsock devices can listen to that event and learn the Enclave's CID
when it is available to perform actions, such as connect to the debug
serial vsock port.
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Alexander Graf <graf@amazon.com>
Link: https://lore.kernel.org/r/20260225220807.33092-4-graf@amazon.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The kvm_get_vcpu_events propogates the state of the pending smi
from the kernel to the cpu->interrupt_request, with the intention
of having un up to date migration state.
Later the opposite is done, the kvm_put_vcpu_events restores the state
of the pending #SMI from the 'cs->interrupt_request'
The only problem is that kvm_get_vcpu_events also resets the SMI
in cpu->interrupt_request when there is no pending #SMI indicated by the kernel,
and that is wrong as the SMI might be still raised by qemu.
While at it, also fix a similar but more theoretical bug with regard to a
latched #INIT while in SMM.
A simple reproducer for this bug is to read an EFI variable in a loop
from within a guest, while at the same time run 'info registers' on
the qemu HMP monitor.
The reads will, once in a while, fail with an 'Invalid argument' error.
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20260223221908.361456-1-mlevitsk@redhat.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
target/i386/emulate doesn't currently properly emulate instructions
which might cause a page fault during their execution. Notably, REP STOS/MOVS
from MMIO to an address which is unmapped until a page fault exception is raised
causes an abort() in vmx_write_mem.
Change the interface between the HW accel backend and target/i386/emulate as a first step towards addressing that.
Adapt the page table walker code to give actionable errors,
while leaving a possibility for backends to provide their own walker.
This removes the usage of the Hyper-V page walker in the mshv backend.
Signed-off-by: Mohamed Mediouni <mohamed@unpredictable.fr>
Link: https://lore.kernel.org/r/20260223233950.96076-20-mohamed@unpredictable.fr
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Compared to decode_instruction(), decode_instruction_stream() has an additional
stream parameter which avoids some guest memory accesses during instruction
decoding. Both functions defer the actual work to decode_opcode() which would
set the stream pointer to zero such that decode_instruction_stream() essentially
behaved like decode_instruction(). Given that all callers of
decode_instruction_stream() properly zero-initialize the decode parameter, the
memset() call can be moved into decode_instruction() which is the only other
user of decode_opcode(). This preserves the non-zero stream pointer which
avoids extra guest memory accesses.
Fixes: 1e25327b24 ("target/i386/emulate: Allow instruction decoding from stream")
cc: qemu-stable
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Reviewed-by: Mohamed Mediouni <mohamed@unpredictable.fr>
Reviewed-by: Wei Liu (Microsoft) <wei.liu@kernel.org>
Tested-by: Magnus Kulke <magnuskulke@linux.microsoft.com>
Link: https://lore.kernel.org/r/20260223233950.96076-4-mohamed@unpredictable.fr
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
When reusing the code in WHPX, GCC emits the following warning when compiling
for i386-softmmu under MSYS2:
In file included from ../src/target/i386/emulate/x86_mmu.c:20:
../src/target/i386/emulate/x86_mmu.c: In function 'vmx_write_mem':
../src/target/i386/emulate/x86_mmu.c:251:25: error: format '%llx' expects argument of type 'long long unsigned int', but argument 3 has type 'target_ulong' {aka 'unsigned int'} [-Werror=format=]
251 | VM_PANIC_EX("%s: mmu_gva_to_gpa %llx failed\n", __func__, gva);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~
| |
| target_ulong {aka unsigned int}
../src/target/i386/emulate/panic.h:34:12: note: in definition of macro 'VM_PANIC_EX'
34 | printf(__VA_ARGS__); \
| ^~~~~~~~~~~
../src/target/i386/emulate/x86_mmu.c:251:48: note: format string is defined here
251 | VM_PANIC_EX("%s: mmu_gva_to_gpa %llx failed\n", __func__, gva);
| ~~~^
| |
| long long unsigned int
| %x
Fix the warning by reusing the target-specific macro TARGET_FMT_lx which exists
for this exact purpose.
Fixes: c97d6d2cdf ("i386: hvf: add code base from Google's QEMU repository")
cc: qemu-stable
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Reviewed-by: Mohamed Mediouni <mohamed@unpredictable.fr>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Wei Liu (Microsoft) <wei.liu@kernel.org>
Link: https://lore.kernel.org/r/20260223233950.96076-3-mohamed@unpredictable.fr
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
When compiling for i386-softmmu under MSYS2, GCC emits the following warning:
In function 'get_reg_val',
inlined from 'calc_modrm_operand64' at ../src/target/i386/emulate/x86_decode.c:1796:15:
../src/target/i386/emulate/x86_decode.c:1703:5: error: 'memcpy' forming offset [4, 7] is out of the bounds [0, 4] of object 'val' with type 'target_ulong' {aka 'unsigned int'} [-Werror=array-bounds=]
1703 | memcpy(&val,
| ^~~~~~~~~~~~
1704 | get_reg_ref(env, reg, rex_present, is_extended, size),
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1705 | size);
| ~~~~~
../src/target/i386/emulate/x86_decode.c: In function 'calc_modrm_operand64':
../src/target/i386/emulate/x86_decode.c:1702:18: note: 'val' declared here
1702 | target_ulong val = 0;
| ^~~
In the calc_modrm_operand64() case the compiler sees size == 8 to be mem-copied
to a target_ulong variable which is only 4 bytes wide in case of i386-softmmu.
Note that when size != 1, get_reg_ref() always returns a pointer to an 8 byte
register, regardless of the target_ulong size. Fix the compiler warning by
always providing 8 bytes of storage by means of uint64_t.
Fixes: 77a2dba45c ("target/i386/emulate: stop overloading decode->op[N].ptr")
cc: qemu-stable
Signed-off-by: Bernhard Beschow <shentey@gmail.com>
Reviewed-by: Mohamed Mediouni <mohamed@unpredictable.fr>
Reviewed-by: Wei Liu (Microsoft) <wei.liu@kernel.org>
Link: https://lore.kernel.org/r/20260223233950.96076-2-mohamed@unpredictable.fr
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The environment we do our coverity build in (amd64-fedora-container)
has just upgraded to Fedora 43. This ships with libnfs version
16.2.0. We can't currently build against that: in commit
e2d98f2571 we added a requirement to meson.build that libnfs be <
6.0.0, because of an upstream API change that we haven't yet updated
block/nfs.c to handle.
The result is that the coverity CI job currently fails in
configure:
Dependency libnfs found: NO. Found 16.2.0 but need: '<6.0.0' ;
matched: '>=1.9.3'
Run-time dependency libnfs found: NO
../meson.build:1150:11: ERROR: Dependency lookup for libnfs with
method 'pkgconfig' failed: Invalid version, need 'libnfs' ['<6.0.0']
found '16.2.0'.
Fix the coverity builds by dropping --enable-libnfs. This means we
will no longer have coverage of block/nfs.c until/unless we do
that update to handle the new libnfs API.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-id: 20260226111001.1021810-1-peter.maydell@linaro.org
We actually do not allow our meson requirements to be fetched online
because we strictly prefer the vendored version. Move the tooling group
installation to a different invocation that does allow PyPI to be
accessed when configure is run without explicitly disabling PyPI access.
This will allow QEMU to download and install python3-wheel for you if
you don't have it in your host environment.
Reported-by: Kevin Wolf <kwolf@redhat.com>
Reported-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Tested-by: Thomas Huth <thuth@redhat.com>
Message-id: 20260225191255.955585-1-jsnow@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
We log a GUEST_ERROR message "PL011 data written to disabled UART" if
the guest writes data to the TX FIFO when it has not set the enable
bit in the UART. The idea is to note that the guest has done
something dubious but let it work anyway. However, since we print
this message for every output character, it floods the logs when
running a guest that does this.
Keep a note of whether we've printed the log message or not, so we
only output it once. If the guest actively disables the UART, we
re-arm the log message.
Notably, the Linux kernel does not bother to enable the UART if it is
used for earlycon, relying on the firmware having already done that.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Mohamed Mediouni <mohamed@unpredictable.fr>
Message-id: 20260210101702.3980804-1-peter.maydell@linaro.org
The migrate_add_blocker() function documents that if it fails it will
free the Error it is passed via its reasonp argument and set reasonp
to NULL. That means that in kvm_arm_enable_mte() we don't need to
call error_free(mte_migration_blocker) in the failure codepath.
Doing so is harmless because error_free(NULL) is permitted and does
nothing, but we can remove the unnecessary code.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Message-id: 20260223173232.453165-1-peter.maydell@linaro.org
Introduce a set of stub property callbacks for when we really
don't want to be able to enable SVE. Register the real or stub
funtions in aarch64_add_sve_properties depending on whether or
not SVE is available.
Adjust aarch64_a64fx_initfn to initialize the set of supported
vector sizes before calling aarch64_add_sve_properties.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20260216034432.23912-6-richard.henderson@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
