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

Hi On 07/11/2017 17:34, Marc Zyngier wrote: > On 07/11/17 16:12, Auger Eric wrote: >> Hi Marc, >> >> On 07/11/2017 16:38, Marc Zyngier wrote: >>> On 07/11/17 15:24, Auger Eric wrote: Hi Marc, Hi Marc, On 27/10/2017 16:28, Marc Zyngier wrote: > The GICv4 architecture

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

Hi, On 27/10/2017 16:28, Marc Zyngier wrote: > 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

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

Hi Marc, On 07/11/2017 22:54, Auger Eric wrote: > Hi Marc, > > On 27/10/2017 16:28, Marc Zyngier wrote: >> 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

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

Hi Marc, On 27/10/2017 16:28, Marc Zyngier wrote: > 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. >

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

Hi, On 27/10/2017 16:28, Marc Zyngier wrote: > 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

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

Hi, On 27/10/2017 16:28, Marc Zyngier wrote: > 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

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

Hi, On 27/10/2017 16:28, Marc Zyngier wrote: > 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. This is actually done in the next patch.

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

Hi Marc, On 27/10/2017 16:28, Marc Zyngier wrote: > 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 > --- >

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

Hi Marc, On 27/10/2017 16:28, Marc Zyngier wrote: > Since when updating the properties one LPI at a time, there is no Since we update the properties one LPI at a time, ... ? > 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

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

Hi Marc, On 27/10/2017 16:28, Marc Zyngier wrote: > 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 nit: where > the intids of the candicate interrupts,

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

Hi Marc, On 27/10/2017 16:28, Marc Zyngier wrote: > 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

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

Hi, On 27/10/2017 16:28, Marc Zyngier wrote: > 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). >

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

Hi Marc, On 27/10/2017 16:28, Marc Zyngier wrote: > 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 > --- >

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

Hi Marc, On 27/10/2017 16:28, Marc Zyngier wrote: > 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

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

On 07/11/17 16:12, Auger Eric wrote: > Hi Marc, > > On 07/11/2017 16:38, Marc Zyngier wrote: >> On 07/11/17 15:24, Auger Eric wrote: >>> Hi Marc, >>> >>> Hi Marc, >>> On 27/10/2017 16:28, Marc Zyngier wrote: The GICv4 architecture doesn't make it easy for save/restore to work, as it

Re: [PATCH 16/37] KVM: arm64: Remove noop calls to timer save/restore from VHE switch

On Thu, Oct 12, 2017 at 12:41:20PM +0200, Christoffer Dall wrote: > The VHE switch function calls __timer_enable_traps and > __timer_disable_traps which don't do anything on VHE systems. > Therefore, simply remove these calls from the VHE switch function and > make the functions non-conditional as

Re: [PATCH 15/37] KVM: arm64: Don't deactivate VM on VHE systems

On Thu, Oct 12, 2017 at 12:41:19PM +0200, Christoffer Dall wrote: > There is no need to reset the VTTBR to zero when exiting the guest on > VHE systems. VHE systems don't use stage 2 translations for the EL2&0 > translation regime used by the host. > > Signed-off-by: Christoffer Dall

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

Hi Marc, On 07/11/2017 16:38, Marc Zyngier wrote: > On 07/11/17 15:24, Auger Eric wrote: >> Hi Marc, >> >> Hi Marc, >> On 27/10/2017 16:28, 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 >>>

Re: [PATCH 14/37] KVM: arm64: Remove kern_hyp_va() use in VHE switch function

On Thu, Oct 12, 2017 at 12:41:18PM +0200, Christoffer Dall wrote: > VHE kernels run completely in EL2 and therefore don't have a notion of > kernel and hyp addresses, they are all just kernel addresses. Therefore > don't call kern_hyp_va() in the VHE switch function. > > Signed-off-by:

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

Hi, On 07/11/2017 15:42, Marc Zyngier wrote: > Hi Eric, > > On 07/11/17 13:06, Auger Eric wrote: >> Hi Marc, >> >> On 27/10/2017 16:28, Marc Zyngier wrote: >>> Let's use the irq bypass mechanism introduced for platform device >>> interrupts >> nit: I would remove "introduced for platform device

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

On 07/11/17 15:24, Auger Eric wrote: > Hi Marc, > > Hi Marc, > On 27/10/2017 16:28, 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 the pending table. > > I don't understand

