aboutsummaryrefslogtreecommitdiffstats
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2019-10-23arm64: defconfig: enable rsu driverRichard Gong1-0/+1
Enable Intel Stratix10 Remote System Update (RSU) driver The Intel Remote System Update (RSU) driver provides a way for customers to update the boot configuration of a Intel Stratix 10 SoC device with significantly reduced risk of corrupting the bitstream storage and bricking the system. Signed-off-by: Richard Gong <richard.gong@intel.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2019-10-23arm64: zynqmp: Add support for zynqmp nvmem firmware driverNava kishore Manne1-0/+10
Add support for zynqmp nvmem firmware driver. Signed-off-by: Nava kishore Manne <nava.manne@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> [m.tretter@pengutronix.de: move to subnode of firmware] Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
2019-10-23arm64: zynqmp: Label whole PL part as fpga_full regionNava kishore Manne1-0/+8
This will simplify dt overlay structure for the whole PL. Signed-off-by: Nava kishore Manne <nava.manne@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
2019-10-23arm64: zynqmp: Add support for zynqmp fpga managerNava kishore Manne1-0/+4
Add support for zynqmp fpga manager. Signed-off-by: Nava kishore Manne <nava.manne@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> [m.tretter@pengutronix.de: moved to subnode of firmware] Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
2019-10-23arm64: zynqmp: Add firmware DT nodeRajan Vaja1-0/+7
Add firmware DT node in ZynqMP device tree. This node uses bindings as per new firmware interface driver. Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
2019-10-23Merge tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-armLinus Torvalds6-33/+62
:Pull ARM fixes from Russell King: - fix for alignment faults under high memory pressure - use u32 for ARM instructions in fault handler - mark functions that must always be inlined with __always_inline - fix for nommu XIP - fix ARMv7M switch to handler mode in reboot path - fix the recently introduced AMBA reset control error paths * tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm: ARM: 8926/1: v7m: remove register save to stack before svc ARM: 8914/1: NOMMU: Fix exc_ret for XIP ARM: 8908/1: add __always_inline to functions called from __get_user_check() ARM: mm: alignment: use "u32" for 32-bit instructions ARM: mm: fix alignment handler faults under memory pressure drivers/amba: fix reset control error handling
2019-10-23crypto: s390/des - convert to skcipher APIEric Biggers1-247/+172
Convert the glue code for the S390 CPACF implementations of DES-ECB, DES-CBC, DES-CTR, 3DES-ECB, 3DES-CBC, and 3DES-CTR from the deprecated "blkcipher" API to the "skcipher" API. This is needed in order for the blkcipher API to be removed. Note: I made CTR use the same function for encryption and decryption, since CTR encryption and decryption are identical. Signed-off-by: Eric Biggers <ebiggers@google.com> reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-23crypto: s390/paes - convert to skcipher APIEric Biggers1-240/+174
Convert the glue code for the S390 CPACF protected key implementations of AES-ECB, AES-CBC, AES-XTS, and AES-CTR from the deprecated "blkcipher" API to the "skcipher" API. This is needed in order for the blkcipher API to be removed. Note: I made CTR use the same function for encryption and decryption, since CTR encryption and decryption are identical. Signed-off-by: Eric Biggers <ebiggers@google.com> reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-23crypto: s390/aes - convert to skcipher APIEric Biggers1-375/+234
Convert the glue code for the S390 CPACF implementations of AES-ECB, AES-CBC, AES-XTS, and AES-CTR from the deprecated "blkcipher" API to the "skcipher" API. This is needed in order for the blkcipher API to be removed. Note: I made CTR use the same function for encryption and decryption, since CTR encryption and decryption are identical. Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-23crypto: sparc/des - convert to skcipher APIEric Biggers1-272/+227
Convert the glue code for the SPARC64 DES opcodes implementations of DES-ECB, DES-CBC, 3DES-ECB, and 3DES-CBC from the deprecated "blkcipher" API to the "skcipher" API. This is needed in order for the blkcipher API to be removed. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-23crypto: sparc/camellia - convert to skcipher APIEric Biggers1-122/+95
Convert the glue code for the SPARC64 Camellia opcodes implementations of Camellia-ECB and Camellia-CBC from the deprecated "blkcipher" API to the "skcipher" API. This is needed in order for the blkcipher API to be removed. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-23crypto: sparc/aes - convert to skcipher APIEric Biggers1-167/+143
Convert the glue code for the SPARC64 AES opcodes implementations of AES-ECB, AES-CBC, and AES-CTR from the deprecated "blkcipher" API to the "skcipher" API. This is needed in order for the blkcipher API to be removed. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-23crypto: arm - use Kconfig based compiler checks for crypto opcodesArd Biesheuvel7-33/+19
Instead of allowing the Crypto Extensions algorithms to be selected when using a toolchain that does not support them, and complain about it at build time, use the information we have about the compiler to prevent them from being selected in the first place. Users that are stuck with a GCC version <4.8 are unlikely to care about these routines anyway, and it cleans up the Makefile considerably. While at it, add explicit 'armv8-a' CPU specifiers to the code that uses the 'crypto-neon-fp-armv8' FPU specifier so we don't regress Clang, which will complain about this in version 10 and later. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-10-22ARM: dts: mmp3: add Dell Wyse 3020 machineLubomir Rintel2-1/+92
This is a Dell Wyse thin client, variously referred to as "Ariel", "3020" or "Tx0D" where "x" stands for the software it was shipped with. I somewhat arbitrarily chose "ariel". There are bits missing, because the drivers are not in and bindings are not settled yet: * Things missing from mmp3.dtsi: HSIC controller and its PHY (only the internal Ethernet is connected here, the hub with external USB2 ports is connected to the U2O controller that works well), Vivante GC2000 GPU * &twsi1/regulator@19 Marvell 88pm867 power regulator * &twsi3/vga-dvi-encoder@76 Chrontel CH7033B-BF VGA & DVI encoder * &twsi3/sound-codec@30 Sound chip, probably a Marvell 88ce156 * &twsi4/embedded-controller@58 ENE KB3930QF Embedded Controller, also seems to be connected to &ssp4. Might not need a driver -- about the only useful thing it can do is to reboot the machine when tickled via some GPIO lines. Also there seems to be something at &twsi1 address 0x50. Link: https://lore.kernel.org/r/20191022152837.3553524-1-lkundrak@v3.sk Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Signed-off-by: Olof Johansson <olof@lixom.net>
2019-10-22Merge tag 'actions-arm64-dt-for-v5.5' of git://git.kernel.org/pub/scm/linux/kernel/git/mani/linux-actions into arm/dtOlof Johansson2-0/+107
Actions Semi ARM64 changes for v5.5: Most of the basic infrastructure is completed for the ARM64 S900 SoC. It can now boot a distro from eMMC/uSD with mainline kernel. Below are the changes for this cycle (only S900): - Added MMC controller support for S900 SoC. There are 4 controllers in this SoC, each capable of accessing MMC cards as well as SDIO. - Added onboard eMMC and uSD support for 96Boards Bubblegum96 board based on S900. Since the MMC driver is not capable of supporting SDIO currently, it is not enabled for now. And with the absence of PMIC support, fixed regulators are used to model the power supply. * tag 'actions-arm64-dt-for-v5.5' of git://git.kernel.org/pub/scm/linux/kernel/git/mani/linux-actions: arm64: dts: actions: Add uSD and eMMC support for Bubblegum96 arm64: dts: actions: Add MMC controller support for S900 Link: https://lore.kernel.org/r/20191022145012.GB3601@Mani-XPS-13-9360 Signed-off-by: Olof Johansson <olof@lixom.net>
2019-10-22KVM: nVMX: Don't leak L1 MMIO regions to L2Jim Mattson4-32/+55
If the "virtualize APIC accesses" VM-execution control is set in the VMCS, the APIC virtualization hardware is triggered when a page walk in VMX non-root mode terminates at a PTE wherein the address of the 4k page frame matches the APIC-access address specified in the VMCS. On hardware, the APIC-access address may be any valid 4k-aligned physical address. KVM's nVMX implementation enforces the additional constraint that the APIC-access address specified in the vmcs12 must be backed by a "struct page" in L1. If not, L0 will simply clear the "virtualize APIC accesses" VM-execution control in the vmcs02. The problem with this approach is that the L1 guest has arranged the vmcs12 EPT tables--or shadow page tables, if the "enable EPT" VM-execution control is clear in the vmcs12--so that the L2 guest physical address(es)--or L2 guest linear address(es)--that reference the L2 APIC map to the APIC-access address specified in the vmcs12. Without the "virtualize APIC accesses" VM-execution control in the vmcs02, the APIC accesses in the L2 guest will directly access the APIC-access page in L1. When there is no mapping whatsoever for the APIC-access address in L1, the L2 VM just loses the intended APIC virtualization. However, when the APIC-access address is mapped to an MMIO region in L1, the L2 guest gets direct access to the L1 MMIO device. For example, if the APIC-access address specified in the vmcs12 is 0xfee00000, then L2 gets direct access to L1's APIC. Since this vmcs12 configuration is something that KVM cannot faithfully emulate, the appropriate response is to exit to userspace with KVM_INTERNAL_ERROR_EMULATION. Fixes: fe3ef05c7572 ("KVM: nVMX: Prepare vmcs02 from vmcs01 and vmcs12") Reported-by: Dan Cross <dcross@google.com> Signed-off-by: Jim Mattson <jmattson@google.com> Reviewed-by: Peter Shier <pshier@google.com> Reviewed-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-22ARC: perf: Accommodate big-endian CPUAlexey Brodkin1-2/+2
8-letter strings representing ARC perf events are stores in two 32-bit registers as ASCII characters like that: "IJMP", "IALL", "IJMPTAK" etc. And the same order of bytes in the word is used regardless CPU endianness. Which means in case of big-endian CPU core we need to swap bytes to get the same order as if it was on little-endian CPU. Otherwise we're seeing the following error message on boot: ------------------------->8---------------------- ARC perf : 8 counters (32 bits), 40 conditions, [overflow IRQ support] sysfs: cannot create duplicate filename '/devices/arc_pct/events/pmji' CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.2.18 #3 Stack Trace: arc_unwind_core+0xd4/0xfc dump_stack+0x64/0x80 sysfs_warn_dup+0x46/0x58 sysfs_add_file_mode_ns+0xb2/0x168 create_files+0x70/0x2a0 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at kernel/events/core.c:12144 perf_event_sysfs_init+0x70/0xa0 Failed to register pmu: arc_pct, reason -17 Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.2.18 #3 Stack Trace: arc_unwind_core+0xd4/0xfc dump_stack+0x64/0x80 __warn+0x9c/0xd4 warn_slowpath_fmt+0x22/0x2c perf_event_sysfs_init+0x70/0xa0 ---[ end trace a75fb9a9837bd1ec ]--- ------------------------->8---------------------- What happens here we're trying to register more than one raw perf event with the same name "PMJI". Why? Because ARC perf events are 4 to 8 letters and encoded into two 32-bit words. In this particular case we deal with 2 events: * "IJMP____" which counts all jump & branch instructions * "IJMPC___" which counts only conditional jumps & branches Those strings are split in two 32-bit words this way "IJMP" + "____" & "IJMP" + "C___" correspondingly. Now if we read them swapped due to CPU core being big-endian then we read "PMJI" + "____" & "PMJI" + "___C". And since we interpret read array of ASCII letters as a null-terminated string on big-endian CPU we end up with 2 events of the same name "PMJI". Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: stable@vger.kernel.org Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
2019-10-22ARC: [plat-hsdk]: Enable on-boardi SPI ADC ICEugeniy Paltsev2-0/+19
HSDK board has adc108s102 SPI ADC IC installed, enable it. Acked-by: Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
2019-10-22ARC: [plat-hsdk]: Enable on-board SPI NOR flash ICEugeniy Paltsev2-0/+10
HSDK board has sst26wf016b SPI NOR flash IC installed, enable it. Acked-by: Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
2019-10-22KVM: SVM: Fix potential wrong physical id in avic_handle_ldr_updateMiaohe Lin3-8/+8
Guest physical APIC ID may not equal to vcpu->vcpu_id in some case. We may set the wrong physical id in avic_handle_ldr_update as we always use vcpu->vcpu_id. Get physical APIC ID from vAPIC page instead. Export and use kvm_xapic_id here and in avic_handle_apic_id_update as suggested by Vitaly. Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-22Merge branch 'misc' into fixesRussell King15-30/+349
2019-10-22ARM: dts: omap: Rename "ocmcram" node to "sram"Krzysztof Kozlowski2-2/+2
The device node name should reflect generic class of a device so rename the "ocmcram" node to "sram". This will be also in sync with upcoming DT schema. No functional change. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-22ARM: dts: logicpd-torpedo-37xx-devkit: Increase camera pixel clockAdam Ford1-0/+5
The default settings used on the baseboard are good for the OMAP3530 and are compatible with the DM3730. However, the DM3730 has a faster L3 clock which means the camera pixel clock can also be pushed faster as well. This patch increase the Pixel clock to 90MHz which is the maximum the current ISP driver permits for an L3 clock of 200MHz. Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-22ARM: dts: am: Rename "ocmcram" node to "sram"Krzysztof Kozlowski2-6/+6
The device node name should reflect generic class of a device so rename the "ocmcram" node and its children to "sram". This will be also in sync with upcoming DT schema. No functional change. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-22ARM: dts: logicpd-torpedo: Disable Bluetooth Serial DMAAdam Ford1-0/+1
The default serial driver for omap2plus is the 8250_omap driver. Unfortunately, this driver does not yet appear to have fully functional DMA on OMAP3630/DM3730 which causes some timeouts and frame errors. This patch removes the DMA entry from the device tree which allow the UART to operate without Bluetooth frame errors. If/when DMA is working on OMAP3630, this should be reverted. Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-22configs: omap2plus: Enable VIDEO_MT9P031 moduleAdam Ford1-0/+1
The Logic PD Torpedo Development Kit supports a Leopard Imaging camera based on the Aptina MT9P031 sensor. This patch enables this to be built as a module. Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-22ARM: OMAP1: ams-delta FIQ: Fix a typo ("Initiaize")Jonathan Neuschäfer1-1/+1
Fix a typo ("Initiaize"). Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Message-Id: <20191002145301.11332-1-j.neuschaefer@gmx.net> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-22ARM: OMAP2+: pdata-quirks: drop TI_ST/KIM supportSebastian Reichel1-52/+0
All TI_ST users have been migrated to the new serdev based HCILL bluetooth driver. That driver is initialized from DT and does not need any platform quirks. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-22ARM: dts: IGEP: Add WiLink UART nodeSebastian Reichel2-0/+16
Add a node for the UART part of WiLink chip. Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-22ARM: dts: LogicPD Torpedo: Add WiLink UART nodeSebastian Reichel1-0/+8
Add a node for the UART part of WiLink chip. This is compile tested only! Cc: Adam Ford <aford173@gmail.com> Acked-by: Adam Ford <aford173@gmail.com> Tested-by: Adam Ford <aford173@gmail.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-10-22s390/kaslr: add support for R_390_GLOB_DAT relocation typeGerald Schaefer2-3/+12
Commit "bpf: Process in-kernel BTF" in linux-next introduced an undefined __weak symbol, which results in an R_390_GLOB_DAT relocation type. That is not yet handled by the KASLR relocation code, and the kernel stops with the message "Unknown relocation type". Add code to detect and handle R_390_GLOB_DAT relocation types and undefined symbols. Fixes: 805bc0bc238f ("s390/kernel: build a relocatable kernel") Cc: <stable@vger.kernel.org> # v5.2+ Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-10-22arm64: dts: actions: Add uSD and eMMC support for Bubblegum96Manivannan Sadhasivam1-0/+62
Add uSD and eMMC support for Bubblegum96 board based on Actions Semi S900 SoC. SD0 is connected to uSD slot and SD2 is connected to eMMC. Since there is no PMIC support added yet, fixed regulator has been used as a regulator node. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2019-10-22arm64: dts: actions: Add MMC controller support for S900Manivannan Sadhasivam1-0/+45
Add MMC controller support for Actions Semi S900 SoC. There are 4 MMC controllers in this SoC which can be used for accessing SD/MMC/SDIO cards. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2019-10-22KVM: Add separate helper for putting borrowed reference to kvmSean Christopherson2-2/+2
Add a new helper, kvm_put_kvm_no_destroy(), to handle putting a borrowed reference[*] to the VM when installing a new file descriptor fails. KVM expects the refcount to remain valid in this case, as the in-progress ioctl() has an explicit reference to the VM. The primary motiviation for the helper is to document that the 'kvm' pointer is still valid after putting the borrowed reference, e.g. to document that doing mutex(&kvm->lock) immediately after putting a ref to kvm isn't broken. [*] When exposing a new object to userspace via a file descriptor, e.g. a new vcpu, KVM grabs a reference to itself (the VM) prior to making the object visible to userspace to avoid prematurely freeing the VM in the scenario where userspace immediately closes file descriptor. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-22kvm: svm: Update svm_xsaves_supportedAaron Lewis1-1/+1
AMD CPUs now support XSAVES in a limited fashion (they require IA32_XSS to be zero). AMD has no equivalent of Intel's "Enable XSAVES/XRSTORS" VM-execution control. Instead, XSAVES is always available to the guest when supported on the host. Reviewed-by: Jim Mattson <jmattson@google.com> Signed-off-by: Aaron Lewis <aaronlewis@google.com> Change-Id: I40dc2c682eb0d38c2208d95d5eb7bbb6c47f6317 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-22kvm: x86: Move IA32_XSS to kvm_{get,set}_msr_commonAaron Lewis2-18/+20
Hoist support for RDMSR/WRMSR of IA32_XSS from vmx into common code so that it can be used for svm as well. Right now, kvm only allows the guest IA32_XSS to be zero, so the guest's usage of XSAVES will be exactly the same as XSAVEC. Reviewed-by: Jim Mattson <jmattson@google.com> Signed-off-by: Aaron Lewis <aaronlewis@google.com> Change-Id: Ie4b0f777d71e428fbee6e82071ac2d7618e9bb40 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-22KVM: x86: Move IA32_XSS-swapping on VM-entry/VM-exit to common x86 codeAaron Lewis4-62/+34
Hoist the vendor-specific code related to loading the hardware IA32_XSS MSR with guest/host values on VM-entry/VM-exit to common x86 code. Reviewed-by: Jim Mattson <jmattson@google.com> Signed-off-by: Aaron Lewis <aaronlewis@google.com> Change-Id: Ic6e3430833955b98eb9b79ae6715cf2a3fdd6d82 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-22KVM: VMX: Use wrmsr for switching between guest and host IA32_XSS on IntelAaron Lewis1-7/+18
When the guest can execute the XSAVES/XRSTORS instructions, use wrmsr to set the hardware IA32_XSS MSR to guest/host values on VM-entry/VM-exit, rather than the MSR-load areas. By using the same approach as AMD, we will be able to use a common implementation for both (in the next patch). Reviewed-by: Jim Mattson <jmattson@google.com> Signed-off-by: Aaron Lewis <aaronlewis@google.com> Change-Id: I9447d104b2615c04e39e4af0c911e1e7309bf464 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-22KVM: SVM: Use wrmsr for switching between guest and host IA32_XSS on AMDAaron Lewis1-0/+23
When the guest can execute the XSAVES/XRSTORS instructions, set the hardware IA32_XSS MSR to guest/host values on VM-entry/VM-exit. Note that vcpu->arch.ia32_xss is currently guaranteed to be 0 on AMD, since there is no way to change it. Suggested-by: Sean Christopherson <sean.j.christopherson@intel.com> Reviewed-by: Jim Mattson <jmattson@google.com> Signed-off-by: Aaron Lewis <aaronlewis@google.com> Change-Id: Id51a782462086e6d7a3ab621838e200f1c005afd Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-22KVM: x86: Remove unneeded kvm_vcpu variable, guest_xcr0_loadedAaron Lewis1-11/+5
The kvm_vcpu variable, guest_xcr0_loaded, is a waste of an 'int' and a conditional branch. VMX and SVM are the only users, and both unconditionally pair kvm_load_guest_xcr0() with kvm_put_guest_xcr0() making this check unnecessary. Without this variable, the predicates in kvm_load_guest_xcr0 and kvm_put_guest_xcr0 should match. Suggested-by: Sean Christopherson <sean.j.christopherson@intel.com> Reviewed-by: Jim Mattson <jmattson@google.com> Signed-off-by: Aaron Lewis <aaronlewis@google.com> Change-Id: I7b1eb9b62969d7bbb2850f27e42f863421641b23 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-22KVM: VMX: Fix conditions for guest IA32_XSS supportAaron Lewis1-13/+11
Volume 4 of the SDM says that IA32_XSS is supported if CPUID(EAX=0DH,ECX=1):EAX.XSS[bit 3] is set, so only the X86_FEATURE_XSAVES check is necessary (X86_FEATURE_XSAVES is the Linux name for CPUID(EAX=0DH,ECX=1):EAX.XSS[bit 3]). Fixes: 4d763b168e9c5 ("KVM: VMX: check CPUID before allowing read/write of IA32_XSS") Reviewed-by: Jim Mattson <jmattson@google.com> Signed-off-by: Aaron Lewis <aaronlewis@google.com> Change-Id: I9059b9f2e3595e4b09a4cdcf14b933b22ebad419 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-22KVM: x86: Introduce vcpu->arch.xsaves_enabledAaron Lewis3-0/+9
Cache whether XSAVES is enabled in the guest by adding xsaves_enabled to vcpu->arch. Reviewed-by: Jim Mattson <jmattson@google.com> Signed-off-by: Aaron Lewis <aaronlewis@google.com> Change-Id: If4638e0901c28a4494dad2e103e2c075e8ab5d68 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-22x86/kdump: Remove the unused crash_copy_backup_region()Lianbo Jiang1-1/+0
The crash_copy_backup_region() function is unused so remove it. Signed-off-by: Lianbo Jiang <lijiang@redhat.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: bhe@redhat.com Cc: dhowells@redhat.com Cc: dyoung@redhat.com Cc: ebiederm@xmission.com Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jürgen Gross <jgross@suse.com> Cc: kexec@lists.infradead.org Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: vgoyal@redhat.com Cc: x86-ml <x86@kernel.org> Cc: Yi Wang <wang.yi59@zte.com.cn> Link: https://lkml.kernel.org/r/20191017094347.20327-3-lijiang@redhat.com
2019-10-22KVM: VMX: Rename {vmx,nested_vmx}_vcpu_setup()Xiaoyao Li3-6/+7
Rename {vmx,nested_vmx}_vcpu_setup() to match what they really do. Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-22KVM: VMX: Initialize vmx->guest_msrs[] right after allocationXiaoyao Li1-18/+16
Move the initialization of vmx->guest_msrs[] from vmx_vcpu_setup() to vmx_create_vcpu(), and put it right after its allocation. This also is the preperation for next patch. Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-22KVM: VMX: Remove vmx->hv_deadline_tsc initialization from vmx_vcpu_setup()Xiaoyao Li1-1/+0
... It can be removed here because the same code is called later in vmx_vcpu_reset() as the flow: kvm_arch_vcpu_setup() -> kvm_vcpu_reset() -> vmx_vcpu_reset() Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-22KVM: VMX: Write VPID to vmcs when creating vcpuXiaoyao Li1-3/+3
Move the code that writes vmx->vpid to vmcs from vmx_vcpu_reset() to vmx_vcpu_setup(), because vmx->vpid is allocated when creating vcpu and never changed. So we don't need to update the vmcs.vpid when resetting vcpu. Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-22KVM: x86/vPMU: Declare kvm_pmu->reprogram_pmi field using DECLARE_BITMAPLike Xu2-11/+6
Replace the explicit declaration of "u64 reprogram_pmi" with the generic macro DECLARE_BITMAP for all possible appropriate number of bits. Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Like Xu <like.xu@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-22KVM: remove redundant code in kvm_arch_vm_ioctlMiaohe Lin1-3/+0
If we reach here with r = 0, we will reassign r = 0 unnecesarry, then do the label set_irqchip_out work. If we reach here with r != 0, then we will do the label work directly. So this if statement and r = 0 assignment is redundant. Signed-off-by: Miaohe Lin <linmiaohe@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-22kvm: x86: Modify kvm_x86_ops.get_enable_apicv() to use struct kvm parameterSuthikulpanit, Suravee4-5/+5
Generally, APICv for all vcpus in the VM are enable/disable in the same manner. So, get_enable_apicv() should represent APICv status of the VM instead of each VCPU. Modify kvm_x86_ops.get_enable_apicv() to take struct kvm as parameter instead of struct kvm_vcpu. Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>