Re: [PATCH V8 05/10] acpi: apei: handle SEA notification type for ARMv8

Hello James, On 2/3/2017 9:00 AM, James Morse wrote: On 01/02/17 17:16, Tyler Baicar wrote: ARM APEI extension proposal added SEA (Synchronous External Abort) notification type for ARMv8. Add a new GHES error source handling function for SEA. If an error source's notification type is SEA,

Re: [PATCH V8 04/10] arm64: exception: handle Synchronous External Abort

Hello James, On 2/3/2017 8:59 AM, James Morse wrote: On 01/02/17 17:16, Tyler Baicar wrote: SEA exceptions are often caused by an uncorrected hardware error, and are handled when data abort and instruction abort exception classes have specific values for their Fault Status Code. When SEA

Re: [PATCH V8 09/10] trace, ras: add ARM processor error trace event

Hello Steve, On 2/1/2017 8:15 PM, Steven Rostedt wrote: On Wed, 1 Feb 2017 10:16:52 -0700 Tyler Baicar wrote: Currently there are trace events for the various RAS errors with the exception of ARM processor type errors. Add a new trace event for such errors so that

Re: [PATCH v2 2/5] KVM: arm/arm64: Add ARM user space interrupt signaling ABI

On 3 February 2017 at 14:56, Christoffer Dall wrote: > From: Christoffer Dall > > We have 2 modes for dealing with interrupts in the ARM world. We can > either handle them all using hardware acceleration through the vgic or > we can emulate a gic in

Re: [RFC v4 00/10] Provide the EL1 physical timer to the VM

On 03/02/17 16:51, Jintack Lim wrote: > On Fri, Feb 3, 2017 at 11:14 AM, Marc Zyngier wrote: >> On 03/02/17 15:19, Jintack Lim wrote: >>> The ARM architecture defines the EL1 physical timer and the virtual timer, >>> and it is reasonable for an OS to expect to be able to

Re: [RFC v4 00/10] Provide the EL1 physical timer to the VM

On Fri, Feb 3, 2017 at 11:14 AM, Marc Zyngier wrote: > On 03/02/17 15:19, Jintack Lim wrote: >> The ARM architecture defines the EL1 physical timer and the virtual timer, >> and it is reasonable for an OS to expect to be able to access both. >> However, the current KVM

Re: [RFC v4 00/10] Provide the EL1 physical timer to the VM

On 03/02/17 15:19, Jintack Lim wrote: > The ARM architecture defines the EL1 physical timer and the virtual timer, > and it is reasonable for an OS to expect to be able to access both. > However, the current KVM implementation does not provide the EL1 physical > timer to VMs but terminates VMs on

Re: [PATCH V8 05/10] acpi: apei: handle SEA notification type for ARMv8

Hi Tyler, On 01/02/17 17:16, Tyler Baicar wrote: > ARM APEI extension proposal added SEA (Synchronous External Abort) > notification type for ARMv8. > Add a new GHES error source handling function for SEA. If an error > source's notification type is SEA, then this function can be registered >

Re: [PATCH V8 04/10] arm64: exception: handle Synchronous External Abort

Hi Tyler, On 01/02/17 17:16, Tyler Baicar wrote: > SEA exceptions are often caused by an uncorrected hardware > error, and are handled when data abort and instruction abort > exception classes have specific values for their Fault Status > Code. > When SEA occurs, before killing the process,

[RFC v4 09/10] KVM: arm64: Add the EL1 physical timer access handler

KVM traps on the EL1 phys timer accesses from VMs, but it doesn't handle those traps. This results in terminating VMs. Instead, set a handler for the EL1 phys timer access, and inject an undefined exception as an intermediate step. Signed-off-by: Jintack Lim Reviewed-by:

[RFC v4 06/10] KVM: arm/arm64: Update the physical timer interrupt level

Now that we maintain the EL1 physical timer register states of VMs, update the physical timer interrupt level along with the virtual one. Signed-off-by: Jintack Lim Acked-by: Christoffer Dall --- virt/kvm/arm/arch_timer.c | 4 1 file

[RFC v4 03/10] KVM: arm/arm64: Decouple kvm timer functions from virtual timer

Now that we have a separate structure for timer context, make functions generic so that they can work with any timer context, not just the virtual timer context. This does not change the virtual timer functionality. Signed-off-by: Jintack Lim Acked-by: Marc Zyngier

[RFC v4 08/10] KVM: arm/arm64: Set up a background timer for the physical timer emulation

Set a background timer for the EL1 physical timer emulation while VMs are running, so that VMs get the physical timer interrupts in a timely manner. Schedule the background timer on entry to the VM and cancel it on exit. This would not have any performance impact to the guest OSes that currently

[RFC v4 05/10] KVM: arm/arm64: Initialize the emulated EL1 physical timer

Initialize the emulated EL1 physical timer with the default irq number. Signed-off-by: Jintack Lim Reviewed-by: Christoffer Dall --- arch/arm/kvm/reset.c | 9 - arch/arm64/kvm/reset.c | 9 -

[RFC v4 07/10] KVM: arm/arm64: Set a background timer to the earliest timer expiration

When scheduling a background timer, consider both of the virtual and physical timer and pick the earliest expiration time. Signed-off-by: Jintack Lim Reviewed-by: Christoffer Dall --- arch/arm/kvm/arm.c| 3 ++-

[RFC v4 01/10] KVM: arm/arm64: Abstract virtual timer context into separate structure

Abstract virtual timer context into a separate structure and change all callers referring to timer registers, irq state and so on. No change in functionality. This is about to become very handy when adding the EL1 physical timer. Signed-off-by: Jintack Lim Acked-by:

