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

Hi Tyler, [auto build test ERROR on pm/linux-next] [also build test ERROR on v4.10-rc6 next-20170201] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Tyler-Baicar/Add-UEFI-2-6-and-ACPI-6-1

Re: [PATCH V8 08/10] ras: acpi / apei: generate trace event for unrecognized CPER section

Hi Tyler, [auto build test ERROR on pm/linux-next] [also build test ERROR on v4.10-rc6 next-20170201] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Tyler-Baicar/Add-UEFI-2-6-and-ACPI-6-1

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

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 the user > will know when they occur. These trace events

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

Hi Tyler, [auto build test ERROR on pm/linux-next] [also build test ERROR on v4.10-rc6 next-20170201] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Tyler-Baicar/Add-UEFI-2-6-and-ACPI-6-1

[PATCH] KVM: arm/arm64: Remove kvm_vgic_inject_mapped_irq

The only benefit of having kvm_vgic_inject_mapped_irq separate from kvm_vgic_inject_irq is that we pass a boolean that we use for error checking on the injection path. While this could potentially help in some aspect of robustness, it's also a little bit of a defensive move, and arguably callers

Re: [PATCH] KVM: arm/arm64: Remove kvm_vgic_inject_mapped_irq

On 01/02/17 10:22, Christoffer Dall wrote: > The only benefit of having kvm_vgic_inject_mapped_irq separate from > kvm_vgic_inject_irq is that we pass a boolean that we use for error > checking on the injection path. > > While this could potentially help in some aspect of robustness, it's > also

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

On Sun, Jan 29, 2017 at 03:21:06PM +, Marc Zyngier wrote: > On Fri, Jan 27 2017 at 01:04:56 AM, Jintack Lim > wrote: > > Now that we maintain the EL1 physical timer register states of VMs, > > update the physical timer interrupt level along with the virtual one. > >

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

On 01/02/17 10:07, Christoffer Dall wrote: > On Wed, Feb 01, 2017 at 03:40:10AM -0500, Jintack Lim wrote: >> On Wed, Feb 1, 2017 at 3:04 AM, Christoffer Dall >> wrote: >>> On Sun, Jan 29, 2017 at 03:21:06PM +, Marc Zyngier wrote: On Fri, Jan 27 2017 at

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

On Wed, Feb 1, 2017 at 3:04 AM, Christoffer Dall wrote: > On Sun, Jan 29, 2017 at 03:21:06PM +, Marc Zyngier wrote: >> On Fri, Jan 27 2017 at 01:04:56 AM, Jintack Lim >> wrote: >> > Now that we maintain the EL1 physical timer register

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

On 01/02/17 08:04, Christoffer Dall wrote: > On Sun, Jan 29, 2017 at 03:21:06PM +, Marc Zyngier wrote: >> On Fri, Jan 27 2017 at 01:04:56 AM, Jintack Lim >> wrote: >>> Now that we maintain the EL1 physical timer register states of VMs, >>> update the physical timer

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

On 30/01/17 19:04, Christoffer Dall wrote: > On Mon, Jan 30, 2017 at 05:44:20PM +, Marc Zyngier wrote: >> Wventually, we'll have to support an offset-able >> physical counter to support nested virtualization, but this can come at >> a later time. >> > Why do we need the offset-able physical

Re: [PATCH] KVM: arm/arm64: Remove kvm_vgic_inject_mapped_irq

Hi, On 01/02/17 10:22, Christoffer Dall wrote: > The only benefit of having kvm_vgic_inject_mapped_irq separate from > kvm_vgic_inject_irq is that we pass a boolean that we use for error > checking on the injection path. > > While this could potentially help in some aspect of robustness, it's >

[PATCH V8 10/10] arm/arm64: KVM: add guest SEA support

Currently external aborts are unsupported by the guest abort handling. Add handling for SEAs so that the host kernel reports SEAs which occur in the guest kernel. Signed-off-by: Tyler Baicar --- arch/arm/include/asm/kvm_arm.h | 1 +

Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003

On Wed, Feb 01, 2017 at 05:36:09PM +, Catalin Marinas wrote: > On Wed, Feb 01, 2017 at 04:33:58PM +, Will Deacon wrote: > > On Wed, Feb 01, 2017 at 11:29:22AM -0500, Christopher Covington wrote: > > > On 01/31/2017 12:56 PM, Marc Zyngier wrote: > > > > Given that all ARMv8 CPUs can support

[RFC v3 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 v3 02/10] KVM: arm/arm64: Move cntvoff to each timer context

Make cntvoff per each timer context. This is helpful to abstract kvm timer functions to work with timer context without considering timer types (e.g. physical timer or virtual timer). This also would pave the way for ever doing adjustments of the cntvoff on a per-CPU basis if that should ever

