Re: [PATCH v2] KVM: arm/arm64: Fix external abort type matching

On 2017/10/28 2:28, Marc Zyngier wrote: >> kvm_vcpu_trap_get_fault_type() will clear the low two bits to zero. So >> I use FSC_SEA_TTW represent "Synchronous external abort on translation >> table walk" > I understand that, and I certainly not keen on adding another "fault > type" for this. Ok,

Re: [PATCH v2] KVM: arm/arm64: Fix external abort type matching

On Fri, Oct 27 2017 at 3:43:26 pm GMT, gengdongjiu wrote: >> >> On Thu, Oct 26 2017 at 6:07:01 pm BST, Dongjiu Geng >> wrote: >> > For this matching, current code using the {I,D}FSC range to match >> > kvm_vcpu_trap_get_fault_type() return

Re: [PATCH v4 20/28] arm64/sve: Add prctl controls for userspace vector length management

Dave Martin writes: > This patch adds two arm64-specific prctls, to permit userspace to > control its vector length: > > * PR_SVE_SET_VL: set the thread's SVE vector length and vector >length inheritance mode. > > * PR_SVE_GET_VL: get the same information. > >

Re: [PATCH v4 19/21] KVM: arm64: Handle RAS SErrors from EL2 on guest exit

Hi gengdongjiu, On 27/10/17 07:26, gengdongjiu wrote: > On 2017/10/19 22:58, James Morse wrote: >> +alternative_if ARM64_HAS_RAS_EXTN >> +// If we have the RAS extensions we can consume a pending error >> +// without an unmask-SError and isb. >> +esb >> +mrs_s x2, SYS_DISR_EL1

re: [PATCH v2] KVM: arm/arm64: Fix external abort type matching

> > On Thu, Oct 26 2017 at 6:07:01 pm BST, Dongjiu Geng > wrote: > > For this matching, current code using the {I,D}FSC range to match > > kvm_vcpu_trap_get_fault_type() return value, but > > kvm_vcpu_trap_get_fault_type() only return the part {I,D}FSC instead > > of

Re: [PATCH v2] KVM: arm/arm64: Fix external abort type matching

On Thu, Oct 26 2017 at 6:07:01 pm BST, Dongjiu Geng wrote: > For this matching, current code using the {I,D}FSC > range to match kvm_vcpu_trap_get_fault_type() return > value, but kvm_vcpu_trap_get_fault_type() only return > the part {I,D}FSC instead of whole, so fix

[PATCH v5 25/26] KVM: arm/arm64: GICv4: Enable VLPI support

All it takes is the has_v4 flag to be set in gic_kvm_info as well as "kvm-arm.vgic_v4_enable=1" being passed on the command line for GICv4 to be enabled in KVM. Acked-by: Christoffer Dall Signed-off-by: Marc Zyngier ---

[PATCH v5 22/26] KVM: arm/arm64: GICv4: Enable virtual cpuif if VLPIs can be delivered

In order for VLPIs to be delivered to the guest, we must make sure that the cpuif is always enabled, irrespective of the presence of virtual interrupt in the LRs. Acked-by: Christoffer Dall Signed-off-by: Marc Zyngier --- virt/kvm/arm/hyp/vgic-v3-sr.c |

[PATCH v5 26/26] KVM: arm/arm64: GICv4: Theory of operations

Yet another braindump so I can free some cells... Acked-by: Christoffer Dall Signed-off-by: Marc Zyngier --- virt/kvm/arm/vgic/vgic-v4.c | 67 + 1 file changed, 67 insertions(+) diff --git

[PATCH v5 17/26] KVM: arm/arm64: GICv4: Handle INVALL applied to a vPE

Since when updating the properties one LPI at a time, there is no need to perform an INV each time we read one. Instead, we rely on the final VINVALL that gets sent to the ITS to do the work. Acked-by: Christoffer Dall Signed-off-by: Marc Zyngier ---

[PATCH v5 19/26] KVM: arm/arm64: GICv4: Add doorbell interrupt handling

When a vPE is not running, a VLPI being made pending results in a doorbell interrupt being delivered. Let's handle this interrupt and update the pending_last flag that indicates that VLPIs are pending. The corresponding vcpu is also kicked into action. Special care is taken to prevent the

