Re: [PATCH] KVM: arm/arm64: don't set vtimer->cnt_ctl in kvm_arch_timer_handler

Hi On 12/14/2017 12:57 PM, Jia He Wrote: Hi Christoffer I have tried your newer level-mapped-v7 branch, but bug is still there. There is no special load in both host and guest. The guest (kernel 4.14) is often hanging when booting the guest kernel log [ OK ] Reached target Remote File

Re: [PATCH] KVM: arm/arm64: don't set vtimer->cnt_ctl in kvm_arch_timer_handler

Hi Christoffer I have tried your newer level-mapped-v7 branch, but bug is still there. There is no special load in both host and guest. The guest (kernel 4.14) is often hanging when booting the guest kernel log [ OK ] Reached target Remote File Systems. Starting File System Check on

Re: [PATCH v8 9/9] KVM: arm/arm64: Update timer and forwarded irq documentation

On Wed, 13 Dec 2017 10:46:02 +, Christoffer Dall wrote: > > Now when we've reworked how mapped level-triggered interrupts are > processed for the timer interrupts, we update the documentation > correspondingly. Seems like the documentation is more out of date than we thought, see below. >

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

On Wed, 13 Dec 2017 10:46:01 +, Christoffer Dall wrote: > > 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

Re: [PATCH v8 7/9] KVM: arm/arm64: Provide a get_input_level for the arch timer

On Wed, 13 Dec 2017 10:46:00 +, Christoffer Dall wrote: > > 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

Re: [PATCH v8 3/9] KVM: arm/arm64: Don't cache the timer IRQ level

On Wed, 13 Dec 2017 10:45:56 +, Christoffer Dall wrote: > > 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

Re: [PATCH v2 05/19] arm64: alternatives: Add dynamic patching feature

On Mon, Dec 11, 2017 at 02:49:23PM +, Marc Zyngier wrote: > We've so far relied on a patching infrastructure that only gave us > a single alternative, without any way to finely control what gets > patched. For a single feature, this is an all or nothing thing. > > It would be interesting to

Re: [RFC v2] arm64: KVM: KVM API extensions for SVE

On Wed, Dec 13, 2017 at 04:58:16PM +, Peter Maydell wrote: > On 13 December 2017 at 16:55, Dave Martin wrote: > > Vector length control: > > > > Some means is needed to determine the set of vector lengths visible > > to guest software running on a vcpu. > > > > When a

Re: [PATCH v2 1/3] arm64: mm: Support Common Not Private translations

Hi James, On 13/12/17 14:19, James Morse wrote: > Hi Vladimir, > > On 11/10/17 13:19, Vladimir Murzin wrote: >> Common Not Private (CNP) is a feature of ARMv8.2 extension which >> allows translation table entries to be shared between different PEs in >> the same inner shareable domain, so the

Re: [RFC v2] arm64: KVM: KVM API extensions for SVE

On 13 December 2017 at 16:55, Dave Martin wrote: > Vector length control: > > Some means is needed to determine the set of vector lengths visible > to guest software running on a vcpu. > > When a vcpu is created, the set would be defaulted to the maximal set > that can be

[RFC v2] arm64: KVM: KVM API extensions for SVE

Hi all, Here's a second, slightly more complete stab at the KVM API extensions for SVE. I haven't started implementing in earnest yet, so any comments at this stage would be very helpful. [libvir-list readers: this is a proposal for extending the KVM API on AArch64 systems to support the

Re: [PATCH 05/12] arm64: mm: Remove VMALLOC checks from update_mapping_prot(.)

On Tue, Dec 12, 2017 at 03:39:23PM +, Steve Capper wrote: > It is not apparent to me how mark_linear_text_alias_ro(.) guarantees > that no page table entries for the linear map are split, though. map_mem() ensures that when mapped via __map_memblock(), no contiguous entries are created. Also

Re: [PATCH v2 07/19] arm64: insn: Add encoder for bitwise operations using litterals

On 13/12/17 15:45, James Morse wrote: > Hi Marc, > > On 13/12/17 14:32, Marc Zyngier wrote: >> On 12/12/17 18:32, James Morse wrote: >>> On 11/12/17 14:49, Marc Zyngier wrote: We lack a way to encode operations such as AND, ORR, EOR that take an immediate value. Doing so is quite

Re: [PATCH v2 07/19] arm64: insn: Add encoder for bitwise operations using litterals

Hi Marc, On 13/12/17 14:32, Marc Zyngier wrote: > On 12/12/17 18:32, James Morse wrote: >> On 11/12/17 14:49, Marc Zyngier wrote: >>> We lack a way to encode operations such as AND, ORR, EOR that take >>> an immediate value. Doing so is quite involved, and is all about >>> reverse engineering the

Re: [PATCH v2 07/19] arm64: insn: Add encoder for bitwise operations using litterals

Hi James, On 12/12/17 18:32, James Morse wrote: > Hi Marc, > > On 11/12/17 14:49, Marc Zyngier wrote: >> We lack a way to encode operations such as AND, ORR, EOR that take >> an immediate value. Doing so is quite involved, and is all about >> reverse engineering the decoding algorithm described

Re: [PATCH v2 1/3] arm64: mm: Support Common Not Private translations

Hi Vladimir, On 11/10/17 13:19, Vladimir Murzin wrote: > Common Not Private (CNP) is a feature of ARMv8.2 extension which > allows translation table entries to be shared between different PEs in > the same inner shareable domain, so the hardware can use this fact to > optimise the caching of such

[PATCH v8 4/9] 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 v8 9/9] KVM: arm/arm64: Update timer and forwarded irq documentation

