Re: [RFC 00/11] KVM, EFI, arm64: EFI Runtime Services Sandboxing

On 25 August 2017 at 01:31, Florent Revest wrote: > Hi, > > This series implements a mechanism to sandbox EFI Runtime Services on arm64. > It can be enabled with CONFIG_EFI_SANDBOX. At boot it spawns an internal KVM > virtual machine that is ran everytime an EFI Runtime

Re: [PATCH v2 03/11] KVM: arm64: Change hyp_panic()s dependency on tpidr_el2

Hi Christoffer, On 17/09/17 15:43, Christoffer Dall wrote: > On Tue, Aug 08, 2017 at 05:46:08PM +0100, James Morse wrote: >> Make tpidr_el2 a cpu-offset for per-cpu variables in the same way the >> host uses tpidr_el1. This lets tpidr_el{1,2} have the same value, and >> on VHE they can be the

[PATCH v3 19/20] KVM: arm/arm64: Get rid of kvm_timer_flush_hwstate

Now when both the vtimer and the ptimer when using both the in-kernel vgic emulation and a userspace IRQ chip are driven by the timer signals and at the vcpu load/put boundaries, instead of recomputing the timer state at every entry/exit to/from the guest, we can get entirely rid of the flush

[PATCH v3 14/20] KVM: arm/arm64: Avoid timer save/restore in vcpu entry/exit

We don't need to save and restore the hardware timer state and examine if it generates interrupts on on every entry/exit to the guest. The timer hardware is perfectly capable of telling us when it has expired by signaling interrupts. When taking a vtimer interrupt in the host, we don't want to

[PATCH v3 02/20] arm64: Use physical counter for in-kernel reads

Using the physical counter allows KVM to retain the offset between the virtual and physical counter as long as it is actively running a VCPU. As soon as a VCPU is released, another thread is scheduled or we start running userspace applications, we reset the offset to 0, so that userspace

[PATCH v3 18/20] KVM: arm/arm64: Avoid phys timer emulation in vcpu entry/exit

There is no need to schedule and cancel a hrtimer when entering and exiting the guest, because we know when the physical timer is going to fire when the guest programs it, and we can simply program the hrtimer at that point. Now when the register modifications from the guest go through the

[PATCH v3 08/20] KVM: arm/arm64: Rename soft timer to bg_timer

As we are about to introduce a separate hrtimer for the physical timer, call this timer bg_timer, because we refer to this timer as the background timer in the code and comments elsewhere. Signed-off-by: Christoffer Dall --- include/kvm/arm_arch_timer.h | 3 +--

[PATCH v3 20/20] KVM: arm/arm64: Rework kvm_timer_should_fire

kvm_timer_should_fire() can be called in two different situations from the kvm_vcpu_block(). The first case is before calling kvm_timer_schedule(), used for wait polling, and in this case the VCPU thread is running and the timer state is loaded onto the hardware so all we have to do is check if

[PATCH v3 04/20] KVM: arm/arm64: Guard kvm_vgic_map_is_active against !vgic_initialized

If the vgic is not initialized, don't try to grab its spinlocks or traverse its data structures. This is important because we soon have to start considering the active state of a virtual interrupts when doing vcpu_load, which may happen early on before the vgic is initialized. Signed-off-by:

[PATCH v3 10/20] KVM: arm/arm64: Move timer/vgic flush/sync under disabled irq

As we are about to play tricks with the timer to be more lazy in saving and restoring state, we need to move the timer sync and flush functions under a disabled irq section and since we have to flush the vgic state after the timer and PMU state, we do the whole flush/sync sequence with disabled

[PATCH v3 12/20] genirq: Document vcpu_info usage for percpu_devid interrupts

It is currently unclear how to set the VCPU affinity for a percpu_devid interrupt , since the Linux irq_data structure describes the state for multiple interrupts, one for each physical CPU on the system. Since each such interrupt can be associated with different VCPUs or none at all, associating

[PATCH v3 03/20] arm64: Use the physical counter when available for read_cycles

Currently get_cycles() is hardwired to arch_counter_get_cntvct() on arm64, but as we move to using the physical timer for the in-kernel time-keeping, we need to make that more flexible. First, we need to make sure the physical counter can be read on equal terms to the virtual counter, which

[PATCH v3 05/20] KVM: arm/arm64: Support calling vgic_update_irq_pending from irq context