[PATCH v5 24/26] KVM: arm/arm64: GICv4: Prevent userspace from changing doorbell affinity

We so far allocate the doorbell interrupts without taking any special measure regarding the affinity of these interrupts. We simply move them around as required when the vcpu gets scheduled on a different CPU. But that's counting without userspace (and the evil irqbalance) that can try and move

[PATCH v5 23/26] KVM: arm/arm64: GICv4: Prevent a VM using GICv4 from being saved

The GICv4 architecture doesn't make it easy for save/restore to work, as it doesn't give any guarantee that the pending state is written into the pending table. So let's not take any chance, and let's return an error if we encounter any LPI that has the HW bit set. In order for userspace to

[PATCH v5 18/26] KVM: arm/arm64: GICv4: Use pending_last as a scheduling hint

When a vPE exits, the pending_last flag is set when there are pending VLPIs stored in the pending table. Similarily, we set this flag when a doorbell interrupt fires, as it indicates the same condition. Let's update kvm_vgic_vcpu_pending_irq() to account for that flag as well, making a vcpu

[PATCH v5 21/26] KVM: arm/arm64: GICv4: Hook vPE scheduling into vgic flush/sync

The redistributor needs to be told which vPE is about to be run, and tells us whether there is any pending VLPI on exit. Let's add the scheduling calls to the vgic flush/sync functions, allowing the VLPIs to be delivered to the guest. Reviewed-by: Christoffer Dall

[PATCH v5 20/26] KVM: arm/arm64: GICv4: Use the doorbell interrupt as an unblocking source

The doorbell interrupt is only useful if the vcpu is blocked on WFI. In all other cases, recieving a doorbell interrupt is just a waste of cycles. So let's only enable the doorbell if a vcpu is getting blocked, and disable it when it is unblocked. This is very similar to what we're doing for the

[PATCH v5 14/26] KVM: arm/arm64: GICv4: Handle CLEAR applied to a VLPI

Handling CLEAR is pretty easy. Just ask the ITS driver to clear the corresponding pending bit (which will turn into a CLEAR command on the physical side). Acked-by: Christoffer Dall Signed-off-by: Marc Zyngier --- virt/kvm/arm/vgic/vgic-its.c | 4 1

[PATCH v5 16/26] KVM: arm/arm64: GICv4: Propagate property updates to VLPIs

Upon updating a property, we propagate it all the way to the physical ITS, and ask for an INV command to be executed there. Acked-by: Christoffer Dall Signed-off-by: Marc Zyngier --- virt/kvm/arm/vgic/vgic-its.c | 3 +++ 1 file changed, 3 insertions(+)

[PATCH v5 15/26] KVM: arm/arm64: GICv4: Handle MOVALL applied to a vPE

The current implementation of MOVALL doesn't allow us to call into the core ITS code as we hold a number of spinlocks. Let's try a method used in other parts of the code, were we copy the intids of the candicate interrupts, and then do whatever we need to do with them outside of the critical

[PATCH v5 10/26] KVM: arm/arm64: GICv4: Wire mapping/unmapping of VLPIs in VFIO irq bypass

Let's use the irq bypass mechanism introduced for platform device interrupts to intercept the virtual PCIe endpoint configuration and establish our LPI->VLPI mapping. Reviewed-by: Christoffer Dall Signed-off-by: Marc Zyngier ---

[PATCH v5 12/26] KVM: arm/arm64: GICv4: Unmap VLPI when freeing an LPI

When freeing an LPI (on a DISCARD command, for example), we need to unmap the VLPI down to the physical ITS level. Acked-by: Christoffer Dall Signed-off-by: Marc Zyngier --- virt/kvm/arm/vgic/vgic-its.c | 6 +- 1 file changed, 5 insertions(+), 1

[PATCH v5 09/26] KVM: arm/arm64: GICv4: Add init/teardown of the per-VM vPE irq domain

In order to control the GICv4 view of virtual CPUs, we rely on an irqdomain allocated for that purpose. Let's add a couple of helpers to that effect. At the same time, the vgic data structures gain new fields to track all this... erm... wonderful stuff. The way we hook into the vgic init is

