Re: [PATCH] KVM: arm/arm64: Don't enable/disable physical timer access on VHE

On Mon, Nov 20, 2017 at 6:16 AM, Christoffer Dall wrote: > After the timer optimization rework we accidentally end up calling > physical timer enable/disable functions on VHE systems, which is neither > needed nor correct, since the CNTHCTL_EL2 register format is >

[PATCH v5 4/8] KVM: arm/arm64: vgic: Support level-triggered mapped interrupts

Level-triggered mapped IRQs are special because we only observe rising edges as input to the VGIC, and we don't set the EOI flag and therefore are not told when the level goes down, so that we can re-queue a new interrupt when the level goes up. One way to solve this problem is to side-step the

[PATCH v5 7/8] KVM: arm/arm64: Provide a get_input_level for the arch timer

The VGIC can now support the life-cycle of mapped level-triggered interrupts, and we no longer have to read back the timer state on every exit from the VM if we had an asserted timer interrupt signal, because the VGIC already knows if we hit the unlikely case where the guest disables the timer

[PATCH v5 1/8] KVM: arm/arm64: Remove redundant preemptible checks

The __this_cpu_read() and __this_cpu_write() functions already implement checks for the required preemption levels when using CONFIG_DEBUG_PREEMPT which gives you nice error messages and such. Therefore there is no need to explicitly check this using a BUG_ON() in the code (which we don't do for

[PATCH v5 0/8] Handle forwarded level-triggered interrupts

This series illustrates an alternative approach to Eric Auger's direct EOI setup patches [1] in terms of the KVM VGIC support. The idea is to maintain existing semantics for the VGIC for mapped level-triggered IRQs and also support the timer using mapped IRQs with the same VGIC support as VFIO

[PATCH v5 5/8] KVM: arm/arm64: Support a vgic interrupt line level sample function

The GIC sometimes need to sample the physical line of a mapped interrupt. As we know this to be notoriously slow, provide a callback function for devices (such as the timer) which can do this much faster than talking to the distributor, for example by comparing a few in-memory values. Fall back

[PATCH v5 8/8] KVM: arm/arm64: Avoid work when userspace iqchips are not used

We currently check if the VM has a userspace irqchip on every exit from the VCPU, and if so, we do some work to ensure correct timer behavior. This is unfortunate, as we could avoid doing any work entirely, if we didn't have to support irqchip in userspace. Realizing the userspace irqchip on ARM

[PATCH v5 6/8] KVM: arm/arm64: Support VGIC dist pend/active changes for mapped IRQs

For mapped IRQs (with the HW bit set in the LR) we have to follow some rules of the architecture. One of these rules is that VM must not be allowed to deactivate a virtual interrupt with the HW bit set unless the physical interrupt is also active. This works fine when injecting mapped

[PATCH v5 3/8] KVM: arm/arm64: Don't cache the timer IRQ level

The timer was modeled after a strict idea of modelling an interrupt line level in software, meaning that only transitions in the level needed to be reported to the VGIC. This works well for the timer, because the arch timer code is in complete control of the device and can track the transitions

[PATCH v5 2/8] KVM: arm/arm64: Factor out functionality to get vgic mmio requester_vcpu

We are about to distinguish between userspace accesses and mmio traps for a number of the mmio handlers. When the requester vcpu is NULL, it mens we are handling a userspace acccess. Factor out the functionality to get the request vcpu into its own function, mostly so we have a common place to

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

On Mon, Nov 20, 2017 at 6:15 AM, Christoffer Dall wrote: > On Thu, Nov 16, 2017 at 03:30:39PM -0500, Jintack Lim wrote: >> Hi Christoffer, >> >> On Fri, Oct 20, 2017 at 7:49 AM, Christoffer Dall >> wrote: >> > From: Christoffer Dall

Re: [PATCH v3 0/3] KVM: arm64: single step emulation instructions

Hi Alex, On Thu, Nov 16, 2017 at 03:39:18PM +, Alex Bennée wrote: > Hi, > > This is rev 3 of the series, practically the same than rev 2 but fixed > a return 1->0 in the kvm_run loop that Julien caught. I've added his > r-b tags to the other patches. > > As usual revision details bellow the

Re: [PATCH 4/7] KVM: arm/arm64: vgic-its: Check result of allocation before use

On Thu, Nov 16, 2017 at 05:58:18PM +, Marc Zyngier wrote: > We miss a test against NULL after allocation. > > Fixes: 6d03a68f8054 ("KVM: arm64: vgic-its: Turn device_id validation into > generic ID validation") > Cc: sta...@vger.kernel.org # 4.8 > Reported-by: AKASHI Takahiro

Re: [PATCH 1/7] KVM: arm/arm64: vgic-irqfd: Fix MSI entry allocation

On Thu, Nov 16, 2017 at 05:58:15PM +, Marc Zyngier wrote: > Using the size of the structure we're allocating is a good idea > and avoids any surprise... In this case, we're happilly confusing > kvm_kernel_irq_routing_entry and kvm_irq_routing_entry... Yikes. Reviewed-by: Christoffer Dall

Re: [PATCH 7/7] arm: KVM: Fix VTTBR_BADDR_MASK BUG_ON off-by-one

On Thu, Nov 16, 2017 at 05:58:21PM +, Marc Zyngier wrote: > VTTBR_BADDR_MASK is used to sanity check the size and alignment of the > VTTBR address. It seems to currently be off by one, thereby only > allowing up to 39-bit addresses (instead of 40-bit) and also > insufficiently checking the

Re: [PATCH] arm64: KVM: fix VTTBR_BADDR_MASK BUG_ON off-by-one

On Tue, Nov 14, 2017 at 02:37:43PM +, Kristina Martsenko wrote: > VTTBR_BADDR_MASK is used to sanity check the size and alignment of the > VTTBR address. It seems to currently be off by one, thereby only > allowing up to 47-bit addresses (instead of 48-bit) and also > insufficiently checking

Re: [PATCH] KVM: arm/arm64: VGIC: extend !vgic_is_initialized guard

Hi Andre, On Fri, Nov 17, 2017 at 05:58:21PM +, Andre Przywara wrote: > Commit f39d16cbabf9 ("KVM: arm/arm64: Guard kvm_vgic_map_is_active against > !vgic_initialized") introduced a check whether the VGIC has been > initialized before accessing the spinlock and the VGIC data structure. >

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

On Thu, Nov 16, 2017 at 12:29:48PM +, Andre Przywara wrote: > Hi, > > On 27/10/17 09:34, Christoffer Dall wrote: > > 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

[PATCH] KVM: arm/arm64: Don't enable/disable physical timer access on VHE

After the timer optimization rework we accidentally end up calling physical timer enable/disable functions on VHE systems, which is neither needed nor correct, since the CNTHCTL_EL2 register format is different when HCR_EL2.E2H is set. The CNTHCTL_EL2 is initialized when CPUs become online in

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

On Thu, Nov 16, 2017 at 03:30:39PM -0500, Jintack Lim wrote: > Hi Christoffer, > > On Fri, Oct 20, 2017 at 7:49 AM, Christoffer Dall > wrote: > > From: Christoffer Dall > > > > We don't need to save and restore the hardware timer state and examine

Re: [PATCH] KVM: arm/arm64: VGIC: extend !vgic_is_initialized guard

Hi Andre, On 17/11/2017 18:58, Andre Przywara wrote: > Commit f39d16cbabf9 ("KVM: arm/arm64: Guard kvm_vgic_map_is_active against > !vgic_initialized") introduced a check whether the VGIC has been > initialized before accessing the spinlock and the VGIC data structure. > However the

Re: [PATCH v4 00/21] SError rework + RAS for firmware first support

On Tue, Nov 14, 2017 at 04:03:01PM +, James Morse wrote: > Hi Christoffer, > > On 13/11/17 11:29, Christoffer Dall wrote: > > On Thu, Nov 09, 2017 at 06:14:56PM +, James Morse wrote: > >> On 19/10/17 15:57, James Morse wrote: > >>> Known issues: > >> [...] > >>> * KVM-Migration:

Re: [PATCH v4 00/21] SError rework + RAS for firmware first support

On Mon, Nov 13, 2017 at 01:05:19PM +, Peter Maydell wrote: > On 13 November 2017 at 11:29, Christoffer Dall wrote: > > I'm thinking this is analogous to migrating a VM that uses an irqchip in > > userspace and has set the IRQ or FIQ lines using KVM_IRQ_LINE. My > > feeling

Re: [PATCH] KVM: arm/arm64: VGIC: extend !vgic_is_initialized guard

Hi Andre, On 17/11/2017 18:58, Andre Przywara wrote: > Commit f39d16cbabf9 ("KVM: arm/arm64: Guard kvm_vgic_map_is_active against > !vgic_initialized") introduced a check whether the VGIC has been > initialized before accessing the spinlock and the VGIC data structure. > However the