Re: KVM/ARM: sleeping function called from invalid context

I have confirmed the theory using a sample code like : spin_lock(); spin_lock(); cond_resched_lock(); spin_unlock(); spin_unlock(); Also, the following patch solves the problem for me. 8>- sched: Fix ___might_sleep preempt count checks

Re: host stalls when qemu-system-aarch64 with kvm and pflash

On 03/29/17 20:56, Christoffer Dall wrote: > On Tue, Mar 28, 2017 at 01:24:15PM -0700, Radha Mohan wrote: >> On Tue, Mar 28, 2017 at 1:16 PM, Christoffer Dall wrote: >>> Hi Radha, >>> >>> On Tue, Mar 28, 2017 at 12:58:24PM -0700, Radha Mohan wrote: Hi, I am seeing an

Re: KVM/ARM: sleeping function called from invalid context

On 30/03/17 17:40, Suzuki K Poulose wrote: On 30/03/17 16:41, Marc Zyngier wrote: On 30/03/17 16:29, Mark Rutland wrote: On Thu, Mar 30, 2017 at 03:31:12PM +0100, Mark Rutland wrote: Hi, I'm seeing the splat below when running KVM on an arm64 host with CONFIG_DEBUG_ATOMIC_SLEEP and

Re: KVM/ARM: sleeping function called from invalid context

On 30/03/17 16:41, Marc Zyngier wrote: On 30/03/17 16:29, Mark Rutland wrote: On Thu, Mar 30, 2017 at 03:31:12PM +0100, Mark Rutland wrote: Hi, I'm seeing the splat below when running KVM on an arm64 host with CONFIG_DEBUG_ATOMIC_SLEEP and CONFIG_LOCKDEP enabled. I saw this on v4.11-rc1, and

Re: [PATCH v3 1/8] trace: ras: add ARM processor error information trace event

On Thu, 30 Mar 2017 18:31:01 +0800 Xie XiuQi wrote: > Add a new trace event for ARM processor error information, so that > the user will know what error occurred. With this information the > user may take appropriate action. > > These trace events are consistent with the

Re: KVM/ARM: sleeping function called from invalid context

On 30/03/17 16:29, Mark Rutland wrote: > On Thu, Mar 30, 2017 at 03:31:12PM +0100, Mark Rutland wrote: >> Hi, >> >> I'm seeing the splat below when running KVM on an arm64 host with >> CONFIG_DEBUG_ATOMIC_SLEEP and CONFIG_LOCKDEP enabled. >> >> I saw this on v4.11-rc1, and I can reproduce the

Re: KVM/ARM: sleeping function called from invalid context

On Thu, Mar 30, 2017 at 03:31:12PM +0100, Mark Rutland wrote: > Hi, > > I'm seeing the splat below when running KVM on an arm64 host with > CONFIG_DEBUG_ATOMIC_SLEEP and CONFIG_LOCKDEP enabled. > > I saw this on v4.11-rc1, and I can reproduce the problem on the current > kvmarm master branch

KVM/ARM: sleeping function called from invalid context

Hi, I'm seeing the splat below when running KVM on an arm64 host with CONFIG_DEBUG_ATOMIC_SLEEP and CONFIG_LOCKDEP enabled. I saw this on v4.11-rc1, and I can reproduce the problem on the current kvmarm master branch (563e2f5daa66fbc1). I've hacked noinlines into arch/arm/kvm/mmu.c in an

[no subject]

subscribe kvm-arm ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: host stalls when qemu-system-aarch64 with kvm and pflash

On 29/03/17 19:56, Christoffer Dall wrote: > On Tue, Mar 28, 2017 at 01:24:15PM -0700, Radha Mohan wrote: >> On Tue, Mar 28, 2017 at 1:16 PM, Christoffer Dall wrote: >>> Hi Radha, >>> >>> On Tue, Mar 28, 2017 at 12:58:24PM -0700, Radha Mohan wrote: Hi, I am seeing an

[PATCH v3 1/8] trace: ras: add ARM processor error information trace event

Add a new trace event for ARM processor error information, so that the user will know what error occurred. With this information the user may take appropriate action. These trace events are consistent with the ARM processor error information table which defined in UEFI 2.6 spec section N.2.4.4.1.

[PATCH v3 8/8] arm64: exception: check shared writable page in SEI handler

From: Wang Xiongfeng Since SEI is asynchronous, the error data has been consumed. So we must suppose that all the memory data current process can write are contaminated. If the process doesn't have shared writable pages, the process will be killed, and the system will

[PATCH v3 8/8] arm64: exception: check shared writable page in SEI handler

From: Wang Xiongfeng Since SEI is asynchronous, the error data has been consumed. So we must suppose that all the memory data current process can write are contaminated. If the process doesn't have shared writable pages, the process will be killed, and the system will

[PATCH v3 7/8] arm64: exception: handle asynchronous SError interrupt

Error Synchronization Barrier (ESB; part of the ARMv8.2 Extensions) is used to synchronize Unrecoverable errors. That is, containable errors architecturally consumed by the PE and not silently propagated. With ESB it is generally possible to isolate an unrecoverable error between two ESB

[PATCH v3 1/8] trace: ras: add ARM processor error information trace event

Add a new trace event for ARM processor error information, so that the user will know what error occurred. With this information the user may take appropriate action. These trace events are consistent with the ARM processor error information table which defined in UEFI 2.6 spec section N.2.4.4.1.

[PATCH v3 3/8] arm64: apei: add a per-cpu variable to indecate sei is processing