[RFC v4 04/10] KVM: arm/arm64: Add the EL1 physical timer context

Add the EL1 physical timer context. Signed-off-by: Jintack Lim Acked-by: Christoffer Dall --- include/kvm/arm_arch_timer.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h

[RFC v4 00/10] Provide the EL1 physical timer to the VM

The ARM architecture defines the EL1 physical timer and the virtual timer, and it is reasonable for an OS to expect to be able to access both. However, the current KVM implementation does not provide the EL1 physical timer to VMs but terminates VMs on access to the timer. This patch series

[PATCH v2 1/5] KVM: arm/arm64: Cleanup the arch timer code's irqchip checking

From: Christoffer Dall Currently we check if we have an in-kernel irqchip and if the vgic was properly implemented several places in the arch timer code. But, we already predicate our enablement of the arm timers on having a valid and initialized gic, so we can

[PATCH v2 0/5] Support userspace irqchip with arch timers

This series is the second version of the rework of the patches to support architected timers with a userspace irqchip sent by Alexander Graf [1]. We first cleanup some of the timer code to make it easier to understand what is being done in the later patches, and then define the ABI, implement

[PATCH v2 3/5] KVM: arm/arm64: Support arch timers with a userspace gic

If you're running with a userspace gic or other interrupt constroller (that is no vgic in the kernel), then you have so far not been able to use the architected timers, because the output of the architected timers, which are driven inside the kernel, was a kernel-only construct between the arch

[PATCH v2 4/5] KVM: arm/arm64: Report PMU overflow interrupts to userspace irqchip

From: Christoffer Dall When not using an in-kernel VGIC, but instead emulating an interrupt controller in userspace, we should report the PMU overflow status to that userspace interrupt controller using the KVM_CAP_ARM_USER_IRQ feature. Signed-off-by: Christoffer

[PATCH v2 5/5] KVM: arm/arm64: Advertise support for KVM_CAP_ARM_USER_IRQ

From: Christoffer Dall Now when we support both the virtual timer and PMU reporting interrupts to userspace, we can advertise this support. Signed-off-by: Christoffer Dall --- arch/arm/kvm/arm.c | 7 +++ 1 file changed, 7

Re: [RFC 01/13] KVM: arm/arm64: Add vITS save/restore API documentation

On 03/02/17 14:00, Peter Maydell wrote: > On 12 January 2017 at 15:56, Eric Auger wrote: >> Add description for how to access vITS registers and how to flush/restore >> vITS tables into/from memory >> >> Signed-off-by: Eric Auger >> --- >>

[RESEND PATCH] KVM: arm/arm64: vgic: Stop injecting the MSI occurrence twice

The IRQFD framework calls the architecture dependent function twice if the corresponding GSI type is edge triggered. For ARM, the function kvm_set_msi() is getting called twice whenever the IRQFD receives the event signal. The rest of the code path is trying to inject the MSI without any

Re: [RFC 01/13] KVM: arm/arm64: Add vITS save/restore API documentation

On 12 January 2017 at 15:56, Eric Auger wrote: > Add description for how to access vITS registers and how to flush/restore > vITS tables into/from memory > > Signed-off-by: Eric Auger > --- > Documentation/virtual/kvm/devices/arm-vgic-its.txt | 70

Re: [PATCH] KVM: arm/arm64: vgic: Stop injecting the MSI occurrence twice

Hi Shanker, [please cc the kvmarm list for kvm/arm patches, thanks] On Thu, Feb 02, 2017 at 08:30:03PM -0600, Shanker Donthineni wrote: > The IRQFD framework calls the architecture dependent function > twice if the corresponding GSI type is edge triggered. For ARM, > the function kvm_set_msi()

Re: [RFC v3 00/10] Provide the EL1 physical timer to the VM

On Fri, Feb 3, 2017 at 2:14 PM, Jintack Lim wrote: > On Fri, Feb 3, 2017 at 7:33 AM, Christoffer Dall wrote: >> On Thu, Feb 02, 2017 at 09:51:13AM -0500, Jintack Lim wrote: >>> On Thu, Feb 2, 2017 at 7:31 AM, Christoffer Dall wrote:

Re: [RFC v3 00/10] Provide the EL1 physical timer to the VM

On Fri, Feb 3, 2017 at 7:33 AM, Christoffer Dall wrote: > On Thu, Feb 02, 2017 at 09:51:13AM -0500, Jintack Lim wrote: >> On Thu, Feb 2, 2017 at 7:31 AM, Christoffer Dall wrote: >> > Hi Jintack, >> > >> > On Wed, Feb 01, 2017 at 12:43:00PM -0500, Jintack Lim

Re: [RFC v3 00/10] Provide the EL1 physical timer to the VM

On Thu, Feb 02, 2017 at 09:51:13AM -0500, Jintack Lim wrote: > On Thu, Feb 2, 2017 at 7:31 AM, Christoffer Dall wrote: > > Hi Jintack, > > > > On Wed, Feb 01, 2017 at 12:43:00PM -0500, Jintack Lim wrote: > >> The ARM architecture defines the EL1 physical timer and the virtual

Re: [PATCH v2 3/3] arm64: kvm: add support for the extended 64bit ccsidr

Hi Marc, On 01/02/17 16:02, Marc Zyngier wrote: [...] > > I'm a bit worried about this patch. If we snapshot a VM on a 32bit > CCSIDR system, and restore it on a 64bit CSSIDR system (or the reverse), > what happens? My hunch is that we cannot restore the VM properly. > I agree. I had a look at