[PATCH v5 13/26] KVM: arm/arm64: GICv4: Propagate affinity changes to the physical ITS

When the guest issues an affinity change, we need to tell the physical ITS that we're now targetting a new vcpu. This is done by extracting the current mapping, updating the target, and reapplying the mapping. Reviewed-by: Christoffer Dall Signed-off-by: Marc

[PATCH v5 11/26] KVM: arm/arm64: GICv4: Handle INT command applied to a VLPI

If the guest issues an INT command targetting a VLPI, let's call into the irq_set_irqchip_state() helper to make it pending on the physical side. This works just as well if userspace decides to inject an interrupt using the normal userspace API... Acked-by: Christoffer Dall

[PATCH v5 07/26] KVM: arm/arm64: vITS: Add a helper to update the affinity of an LPI

In order help integrating the vITS code with GICv4, let's add a new helper that deals with updating the affinity of an LPI, which will later be augmented with super duper extra GICv4 goodness. Reviewed-by: Christoffer Dall Signed-off-by: Marc Zyngier

[PATCH v5 08/26] KVM: arm/arm64: GICv4: Add property field and per-VM predicate

Add a new has_gicv4 field in the global VGIC state that indicates whether the HW is GICv4 capable, as a per-VM predicate indicating if there is a possibility for a VM to support direct injection (the above being true and the VM having an ITS). Reviewed-by: Christoffer Dall

[PATCH v5 03/26] KVM: arm/arm64: vgic: restructure kvm_vgic_(un)map_phys_irq

From: Eric Auger We want to reuse the core of the map/unmap functions for IRQ forwarding. Let's move the computation of the hwirq in kvm_vgic_map_phys_irq and pass the linux IRQ as parameter. the host_irq is added to struct vgic_irq. We introduce kvm_vgic_map/unmap_irq

[PATCH v5 04/26] KVM: arm: Select ARM_GIC_V3 and ARM_GIC_V3_ITS

The GICv4 support introduces a hard dependency between the KVM core and the ITS infrastructure. arm64 already selects it at the architecture level, but 32bit doesn't. In order to avoid littering the kernel with #ifdefs, let's just select the whole of the GICv3 suport code. You know you want it.

[PATCH v5 06/26] KVM: arm/arm64: vITS: Add MSI translation helpers

The whole MSI injection process is fairly monolithic. An MSI write gets turned into an injected LPI in one swift go. But this is actually a more fine-grained process: - First, a virtual ITS gets selected using the doorbell address - Then the DevID/EventID pair gets translated into an LPI -

[PATCH v5 05/26] KVM: arm/arm64: vgic: Move kvm_vgic_destroy call around

The way we call kvm_vgic_destroy is a bit bizarre. We call it *after* having freed the vcpus, which sort of defeats the point of cleaning up things before that point. Let's move kvm_vgic_destroy towards the beginning of kvm_arch_destroy_vm, which seems more sensible. Acked-by: Christoffer Dall

[PATCH v5 02/26] KVM: arm/arm64: register irq bypass consumer on ARM/ARM64

From: Eric Auger This patch selects IRQ_BYPASS_MANAGER and HAVE_KVM_IRQ_BYPASS configs for ARM/ARM64. kvm_arch_has_irq_bypass() now is implemented and returns true. As a consequence the irq bypass consumer will be registered for ARM/ARM64 with the forwarding callbacks: -

[PATCH v5 01/26] irqchip/gic-v3-its: Setup VLPI properties at map time

So far, we require the hypervisor to update the VLPI properties once the the VLPI mapping has been established. While this makes it easy for the ITS driver, it creates a window where an incoming interrupt can be delivered with an unknown set of properties. Not very nice. Instead, let's add a

[PATCH v5 00/26] KVM/ARM: Add support for GICv4

This series implements full support for GICv4 in KVM, bringing direct injection of MSIs to arm and arm64, assuming you have the right hardware (which is quite unlikely). To get an idea of the design, I'd recommend you start with commit 7954907bedaf as well as patch #26, which try to shed some