Re: [PATCH v4 3/4] arm64: Use __tlbi() macros in KVM code

Will Deacon writes: > On Wed, Jan 25, 2017 at 08:39:43PM +0100, Christoffer Dall wrote: >> On Wed, Jan 25, 2017 at 10:52:31AM -0500, Christopher Covington wrote: >> > Refactor the KVM code to use the __tlbi macros, which will allow an errata >> > workaround that repeats tlbi

[PATCH V8 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1

Currently when a RAS error is reported it is not timestamped. The ACPI 6.1 spec adds the timestamp field to the generic error data entry v3 structure. The timestamp of when the firmware generated the error is now being reported. Signed-off-by: Tyler Baicar Signed-off-by:

[PATCH V8 01/10] acpi: apei: read ack upon ghes record consumption

A RAS (Reliability, Availability, Serviceability) controller may be a separate processor running in parallel with OS execution, and may generate error records for consumption by the OS. If the RAS controller produces multiple error records, then they may be overwritten before the OS has consumed

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

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, report the error in the kernel logs. Update fault_info[] with

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

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 into the SEA exception handler. That way GHES will parse and

[PATCH V8 06/10] acpi: apei: panic OS with fatal error status block

From: "Jonathan (Zhixiong) Zhang" Even if an error status block's severity is fatal, the kernel does not honor the severity level and panic. With the firmware first model, the platform could inform the OS about a fatal hardware error through the non-NMI GHES notification

[PATCH V8 00/10] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64

When a memory error, CPU error, PCIe error, or other type of hardware error that's covered by RAS occurs, firmware should populate the shared GHES memory location with the proper GHES structures to notify the OS of the error. For example, platforms that implement firmware first handling may

[PATCH V8 03/10] efi: parse ARM processor error

Add support for ARM Common Platform Error Record (CPER). UEFI 2.6 specification adds support for ARM specific processor error information to be reported as part of the CPER records. This provides more detail on for processor error logs. Signed-off-by: Tyler Baicar

Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003

On Wed, Feb 01, 2017 at 05:49:34PM +, Catalin Marinas wrote: > On Wed, Feb 01, 2017 at 05:41:05PM +, Will Deacon wrote: > > On Wed, Feb 01, 2017 at 05:36:09PM +, Catalin Marinas wrote: > > > On Wed, Feb 01, 2017 at 04:33:58PM +, Will Deacon wrote: > > > > On Wed, Feb 01, 2017 at

Re: [PATCH v4 3/4] arm64: Use __tlbi() macros in KVM code

On Wed, Feb 01, 2017 at 05:02:43PM +, Punit Agrawal wrote: > Will Deacon writes: > > > On Wed, Jan 25, 2017 at 08:39:43PM +0100, Christoffer Dall wrote: > >> On Wed, Jan 25, 2017 at 10:52:31AM -0500, Christopher Covington wrote: > >> > Refactor the KVM code to use the

Re: [PATCH v8 01/16] FDT: introduce global phandle allocation

On Wed, Feb 01 2017 at 4:44:19 pm GMT, André Przywara wrote: Hi Andre, > Hi Marc, Will, > > On 09/12/16 12:03, Marc Zyngier wrote: >> On 04/11/16 17:31, Andre Przywara wrote: >>> Allocating an FDT phandle (a unique identifier) using a static >>> variable in a static

[PATCH V8 07/10] efi: print unrecognized CPER section

UEFI spec allows for non-standard section in Common Platform Error Record. This is defined in section N.2.3 of UEFI version 2.5. Currently if the CPER section's type (UUID) does not match with one of the section types that the kernel knows how to parse, the section is skipped. Therefore, user is

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

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 the user will know when they occur. These trace events are consistent with the ARM processor error section type defined in UEFI 2.6 spec

[PATCH V8 08/10] ras: acpi / apei: generate trace event for unrecognized CPER section

UEFI spec allows for non-standard section in Common Platform Error Record. This is defined in section N.2.3 of UEFI version 2.5. Currently if the CPER section's type (UUID) does not match with any section type that the kernel knows how to parse, trace event is not generated for such section. And

Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003

On Wed, Feb 01, 2017 at 04:33:58PM +, Will Deacon wrote: > On Wed, Feb 01, 2017 at 11:29:22AM -0500, Christopher Covington wrote: > > On 01/31/2017 12:56 PM, Marc Zyngier wrote: > > > Given that all ARMv8 CPUs can support SW_PAN, it is more likely to be > > > enabled than the ARMv8.1 PAN. I'd

[RFC v3 10/10] KVM: arm/arm64: Emulate the EL1 phys timer registers

Emulate read and write operations to CNTP_TVAL, CNTP_CVAL and CNTP_CTL. Now VMs are able to use the EL1 physical timer. Signed-off-by: Jintack Lim --- arch/arm64/kvm/sys_regs.c| 37 ++--- include/kvm/arm_arch_timer.h | 2 ++

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

Add the EL1 physical timer context. Signed-off-by: Jintack Lim --- 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 index f46fa3b..6445a3d 100644 ---

[RFC v3 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 v3 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 v3 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 --- arch/arm/kvm/arm.c| 3 ++- virt/kvm/arm/arch_timer.c | 53 +++

[RFC v3 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 ---

[RFC v3 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

[RFC v3 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 --- arch/arm/kvm/reset.c | 9 - arch/arm64/kvm/reset.c | 9 - include/kvm/arm_arch_timer.h | 3 ++- virt/kvm/arm/arch_timer.c| 9

[RFC v3 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 --- virt/kvm/arm/arch_timer.c | 4 1 file changed, 4 insertions(+) diff --git

Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003

On Wed, Feb 01, 2017 at 05:41:05PM +, Will Deacon wrote: > On Wed, Feb 01, 2017 at 05:36:09PM +, Catalin Marinas wrote: > > On Wed, Feb 01, 2017 at 04:33:58PM +, Will Deacon wrote: > > > On Wed, Feb 01, 2017 at 11:29:22AM -0500, Christopher Covington wrote: > > > > On 01/31/2017 12:56

Re: [PATCH v2 2/3] arm64: kvm: reuse existing cache type/info related macros

On 30/01/17 16:25, Sudeep Holla wrote: > We already have various macros related to cache type and bitfields in > CLIDR system register. We can replace some of the hardcoded values > here using those existing macros. > > This patch reuses those existing cache type/info related macros and >

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

On 30/01/17 16:25, Sudeep Holla wrote: > csselr and ccsidr are treated as 64-bit values already elsewhere in the > kernel. It also aligns well with the architecture extensions that allow > 64-bit format for ccsidr. > > This patch upgrades the existing accesses to csselr and ccsidr from > 32-bit

Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003

On 01/31/2017 12:56 PM, Marc Zyngier wrote: > On 31/01/17 17:48, Christopher Covington wrote: >> On 01/31/2017 07:37 AM, Mark Rutland wrote: >>> On Wed, Jan 25, 2017 at 10:52:30AM -0500, Christopher Covington wrote: The Qualcomm Datacenter Technologies Falkor v1 CPU may allocate TLB entries

Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003

On Wed, Feb 01, 2017 at 11:29:22AM -0500, Christopher Covington wrote: > On 01/31/2017 12:56 PM, Marc Zyngier wrote: > > Given that all ARMv8 CPUs can support SW_PAN, it is more likely to be > > enabled than the ARMv8.1 PAN. I'd vote for supporting the workaround in > > that case too, and hope

Re: [PATCH v8 01/16] FDT: introduce global phandle allocation

Hi Marc, Will, On 09/12/16 12:03, Marc Zyngier wrote: > On 04/11/16 17:31, Andre Przywara wrote: >> Allocating an FDT phandle (a unique identifier) using a static >> variable in a static inline function defined in a header file works >> only if all users are in the same source file. So trying to

Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003

On Wed, Feb 01, 2017 at 06:34:01PM +, Will Deacon wrote: > On Wed, Feb 01, 2017 at 06:22:44PM +, Catalin Marinas wrote: > > On Wed, Feb 01, 2017 at 05:59:48PM +, Will Deacon wrote: > > > On Wed, Feb 01, 2017 at 05:49:34PM +, Catalin Marinas wrote: > > > > On Wed, Feb 01, 2017 at

Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003

On Wed, Feb 01, 2017 at 05:49:34PM +, Catalin Marinas wrote: > On Wed, Feb 01, 2017 at 05:41:05PM +, Will Deacon wrote: > > On Wed, Feb 01, 2017 at 05:36:09PM +, Catalin Marinas wrote: > > > On Wed, Feb 01, 2017 at 04:33:58PM +, Will Deacon wrote: > > > > On Wed, Feb 01, 2017 at

Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003

On Wed, Feb 01, 2017 at 06:22:44PM +, Catalin Marinas wrote: > On Wed, Feb 01, 2017 at 05:59:48PM +, Will Deacon wrote: > > On Wed, Feb 01, 2017 at 05:49:34PM +, Catalin Marinas wrote: > > > On Wed, Feb 01, 2017 at 05:41:05PM +, Will Deacon wrote: > > > > Maybe > > > > just select

Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003

On Wed, Feb 01, 2017 at 05:59:48PM +, Will Deacon wrote: > On Wed, Feb 01, 2017 at 05:49:34PM +, Catalin Marinas wrote: > > On Wed, Feb 01, 2017 at 05:41:05PM +, Will Deacon wrote: > > > On Wed, Feb 01, 2017 at 05:36:09PM +, Catalin Marinas wrote: > > > > On Wed, Feb 01, 2017 at