We are about to optimize our timer handling logic which involves injecting irqs to the vgic directly from the irq handler. Unfortunately, the injection path can take any AP list lock and irq lock and we must therefore make sure to use spin_lock_irqsave where ever interrupts are enabled and we are

[PATCH v3 17/20] KVM: arm/arm64: Move phys_timer_emulate function

We are about to call phys_timer_emulate() from kvm_timer_update_state() and modify phys_timer_emulate() at the same time. Moving the function and modifying it in a single patch makes the diff hard to read, so do this separately first. No functional change. Signed-off-by: Christoffer Dall

[PATCH v3 06/20] KVM: arm/arm64: Check that system supports split eoi/deactivate

Some systems without proper firmware and/or hardware description data don't support the split EOI and deactivate operation. On such systems, we cannot leave the physical interrupt active after the timer handler on the host has run, so we cannot support KVM with an in-kernel GIC with the timer

[PATCH v3 16/20] KVM: arm/arm64: Use kvm_arm_timer_set/get_reg for guest register traps

When trapping on a guest access to one of the timer registers, we were messing with the internals of the timer state from the sysregs handling code, and that logic was about to receive more added complexity when optimizing the timer handling code. Therefore, since we already have timer register

[PATCH v3 09/20] KVM: arm/arm64: Use separate timer for phys timer emulation

We were using the same hrtimer for emulating the physical timer and for making sure a blocking VCPU thread would be eventually woken up. That worked fine in the previous arch timer design, but as we are about to actually use the soft timer expire function for the physical timer emulation, change

[PATCH v3 11/20] KVM: arm/arm64: Move timer save/restore out of the hyp code

As we are about to be lazy with saving and restoring the timer registers, we prepare by moving all possible timer configuration logic out of the hyp code. All virtual timer registers can be programmed from EL1 and since the arch timer is always a level triggered interrupt we can safely do this

[PATCH v3 00/20] KVM: arm/arm64: Optimize arch timer register handling

We currently spend a measurable amount of time on each entry/exit to the guest dealing with arch timer registers, even when the timer is not pending and not doing anything (on certain architectures). We can do much better by moving the arch timer save/restore to the vcpu_load and vcpu_put

[PATCH v3 13/20] KVM: arm/arm64: Set VCPU affinity for virt timer irq

As we are about to take physical interrupts for the virtual timer on the host but want to leave those active while running the VM (and let the VM deactivate them), we need to set the vtimer PPI affinity accordingly. Signed-off-by: Christoffer Dall --- virt/kvm/arm/arch_timer.c

[PATCH v3 01/20] irqchip/gic: Deal with broken firmware exposing only 4kB of GICv2 CPU interface

From: Marc Zyngier There is a lot of broken firmware out there that don't really expose the information the kernel requires when it comes with dealing with GICv2: (1) Firmware that only describes the first 4kB of GICv2 (2) Firmware that describe 128kB of CPU interface,

Re: [PATCH v6 6/7] KVM: arm64: allow get exception information from userspace

Hi gengdongjiu, On 18/09/17 14:36, gengdongjiu wrote: > On 2017/9/14 21:00, James Morse wrote: >> On 13/09/17 08:32, gengdongjiu wrote: >>> On 2017/9/8 0:30, James Morse wrote: On 28/08/17 11:38, Dongjiu Geng wrote: For BUS_MCEERR_A* from memory_failure() we can't know if they are

Re: [PATCH v6 6/7] KVM: arm64: allow get exception information from userspace

Hi gengdongjiu, On 21/09/17 08:55, gengdongjiu wrote: > On 2017/9/14 21:00, James Morse wrote: >> user-space can choose whether to use SEA or SEI, it doesn't have to choose >> the >> same notification type that firmware used, which in turn doesn't have to be >> the >> same as that used by the

[PATCH v3 11/13] firmware: arm_sdei: add support for CPU private events

Private SDE events are per-cpu, and need to be registered and enabled on each CPU. Hide this detail from the caller by adapting our {,un}register and {en,dis}able calls to send an IPI to each CPU if the event is private. CPU private events are unregistered when the CPU is powered-off, and

[PATCH v3 07/13] firmware: arm_sdei: Add driver for Software Delegated Exceptions

The Software Delegated Exception Interface (SDEI) is an ARM standard for registering callbacks from the platform firmware into the OS. This is typically used to implement firmware notifications (such as firmware-first RAS) or promote an IRQ that has been promoted to a firmware-assisted NMI. Add