Add a per-cpu variable to indicate sei is processing, with which we could use to reserve a separate virtual space address page for sei in next patch Signed-off-by: Xie XiuQi --- arch/arm64/kernel/traps.c | 4 include/acpi/ghes.h | 2 ++ 2 files changed, 6

[PATCH v3 2/8] acpi: apei: handle SEI notification type for ARMv8

ARM APEI extension proposal added SEI (asynchronous SError interrupt) notification type for ARMv8. Add a new GHES error source handling function for SEI. In firmware first mode, if an error source's notification type is SEI. Then GHES could parse and report the detail error information.

[PATCH v3 4/8] APEI: GHES: reserve a virtual page for SEI context

On arm64 platform, SEI may interrupt code which had interrupts masked. But SEI could be masked, so it's not treated as NMI, however SEA is treated as NMI. So, the memory area used to transfer hardware error information from BIOS to Linux can be determined only in NMI, SEI(arm64), IRQ or timer

[PATCH v3 6/8] arm64: RAS: add ras extension runtime detection

According to <> document, we add RAS extension feature runtime detection, which would be used for error recovery in the future. Signed-off-by: Xie XiuQi Reviewed-by: Kefeng Wang --- arch/arm64/include/asm/cpucaps.h | 3 ++-

[PATCH v3 2/8] acpi: apei: handle SEI notification type for ARMv8

ARM APEI extension proposal added SEI (asynchronous SError interrupt) notification type for ARMv8. Add a new GHES error source handling function for SEI. In firmware first mode, if an error source's notification type is SEI. Then GHES could parse and report the detail error information.

[PATCH v3 0/8] arm64: acpi: apei: handle SEI notification type for ARMv8

ARM APEI extension proposal added SEI (asynchronous SError interrupt) notification type for ARMv8. Add a new GHES error source handling function for SEI. In firmware first mode, if an error source's notification type is SEI. Then GHES could parse and report the detail error information. In

[PATCH v3 6/8] arm64: RAS: add ras extension runtime detection

According to <> document, we add RAS extension feature runtime detection, which would be used for error recovery in the future. Signed-off-by: Xie XiuQi Reviewed-by: Kefeng Wang --- arch/arm64/include/asm/cpucaps.h | 3 ++-

[PATCH v3 4/8] APEI: GHES: reserve a virtual page for SEI context

On arm64 platform, SEI may interrupt code which had interrupts masked. But SEI could be masked, so it's not treated as NMI, however SEA is treated as NMI. So, the memory area used to transfer hardware error information from BIOS to Linux can be determined only in NMI, SEI(arm64), IRQ or timer

[PATCH v3 0/8] arm64: acpi: apei: handle SEI notification type for ARMv8

ARM APEI extension proposal added SEI (asynchronous SError interrupt) notification type for ARMv8. Add a new GHES error source handling function for SEI. In firmware first mode, if an error source's notification type is SEI. Then GHES could parse and report the detail error information. In

Re: [kbuild-all] [PATCH v4 13/22] KVM: arm64: ITS: KVM_DEV_ARM_VGIC_GRP_ITS_TABLES group

On 03/30, Auger Eric wrote: >Hi Xiaolong > >On 30/03/2017 04:21, Ye Xiaolong wrote: >> Hi, Eric >> >> On 03/27, Auger Eric wrote: >>> Hi, >>> >>> On 27/03/2017 17:04, kbuild test robot wrote: Hi Eric, [auto build test ERROR on kvmarm/next] [also build test ERROR on v4.11-rc4

Re: [kbuild-all] [PATCH v4 13/22] KVM: arm64: ITS: KVM_DEV_ARM_VGIC_GRP_ITS_TABLES group

Hi, Eric On 03/27, Auger Eric wrote: >Hi, > >On 27/03/2017 17:04, kbuild test robot wrote: >> Hi Eric, >> >> [auto build test ERROR on kvmarm/next] >> [also build test ERROR on v4.11-rc4 next-20170327] >> [if your patch is applied to the wrong git tree, please drop us a note to >> help improve

Re: [kbuild-all] [PATCH v4 13/22] KVM: arm64: ITS: KVM_DEV_ARM_VGIC_GRP_ITS_TABLES group

Hi Xiaolong, On 30/03/2017 09:29, Ye Xiaolong wrote: > On 03/30, Auger Eric wrote: >> Hi Xiaolong >> >> On 30/03/2017 04:21, Ye Xiaolong wrote: >>> Hi, Eric >>> >>> On 03/27, Auger Eric wrote: Hi, On 27/03/2017 17:04, kbuild test robot wrote: > Hi Eric, > > [auto build

Re: [kvmtool PATCH v9 06/15] PCI: Only allocate IRQ routing entry when available

On Wed, Mar 29 2017 at 9:44:47 pm BST, André Przywara wrote: > Hi Marc, > > thanks for having a look! > > On 29/03/17 09:30, Marc Zyngier wrote: >> On 02/02/17 16:32, Andre Przywara wrote: >>> If we need to inject an MSI into the guest, we rely at the moment on a >>>

Re: [kbuild-all] [PATCH v4 13/22] KVM: arm64: ITS: KVM_DEV_ARM_VGIC_GRP_ITS_TABLES group

Hi Xiaolong On 30/03/2017 04:21, Ye Xiaolong wrote: > Hi, Eric > > On 03/27, Auger Eric wrote: >> Hi, >> >> On 27/03/2017 17:04, kbuild test robot wrote: >>> Hi Eric, >>> >>> [auto build test ERROR on kvmarm/next] >>> [also build test ERROR on v4.11-rc4 next-20170327] >>> [if your patch is