aboutsummaryrefslogtreecommitdiff
path: root/target
AgeCommit message (Collapse)Author
2021-06-02docs: fix references to docs/devel/tracing.rstStefano Garzarella
Commit e50caf4a5c ("tracing: convert documentation to rST") converted docs/devel/tracing.txt to docs/devel/tracing.rst. We still have several references to the old file, so let's fix them with the following command: sed -i s/tracing.txt/tracing.rst/ $(git grep -l docs/devel/tracing.txt) Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210517151702.109066-2-sgarzare@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-06-01sev: add missing firmware error conditionsConnor Kuehl
The SEV userspace header[1] exports a couple of other error conditions that aren't listed in QEMU's SEV implementation, so let's just round out the list. [1] linux-headers/linux/psp-sev.h Signed-off-by: Connor Kuehl <ckuehl@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210430134830.254741-3-ckuehl@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-06-01sev: use explicit indices for mapping firmware error codes to stringsConnor Kuehl
This can help lower any margin for error when making future additions to the list, especially if they're made out of order. While doing so, make capitalization of ASID consistent with its usage in the SEV firmware spec (Asid -> ASID). Signed-off-by: Connor Kuehl <ckuehl@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210430134830.254741-2-ckuehl@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-06-01target/i386/sev: add support to query the attestation reportBrijesh Singh
The SEV FW >= 0.23 added a new command that can be used to query the attestation report containing the SHA-256 digest of the guest memory and VMSA encrypted with the LAUNCH_UPDATE and sign it with the PEK. Note, we already have a command (LAUNCH_MEASURE) that can be used to query the SHA-256 digest of the guest memory encrypted through the LAUNCH_UPDATE. The main difference between previous and this command is that the report is signed with the PEK and unlike the LAUNCH_MEASURE command the ATTESATION_REPORT command can be called while the guest is running. Add a QMP interface "query-sev-attestation-report" that can be used to get the report encoded in base64. Cc: James Bottomley <jejb@linux.ibm.com> Cc: Tom Lendacky <Thomas.Lendacky@amd.com> Cc: Eric Blake <eblake@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: kvm@vger.kernel.org Reviewed-by: James Bottomley <jejb@linux.ibm.com> Tested-by: James Bottomley <jejb@linux.ibm.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Connor Kuehl <ckuehl@redhat.com> Message-Id: <20210429170728.24322-1-brijesh.singh@amd.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-31i386: use global kvm_state in hyperv_enabled() checkVitaly Kuznetsov
There is no need to use vCPU-specific kvm state in hyperv_enabled() check and we need to do that when feature expansion happens early, before vCPU specific KVM state is created. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20210422161130.652779-15-vkuznets@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-31i386: prefer system KVM_GET_SUPPORTED_HV_CPUID ioctl over vCPU's oneVitaly Kuznetsov
KVM_GET_SUPPORTED_HV_CPUID was made a system wide ioctl which can be called prior to creating vCPUs and we are going to use that to expand Hyper-V cpu features early. Use it when it is supported by KVM. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20210422161130.652779-14-vkuznets@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-31i386: adjust the expected KVM_GET_SUPPORTED_HV_CPUID array sizeVitaly Kuznetsov
SYNDBG leaves were recently (Linux-5.8) added to KVM but we haven't updated the expected size of KVM_GET_SUPPORTED_HV_CPUID output in KVM so we now make serveral tries before succeeding. Update the default. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20210422161130.652779-13-vkuznets@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-31i386: switch hyperv_expand_features() to using error_setg()Vitaly Kuznetsov
Use standard error_setg() mechanism in hyperv_expand_features(). Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20210422161130.652779-12-vkuznets@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-31i386: move eVMCS enablement to hyperv_init_vcpu()Vitaly Kuznetsov
hyperv_expand_features() will be called before we create vCPU so evmcs enablement should go away. hyperv_init_vcpu() looks like the right place. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20210422161130.652779-11-vkuznets@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-31i386: split hyperv_handle_properties() into ↵Vitaly Kuznetsov
hyperv_expand_features()/hyperv_fill_cpuids() The intention is to call hyperv_expand_features() early, before vCPUs are created and use the acquired data later when we set guest visible CPUID data. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20210422161130.652779-10-vkuznets@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-31i386: introduce hv_cpuid_cacheVitaly Kuznetsov
Just like with cpuid_cache, it makes no sense to call KVM_GET_SUPPORTED_HV_CPUID more than once and instead of (ab)using env->features[] and/or trying to keep all the code in one place, it is better to introduce persistent hv_cpuid_cache and hv_cpuid_get_host() accessor to it. Note, hv_cpuid_get_fw() is converted to using hv_cpuid_get_host() just to be removed later with Hyper-V specific feature words. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20210422161130.652779-9-vkuznets@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-31i386: drop FEAT_HYPERV feature leavesVitaly Kuznetsov
Hyper-V feature leaves are weird. We have some of them in feature_word_info[] array but we don't use feature_word_info magic to enable them. Neither do we use feature_dependencies[] mechanism to validate the configuration as it doesn't allign well with Hyper-V's many-to-many dependency chains. Some of the feature leaves hold not only feature bits, but also values. E.g. FEAT_HV_NESTED_EAX contains both features and the supported Enlightened VMCS range. Hyper-V features are already represented in 'struct X86CPU' with uint64_t hyperv_features so duplicating them in env->features adds little (or zero) benefits. THe other half of Hyper-V emulation features is also stored with values in hyperv_vendor_id[], hyperv_limits[],... so env->features[] is already incomplete. Remove Hyper-V feature leaves from env->features[] completely. kvm_hyperv_properties[] is converted to using raw CPUID func/reg pairs for features, this allows us to get rid of hv_cpuid_get_fw() conversion. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20210422161130.652779-8-vkuznets@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-31i386: introduce hv_cpuid_get_host()Vitaly Kuznetsov
As a preparation to implementing hv_cpuid_cache intro introduce hv_cpuid_get_host(). No functional change intended. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20210422161130.652779-7-vkuznets@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-31i386: introduce hyperv_feature_supported()Vitaly Kuznetsov
Clean up hv_cpuid_check_and_set() by separating hyperv_feature_supported() off it. No functional change intended. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20210422161130.652779-6-vkuznets@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-31i386: stop using env->features[] for filling Hyper-V CPUIDsVitaly Kuznetsov
As a preparatory patch to dropping Hyper-V CPUID leaves from feature_word_info[] stop using env->features[] as a temporary storage of Hyper-V CPUIDs, just build Hyper-V CPUID leaves directly from kvm_hyperv_properties[] data. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20210422161130.652779-5-vkuznets@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-31i386: always fill Hyper-V CPUID feature leaves from X86CPU dataVitaly Kuznetsov
We have all the required data in X86CPU already and as we are about to split hyperv_handle_properties() into hyperv_expand_features()/ hyperv_fill_cpuids() we can remove the blind copy. The functional change is that QEMU won't pass CPUID leaves it doesn't currently know about to the guest but arguably this is a good change. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20210422161130.652779-4-vkuznets@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-31i386: invert hyperv_spinlock_attempts setting logic with hv_passthroughVitaly Kuznetsov
There is no need to have this special case: like all other Hyper-V enlightenments we can just use kernel's supplied value in hv_passthrough mode. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20210422161130.652779-3-vkuznets@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-31i386: keep hyperv_vendor string up-to-dateVitaly Kuznetsov
When cpu->hyperv_vendor is not set manually we default to "Microsoft Hv" and in 'hv_passthrough' mode we get the information from the host. This information is stored in cpu->hyperv_vendor_id[] array but we don't update cpu->hyperv_vendor string so e.g. QMP's query-cpu-model-expansion output is incorrect. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20210422161130.652779-2-vkuznets@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-31i386: use better matching family/model/stepping for 'max' CPUDaniel P. Berrangé
The 'max' CPU under TCG currently reports a family/model/stepping that approximately corresponds to an AMD K7 vintage architecture. The K7 series predates the introduction of 64-bit support by AMD in the K8 series. This has been reported to lead to LLVM complaints about generating 64-bit code for a 32-bit CPU target LLVM ERROR: 64-bit code requested on a subtarget that doesn't support it! It appears LLVM looks at the family/model/stepping, despite qemu64 reporting it is 64-bit capable. This patch changes 'max' to report a CPUID with the family, model and stepping taken from a AMD Athlon(tm) 64 X2 Dual Core Processor 4000+ which is one of the first 64-bit AMD CPUs. Closes https://gitlab.com/qemu-project/qemu/-/issues/191 Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210507133650.645526-3-berrange@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-31i386: use better matching family/model/stepping for 'qemu64' CPUDaniel P. Berrangé
The 'qemu64' CPUID currently reports a family/model/stepping that approximately corresponds to an AMD K7 vintage architecture. The K7 series predates the introduction of 64-bit support by AMD in the K8 series. This has been reported to lead to LLVM complaints about generating 64-bit code for a 32-bit CPU target LLVM ERROR: 64-bit code requested on a subtarget that doesn't support it! It appears LLVM looks at the family/model/stepping, despite qemu64 reporting it is 64-bit capable. This patch changes 'qemu64' to report a CPUID with the family, model and stepping taken from a AMD Athlon(tm) 64 X2 Dual Core Processor 4000+ which is one of the first 64-bit AMD CPUs. Closes https://gitlab.com/qemu-project/qemu/-/issues/191 Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20210507133650.645526-2-berrange@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-31i386/cpu_dump: support AVX512 ZMM regs dumpRobert Hoo
Since commit fa4518741e (target-i386: Rename struct XMMReg to ZMMReg), CPUX86State.xmm_regs[] has already been extended to 512bit to support AVX512. Also, other qemu level supports for AVX512 registers are there for years. But in x86_cpu_dump_state(), still only dump XMM registers no matter YMM/ZMM is enabled. This patch is to complement this, let it dump XMM/YMM/ZMM accordingly. Signed-off-by: Robert Hoo <robert.hu@linux.intel.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <1618986232-73826-1-git-send-email-robert.hu@linux.intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-31target/i386/cpu: Constify X86CPUDefinitionPhilippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210503173524.833052-3-philmd@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-31target/i386/cpu: Constify CPUCachesPhilippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210503173524.833052-2-philmd@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-31i386: Document when features can be added to kvm_default_propsEduardo Habkost
It's very easy to mistakenly extend kvm_default_props to include features that require a kernel version that's too recent. Add a comment warning about that, pointing to the documentation file where the minimum kernel version for KVM is documented. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200925211021.4158567-1-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-31target/i386: Add CPU model versions supporting 'xsaves'Vitaly Kuznetsov
Hyper-V 2016 refuses to boot on Skylake+ CPU models because they lack 'xsaves'/'vmx-xsaves' features and this diverges from real hardware. The same issue emerges with AMD "EPYC" CPU model prior to version 3 which got 'xsaves' added. EPYC-Rome/EPYC-Milan CPU models have 'xsaves' enabled from the very beginning so the comment blaming KVM to explain why other CPUs lack 'xsaves' is likely outdated. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20210412073952.860944-1-vkuznets@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2021-05-28Merge remote-tracking branch 'remotes/rth-gitlab/tags/pull-tcg-20210526' ↵Peter Maydell
into staging Adjust types for some memory access functions. Reduce inclusion of tcg headers. Fix watchpoints vs replay. Fix tcg/aarch64 roli expansion. Introduce SysemuCPUOps structure. # gpg: Signature made Thu 27 May 2021 00:43:54 BST # 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-20210526: (31 commits) hw/core: Constify TCGCPUOps target/mips: Fold jazz behaviour into mips_cpu_do_transaction_failed cpu: Move CPUClass::get_paging_enabled to SysemuCPUOps cpu: Move CPUClass::get_memory_mapping to SysemuCPUOps cpu: Move CPUClass::get_phys_page_debug to SysemuCPUOps cpu: Move CPUClass::asidx_from_attrs to SysemuCPUOps cpu: Move CPUClass::write_elf* to SysemuCPUOps cpu: Move CPUClass::get_crash_info to SysemuCPUOps cpu: Move CPUClass::virtio_is_big_endian to SysemuCPUOps cpu: Move CPUClass::vmsd to SysemuCPUOps cpu: Introduce SysemuCPUOps structure cpu: Move AVR target vmsd field from CPUClass to DeviceClass cpu: Rename CPUClass vmsd -> legacy_vmsd cpu: Assert DeviceClass::vmsd is NULL on user emulation cpu: Directly use get_memory_mapping() fallback handlers in place cpu: Directly use get_paging_enabled() fallback handlers in place cpu: Directly use cpu_write_elf*() fallback handlers in place cpu: Introduce cpu_virtio_is_big_endian() cpu: Un-inline cpu_get_phys_page_debug and cpu_asidx_from_attrs cpu: Split as cpu-common / cpu-sysemu ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-05-27Merge remote-tracking branch 'remotes/vivier/tags/m68k-for-6.1-pull-request' ↵Peter Maydell
into staging m68k pull request 20210526 implement m68k "any instruction" trace mode # gpg: Signature made Wed 26 May 2021 20:56:58 BST # gpg: using RSA key CD2F75DDC8E3A4DC2E4F5173F30C38BD3F2FBE3C # gpg: issuer "laurent@vivier.eu" # gpg: Good signature from "Laurent Vivier <lvivier@redhat.com>" [full] # gpg: aka "Laurent Vivier <laurent@vivier.eu>" [full] # gpg: aka "Laurent Vivier (Red Hat) <lvivier@redhat.com>" [full] # Primary key fingerprint: CD2F 75DD C8E3 A4DC 2E4F 5173 F30C 38BD 3F2F BE3C * remotes/vivier/tags/m68k-for-6.1-pull-request: target/m68k: implement m68k "any instruction" trace mode target/m68k: introduce gen_singlestep_exception() function target/m68k: call gen_raise_exception() directly if single-stepping in gen_jmp_tb() target/m68k: introduce is_singlestepping() function Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-05-26hw/core: Constify TCGCPUOpsRichard Henderson
We no longer have any runtime modifications to this struct, so declare them all const. Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20210227232519.222663-3-richard.henderson@linaro.org>
2021-05-26target/mips: Fold jazz behaviour into mips_cpu_do_transaction_failedRichard Henderson
Add a flag to MIPSCPUClass in order to avoid needing to replace mips_tcg_ops.do_transaction_failed. Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20210227232519.222663-2-richard.henderson@linaro.org>
2021-05-26cpu: Move CPUClass::get_paging_enabled to SysemuCPUOpsPhilippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210517105140.1062037-23-f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-05-26cpu: Move CPUClass::get_memory_mapping to SysemuCPUOpsPhilippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210517105140.1062037-22-f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-05-26cpu: Move CPUClass::get_phys_page_debug to SysemuCPUOpsPhilippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210517105140.1062037-21-f4bug@amsat.org> [rth: Drop declaration movement from target/*/cpu.h] Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-05-26cpu: Move CPUClass::asidx_from_attrs to SysemuCPUOpsPhilippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210517105140.1062037-20-f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-05-26cpu: Move CPUClass::write_elf* to SysemuCPUOpsPhilippe Mathieu-Daudé
The write_elf*() handlers are used to dump vmcore images. This feature is only meaningful for system emulation. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210517105140.1062037-19-f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-05-26cpu: Move CPUClass::get_crash_info to SysemuCPUOpsPhilippe Mathieu-Daudé
cpu_get_crash_info() is called on GUEST_PANICKED events, which only occur in system emulation. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210517105140.1062037-18-f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-05-26cpu: Move CPUClass::virtio_is_big_endian to SysemuCPUOpsPhilippe Mathieu-Daudé
VirtIO devices are only meaningful with system emulation. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210517105140.1062037-17-f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-05-26cpu: Move CPUClass::vmsd to SysemuCPUOpsPhilippe Mathieu-Daudé
Migration is specific to system emulation. - Move the CPUClass::vmsd field to SysemuCPUOps, - restrict VMSTATE_CPU() macro to sysemu, - vmstate_dummy is now unused, remove it. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210517105140.1062037-16-f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-05-26cpu: Introduce SysemuCPUOps structurePhilippe Mathieu-Daudé
Introduce a structure to hold handler specific to sysemu. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210517105140.1062037-15-f4bug@amsat.org> [rth: Squash "restrict hw/core/sysemu-cpu-ops.h" patch] Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-05-26cpu: Move AVR target vmsd field from CPUClass to DeviceClassPhilippe Mathieu-Daudé
See rationale in previous commit. Targets should use the vmsd field of DeviceClass, not CPUClass. As migration is not important on the AVR target, break the migration compatibility and set the DeviceClass vmsd field. To feel safer, increment the vmstate version. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210517105140.1062037-14-f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-05-26cpu: Rename CPUClass vmsd -> legacy_vmsdPhilippe Mathieu-Daudé
Quoting Peter Maydell [*]: There are two ways to handle migration for a CPU object: (1) like any other device, so it has a dc->vmsd that covers migration for the whole object. As usual for objects that are a subclass of a parent that has state, the first entry in the VMStateDescription field list is VMSTATE_CPU(), which migrates the cpu_common fields, followed by whatever the CPU's own migration fields are. (2) a backwards-compatible mechanism for CPUs that were originally migrated using manual "write fields to the migration stream structures". The on-the-wire migration format for those is based on the 'env' pointer (which isn't a QOM object), and the cpu_common part of the migration data is elsewhere. cpu_exec_realizefn() handles both possibilities: * for type 1, dc->vmsd is set and cc->vmsd is not, so cpu_exec_realizefn() does nothing, and the standard "register dc->vmsd for a device" code does everything needed * for type 2, dc->vmsd is NULL and so we register the vmstate_cpu_common directly to handle the cpu-common fields, and the cc->vmsd to handle the per-CPU stuff You can't change a CPU from one type to the other without breaking migration compatibility, which is why some guest architectures are stuck on the cc->vmsd form. New targets should use dc->vmsd. To avoid new targets to start using type (2), rename cc->vmsd as cc->legacy_vmsd. The correct field to implement is dc->vmsd (the DeviceClass one). See also commit b170fce3dd0 ("cpu: Register VMStateDescription through CPUState") for historic background. [*] https://www.mail-archive.com/qemu-devel@nongnu.org/msg800849.html Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Cc: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20210517105140.1062037-13-f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-05-26cpu: Assert DeviceClass::vmsd is NULL on user emulationPhilippe Mathieu-Daudé
Migration is specific to system emulation. Restrict current DeviceClass::vmsd to sysemu using #ifdef'ry, and assert in cpu_exec_realizefn() that dc->vmsd not set under user emulation. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210517105140.1062037-12-f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-05-26target/m68k: implement m68k "any instruction" trace modeMark Cave-Ayland
The m68k trace mode is controlled by the top 2 bits in the SR register. Implement the m68k "any instruction" trace mode where bit T1=1 and bit T0=0 in which the CPU generates an EXCP_TRACE exception (vector 9 or offset 0x24) after executing each instruction. This functionality is used by the NetBSD kernel debugger to allow single-stepping on m68k architectures. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210519142917.16693-5-mark.cave-ayland@ilande.co.uk> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-05-26target/m68k: introduce gen_singlestep_exception() functionMark Cave-Ayland
Introduce a new gen_singlestep_exception() function to be called when generating the EXCP_DEBUG exception in single-step mode rather than calling gen_raise_exception(EXCP_DEBUG) directly. This allows for the single-step exception behaviour for all callers to be managed in a single place. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210519142917.16693-4-mark.cave-ayland@ilande.co.uk> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-05-26target/m68k: call gen_raise_exception() directly if single-stepping in ↵Mark Cave-Ayland
gen_jmp_tb() In order to consolidate the single-step exception handling into a single helper, change gen_jmp_tb() so that it calls gen_raise_exception() directly instead of gen_exception(). This ensures that all single-step exceptions are now handled directly by gen_raise_exception(). Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210519142917.16693-3-mark.cave-ayland@ilande.co.uk> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-05-26target/m68k: introduce is_singlestepping() functionMark Cave-Ayland
The m68k translator currently checks the DisasContextBase singlestep_enabled boolean directly to determine whether to single-step execution. Soon single-stepping may also be triggered by setting the appropriate bits in the SR register so centralise the check into a single is_singlestepping() function. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210519142917.16693-2-mark.cave-ayland@ilande.co.uk> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-05-26i386/cpu: Expose AVX_VNNI instruction to guestYang Zhong
Expose AVX (VEX-encoded) versions of the Vector Neural Network Instructions to guest. The bit definition: CPUID.(EAX=7,ECX=1):EAX[bit 4] AVX_VNNI The following instructions are available when this feature is present in the guest. 1. VPDPBUS: Multiply and Add Unsigned and Signed Bytes 2. VPDPBUSDS: Multiply and Add Unsigned and Signed Bytes with Saturation 3. VPDPWSSD: Multiply and Add Signed Word Integers 4. VPDPWSSDS: Multiply and Add Signed Integers with Saturation As for the kvm related code, please reference Linux commit id 1085a6b585d7. The release document ref below link: https://software.intel.com/content/www/us/en/develop/download/\ intel-architecture-instruction-set-extensions-programming-reference.html Signed-off-by: Yang Zhong <yang.zhong@intel.com> Message-Id: <20210407015609.22936-1-yang.zhong@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-05-25target/arm: Enable SVE2 and related extensionsRichard Henderson
Disable I8MM again for !have_neon during realize. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20210525010358.152808-93-richard.henderson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-05-25target/arm: Implement integer matrix multiply accumulateRichard Henderson
This is {S,U,US}MMLA for both AArch64 AdvSIMD and SVE, and V{S,U,US}MMLA.S8 for AArch32 NEON. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20210525010358.152808-91-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-05-25target/arm: Implement aarch32 VSUDOT, VUSDOTRichard Henderson
Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20210525010358.152808-90-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-05-25target/arm: Split decode of VSDOT and VUDOTRichard Henderson
Now that we have a common helper, sharing decode does not save much. Also, this will solve an upcoming naming problem. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20210525010358.152808-89-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-17 18:12:50 +0000