Re: [PATCH 2/2] arm64: Support systems without FP/ASIMD

On 25/10/16 15:00, Ard Biesheuvel wrote: Hi Suzuki, On 25 October 2016 at 14:50, Suzuki K Poulose wrote: The arm64 kernel assumes that FP/ASIMD units are always present and accesses the FP/ASIMD specific registers unconditionally. This could cause problems when they

Re: [PATCH 2/2] arm64: Support systems without FP/ASIMD

Hi Suzuki, On 25 October 2016 at 14:50, Suzuki K Poulose wrote: > The arm64 kernel assumes that FP/ASIMD units are always present > and accesses the FP/ASIMD specific registers unconditionally. This > could cause problems when they are absent. This patch adds the >

[PATCH 0/2] arm64: Support systems without FP/ASIMD

This series adds supports to the kernel and KVM hyp to handle systems without FP/ASIMD properly. At the moment the kernel doesn't check if the FP unit is available before accessing the registers (e.g during context switch). Also for KVM, we trap the FP/ASIMD accesses and handle it by injecting an

[PATCH 2/2] arm64: Support systems without FP/ASIMD

The arm64 kernel assumes that FP/ASIMD units are always present and accesses the FP/ASIMD specific registers unconditionally. This could cause problems when they are absent. This patch adds the support for kernel handling systems without FP/ASIMD by skipping the register access within the kernel.

[PATCH 1/2] arm64: Add hypervisor safe helper for checking constant capabilities

The hypervisor may not have full access to the kernel data structures and hence cannot safely use cpus_have_cap() helper for checking the system capability. Add a safe helper for hypervisors to check a constant system capability, which *doesn't* fall back to checking the bitmap maintained by the

Re: [PATCH] arm/arm64: KVM: Perform local TLB invalidation when multiplexing vcpus on a single CPU

Hi Mark, On 24/10/16 17:16, Mark Rutland wrote: > Hi Marc, > > On Mon, Oct 24, 2016 at 04:31:28PM +0100, Marc Zyngier wrote: >> Architecturally, TLBs are private to the (physical) CPU they're >> associated with. But when multiple vcpus from the same VM are >> being multiplexed on the same CPU,