Re: [PATCH v4 23/26] KVM: arm/arm64: GICv4: Prevent a VM using GICv4 from being saved

On Thu, Oct 26 2017 at 5:28:28 pm BST, Christoffer Dall wrote: > On Fri, Oct 06, 2017 at 04:33:58PM +0100, Marc Zyngier wrote: >> The GICv4 architecture doesn't make it easy for save/restore to >> work, as it doesn't give any guarantee that the pending state >> is written into

Re: [PATCH v4 26/28] arm64/sve: Add documentation

On Fri, Oct 27, 2017 at 11:51:08AM +0100, Dave P Martin wrote: > This patch adds basic documentation of the user/kernel interface > provided by the for SVE. > > Signed-off-by: Dave Martin > Cc: Alan Hayward > Cc: Alex Bennée >

Re: [PATCH v4 25/28] arm64/sve: Detect SVE and activate runtime support

On Fri, Oct 27, 2017 at 11:51:07AM +0100, Dave P Martin wrote: > This patch enables detection of hardware SVE support via the > cpufeatures framework, and reports its presence to the kernel and > userspace via the new ARM64_SVE cpucap and HWCAP_SVE hwcap > respectively. > > Userspace can also

Re: [PATCH v4 19/28] arm64/sve: ptrace and ELF coredump support

On Fri, Oct 27, 2017 at 11:51:01AM +0100, Dave P Martin wrote: > This patch defines and implements a new regset NT_ARM_SVE, which > describes a thread's SVE register state. This allows a debugger to > manipulate the SVE state, as well as being included in ELF > coredumps for post-mortem

Re: [PATCH v4 16/28] arm64/sve: Probe SVE capabilities and usable vector lengths

On Fri, Oct 27, 2017 at 11:50:58AM +0100, Dave P Martin wrote: > This patch uses the cpufeatures framework to determine common SVE > capabilities and vector lengths, and configures the runtime SVE > support code appropriately. > > ZCR_ELx is not really a feature register, but it is convenient to

Re: [PATCH v4 13/28] arm64/sve: Signal handling support

On Fri, Oct 27, 2017 at 11:50:55AM +0100, Dave P Martin wrote: > This patch implements support for saving and restoring the SVE > registers around signals. > > A fixed-size header struct sve_context is always included in the > signal frame encoding the thread's vector length at the time of >

Re: [PATCH v4 11/28] arm64/sve: Core task context handling

On Fri, Oct 27, 2017 at 11:50:53AM +0100, Dave P Martin wrote: > This patch adds the core support for switching and managing the SVE > architectural state of user tasks. > > Calls to the existing FPSIMD low-level save/restore functions are > factored out as new functions

Re: [PATCH v5 02/20] arm64: Implement arch_counter_get_cntpct to read the physical counter

On Fri, Oct 27, 2017 at 10:34:23AM +0200, Christoffer Dall wrote: > From: Christoffer Dall > > As we are about to use the physical counter on arm64 systems that have > KVM support, implement arch_counter_get_cntpct() and the associated > errata workaround

Re: [PATCH v5 03/20] arm64: Use physical counter for in-kernel reads when booted in EL2

On Fri, Oct 27, 2017 at 10:34:24AM +0200, Christoffer Dall wrote: > 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

[RFC PATCH v4 28/28] arm64/sve: signal: Include SVE when computing AT_MINSIGSTKSZ

The SVE context block in the signal frame needs to be considered too when computing the maximum possible signal frame size. Because the size of this block depends on the vector length, this patch computes the size based not on the thread's current vector length but instead on the maximum possible

[PATCH v4 15/28] arm64: cpufeature: Move sys_caps_initialised declarations

update_cpu_features() currently cannot tell whether it is being called during early or late secondary boot. This doesn't desperately matter for anything it currently does. However, SVE will need to know here whether the set of available vector lengths is known or still to be determined when

[PATCH v4 10/28] arm64/sve: Low-level CPU setup