[PATCH v3 04/13] arm64: alternatives: use tpidr_el2 on VHE hosts

Now that KVM uses tpidr_el2 in the same way as Linux's cpu_offset in tpidr_el1, merge the two. This saves KVM from save/restoring tpidr_el1 on VHE hosts, and allows future code to blindly access per-cpu variables without triggering world-switch. Signed-off-by: James Morse

[PATCH v3 01/13] KVM: arm64: Store vcpu on the stack during __guest_enter()

KVM uses tpidr_el2 as its private vcpu register, which makes sense for non-vhe world switch as only KVM can access this register. This means vhe Linux has to use tpidr_el1, which KVM has to save/restore as part of the host context. If the SDEI handler code runs behind KVMs back, it mustn't access

[PATCH v3 02/13] KVM: arm/arm64: Convert kvm_host_cpu_state to a static per-cpu allocation

kvm_host_cpu_state is a per-cpu allocation made from kvm_arch_init() used to store the host EL1 registers when KVM switches to a guest. Make it easier for ASM to generate pointers into this per-cpu memory by making it a static allocation. Signed-off-by: James Morse

[PATCH v3 06/13] Docs: dt: add devicetree binding for describing arm64 SDEI firmware

The Software Delegated Exception Interface (SDEI) is an ARM standard for registering callbacks from the platform firmware into the OS. This is typically used to implement RAS notifications, or from an IRQ that has been promoted to a firmware-assisted NMI. Add a new devicetree binding to describe

[PATCH v3 05/13] KVM: arm64: Stop save/restoring host tpidr_el1 on VHE

Now that a VHE host uses tpidr_el2 for the cpu offset we no longer need KVM to save/restore tpidr_el1. Move this from the 'common' code into the non-vhe code. While we're at it, on VHE we don't need to save the ELR or SPSR as kernel_entry in entry.S will have pushed these onto the kernel stack,

[PATCH v3 00/13] arm64/firmware: Software Delegated Exception Interface

Hello! The Software Delegated Exception Interface (SDEI) is an ARM specification for registering callbacks from the platform firmware into the OS. This is intended to be used to implement firmware-first RAS notifications, but also supports vendor-defined events and binding IRQs as events. The

[PATCH v3 03/13] KVM: arm64: Change hyp_panic()s dependency on tpidr_el2

Make tpidr_el2 a cpu-offset for per-cpu variables in the same way the host uses tpidr_el1. This lets tpidr_el{1,2} have the same value, and on VHE they can be the same register. KVM calls hyp_panic() when anything unexpected happens. This may occur while a guest owns the EL1 registers. KVM

[PATCH v3 09/13] arm64: kernel: Add arch-specific SDEI entry code and CPU masking

The Software Delegated Exception Interface (SDEI) is an ARM standard for registering callbacks from the platform firmware into the OS. This is typically used to implement RAS notifications. Such notifications enter the kernel at the registered entry-point with the register values of the

[PATCH v3 12/13] arm64: acpi: Remove __init from acpi_psci_use_hvc() for use by SDEI

SDEI inherits the 'use hvc' bit that is also used by PSCI. PSCI does all its initialisation early, SDEI does its late. Remove the __init annotation from acpi_psci_use_hvc(). Signed-off-by: James Morse --- The function name is unchanged as this bit is named 'PSCI_USE_HVC' in

[PATCH v3 10/13] firmware: arm_sdei: Add support for CPU and system power states

When a CPU enters an idle lower-power state or is powering off, we need to mask SDE events so that no events can be delivered while we are messing with the MMU as the registered entry points won't be valid. If the system reboots, we want to unregister all events and mask the CPUs. For kexec this

[PATCH v3 08/13] arm64: Add vmap_stack header file

Today the arm64 arch code allocates an extra IRQ stack per-cpu. If we also have SDEI and VMAP stacks we need two extra per-cpu VMAP stacks. Move the VMAP stack allocation out to a helper in a new header file. This avoids missing THREADINFO_GFP, or getting the all-important alignment wrong.

[PATCH v3 13/13] firmware: arm_sdei: Discover SDEI support via ACPI

SDEI defines a new ACPI table to indicate the presence of the interface. The conduit is discovered in the same way as PSCI. For ACPI we need to create the platform device ourselves as SDEI doesn't have an entry in the DSDT. The SDEI platform device should be created after ACPI has been