- 08 May, 2017 11 commits
-
-
Eric Auger authored
Up to now the MAPD's ITT size field has been ignored. It encodes the number of eventid bit minus 1. It should be used to check the eventid when a MAPTI command is issued on a device. Let's store the number of eventid bits in the its_device and do the check on MAPTI. Also make sure the ITT size field does not exceed the GITS_TYPER IDBITS field. Signed-off-by:
Eric Auger <eric.auger@redhat.com> Reviewed-by:
Christoffer Dall <cdall@linaro.org> Reviewed-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Eric Auger authored
The GITS_IIDR revision field is used to encode the migration ABI revision. So we need to restore it to check the table layout is readable by the destination. By writing the IIDR, userspace thus forces the ABI revision to be used and this must be less than or equal to the max revision KVM supports. Signed-off-by:
-
Eric Auger authored
We plan to support different migration ABIs, ie. characterizing the ITS table layout format in guest RAM. For example, a new ABI will be needed if vLPIs get supported for nested use case. So let's introduce an array of supported ABIs (at the moment a single ABI is supported though). The following characteristics are foreseen to vary with the ABI: size of table entries, save/restore operation, the way abi settings are applied. By default the MAX_ABI_REV is applied on its creation. In subsequent patches we will introduce a way for the userspace to change the ABI in use. The entry sizes now are set according to the ABI version and not hardcoded anymore. Signed-off-by:
-
Eric Auger authored
GITS_CREADR needs to be restored so let's implement the associated uaccess_write_its callback. The write only is allowed if the its is disabled. Signed-off-by:
-
Eric Auger authored
This patch implements vgic_its_has_attr_regs and vgic_its_attr_regs_access upon the MMIO framework. VGIC ITS KVM device KVM_DEV_ARM_VGIC_GRP_ITS_REGS group becomes functional. At least GITS_CREADR and GITS_IIDR require to differentiate a guest write action from a user access. As such let's introduce a new uaccess_its_write vgic_register_region callback. Signed-off-by:
-
Eric Auger authored
We need to use those helpers in vgic-its.c so let's expose them in the private vgic header. Signed-off-by:
-
Eric Auger authored
The ITS KVM device exposes a new KVM_DEV_ARM_VGIC_GRP_ITS_REGS group which allows the userspace to save/restore ITS registers. At this stage the get/set/has operations are not yet implemented. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Reviewed-by:
-
Eric Auger authored
We plan to use vgic_find_mmio_region in vgic-its.c so let's turn it into a public function. Also let's take the opportunity to rename the region parameter into regions to emphasize this latter is an array of regions. Signed-off-by:
-
Eric Auger authored
The actual abbreviation for the interrupt translation table entry is ITE. Let's rename all itte instances by ite. Signed-off-by:
-
Eric Auger authored
Add description for how to save GICV3 LPI pending bit into guest RAM pending tables. Signed-off-by:
-
Eric Auger authored
Add description for how to access ITS registers and how to save/restore ITS tables into/from memory. Reviewed-by:
-
- 04 May, 2017 1 commit
-
-
Christoffer Dall authored
For some time now we have been having a lot of shared functionality between the arm and arm64 KVM support in arch/arm, which not only required a horrible inter-arch reference from the Makefile in arch/arm64/kvm, but also created confusion for newcomers to the code base, as was recently seen on the mailing list. Further, it causes confusion for things like cscope, which needs special attention to index specific shared files for arm64 from the arm tree. Move the shared files into virt/kvm/arm and move the trace points along with it. When moving the tracepoints we have to modify the way the vgic creates definitions of the trace points, so we take the chance to include the VGIC tracepoints in its very own special vgic trace.h file. Signed-off-by:
-
- 02 May, 2017 1 commit
-
-
Marc Zyngier authored
Our 32bit CP14/15 handling inherited some of the ARMv7 code for handling the trapped system registers, completely missing the fact that the fields for Rt and Rt2 are now 5 bit wide, and not 4... Let's fix it, and provide an accessor for the most common Rt case. Cc: stable@vger.kernel.org Reviewed-by:
-
- 20 Apr, 2017 2 commits
-
-
Marc Zyngier authored
When entering the hyp stub implemented in the idmap, we try to be mindful of the fact that we could be running a Thumb-2 kernel by adding 1 to the address we compute. Unfortunately, the assembler also knows about this trick, and has already generated an address that has bit 0 set in the litteral pool. Our superfluous correction ends up confusing the CPU entierely, as we now branch to the stub in ARM mode instead of Thumb, and on a possibly unaligned address for good measure. From that point, nothing really good happens. The obvious fix in to remove this stupid target PC correction. Fixes: 6bebcecb ("ARM: KVM: Allow the main HYP code to use the init hyp stub implementation") Reported-by:
-
Marc Zyngier authored
The assembler defaults to emiting the short form of ADR, leading to an out-of-range immediate. Using the wide version solves this issue. Fixes: bc845e4f ("ARM: KVM: Implement HVC_RESET_VECTORS stub hypercall in the init code") Reported-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
- 19 Apr, 2017 3 commits
-
-
Marc Zyngier authored
When iterating over the used LRs, be careful not to try to access an unused LR, or even an unimplemented one if you're unlucky... Reviewed-by:
-
Marc Zyngier authored
When emulating a GICv2-on-GICv3, special care must be taken to only save/restore VMCR_EL2 when ICC_SRE_EL1.SRE is cleared. Otherwise, all Group-0 interrupts end-up being delivered as FIQ, which is probably not what the guest expects, as demonstrated here with an unhappy EFI: FIQ Exception at 0x000000013BD21CC4 This means that we cannot perform the load/put trick when dealing with VMCR_EL2 (because the host has SRE set), and we have to deal with it in the world-switch. Fortunately, this is not the most common case (modern guests should be able to deal with GICv3 directly), and the performance is not worse than what it was before the VMCR optimization. Reviewed-by:
-
Andrew Jones authored
Fix potential races in kvm_psci_vcpu_on() by taking the kvm->lock mutex. In general, it's a bad idea to allow more than one PSCI_CPU_ON to process the same target VCPU at the same time. One such problem that may arise is that one PSCI_CPU_ON could be resetting the target vcpu, which fills the entire sys_regs array with a temporary value including the MPIDR register, while another looks up the VCPU based on the MPIDR value, resulting in no target VCPU found. Resolves both races found with the kvm-unit-tests/arm/psci unit test. Reviewed-by:
Levente Kurusa <lkurusa@redhat.com> Suggested-by:
Andrew Jones <drjones@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
-
- 09 Apr, 2017 22 commits
-
-
Christoffer Dall authored
-
Christoffer Dall authored
Now that we support both timers and PMU reporting interrupts to userspace, we can advertise this support. Reviewed-by:
Alexander Graf <agraf@suse.de> Reviewed-by:
Christoffer Dall <christoffer.dall@linaro.org>
-
Christoffer Dall authored
When not using an in-kernel VGIC, but instead emulating an interrupt controller in userspace, we should report the PMU overflow status to that userspace interrupt controller using the KVM_CAP_ARM_USER_IRQ feature. Reviewed-by:
-
Alexander Graf authored
If you're running with a userspace gic or other interrupt controller (that is no vgic in the kernel), then you have so far not been able to use the architected timers, because the output of the architected timers, which are driven inside the kernel, was a kernel-only construct between the arch timer code and the vgic. This patch implements the new KVM_CAP_ARM_USER_IRQ feature, where we use a side channel on the kvm_run structure, run->s.regs.device_irq_level, to always notify userspace of the timer output levels when using a userspace irqchip. This works by ensuring that before we enter the guest, if the timer output level has changed compared to what we last told userspace, we don't enter the guest, but instead return to userspace to notify it of the new level. If we are exiting, because of an MMIO for example, and the level changed at the same time, the value is also updated and userspace can sample the line as it needs. This is nicely achieved simply always updating the timer_irq_level field after the main run loop. Note that the kvm_timer_update_irq trace event is changed to show the host IRQ number for the timer instead of the guest IRQ number, because the kernel no longer know which IRQ userspace wires up the timer signal to. Also note that this patch implements all required functionality but does not yet advertise the capability. Reviewed-by:
-
Alexander Graf authored
We have 2 modes for dealing with interrupts in the ARM world. We can either handle them all using hardware acceleration through the vgic or we can emulate a gic in user space and only drive CPU IRQ pins from there. Unfortunately, when driving IRQs from user space, we never tell user space about events from devices emulated inside the kernel, which may result in interrupt line state changes, so we lose out on for example timer and PMU events if we run with user space gic emulation. Define an ABI to publish such device output levels to userspace. Reviewed-by:
-
Christoffer Dall authored
Currently we check if we have an in-kernel irqchip and if the vgic was properly implemented several places in the arch timer code. But, we already predicate our enablement of the arm timers on having a valid and initialized gic, so we can simply check if the timers are enabled or not. This also gets rid of the ugly "error that's not an error but used to signal that the timer shouldn't poke the gic" construct we have. Reviewed-by:
-
Marc Zyngier authored
In order to help people understanding the hyp-stub API that exists between the host kernel and the hypervisor mode (whether a hypervisor has been installed or not), let's document said API. As with any form of documentation, I expect it to become obsolete and completely misleading within 20 minutes after having being merged. Acked-by:
Russell King <rmk+kernel@armlinux.org.uk> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Marc Zyngier authored
We now return HVC_STUB_ERR when a stub hypercall fails, but we leave whatever was in r0 on success. Zeroing it on return seems like a good idea. Signed-off-by:
-
Marc Zyngier authored
We now return HVC_STUB_ERR when a stub hypercall fails, but we leave whatever was in x0 on success. Zeroing it on return seems like a good idea. Signed-off-by:
-
Marc Zyngier authored
Nobody is using __hyp_get_vectors anymore, so let's remove both implementations (hyp-stub and KVM). Acked-by:
-
Marc Zyngier authored
Nobody is using __hyp_get_vectors anymore, so let's remove both implementations (hyp-stub and KVM). Acked-by:
-
Marc Zyngier authored
When the compressed image needs to be relocated to avoid being overwritten by the decompression process, we need to relocate the hyp vectors as well so that we can find them once the decompression has taken effect. For that, we perform the following calculation: u32 v = __hyp_get_vectors(); v += offset; __hyp_set_vectors(v); But we're guaranteed that the initial value of v as returned by __hyp_get_vectors is always __hyp_stub_vectors, because we have just set it by calling __hyp_stub_install. So let's remove the use of __hyp_get_vectors, and directly use __hyp_stub_vectors instead. Acked-by:
-
Marc Zyngier authored
Instead of trying to compare the value given by __hyp_get_vectors(), which doesn't offer any real guarantee to be the stub's address, use HVC_RESET_VECTORS to make sure we're in a sane state to reinstall KVM across PM events. Acked-by:
-
Marc Zyngier authored
With __cpu_reset_hyp_mode having become fairly dumb, there is no need for kvm_get_idmap_start anymore. Acked-by:
-
Marc Zyngier authored
__cpu_reset_hyp_mode doesn't need to be passed any argument now, as the hyp-stub implementations are self-contained, and is now reduced to just calling __hyp_reset_vectors(). Let's drop the wrapper and use the stub hypercall directly. Acked-by:
-
Marc Zyngier authored
Should kvm_reboot() be invoked while guest is running, an IPI wil be issued, forcing the guest to exit and HYP being reset to the stubs. We will then try to reenter the guest, only to get an error (HVC_STUB_ERR). This patch allows this case to be gracefully handled by exiting the run loop. Signed-off-by:
-
Marc Zyngier authored
Another missing stub hypercall is HVC_SOFT_RESTART. It turns out that it is pretty easy to implement in terms of HVC_RESET_VECTORS (since it needs to turn the MMU off). Tested-by:
Keerthy <j-keerthy@ti.com> Acked-by:
-
Marc Zyngier authored
We are now able to use the hyp stub to reset HYP mode. Time to kiss __kvm_hyp_reset goodbye, and use __hyp_reset_vectors. Tested-by:
-
Marc Zyngier authored
We now have a full hyp-stub implementation in the KVM init code, but the main KVM code only supports HVC_GET_VECTORS, which is not enough. Instead of reinventing the wheel, let's reuse the init implementation by branching to the idmap page when called with a hyp-stub hypercall. Tested-by:
-
Marc Zyngier authored
Now that we have an infrastructure to handle hypercalls in the KVM init code, let's implement HVC_GET_VECTORS there. Tested-by:
-
Marc Zyngier authored
In order to restore HYP mode to its original condition, KVM currently implements __kvm_hyp_reset(). As we're moving towards a hyp-stub defined API, it becomes necessary to implement HVC_RESET_VECTORS. This patch adds the HVC_RESET_VECTORS hypercall to the KVM init code, which so far lacked any form of hypercall support. Tested-by:
-
Marc Zyngier authored
Let's define a new stub hypercall that resets the HYP configuration to its default: hyp-stub vectors, and MMU disabled. Of course, for the hyp-stub itself, this is a trivial no-op. Hypervisors will have a bit more work to do. Tested-by:
-
