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
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
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
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
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
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
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.
> >
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
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
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
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
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
>
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 +
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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 ++
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
---
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
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:
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 +++
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
---
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
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
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
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
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
>
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
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
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
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
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
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
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
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
50 matches
Mail list logo