Re: [PATCH 13/37] KVM: arm64: Introduce VHE-specific kvm_vcpu_run

On Thu, Oct 12, 2017 at 12:41:17PM +0200, Christoffer Dall wrote: > So far this is just a copy of the legacy non-VHE switch function, where > we only change the existing calls to has_vhe() in both the original and > new functions. > > Signed-off-by: Christoffer Dall

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

Hi Marc, Hi Marc, On 27/10/2017 16:28, 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 the pending table. I don't understand where does the limitation exactly come from. Can't

Re: [PATCH 12/37] KVM: arm64: Factor out fault info population and gic workarounds

On Thu, Oct 12, 2017 at 12:41:16PM +0200, Christoffer Dall wrote: > The current world-switch function has functionality to detect a number > of cases where we need to fixup some part of the exit condition and > possibly run the guest again, before having restored the host state. > > This includes

Re: [PATCH 11/37] KVM: arm64: Improve debug register save/restore flow

On Thu, Oct 12, 2017 at 12:41:15PM +0200, Christoffer Dall wrote: > Instead of having multiple calls from the world switch path to the debug > logic, each figuring out if the dirty bit is set and if we should > save/restore the debug registes, let's just provide two hooks to the > debug

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

Hi Eric, On 07/11/17 13:06, Auger Eric wrote: > Hi Marc, > > On 27/10/2017 16:28, Marc Zyngier wrote: >> Let's use the irq bypass mechanism introduced for platform device >> interrupts > nit: I would remove "introduced for platform device interrupts" > as this is not upstream yet. x86 posted

Re: [PATCH 10/37] KVM: arm64: Slightly improve debug save/restore functions

On Thu, Oct 12, 2017 at 12:41:14PM +0200, Christoffer Dall wrote: > The debug save/restore functions can be improved by using the has_vhe() > static key instead of the instruction alternative. Using the static key > uses the same paradigm as we're going to use elsewhere, it makes the > code more

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

Hi, On 27/10/2017 16:28, Marc Zyngier wrote: > In order help integrating the vITS code with GICv4, let's add in order to > 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

Re: [PATCH 08/37] KVM: arm64: Defer restoring host VFP state to vcpu_put

On Thu, Oct 12, 2017 at 12:41:12PM +0200, Christoffer Dall wrote: > Avoid saving the guest VFP registers and restoring the host VFP > registers on every exit from the VM. Only when we're about to run > userspace or other threads in the kernel do we really have to switch the > state back to the

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

Hi Marc, On 27/10/2017 16:28, Marc Zyngier wrote: > 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...

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

Hi Marc, On 27/10/2017 16:28, Marc Zyngier wrote: > Let's use the irq bypass mechanism introduced for platform device > interrupts nit: I would remove "introduced for platform device interrupts" as this is not upstream yet. x86 posted interrupts also use it. > and establish our LPI->VLPI

Re: [PATCH 07/37] KVM: arm/arm64: Add kvm_vcpu_load_sysregs and kvm_vcpu_put_sysregs

On Thu, Oct 12, 2017 at 12:41:11PM +0200, Christoffer Dall wrote: > As we are about to move a buch of save/restore logic for VHE kernels to > the load and put functions, we need some infrastructure to do this. > > Signed-off-by: Christoffer Dall > --- >

[PULL 26/26] KVM: arm/arm64: fix the incompatible matching for external abort

From: Dongjiu Geng kvm_vcpu_dabt_isextabt() tries to match a full fault syndrome, but calls kvm_vcpu_trap_get_fault_type() that only returns the fault class, thus reducing the scope of the check. This doesn't cause any observable bug yet as we end-up matching a closely

[PULL 25/26] KVM: arm/arm64: Unify 32bit fault injection

From: Marc Zyngier Both arm and arm64 implementations are capable of injecting faults, and yet have completely divergent implementations, leading to different bugs and reduced maintainability. Let's elect the arm64 version as the canonical one and move it into aarch32.c,

[PULL 21/26] KVM: arm/arm64: vgic-its: New helper functions to free the caches

From: wanghaibin We create two new functions that free the device and collection lists. They are currently called by vgic_its_destroy() and other callers will be added in subsequent patches. We also remove the check on its->device_list.next. Lists are initialized in

[PULL 22/26] KVM: arm/arm64: vgic-its: Free caches when GITS_BASER Valid bit is cleared

