summaryrefslogtreecommitdiffstats
path: root/target/i386
Commit message (Collapse)AuthorAgeFilesLines
* sysemu: Let VMChangeStateHandler take boolean 'running' argumentPhilippe Mathieu-Daudé2021-03-093-3/+3
| | | | | | | | | | | 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>
* Various spelling fixesMichael Tokarev2021-03-092-2/+2
| | | | | | | | | | | An assorted set of spelling fixes in various places. Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Stefan Weil <sw@weilnetz.de> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20210309111510.79495-1-mjt@msgid.tls.msk.ru> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
* KVM: x86: do not fail if software breakpoint has already been removedPaolo Bonzini2021-03-061-2/+7
| | | | | | | | | | | | If kvm_arch_remove_sw_breakpoint finds that a software breakpoint does not have an INT3 instruction, it fails. This can happen if one sets a software breakpoint in a kernel module and then reloads it. gdb then thinks the breakpoint cannot be deleted and there is no way to add it back. Suggested-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* tcg/i386: rdpmc: fix the the condtionsZheng Zhan Liang2021-02-251-1/+2
| | | | | | Signed-off-by: Zheng Zhan Liang <linuxmaker@163.com> Message-Id: <20210225054756.35962-1-linuxmaker@163.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* target/i386: Add bus lock debug exception supportChenyi Qiang2021-02-252-1/+3
| | | | | | | | | | | | | Bus lock debug exception is a feature that can notify the kernel by generate an #DB trap after the instruction acquires a bus lock when CPL>0. This allows the kernel to enforce user application throttling or mitigations. This feature is enumerated via CPUID.(EAX=7,ECX=0).ECX[bit 24]. Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com> Message-Id: <20210202090224.13274-1-chenyi.qiang@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* target/i386: update to show preferred boolean syntax for -cpuDaniel P. Berrangé2021-02-251-1/+1
| | | | | | | | | The preferred syntax is to use "foo=on|off", rather than a bare "+foo" or "-foo" Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210216191027.595031-11-berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* i386: Add the support for AMD EPYC 3rd generation processorsBabu Moger2021-02-192-1/+110
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds the support for AMD 3rd generation processors. The model display for the new processor will be EPYC-Milan. Adds the following new feature bits on top of the feature bits from the first and second generation EPYC models. pcid : Process context identifiers support ibrs : Indirect Branch Restricted Speculation ssbd : Speculative Store Bypass Disable erms : Enhanced REP MOVSB/STOSB support fsrm : Fast Short REP MOVSB support invpcid : Invalidate processor context ID pku : Protection keys support svme-addr-chk : SVM instructions address check for #GP handling Depends on the following kernel commits: 14c2bf81fcd2 ("KVM: SVM: Fix #GP handling for doubly-nested virtualization") 3b9c723ed7cf ("KVM: SVM: Add support for SVM instruction address check change") 4aa2691dcbd3 ("8ce1c461188799d863398dd2865d KVM: x86: Factor out x86 instruction emulation with decoding") 4407a797e941 ("KVM: SVM: Enable INVPCID feature on AMD") 9715092f8d7e ("KVM: X86: Move handling of INVPCID types to x86") 3f3393b3ce38 ("KVM: X86: Rename and move the function vmx_handle_memory_failure to x86.c") 830bd71f2c06 ("KVM: SVM: Remove set_cr_intercept, clr_cr_intercept and is_cr_intercept") 4c44e8d6c193 ("KVM: SVM: Add new intercept word in vmcb_control_area") c62e2e94b9d4 ("KVM: SVM: Modify 64 bit intercept field to two 32 bit vectors") 9780d51dc2af ("KVM: SVM: Modify intercept_exceptions to generic intercepts") 30abaa88382c ("KVM: SVM: Change intercept_dr to generic intercepts") 03bfeeb988a9 ("KVM: SVM: Change intercept_cr to generic intercepts") c45ad7229d13 ("KVM: SVM: Introduce vmcb_(set_intercept/clr_intercept/_is_intercept)") a90c1ed9f11d ("(pcid) KVM: nSVM: Remove unused field") fa44b82eb831 ("KVM: x86: Move MPK feature detection to common code") 38f3e775e9c2 ("x86/Kconfig: Update config and kernel doc for MPK feature on AMD") 37486135d3a7 ("KVM: x86: Fix pkru save/restore when guest CR4.PKE=0, move it to x86.c") Signed-off-by: Babu Moger <babu.moger@amd.com> Message-Id: <161290460478.11352.8933244555799318236.stgit@bmoger-ubuntu> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* Merge remote-tracking branch 'remotes/bonzini-gitlab/tags/for-upstream' into ↵Peter Maydell2021-02-1711-34/+351
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | staging * HVF fixes * Extra qos-test debugging output (Christian) * SEV secret address autodetection (James) * SEV-ES support (Thomas) * Relocatable paths bugfix (Stefan) * RR fix (Pavel) * EventNotifier fix (Greg) # gpg: Signature made Tue 16 Feb 2021 16:15:59 GMT # gpg: using RSA key F13338574B662389866C7682BFFBD25F78C7AE83 # gpg: issuer "pbonzini@redhat.com" # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full] # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full] # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini-gitlab/tags/for-upstream: (21 commits) replay: fix icount request when replaying clock access event_notifier: Set ->initialized earlier in event_notifier_init() hvf: Fetch cr4 before evaluating CPUID(1) target/i386/hvf: add rdmsr 35H MSR_CORE_THREAD_COUNT hvf: x86: Remove unused definitions target/i386/hvf: add vmware-cpuid-freq cpu feature hvf: Guard xgetbv call util/cutils: Skip "." when looking for next directory component tests/qtest/qos-test: dump QEMU command if verbose tests/qtest/qos-test: dump environment variables if verbose tests/qtest/qos-test: dump qos graph if verbose libqos/qgraph_internal: add qos_printf() and qos_printf_literal() libqos/qgraph: add qos_node_create_driver_named() sev/i386: Enable an SEV-ES guest based on SEV policy kvm/i386: Use a per-VM check for SMM capability sev/i386: Don't allow a system reset under an SEV-ES guest sev/i386: Allow AP booting under SEV-ES sev/i386: Require in-kernel irqchip support for SEV-ES guests sev/i386: Add initial support for SEV-ES sev: update sev-inject-launch-secret to make gpa optional ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * hvf: Fetch cr4 before evaluating CPUID(1)Alexander Graf2021-02-161-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The CPUID function 1 has a bit called OSXSAVE which tells user space the status of the CR4.OSXSAVE bit. Our generic CPUID function injects that bit based on the status of CR4. With Hypervisor.framework, we do not synchronize full CPU state often enough for this function to see the CR4 update before guest user space asks for it. To be on the save side, let's just always synchronize it when we receive a CPUID(1) request. That way we can set the bit with real confidence. Reported-by: Asad Ali <asad@osaro.com> Signed-off-by: Alexander Graf <agraf@csgraf.de> Message-Id: <20210123004129.6364-1-agraf@csgraf.de> [RB: resolved conflict with another CPUID change] Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
| * target/i386/hvf: add rdmsr 35H MSR_CORE_THREAD_COUNTVladislav Yaroshchuk2021-02-162-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some guests (ex. Darwin-XNU) can attemp to read this MSR to retrieve and validate CPU topology comparing it to ACPI MADT content MSR description from Intel Manual: 35H: MSR_CORE_THREAD_COUNT: Configured State of Enabled Processor Core Count and Logical Processor Count Bits 15:0 THREAD_COUNT The number of logical processors that are currently enabled in the physical package Bits 31:16 Core_COUNT The number of processor cores that are currently enabled in the physical package Bits 63:32 Reserved Signed-off-by: Vladislav Yaroshchuk <yaroshchuk2000@gmail.com> Message-Id: <20210113205323.33310-1-yaroshchuk2000@gmail.com> [RB: reordered MSR definition and dropped u suffix from shift offset] Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
| * hvf: x86: Remove unused definitionsAlexander Graf2021-02-161-16/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | The hvf i386 has a few struct and cpp definitions that are never used. Remove them. Suggested-by: Roman Bolshakov <r.bolshakov@yadro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Alexander Graf <agraf@csgraf.de> Message-Id: <20210120224444.71840-3-agraf@csgraf.de> Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
| * target/i386/hvf: add vmware-cpuid-freq cpu featureVladislav Yaroshchuk2021-02-161-1/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For `-accel hvf` cpu_x86_cpuid() is wrapped with hvf_cpu_x86_cpuid() to add paravirtualization cpuid leaf 0x40000010 https://lkml.org/lkml/2008/10/1/246 Leaf 0x40000010, Timing Information: EAX: (Virtual) TSC frequency in kHz. EBX: (Virtual) Bus (local apic timer) frequency in kHz. ECX, EDX: RESERVED (Per above, reserved fields are set to zero). On macOS TSC and APIC Bus frequencies can be readed by sysctl call with names `machdep.tsc.frequency` and `hw.busfrequency` This options is required for Darwin-XNU guest to be synchronized with host Leaf 0x40000000 not exposes HVF leaving hypervisor signature empty Signed-off-by: Vladislav Yaroshchuk <yaroshchuk2000@gmail.com> Message-Id: <20210122150518.3551-1-yaroshchuk2000@gmail.com> Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
| * hvf: Guard xgetbv callHill Ma2021-02-161-12/+22
| | | | | | | | | | | | | | | | | | | | | | This prevents illegal instruction on cpus that do not support xgetbv. Buglink: https://bugs.launchpad.net/qemu/+bug/1758819 Reviewed-by: Cameron Esfahani <dirty@apple.com> Signed-off-by: Hill Ma <maahiuzeon@gmail.com> Message-Id: <X/6OJ7qk0W6bHkHQ@Hills-Mac-Pro.local> Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
| * sev/i386: Enable an SEV-ES guest based on SEV policyTom Lendacky2021-02-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Update the sev_es_enabled() function return value to be based on the SEV policy that has been specified. SEV-ES is enabled if SEV is enabled and the SEV-ES policy bit is set in the policy object. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Eduardo Habkost <ehabkost@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: <c69f81c6029f31fc4c52a9f35f1bd704362476a5.1611682609.git.thomas.lendacky@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
| * kvm/i386: Use a per-VM check for SMM capabilityTom Lendacky2021-02-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SMM is not currently supported for an SEV-ES guest by KVM. Change the SMM capability check from a KVM-wide check to a per-VM check in order to have a finer-grained SMM capability check. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Eduardo Habkost <ehabkost@redhat.com> Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Venu Busireddy <venu.busireddy@oracle.com> Message-Id: <f851903809e9d4e6a22d5dfd738dac8da991e28d.1611682609.git.thomas.lendacky@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
| * sev/i386: Don't allow a system reset under an SEV-ES guestTom Lendacky2021-02-161-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * sev/i386: Allow AP booting under SEV-ESPaolo Bonzini2021-02-163-0/+139
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * sev/i386: Require in-kernel irqchip support for SEV-ES guestsTom Lendacky2021-02-161-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In prep for AP booting, require the use of in-kernel irqchip support. This lessens the Qemu support burden required to boot APs. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Eduardo Habkost <ehabkost@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: <e9aec5941e613456f0757f5a73869cdc5deea105.1611682609.git.thomas.lendacky@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
| * sev/i386: Add initial support for SEV-ESTom Lendacky2021-02-164-2/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Provide initial support for SEV-ES. This includes creating a function to indicate the guest is an SEV-ES guest (which will return false until all support is in place), performing the proper SEV initialization and ensuring that the guest CPU state is measured as part of the launch. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Co-developed-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Venu Busireddy <venu.busireddy@oracle.com> Message-Id: <2e6386cbc1ddeaf701547dd5677adf5ddab2b6bd.1611682609.git.thomas.lendacky@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
| * sev: update sev-inject-launch-secret to make gpa optionalJames Bottomley2021-02-161-1/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the gpa isn't specified, it's value is extracted from the OVMF properties table located below the reset vector (and if this doesn't exist, an error is returned). OVMF has defined the GUID for the SEV secret area as 4c2eb361-7d9b-4cc3-8081-127c90d3d294 and the format of the <data> is: <base>|<size> where both are uint32_t. We extract <base> and use it as the gpa for the injection. Note: it is expected that the injected secret will also be GUID described but since qemu can't interpret it, the format is left undefined here. Signed-off-by: James Bottomley <jejb@linux.ibm.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20210204193939.16617-3-jejb@linux.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
| * pc: add parser for OVMF reset blockJames Bottomley2021-02-161-1/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OVMF is developing a mechanism for depositing a GUIDed table just below the known location of the reset vector. The table goes backwards in memory so all entries are of the form <data>|len|<GUID> Where <data> is arbtrary size and type, <len> is a uint16_t and describes the entire length of the entry from the beginning of the data to the end of the guid. The foot of the table is of this form and <len> for this case describes the entire size of the table. The table foot GUID is defined by OVMF as 96b582de-1fb2-45f7-baea-a366c55a082d and if the table is present this GUID is just below the reset vector, 48 bytes before the end of the firmware file. Add a parser for the ovmf reset block which takes a copy of the block, if the table foot guid is found, minus the footer and a function for later traversal to return the data area of any specified GUIDs. Signed-off-by: James Bottomley <jejb@linux.ibm.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20210204193939.16617-2-jejb@linux.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* | exec: Use cpu_untagged_addr in g2h; split out g2h_untaggedRichard Henderson2021-02-161-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | 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>
* target/i386: Expose VMX entry/exit load pkrs control bitsChenyi Qiang2021-02-082-2/+4
| | | | | | | | | | Expose the VMX exit/entry load pkrs control bits in VMX_TRUE_EXIT_CTLS/VMX_TRUE_ENTRY_CTLS MSRs to guest, which supports the PKS in nested VM. Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com> Message-Id: <20210205083325.13880-3-chenyi.qiang@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* target/i386: Add support for save/load IA32_PKRS MSRChenyi Qiang2021-02-081-0/+13
| | | | | | | | | | | | PKS introduces MSR IA32_PKRS(0x6e1) to manage the supervisor protection key rights. Page access and writes can be managed via the MSR update without TLB flushes when permissions change. Add the support to save/load IA32_PKRS MSR in guest. Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com> Message-Id: <20210205083325.13880-2-chenyi.qiang@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* target/i86: implement PKSPaolo Bonzini2021-02-086-18/+64
| | | | | | | | | | | | | | | Protection Keys for Supervisor-mode pages is a simple extension of the PKU feature that QEMU already implements. For supervisor-mode pages, protection key restrictions come from a new MSR. The MSR has no XSAVE state associated to it. PKS is only respected in long mode. However, in principle it is possible to set the MSR even outside long mode, and in fact even the XSAVE state for PKRU could be set outside long mode using XRSTOR. So do not limit the migration subsections for PKRU and PKRS to long mode. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* target/i386: Fix decoding of certain BMI instructionsDavid Greenaway2021-02-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes a translation bug for a subset of x86 BMI instructions such as the following: c4 e2 f9 f7 c0 shlxq %rax, %rax, %rax Currently, these incorrectly generate an undefined instruction exception when SSE is disabled via CR4, while instructions like "shrxq" work fine. The problem appears to be related to BMI instructions encoded using VEX and with a mandatory prefix of "0x66" (data). Instructions with this data prefix (such as shlxq) are currently rejected. Instructions with other mandatory prefixes (such as shrxq) translate as expected. This patch removes the incorrect check in "gen_sse" that causes the exception to be generated. For the non-BMI cases, the check is redundant: prefixes are already checked at line 3696. Buglink: https://bugs.launchpad.net/qemu/+bug/1748296 Signed-off-by: David Greenaway <dgreenaway@google.com> Message-Id: <20210114063958.1508050-1-dgreenaway@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* x86/cpu: Populate SVM CPUID feature bitsWei Huang2021-02-082-13/+17
| | | | | | | | | | | | | | Newer AMD CPUs will add CPUID_0x8000000A_EDX[28] bit, which indicates that SVM instructions (VMRUN/VMSAVE/VMLOAD) will trigger #VMEXIT before CPU checking their EAX against reserved memory regions. This change will allow the hypervisor to avoid intercepting #GP and emulating SVM instructions. KVM turns on this CPUID bit for nested VMs. In order to support it, let us populate this bit, along with other SVM feature bits, in FEAT_SVM. Signed-off-by: Wei Huang <wei.huang2@amd.com> Message-Id: <20210126202456.589932-1-wei.huang2@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* target/i386: do not set LM for 32-bit emulation "-cpu host/max"Paolo Bonzini2021-02-081-0/+5
| | | | | | | | | | | | | | | | | | | 32-bit targets by definition do not support long mode; therefore, the bit must be masked in the features supported by the accelerator. As a side effect, this avoids setting up the 0x80000008 CPUID leaf for qemu-system-i386 -cpu host which since commit 5a140b255d ("x86/cpu: Use max host physical address if -cpu max option is applied") would have printed this error: qemu-system-i386: phys-bits should be between 32 and 36 (but is 48) Reported-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* confidential guest support: Move SEV initialization into arch specific codeDavid Gibson2021-02-082-1/+26
| | | | | | | | | | | 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>
* confidential guest support: Introduce cgs "ready" flagDavid Gibson2021-02-081-0/+2
| | | | | | | | | | | | | | | | | | | | | 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>
* sev: Add Error ** to sev_kvm_init()David Gibson2021-02-081-16/+15Star
| | | | | | | | | 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>
* confidential guest support: Rework the "memory-encryption" propertyDavid Gibson2021-02-081-30/+2Star
| | | | | | | | | | | | | | | | | | | 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>
* sev: Remove false abstraction of flash encryptionDavid Gibson2021-02-082-10/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* confidential guest support: Introduce new confidential guest support classDavid Gibson2021-02-081-2/+3
| | | | | | | | | | | | | | | | | | | | | 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>
* accel: replace struct CpusAccel with AccelOpsClassClaudio Fontana2021-02-0517-46/+86
| | | | | | | | | | | | | | | 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>
* accel: extend AccelState and AccelClass to user-modeClaudio Fontana2021-02-055-5/+5
| | | | | | | | | | | Signed-off-by: Claudio Fontana <cfontana@suse.de> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> [claudio: rebased on Richard's splitwx work] Signed-off-by: Claudio Fontana <cfontana@suse.de> Message-Id: <20210204163931.7358-17-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
* cpu: tcg_ops: move to tcg-cpu-ops.h, keep a pointer in CPUClassClaudio Fontana2021-02-051-10/+16
| | | | | | | | | | | | | | | | | | | 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>
* cpu: move cc->do_interrupt to tcg_opsClaudio Fontana2021-02-051-1/+1
| | | | | | | | Signed-off-by: Claudio Fontana <cfontana@suse.de> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210204163931.7358-10-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
* cpu: Move debug_excp_handler to tcg_opsEduardo Habkost2021-02-051-1/+1
| | | | | | | | | Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Claudio Fontana <cfontana@suse.de> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210204163931.7358-8-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
* cpu: Move tlb_fill to tcg_opsEduardo Habkost2021-02-051-1/+1
| | | | | | | | | | | | [claudio: wrapped target code in CONFIG_TCG] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Claudio Fontana <cfontana@suse.de> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210204163931.7358-7-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
* cpu: Move cpu_exec_* to tcg_opsEduardo Habkost2021-02-051-3/+3
| | | | | | | | | | | Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> [claudio: wrapped target code in CONFIG_TCG] Signed-off-by: Claudio Fontana <cfontana@suse.de> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210204163931.7358-6-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
* cpu: Move synchronize_from_tb() to tcg_opsEduardo Habkost2021-02-051-1/+1
| | | | | | | | | Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> [claudio: wrapped target code in CONFIG_TCG, reworded comments] Signed-off-by: Claudio Fontana <cfontana@suse.de> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20210204163931.7358-5-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
* cpu: Introduce TCGCpuOperations structEduardo Habkost2021-02-051-1/+1
| | | | | | | | | | | | | | | | 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>
* qapi: Use QAPI_LIST_APPEND in trivial casesEric Blake2021-01-281-16/+8Star
| | | | | | | | | | | | The easiest spots to use QAPI_LIST_APPEND are where we already have an obvious pointer to the tail of a list. While at it, consistently use the variable name 'tail' for that purpose. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20210113221013.390592-5-eblake@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* x86/cpu: Use max host physical address if -cpu max option is appliedYang Weijiang2021-01-211-0/+1
| | | | | | | | | | QEMU option -cpu max(max_features) means "Enables all features supported by the accelerator in the current host", this looks true for all the features except guest max physical address width, so add this patch to enable it. Signed-off-by: Yang Weijiang <weijiang.yang@intel.com> Message-Id: <20210113090430.26394-1-weijiang.yang@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* target/i386: Use X86Seg enum for segment registersPhilippe Mathieu-Daudé2021-01-124-10/+10
| | | | | | | | | Use the dedicated X86Seg enum type for segment registers. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210109233427.749748-1-f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* whpx: move whpx_lapic_state from header to c fileYonggang Luo2021-01-122-7/+7
| | | | | | | | | This struct only used in whpx-apic.c, there is no need expose it in whpx.h. Signed-off-by: Yonggang Luo <luoyonggang@gmail.com> Message-Id: <20210107101919.80-6-luoyonggang@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* whpx: move internal definitions to whpx-internal.hPaolo Bonzini2021-01-122-0/+22
| | | | | | | | | | | Only leave the external interface in sysemu/whpx.h. whpx_apic_in_platform is moved to a .c file because it needs whpx_state. Reported-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20201219090637.1700900-3-pbonzini@redhat.com>
* whpx: rename whp-dispatch to whpx-internal.hPaolo Bonzini2021-01-124-11/+6Star
| | | | | | | | | Rename the file in preparation for moving more implementation-internal definitions to it. The build is still broken though. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20201219090637.1700900-2-pbonzini@redhat.com>
* tcg: Make tb arg to synchronize_from_tb constRichard Henderson2021-01-071-1/+2
| | | | | | | | | | | | There is nothing within the translators that ought to be changing the TranslationBlock data, so make it const. This does not actually use the read-only copy of the data structure that exists within the rx region. Reviewed-by: Joelle van Dyne <j@getutm.app> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>