aboutsummaryrefslogtreecommitdiff
path: root/target-arm/kvm64.c
AgeCommit message (Collapse)Author
2014-05-27target-arm: Make elr_el1 an arrayEdgar E. Iglesias
No functional change. Prepares for future additions of the EL2 and 3 versions of this reg. Reviewed-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Message-id: 1400980132-25949-7-git-send-email-edgar.iglesias@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2014-05-13kvm: reset state from the CPU's reset methodPaolo Bonzini
Now that we have a CPU object with a reset method, it is better to keep the KVM reset close to the CPU reset. Using qemu_register_reset as we do now keeps them far apart. With this patch, PPC no longer calls the kvm_arch_ function, so it can get removed there. Other arches call it from their CPU reset handler, and the function gets an ARMCPU/X86CPU/S390CPU. Note that ARM- and s390-specific functions are called kvm_arm_* and kvm_s390_*, while x86-specific functions are called kvm_arch_*. That follows the convention used by the different architectures. Changing that is the topic of a separate patch. Reviewed-by: Gleb Natapov <gnatapov@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2014-04-17target-arm: Implement AArch64 SPSR_EL1Peter Maydell
Implement the AArch64 SPSR_EL1. For compatibility with how KVM handles SPSRs and with the architectural mapping between AArch32 and AArch64, we put this in the banked_spsr[] array in the slot that is used for SVC in AArch32. This means we need to extend the array from uint32_t to uint64_t, which requires some reworking of the 32 bit KVM save/restore code. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
2014-04-17target-arm: Implement SP_EL0, SP_EL1Peter Maydell
Implement handling for the AArch64 SP_EL0 system register. This holds the EL0 stack pointer, and is only accessible when it's not being used as the stack pointer, ie when we're in EL1 and EL1 is using its own stack pointer. We also provide a definition of the SP_EL1 register; this isn't guest visible as a system register for an implementation like QEMU which doesn't provide EL2 or EL3; however it is useful for ensuring the underlying state is migrated. We need to update the state fields in the CPU state whenever we switch stack pointers; this happens when we take an exception and also when SPSEL is used to change the bit in PSTATE which indicates which stack pointer EL1 should use. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
2014-04-17target-arm: Add AArch64 ELR_EL1 register.Peter Maydell
Add the AArch64 ELR_EL1 register. Note that this does not live in env->cp15: for KVM migration compatibility we need to migrate it separately rather than as part of the system registers, because the KVM-to-userspace interface puts it in the struct kvm_regs rather than making them visible via the ONE_REG ioctls. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
2013-12-17target-arm: Add minimal KVM AArch64 supportMian M. Hamayun
Add the bare minimum set of functions needed for control of an AArch64 KVM vcpu: * CPU initialization * minimal get/put register functions which only handle the basic state of the CPU Signed-off-by: Mian M. Hamayun <m.hamayun@virtualopensystems.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1385645602-18662-4-git-send-email-peter.maydell@linaro.org [PMM: significantly overhauled; most notably: * code lives in kvm64.c rather than using #ifdefs * support '-cpu host' rather than implicitly using whatever the host's CPU is regardless of what the user requests * fix bug attempting to get/set nonexistent X[31] * fix bug writing 64 bit kernel pstate into uint32_t env field ] Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>