Now when we've reworked how mapped level-triggered interrupts are processed for the timer interrupts, we update the documentation correspondingly. Signed-off-by: Christoffer Dall --- Documentation/virtual/kvm/arm/vgic-mapped-irqs.txt | 50 ++ 1

[PATCH v8 8/9] 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 v8 1/9] 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 v8 0/9] Handle forwarded level-triggered interrupts

This series is 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 interrupts.

[PATCH v8 5/9] 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 v8 6/9] 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 v8 3/9] 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

Re: [PATCH] KVM: arm/arm64: don't set vtimer->cnt_ctl in kvm_arch_timer_handler

On Wed, Dec 13, 2017 at 10:27 AM, Marc Zyngier wrote: > On 13/12/17 09:08, Auger Eric wrote: >> Marc, >> On 13/12/17 09:56, Marc Zyngier wrote: >>> Hi Jia, >>> >>> On 13/12/17 07:00, Jia He wrote: In our Armv8a server (qualcomm Amberwing, non VHE), after applying

Re: [PATCH] KVM: arm/arm64: don't set vtimer->cnt_ctl in kvm_arch_timer_handler

On 13/12/17 09:08, Auger Eric wrote: > Marc, > On 13/12/17 09:56, Marc Zyngier wrote: >> Hi Jia, >> >> On 13/12/17 07:00, Jia He wrote: >>> In our Armv8a server (qualcomm Amberwing, non VHE), after applying >>> Christoffer's timer optimizing patchset(Optimize arch timer register >>> handling), the

Re: [PATCH] KVM: arm/arm64: don't set vtimer->cnt_ctl in kvm_arch_timer_handler

On Wed, Dec 13, 2017 at 08:56:12AM +, Marc Zyngier wrote: > Hi Jia, > > On 13/12/17 07:00, Jia He wrote: > > In our Armv8a server (qualcomm Amberwing, non VHE), after applying > > Christoffer's timer optimizing patchset(Optimize arch timer register > > handling), the guest is hang during

Re: [PATCH] KVM: arm/arm64: don't set vtimer->cnt_ctl in kvm_arch_timer_handler

On Tue, Dec 12, 2017 at 11:00:07PM -0800, Jia He wrote: > In our Armv8a server (qualcomm Amberwing, non VHE), after applying > Christoffer's timer optimizing patchset(Optimize arch timer register > handling), the guest is hang during kernel booting. > > The error root cause might be as follows: >

Re: [PATCH] KVM: arm/arm64: don't set vtimer->cnt_ctl in kvm_arch_timer_handler

Marc, On 13/12/17 09:56, Marc Zyngier wrote: > Hi Jia, > > On 13/12/17 07:00, Jia He wrote: >> In our Armv8a server (qualcomm Amberwing, non VHE), after applying >> Christoffer's timer optimizing patchset(Optimize arch timer register >> handling), the guest is hang during kernel booting. >> >>

Re: [PATCH] KVM: arm/arm64: don't set vtimer->cnt_ctl in kvm_arch_timer_handler

Hi Jia, On 13/12/17 07:00, Jia He wrote: > In our Armv8a server (qualcomm Amberwing, non VHE), after applying > Christoffer's timer optimizing patchset(Optimize arch timer register > handling), the guest is hang during kernel booting. > > The error root cause might be as follows: > 1. in