From: Eric Auger When the GITS_BASER.Valid gets cleared, the data structures in guest RAM are not valid anymore. The device, collection and LPI lists stored in the in-kernel ITS represent the same information in some form of cache. So let's void the cache. Reviewed-by:

[PULL 18/26] KVM: arm/arm64: Rework kvm_timer_should_fire

From: Christoffer Dall 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

[PULL 23/26] KVM: arm/arm64: Document KVM_DEV_ARM_ITS_CTRL_RESET

From: Eric Auger At the moment, the in-kernel emulated ITS is not properly reset. On guest restart/reset some registers keep their old values and internal structures like device, ITE, and collection lists are not freed. This may lead to various bugs. Among them, we can

[PULL 07/26] KVM: arm/arm64: Rename soft timer to bg_timer

From: Christoffer Dall 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

[PULL 06/26] KVM: arm/arm64: Make timer_arm and timer_disarm helpers more generic

From: Christoffer Dall We are about to add an additional soft timer to the arch timer state for a VCPU and would like to be able to reuse the functions to program and cancel a timer, so we make them slightly more generic and rename to make it more clear that these functions

[PULL 19/26] arm/arm64: KVM: Load the timer state when enabling the timer

After being lazy with saving/restoring the timer state, we defer that work to vcpu_load and vcpu_put, which ensure that the timer state is loaded on the hardware timers whenever the VCPU runs. Unfortunately, we are failing to do that the first time vcpu_load() runs, because the timer has not yet

[PULL 04/26] KVM: arm/arm64: Support calling vgic_update_irq_pending from irq context

From: Christoffer Dall 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

[PULL 16/26] KVM: arm/arm64: Avoid phys timer emulation in vcpu entry/exit

From: Christoffer Dall 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

[PULL 12/26] KVM: arm/arm64: Avoid timer save/restore in vcpu entry/exit

From: Christoffer Dall 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

[PULL 14/26] KVM: arm/arm64: Use kvm_arm_timer_set/get_reg for guest register traps

From: Christoffer Dall 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.

[PULL 13/26] KVM: arm/arm64: Support EL1 phys timer register access in set/get reg

From: Christoffer Dall 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,

[PULL 20/26] KVM: arm/arm64: vgic-its: Remove kvm_its_unmap_device

From: Eric Auger Let's remove kvm_its_unmap_device and use kvm_its_free_device as both functions are identical. Signed-off-by: Eric Auger Acked-by: Marc Zyngier Acked-by: Christoffer Dall

[PULL 17/26] KVM: arm/arm64: Get rid of kvm_timer_flush_hwstate

From: Christoffer Dall 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

[PULL 02/26] arm64: Use physical counter for in-kernel reads when booted in EL2

From: Christoffer Dall 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

[PULL 11/26] KVM: arm/arm64: Set VCPU affinity for virt timer irq

From: Christoffer Dall 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

[PULL 05/26] KVM: arm/arm64: Check that system supports split eoi/deactivate

From: Christoffer Dall 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

[PULL 08/26] KVM: arm/arm64: Move timer/vgic flush/sync under disabled irq

From: Christoffer Dall 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

[PULL 10/26] KVM: arm/arm64: Move timer save/restore out of the hyp code

From: Christoffer Dall 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

[PULL 00/26] KVM/ARM Changes for v4.15

Hi Paolo and Radim, Here is the first round of KVM/ARM Changes for v4.15. I will follow up with a second pull request based on tip:irq/core containing the KVM/ARM side of the GICv4 support. Changes in this pull requestinclude: - Optimized arch timer handling for KVM/ARM - Improvements to the

Re: [PATCH 05/37] KVM: Record the executing ioctl number on the vcpu struct

On Thu, Oct 12, 2017 at 12:41:09PM +0200, Christoffer Dall wrote: > Some architectures may decide to do different things during > kvm_arch_vcpu_load depending on the ioctl being executed. For example, > arm64 is about to do significant work in vcpu load/put when running a > vcpu, but not when

Re: [PATCH 01/37] KVM: arm64: Avoid storing the vcpu pointer on the stack

On Mon, Nov 06, 2017 at 06:22:51PM +0100, Andrew Jones wrote: > On Thu, Oct 12, 2017 at 12:41:05PM +0200, Christoffer Dall wrote: > > We already have the percpu area for the host cpu state, which points to > > the VCPU, so there's no need to store the VCPU pointer on the stack on > > every context