To enable the kernel to use SVE, SVE traps from EL1 to EL2 must be disabled. To take maximum advantage of the hardware, the full available vector length also needs to be enabled for EL1 by programming ZCR_EL2.LEN. (The kernel will program ZCR_EL1.LEN as required, but this cannot override the

[PATCH v4 21/28] arm64/sve: Add sysctl to set the default vector length for new processes

Because of the effect of SVE on the size of the signal frame, the default vector length used for new processes involves a tradeoff between performance of SVE-enabled software on the one hand, and reliability of non-SVE-aware software on the other hand. For this reason, the best choice depends on

[PATCH v4 25/28] arm64/sve: Detect SVE and activate runtime support

This patch enables detection of hardware SVE support via the cpufeatures framework, and reports its presence to the kernel and userspace via the new ARM64_SVE cpucap and HWCAP_SVE hwcap respectively. Userspace can also detect SVE using ID_AA64PFR0_EL1, using the cpufeatures MRS emulation. When

[PATCH v4 26/28] arm64/sve: Add documentation

This patch adds basic documentation of the user/kernel interface provided by the for SVE. Signed-off-by: Dave Martin Cc: Alan Hayward Cc: Alex Bennée Cc: Mark Rutland Cc: Michael Kerrisk

[PATCH v4 23/28] arm64/sve: KVM: Treat guest SVE use as undefined instruction execution

When trapping forbidden attempts by a guest to use SVE, we want the guest to see a trap consistent with SVE not being implemented. This patch injects an undefined instruction exception into the guest in response to such an exception. Signed-off-by: Dave Martin Reviewed-by:

[PATCH v4 22/28] arm64/sve: KVM: Prevent guests from using SVE

Until KVM has full SVE support, guests must not be allowed to execute SVE instructions. This patch enables the necessary traps, and also ensures that the traps are disabled again on exit from the guest so that the host can still use SVE if it wants to. On guest exit, high bits of the SVE Zn

[PATCH v4 20/28] arm64/sve: Add prctl controls for userspace vector length management

This patch adds two arm64-specific prctls, to permit userspace to control its vector length: * PR_SVE_SET_VL: set the thread's SVE vector length and vector length inheritance mode. * PR_SVE_GET_VL: get the same information. Although these prctls resemble instruction set features in the SVE

[RFC PATCH v4 27/28] arm64: signal: Report signal frame size to userspace via auxv

Stateful CPU architecture extensions may require the signal frame to grow to a size that exceeds the arch's MINSIGSTKSZ #define. However, changing this #define is an ABI break. To allow userspace the option of determining the signal frame size in a more forwards-compatible way, this patch adds a

[PATCH v4 12/28] arm64/sve: Support vector length resetting for new processes

It's desirable to be able to reset the vector length to some sane default for new processes, since the new binary and its libraries may or may not be SVE-aware. This patch tracks the desired post-exec vector length (if any) in a new thread member sve_vl_onexec, and adds a new thread flag

[PATCH v4 05/28] arm64: fpsimd: Simplify uses of {set, clear}_ti_thread_flag()

The existing FPSIMD context switch code contains a couple of instances of {set,clear}_ti_thread(task_thread_info(task)). Since there are thread flag manipulators that operate directly on task_struct, this verbosity isn't strictly needed. For consistency, this patch simplifies the affected calls.

[PATCH v4 17/28] arm64/sve: Preserve SVE registers around kernel-mode NEON use

Kernel-mode NEON will corrupt the SVE vector registers, due to the way they alias the FPSIMD vector registers in the hardware. This patch ensures that any live SVE register content for the task is saved by kernel_neon_begin(). The data will be restored in the usual way on return to userspace.

[PATCH v4 06/28] arm64/sve: System register and exception syndrome definitions

The SVE architecture adds some system registers, ID register fields and a dedicated ESR exception class. This patch adds the appropriate definitions that will be needed by the kernel. Signed-off-by: Dave Martin Reviewed-by: Alex Bennée Reviewed-by:

[PATCH v4 08/28] arm64/sve: Kconfig update and conditional compilation support

This patch adds CONFIG_ARM64_SVE to control building of SVE support into the kernel, and adds a stub predicate system_supports_sve() to control conditional compilation and runtime SVE support. system_supports_sve() just returns false for now: it will be replaced with a non-trivial implementation

[PATCH v4 04/28] arm64: Port deprecated instruction emulation to new sysctl interface

Currently, armv8_deprected.c takes charge of the "abi" sysctl directory, which makes life difficult for other code that wants to register sysctls in the same directory. There is a "new" [1] sysctl registration interface that removes the need to define ctl_tables for parent directories explicitly,

[PATCH v4 14/28] arm64/sve: Backend logic for setting the vector length

This patch implements the core logic for changing a task's vector length on request from userspace. This will be used by the ptrace and prctl frontends that are implemented in later patches. The SVE architecture permits, but does not require, implementations to support vector lengths that are

[PATCH v4 16/28] arm64/sve: Probe SVE capabilities and usable vector lengths

This patch uses the cpufeatures framework to determine common SVE capabilities and vector lengths, and configures the runtime SVE support code appropriately. ZCR_ELx is not really a feature register, but it is convenient to use it as a template for recording the maximum vector length supported by

[PATCH v4 19/28] arm64/sve: ptrace and ELF coredump support

This patch defines and implements a new regset NT_ARM_SVE, which describes a thread's SVE register state. This allows a debugger to manipulate the SVE state, as well as being included in ELF coredumps for post-mortem debugging. Because the regset size and layout are dependent on the thread's

[PATCH v4 11/28] arm64/sve: Core task context handling

This patch adds the core support for switching and managing the SVE architectural state of user tasks. Calls to the existing FPSIMD low-level save/restore functions are factored out as new functions task_fpsimd_{save,load}(), since SVE now dynamically may or may not need to be handled at these

[PATCH v4 13/28] arm64/sve: Signal handling support

This patch implements support for saving and restoring the SVE registers around signals. A fixed-size header struct sve_context is always included in the signal frame encoding the thread's vector length at the time of signal delivery, optionally followed by a variable-layout structure encoding

[PATCH v4 09/28] arm64/sve: Signal frame and context structure definition

This patch defines the representation that will be used for the SVE register state in the signal frame, and implements support for saving and restoring the SVE registers around signals. The same layout will also be used for the in-kernel task state. Due to the variability of the SVE vector

[PATCH v4 07/28] arm64/sve: Low-level SVE architectural state manipulation functions

Manipulating the SVE architectural state, including the vector and predicate registers, first-fault register and the vector length, requires the use of dedicated instructions added by SVE. This patch adds suitable assembly functions for saving and restoring the SVE registers and querying the

[PATCH v4 03/28] arm64: efi: Add missing Kconfig dependency on KERNEL_MODE_NEON

The EFI runtime services ABI permits calls to EFI to clobber certain FPSIMD/NEON registers, as per the AArch64 procedure call standard. Saving/restoring the clobbered registers around such calls needs KERNEL_MODE_NEON, but the dependency is missing from Kconfig. This patch adds the missing

[PATCH v4 01/28] regset: Add support for dynamically sized regsets

Currently the regset API doesn't allow for the possibility that regsets (or at least, the amount of meaningful data in a regset) may change in size. In particular, this results in useless padding being added to coredumps if a regset's current size is smaller than its theoretical maximum size.

[PATCH v4 00/28] ARM Scalable Vector Extension (SVE)

This series implements Linux kernel support for the ARM Scalable Vector Extension (SVE). [1] It supersedes the previous v3: see [3] for link. See the individual patches for details of changes. The patches apply on git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core

[PATCH v4 02/28] arm64: KVM: Hide unsupported AArch64 CPU features from guests

Currently, a guest kernel sees the true CPU feature registers (ID_*_EL1) when it reads them using MRS instructions. This means that the guest may observe features that are present in the hardware but the host doesn't understand or doesn't provide support for. A guest may legimitately try to use

[PATCH v5 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 v5 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 v5 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 v5 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 v5 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 v5 15/20] KVM: arm/arm64: Support EL1 phys timer register access in set/get reg

Add suport for the physical timer registers in kvm_arm_timer_set_reg and kvm_arm_timer_get_reg so that these functions can be reused to interact with the rest of the system. Note that this paves part of the way for the physical timer state save/restore, but we still need to add those registers to

[PATCH v5 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 v5 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 v5 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 v5 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 Reviewed-by: Marc Zyngier

[PATCH v5 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 v5 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 v5 09/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 v5 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 Acked-by: Marc Zyngier ---

[PATCH v5 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 v5 02/20] arm64: Implement arch_counter_get_cntpct to read the physical counter

From: Christoffer Dall As we are about to use the physical counter on arm64 systems that have KVM support, implement arch_counter_get_cntpct() and the associated errata workaround functionality for stable timer reads. Cc: Catalin Marinas

[PATCH v5 10/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 v5 03/20] arm64: Use physical counter for in-kernel reads when booted in EL2

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 v5 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,

[PATCH v5 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

Re: [PATCH v4 25/26] KVM: arm/arm64: GICv4: Prevent heterogenous systems from using GICv4

On Fri, Oct 27 2017 at 9:04:21 am BST, Mark Rutland wrote: > On Fri, Oct 27, 2017 at 08:59:23AM +0100, Marc Zyngier wrote: >> On Fri, Oct 27 2017 at 8:37:28 am BST, Mark Rutland >> wrote: >> > On Fri, Oct 27, 2017 at 07:57:12AM +0100, Marc Zyngier

Re: [PATCH v4 25/26] KVM: arm/arm64: GICv4: Prevent heterogenous systems from using GICv4

On Fri, Oct 27, 2017 at 08:59:23AM +0100, Marc Zyngier wrote: > On Fri, Oct 27 2017 at 8:37:28 am BST, Mark Rutland > wrote: > > On Fri, Oct 27, 2017 at 07:57:12AM +0100, Marc Zyngier wrote: > >> On Thu, Oct 26 2017 at 4:48:39 pm BST, Mark Rutland > >>

Re: [PATCH v4 25/26] KVM: arm/arm64: GICv4: Prevent heterogenous systems from using GICv4

On Fri, Oct 27 2017 at 8:37:28 am BST, Mark Rutland wrote: > On Fri, Oct 27, 2017 at 07:57:12AM +0100, Marc Zyngier wrote: >> On Thu, Oct 26 2017 at 4:48:39 pm BST, Mark Rutland >> wrote: >> > On Fri, Oct 06, 2017 at 04:34:00PM +0100, Marc Zyngier

Re: [PATCH v4 25/26] KVM: arm/arm64: GICv4: Prevent heterogenous systems from using GICv4

On Fri, Oct 27, 2017 at 07:57:12AM +0100, Marc Zyngier wrote: > On Thu, Oct 26 2017 at 4:48:39 pm BST, Mark Rutland > wrote: > > On Fri, Oct 06, 2017 at 04:34:00PM +0100, Marc Zyngier wrote: > >> @@ -485,8 +495,21 @@ int vgic_v3_probe(const struct gic_kvm_info *info) > >>

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

James, Thanks for the comment. On 2017/10/26 1:42, James Morse wrote: > Hi gengdongjiu, > > On 20/10/17 16:33, gengdongjiu wrote: >> As we discuss below solution: >> When guest happen SEA/SEI, KVM calls memory_failure() to send an >> asynchronous SIGBUS >> signal(BUS_MCEERR_AO) to QEMU, and

Re: [PATCH v4 25/26] KVM: arm/arm64: GICv4: Prevent heterogenous systems from using GICv4

On Thu, Oct 26 2017 at 4:48:39 pm BST, Mark Rutland wrote: > Hi, > > On Fri, Oct 06, 2017 at 04:34:00PM +0100, Marc Zyngier wrote: >> The GICv4 architecture doesn't prevent CPUs implementing GICv4 to >> cohabit with CPUs limited to GICv3 in the same system. >> >> This is

Re: [PATCH v4 19/21] KVM: arm64: Handle RAS SErrors from EL2 on guest exit

On 2017/10/19 22:58, James Morse wrote: > +alternative_if ARM64_HAS_RAS_EXTN > + // If we have the RAS extensions we can consume a pending error > + // without an unmask-SError and isb. > + esb > + mrs_s x2, SYS_DISR_EL1 I do not think you can get the right value when esb