- May 04, 2021
-
-
Reinoud Zandijk authored
Signed-off-by:
Kamil Rytarowski <kamil@NetBSD.org> Signed-off-by:
Reinoud Zandijk <reinoud@NetBSD.org> Message-Id: <20210402202535.11550-2-reinoud@NetBSD.org> [Check for nvmm_vcpu_stop. - Paolo] Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- May 02, 2021
-
-
Thomas Huth authored
Stop including exec/address-spaces.h in files that don't need it. Signed-off-by:
Thomas Huth <thuth@redhat.com> Message-Id: <20210416171314.2074665-5-thuth@redhat.com> Signed-off-by:
Laurent Vivier <laurent@vivier.eu>
-
Thomas Huth authored
Stop including cpu.h in files that don't need it. Signed-off-by:
Thomas Huth <thuth@redhat.com> Message-Id: <20210416171314.2074665-4-thuth@redhat.com> Signed-off-by:
Laurent Vivier <laurent@vivier.eu>
-
Thomas Huth authored
Stop including hw/boards.h in files that don't need it. Signed-off-by:
Thomas Huth <thuth@redhat.com> Message-Id: <20210416171314.2074665-3-thuth@redhat.com> Signed-off-by:
Laurent Vivier <laurent@vivier.eu>
-
Thomas Huth authored
Stop including sysemu/sysemu.h in files that don't need it. Signed-off-by:
Thomas Huth <thuth@redhat.com> Message-Id: <20210416171314.2074665-2-thuth@redhat.com> Signed-off-by:
Laurent Vivier <laurent@vivier.eu>
-
David Edmondson authored
When dumping the extra exit data provided by KVM, make it clear that the data is hexadecimal. At the same time, zero-pad the output. Signed-off-by:
David Edmondson <david.edmondson@oracle.com> Reviewed-by:
Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210428142431.266879-1-david.edmondson@oracle.com> Signed-off-by:
Laurent Vivier <laurent@vivier.eu>
-
- Apr 17, 2021
-
-
Alex Bennée authored
By definition a single instruction is capable of being an IO instruction. This avoids a problem of triggering a cpu_io_recompile on a non-recorded translation which then fails because it expects tcg_tb_lookup() to succeed unconditionally. The normal use case requires a TB to be able to resolve machine state. The other users of tcg_tb_lookup() are able to tolerate a missing TB if the machine state has been resolved by other means - which in the single-shot case is always true because machine state is synced at the start of a block. Reported-by:
Peter Maydell <peter.maydell@linaro.org> Signed-off-by:
Alex Bennée <alex.bennee@linaro.org> Reviewed-by:
Peter Maydell <peter.maydell@linaro.org> Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Message-id: 20210415162454.22056-1-alex.bennee@linaro.org Signed-off-by:
Peter Maydell <peter.maydell@linaro.org>
-
- Apr 12, 2021
-
-
Richard Henderson authored
Using mprotect() to change PROT_* does not change the MAP_ANON previously set with mmap(). Our linux-user version of MTE only works with MAP_ANON pages, so losing PAGE_ANON caused MTE to stop working. Reported-by:
Stephen Long <steplong@quicinc.com> Signed-off-by:
Richard Henderson <richard.henderson@linaro.org> Reviewed-by:
Alex Bennée <alex.bennee@linaro.org> Tested-by:
Alex Bennée <alex.bennee@linaro.org> Signed-off-by:
Peter Maydell <peter.maydell@linaro.org>
-
- Mar 16, 2021
-
-
Paolo Bonzini authored
This reverts commit 39205528. Thomas Huth reported a failure with CentOS 6 guests: ../../devel/qemu/accel/kvm/kvm-all.c:690: kvm_log_clear_one_slot: Assertion `QEMU_IS_ALIGNED(start | size, psize)' failed. Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Mar 12, 2021
-
-
Andrew Jones authored
Prior to commit f2ce39b4 a MachineClass kvm_type method only needed to be registered to ensure it would be executed. With commit f2ce39b4 a kvm-type machine property must also be specified. hw/arm/virt relies on the kvm_type method to pass its selected IPA limit to KVM, but this is not exposed as a machine property. Restore the previous functionality of invoking kvm_type when it's present. Fixes: f2ce39b4 ("vl: make qemu_get_machine_opts static") Signed-off-by:
Andrew Jones <drjones@redhat.com> Reviewed-by:
Eric Auger <eric.auger@redhat.com> Message-id: 20210310135218.255205-2-drjones@redhat.com Signed-off-by:
Peter Maydell <peter.maydell@linaro.org>
-
- Mar 09, 2021
-
-
Philippe Mathieu-Daudé authored
The 'running' argument from VMChangeStateHandler does not require other value than 0 / 1. Make it a plain boolean. Signed-off-by:
Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by:
Alex Bennée <alex.bennee@linaro.org> Acked-by:
David Gibson <david@gibson.dropbear.id.au> Message-Id: <20210111152020.1422021-3-philmd@redhat.com> Signed-off-by:
Laurent Vivier <laurent@vivier.eu>
-
Chen Qun authored
There are 23 files that include the "sysemu/qtest.h", but they do not use any qtest functions. Signed-off-by:
Chen Qun <kuhn.chenqun@huawei.com> Acked-by:
Markus Armbruster <armbru@redhat.com> Message-Id: <20210226081414.205946-1-kuhn.chenqun@huawei.com> Signed-off-by:
Thomas Huth <thuth@redhat.com>
-
- Mar 06, 2021
-
-
Richard Henderson authored
The primary motivation is to remove a dozen insns along the fast-path in tb_lookup. As a byproduct, this allows us to completely remove parallel_cpus. Reviewed-by:
Alex Bennée <alex.bennee@linaro.org> Signed-off-by:
Richard Henderson <richard.henderson@linaro.org>
-
Alex Bennée authored
We don't really deal in cf_mask most of the time. The one time it's relevant is when we want to remove an invalidated TB from the QHT lookup. Everywhere else we should be looking up things without CF_INVALID set. Signed-off-by:
Alex Bennée <alex.bennee@linaro.org> Message-Id: <20210224165811.11567-4-alex.bennee@linaro.org> Signed-off-by:
Richard Henderson <richard.henderson@linaro.org>
-
Alex Bennée authored
There is nothing special about this compile flag that doesn't mean we can't just compute it with curr_cflags() which we should be using when building a new set. Signed-off-by:
Alex Bennée <alex.bennee@linaro.org> Message-Id: <20210224165811.11567-3-alex.bennee@linaro.org> Signed-off-by:
Richard Henderson <richard.henderson@linaro.org>
-
Alex Bennée authored
Having a function return either and valid TB and some system state seems excessive. It will make the subsequent re-factoring easier if we lookup the current state where we are. Signed-off-by:
Alex Bennée <alex.bennee@linaro.org> Message-Id: <20210224165811.11567-2-alex.bennee@linaro.org> Signed-off-by:
Richard Henderson <richard.henderson@linaro.org>
-
Keqian Zhu authored
The parameters start and size are transfered from QEMU memory emulation layer. It can promise that they are TARGET_PAGE_SIZE aligned. However, KVM needs they are qemu_real_page_size aligned. Though no caller breaks this aligned requirement currently, we'd better add an explicit assert to avoid future breaking. Signed-off-by:
Keqian Zhu <zhukeqian1@huawei.com> Acked-by:
Peter Xu <peterx@redhat.com> Reviewed-by:
Andrew Jones <drjones@redhat.com> Message-Id: <20201217014941.22872-3-zhukeqian1@huawei.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Keqian Zhu authored
When handle dirty log, we face qemu_real_host_page_size and TARGET_PAGE_SIZE. The first one is the granule of KVM dirty bitmap, and the second one is the granule of QEMU dirty bitmap. As qemu_real_host_page_size >= TARGET_PAGE_SIZE (kvm_init() enforced it), misuse TARGET_PAGE_SIZE to init kvmslot dirty_bmap may waste memory. For example, when qemu_real_host_page_size is 64K and TARGET_PAGE_SIZE is 4K, it wastes 93.75% (15/16) memory. Signed-off-by:
Keqian Zhu <zhukeqian1@huawei.com> Reviewed-by:
Andrew Jones <drjones@redhat.com> Reviewed-by:
Peter Xu <peterx@redhat.com> Message-Id: <20201217014941.22872-2-zhukeqian1@huawei.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- Feb 18, 2021
-
-
Alex Bennée authored
When icount is enabled and we recompile an MMIO access we end up double counting the instruction execution. To avoid this we introduce the CF_MEMI cflag which only allows memory instrumentation for the next TB (which won't yet have been counted). As this is part of the hashed compile flags we will only execute the generated TB while coming out of a cpu_io_recompile. While we are at it delete the old TODO. We might as well keep the translation handy as it's likely you will repeatedly hit it on each MMIO access. Reported-by:
Aaron Lindsay <aaron@os.amperecomputing.com> Signed-off-by:
Alex Bennée <alex.bennee@linaro.org> Tested-by:
Aaron Lindsay <aaron@os.amperecomputing.com> Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210213130325.14781-21-alex.bennee@linaro.org>
-
Alex Bennée authored
Now we no longer generate CF_NOCACHE blocks we can remove a bunch of the special case handling for them. While we are at it we can remove the unused tb->orig_tb field and save a few bytes on the TB structure. Signed-off-by:
Alex Bennée <alex.bennee@linaro.org> Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210213130325.14781-20-alex.bennee@linaro.org>
-
Alex Bennée authored
There is no real need to use CF_NOCACHE here. As long as the TB isn't linked to other TBs or included in the QHT or jump cache then it will only get executed once. Signed-off-by:
Alex Bennée <alex.bennee@linaro.org> Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210213130325.14781-19-alex.bennee@linaro.org>
-
Alex Bennée authored
Again there is no reason to jump through the nocache hoops to execute a single instruction block. We do have to add an additional wrinkle to the cpu_handle_interrupt case to ensure we let through a TB where we have specifically disabled icount for the block. As the last user of cpu_exec_nocache we can now remove the function. Further clean-up will follow in subsequent patches. Signed-off-by:
Alex Bennée <alex.bennee@linaro.org> Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210213130325.14781-18-alex.bennee@linaro.org>
-
Alex Bennée authored
When we exit a block under icount with instructions left to execute we might need a shorter than normal block to take us to the next deterministic event. Instead of creating a throwaway block on demand we use the existing compile flags mechanism to ensure we fetch (or compile and fetch) a block with exactly the number of instructions we need. Signed-off-by:
Alex Bennée <alex.bennee@linaro.org> Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210213130325.14781-17-alex.bennee@linaro.org>
-
Richard Henderson authored
Move the code from accel/tcg/translate-all.c to target/sh4/cpu.c. Signed-off-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
Alex Bennée <alex.bennee@linaro.org> Reviewed-by:
Alex Bennée <alex.bennee@linaro.org> Reviewed-by:
Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210208233906.479571-5-richard.henderson@linaro.org> Message-Id: <20210213130325.14781-14-alex.bennee@linaro.org>
-
Richard Henderson authored
Move the code from accel/tcg/translate-all.c to target/mips/cpu.c. Signed-off-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
Alex Bennée <alex.bennee@linaro.org> Reviewed-by:
Alex Bennée <alex.bennee@linaro.org> Reviewed-by:
Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210208233906.479571-4-richard.henderson@linaro.org> Message-Id: <20210213130325.14781-13-alex.bennee@linaro.org>
-
Richard Henderson authored
Create a hook in which to split out the mips and sh4 ifdefs from cpu_io_recompile. [AJB: s/stoped/stopped/] Signed-off-by:
Richard Henderson <richard.henderson@linaro.org> Signed-off-by:
Alex Bennée <alex.bennee@linaro.org> Reviewed-by:
Alex Bennée <alex.bennee@linaro.org> Reviewed-by:
Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210208233906.479571-3-richard.henderson@linaro.org> Message-Id: <20210213130325.14781-12-alex.bennee@linaro.org>
-
Alex Bennée authored
A recent change to the handling of constants in TCG changed the pattern of ops emitted for a constant add. We no longer emit a mov and the constant can be applied directly to the TCG_op_add arguments. This was causing SEGVs when running the insn plugin with arg=inline. Fix this by updating copy_add_i64 to do the right thing while also adding a comment at the top of the append section as an aide memoir if something like this happens again. Signed-off-by:
Alex Bennée <alex.bennee@linaro.org> Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Cc: Emilio G. Cota <cota@braap.org> Message-Id: <20210213130325.14781-10-alex.bennee@linaro.org>
-
- Feb 16, 2021
-
-
Tom Lendacky authored
An SEV-ES guest does not allow register state to be altered once it has been measured. When an SEV-ES guest issues a reboot command, Qemu will reset the vCPU state and resume the guest. This will cause failures under SEV-ES. Prevent that from occuring by introducing an arch-specific callback that returns a boolean indicating whether vCPUs are resettable. Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Aurelien Jarno <aurelien@aurel32.net> Cc: Jiaxun Yang <jiaxun.yang@flygoat.com> Cc: Aleksandar Rikalo <aleksandar.rikalo@syrmia.com> Cc: David Gibson <david@gibson.dropbear.id.au> Cc: David Hildenbrand <david@redhat.com> Reviewed-by:
Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by:
Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by:
Venu Busireddy <venu.busireddy@oracle.com> Message-Id: <1ac39c441b9a3e970e9556e1cc29d0a0814de6fd.1611682609.git.thomas.lendacky@amd.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Paolo Bonzini authored
When SEV-ES is enabled, it is not possible modify the guests register state after it has been initially created, encrypted and measured. Normally, an INIT-SIPI-SIPI request is used to boot the AP. However, the hypervisor cannot emulate this because it cannot update the AP register state. For the very first boot by an AP, the reset vector CS segment value and the EIP value must be programmed before the register has been encrypted and measured. Search the guest firmware for the guest for a specific GUID that tells Qemu the value of the reset vector to use. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <22db2bfb4d6551aed661a9ae95b4fdbef613ca21.1611682609.git.thomas.lendacky@amd.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Richard Henderson authored
The places that use these are better off using untagged addresses, so do not provide a tagged versions. Rename to make it clear about the address type. Reviewed-by:
Peter Maydell <peter.maydell@linaro.org> Signed-off-by:
Richard Henderson <richard.henderson@linaro.org> Message-id: 20210212184902.1251044-16-richard.henderson@linaro.org Signed-off-by:
Peter Maydell <peter.maydell@linaro.org>
-
Richard Henderson authored
Use g2h_untagged in contexts that have no cpu, e.g. the binary loaders that operate before the primary cpu is created. As a colollary, target_mmap and friends must use untagged addresses, since they are used by the loaders. Use g2h_untagged on values returned from target_mmap, as the kernel never applies a tag itself. Use g2h_untagged on all pc values. The only current user of tags, aarch64, removes tags from code addresses upon branch, so "pc" is always untagged. Use g2h with the cpu context on hand wherever possible. Use g2h_untagged in lock_user, which will be updated soon. Reviewed-by:
Peter Maydell <peter.maydell@linaro.org> Signed-off-by:
Richard Henderson <richard.henderson@linaro.org> Message-id: 20210212184902.1251044-13-richard.henderson@linaro.org Signed-off-by:
Peter Maydell <peter.maydell@linaro.org>
-
Richard Henderson authored
This data can be allocated by page_alloc_target_data() and released by page_set_flags(start, end, prot | PAGE_RESET). This data will be used to hold tag memory for AArch64 MTE. Reviewed-by:
Peter Maydell <peter.maydell@linaro.org> Signed-off-by:
Richard Henderson <richard.henderson@linaro.org> Message-id: 20210212184902.1251044-2-richard.henderson@linaro.org Signed-off-by:
Peter Maydell <peter.maydell@linaro.org>
-
- Feb 11, 2021
-
-
Peter Maydell authored
In cpu_exec() we have a longstanding workaround for compilers which do not correctly implement the part of the sigsetjmp()/siglongjmp() spec which requires that local variables which are not changed between the setjmp and the longjmp retain their value. I recently ran across the upstream clang bug report for this; add a link to it to the comment describing the workaround, and generally expand the comment, so that we have a reasonable chance in future of understanding why it's there and determining when we can remove it, assuming clang eventually fixes the bug. Remove the /* buggy compiler */ comments on the #else and #endif: they don't add anything to understanding and are somewhat misleading since they're sandwiching the code path for *non*-buggy compilers. Signed-off-by:
Peter Maydell <peter.maydell@linaro.org> Reviewed-by:
Alex Bennée <alex.bennee@linaro.org> Message-id: 20210129130330.30820-1-peter.maydell@linaro.org
-
- Feb 08, 2021
-
-
Pavel Dovgalyuk authored
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 authored
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 b533f658 but that commit missed that the ENOENT error code is not fatal for this ioctl, so the commit has been reverted in commit 50212d63 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>
-
David Gibson authored
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 authored
This allows failures to be reported richly and idiomatically. Signed-off-by:
David Gibson <david@gibson.dropbear.id.au> Reviewed-by:
Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by:
Richard Henderson <richard.henderson@linaro.org> Reviewed-by:
Cornelia Huck <cohuck@redhat.com>
-
David Gibson authored
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 authored
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>
-
- Feb 05, 2021
-
-
Claudio Fontana authored
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>
-