Re: [PATCH v3 00/25] arm/arm64: KVM: Rework the hyp-stub API
On Tuesday 14 March 2017 07:55 PM, Nishanth Menon wrote: > On Tue, Mar 14, 2017 at 8:55 AM, Marc Zyngier wrote: > [...] >>> Tested for kexec booting with the patch series applied on linux-next. >>> >>> kexec is working nicely with HYP and SVC modes. Tested for both modes by >>> using different u-boot for booting in HYP and SVC modes. Kexec works well. >>> >>> Tested on DRA7-EVM, AM57XX-EVM and KEYSTONE-K2E-EVM. >>> >>> Tested-by: Keerthy >> >> Thanks a lot. I assume this Tested-by applies to the 32bit patches in >> this series? > > Yes, the above platform list from Keerthy are all A15 32bit platforms. Yes Marc. All are 32 bit platforms. > > --- > Regards, > Nishanth Menon > ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH V12 09/10] trace, ras: add ARM processor error trace event
Hello Xie XiUQi,
On 3/12/2017 8:31 PM, Xie XiuQi wrote:
Hi Baicar Tyler,
On 2017/3/11 2:23, Baicar, Tyler wrote:
Hello Xie XiuQi,
On 3/9/2017 2:41 AM, Xie XiuQi wrote:
On 2017/3/7 4:45, 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 are
consistent with the ARM processor error section type
defined in UEFI 2.6 spec section N.2.4.4.
Signed-off-by: Tyler Baicar
Acked-by: Steven Rostedt
---
drivers/acpi/apei/ghes.c| 8 +++-
drivers/firmware/efi/cper.c | 1 +
drivers/ras/ras.c | 1 +
include/ras/ras_event.h | 34 ++
4 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h
index 5861b6f..b36db48 100644
--- a/include/ras/ras_event.h
+++ b/include/ras/ras_event.h
@@ -162,6 +162,40 @@
);
/*
+ * ARM Processor Events Report
+ *
+ * This event is generated when hardware detects an ARM processor error
+ * has occurred. UEFI 2.6 spec section N.2.4.4.
+ */
+TRACE_EVENT(arm_event,
+
+TP_PROTO(const struct cper_sec_proc_arm *proc),
+
+TP_ARGS(proc),
+
+TP_STRUCT__entry(
+__field(u64, mpidr)
+__field(u64, midr)
+__field(u32, running_state)
+__field(u32, psci_state)
+__field(u8, affinity)
+),
+
+TP_fast_assign(
+__entry->affinity = proc->affinity_level;
+__entry->mpidr = proc->mpidr;
+__entry->midr = proc->midr;
+__entry->running_state = proc->running_state;
+__entry->psci_state = proc->psci_state;
+),
+
+TP_printk("affinity level: %d; MPIDR: %016llx; MIDR: %016llx; "
+ "running state: %d; PSCI state: %d",
+ __entry->affinity, __entry->mpidr, __entry->midr,
+ __entry->running_state, __entry->psci_state)
+);
+
I think these fields are not enough, we need also export arm processor error
information (UEFI 2.6 spec section N.2.4.4.1), or at least the error type,
address, etc. So that the userspace (such as rasdaemon tool) could know what
error occurred.
This is something I am planning on adding in later. It is not clear to me how to
actually do this at this point. If you look at the spec, there is not a single
error information structure. There is at least one, but possibly a lot. There is
also an unknown amount of context information structures. In "Table 260. ARM
Processor
Error Section" there are ERR_INFO_NUM and CONTEXT_INFO_NUM which give the
number of these
structures. I think there will need to be separate trace events added in for
each of
these structures because I don't think there is a way to have variable amounts
of
structures inside of a trace event.
Yes, I agree.
Additional, cper_sec_proc_arm has validation bit, which indicates whether or
not each of
the fields is valid in this section. How could we show it in this trace event?
If the filed
is invalid, we would get a wrong value here.
I will add in checks for whether the fields are valid similar to what
you did for the error info patch.
Thanks,
Tyler
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: kvm/arm64: use-after-free in kvm_unmap_hva_handler/unmap_stage2_pmds
On 14/03/2017 12:07, Suzuki K Poulose wrote: > On 10/03/17 13:34, Andrey Konovalov wrote: >> Hi, >> >> I've got the following error report while fuzzing the kernel with >> syzkaller. >> >> On linux-next commit 56b8bad5e066c23e8fa273ef5fba50bd3da2ace8 (Mar 8). >> >> Unfortunately I can't reproduce it. >> >> == >> BUG: KASAN: use-after-free in put_page include/linux/compiler.h:243 >> [inline] >> BUG: KASAN: use-after-free in unmap_stage2_pmds >> arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:240 [inline] >> BUG: KASAN: use-after-free in unmap_stage2_puds >> arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:269 [inline] >> BUG: KASAN: use-after-free in unmap_stage2_range+0x884/0x938 >> arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:299 >> Read of size 8 at addr 80004585c000 by task syz-executor/5176 > > >> [] put_page include/linux/compiler.h:243 [inline] >> [] unmap_stage2_pmds >> arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:240 [inline] >> [] unmap_stage2_puds >> arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:269 [inline] >> [] unmap_stage2_range+0x884/0x938 >> arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:299 >> [] kvm_unmap_hva_handler+0x28/0x38 >> arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:1556 >> [] handle_hva_to_gpa+0x140/0x250 >> arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:1547 >> [] kvm_unmap_hva_range+0x60/0x80 >> arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:1579 >> [] >> kvm_mmu_notifier_invalidate_range_start+0x194/0x278 >> arch/arm64/kvm/../../../virt/kvm/kvm_main.c:357 >> [] __mmu_notifier_invalidate_range_start+0x1d0/0x2a0 >> mm/mmu_notifier.c:199 >> [] mmu_notifier_invalidate_range_start >> include/linux/mmu_notifier.h:282 [inline] >> [] unmap_vmas+0x12c/0x198 mm/memory.c:1372 >> [] unmap_region+0x128/0x230 mm/mmap.c:2460 >> [] update_hiwater_vm include/linux/mm.h:1483 [inline] >> [] remove_vma_list mm/mmap.c:2432 [inline] >> [] do_munmap+0x598/0x9b0 mm/mmap.c:2662 >> [] find_vma_links mm/mmap.c:495 [inline] >> [] mmap_region+0x138/0xc78 mm/mmap.c:1610 >> [] is_file_hugepages include/linux/hugetlb.h:269 >> [inline] >> [] do_mmap+0x3cc/0x848 mm/mmap.c:1446 >> [] do_mmap_pgoff include/linux/mm.h:2039 [inline] >> [] vm_mmap_pgoff+0xec/0x120 mm/util.c:305 >> [] SYSC_mmap_pgoff mm/mmap.c:1475 [inline] >> [] SyS_mmap_pgoff+0x220/0x420 mm/mmap.c:1458 >> [] sys_mmap+0x58/0x80 arch/arm64/kernel/sys.c:37 >> [] el0_svc_naked+0x24/0x28 >> > > We hold kvm->mmu_lock, while manipulating the stage2 ranges. However, I > find that > we don't take the lock, when we do it f rom kvm_free_stage2_pgd(), which > could > potentially have caused a problem with an munmap of a memslot ? > > Lightly tested... > > > commit fa75684dbf0fe845cf8403517d6e0c2c3344a544 > Author: Suzuki K Poulose > Date: Tue Mar 14 10:26:54 2017 + > > kvm: arm: Fix locking for kvm_free_stage2_pgd > In kvm_free_stage2_pgd() we don't hold the kvm->mmu_lock while > calling > unmap_stage2_range() on the entire memory range for the guest. This > could > cause problems with other callers (e.g, munmap on a memslot) trying to > unmap a range. > Cc: Marc Zyngier > Cc: Christoffer Dall > Signed-off-by: Suzuki K Poulose > > diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c > index a07ce3e..7f97063 100644 > --- a/arch/arm/kvm/mmu.c > +++ b/arch/arm/kvm/mmu.c > @@ -831,7 +831,10 @@ void kvm_free_stage2_pgd(struct kvm *kvm) > if (kvm->arch.pgd == NULL) > return; > > + spin_lock(&kvm->mmu_lock); > unmap_stage2_range(kvm, 0, KVM_PHYS_SIZE); > + spin_unlock(&kvm->mmu_lock); > + > /* Free the HW pgd, one page at a time */ > free_pages_exact(kvm->arch.pgd, S2_PGD_SIZE); > kvm->arch.pgd = NULL; Reviewed-by: Paolo Bonzini > > > >> The buggy address belongs to the page: >> page:7e0001161700 count:0 mapcount:0 mapping: (null) >> index:0x0 >> flags: 0xfffc000() >> raw: 0fffc000 >> raw: 7e00018c9120 7eea8b60 >> page dumped because: kasan: bad access detected >> >> Memory state around the buggy address: >> 80004585bf00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >> 80004585bf80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >>> 80004585c000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >>^ >> 80004585c080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >> 80004585c100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >> == >> > ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v3 00/25] arm/arm64: KVM: Rework the hyp-stub API
On 14/03/17 16:05, Russell King - ARM Linux wrote: > On Mon, Mar 06, 2017 at 02:24:33PM +, Marc Zyngier wrote: >> As noticed by RMK in this thread[1], the hyp-stub API on 32bit ARM >> could do with some TLC (it cannot perform a soft-restart at HYP, and >> has holes in the hyp-stub support in a number of places). In general, >> it would be desirable for the 32bit behaviour to align on 64bit, if >> only to ease maintenance. > > What's the merge plan for this? If you're happy with it (together with Christoffer, Will and Catalin), I plat to take it through the kvmarm tree. Thanks, M. -- Jazz is not dead. It just smells funny... ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v3 00/25] arm/arm64: KVM: Rework the hyp-stub API
On Mon, Mar 06, 2017 at 02:24:33PM +, Marc Zyngier wrote: > As noticed by RMK in this thread[1], the hyp-stub API on 32bit ARM > could do with some TLC (it cannot perform a soft-restart at HYP, and > has holes in the hyp-stub support in a number of places). In general, > it would be desirable for the 32bit behaviour to align on 64bit, if > only to ease maintenance. What's the merge plan for this? -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
[PATCH 1/3] kvm: arm/arm64: Take mmap_sem in stage2_unmap_vm
From: Marc Zyngier
We don't hold the mmap_sem while searching for the VMAs when
we try to unmap each memslot for a VM. Fix this properly to
avoid unexpected results.
Fixes: commit 957db105c997 ("arm/arm64: KVM: Introduce stage2_unmap_vm")
Cc: sta...@vger.kernel.org # v3.19+
Cc: Christoffer Dall
Signed-off-by: Marc Zyngier
Signed-off-by: Suzuki K Poulose
---
arch/arm/kvm/mmu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 962616f..f2e2e0c 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -803,6 +803,7 @@ void stage2_unmap_vm(struct kvm *kvm)
int idx;
idx = srcu_read_lock(&kvm->srcu);
+ down_read(¤t->mm->mmap_sem);
spin_lock(&kvm->mmu_lock);
slots = kvm_memslots(kvm);
@@ -810,6 +811,7 @@ void stage2_unmap_vm(struct kvm *kvm)
stage2_unmap_memslot(kvm, memslot);
spin_unlock(&kvm->mmu_lock);
+ up_read(¤t->mm->mmap_sem);
srcu_read_unlock(&kvm->srcu, idx);
}
--
2.7.4
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
[PATCH 0/3] kvm: arm/arm64: Fixes for use after free problems
This series contains potential fixes for problems reported by [0] & [1]. [0] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/492944.html [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/492943.html Marc Zyngier (2): kvm: arm/arm64: Take mmap_sem in stage2_unmap_vm kvm: arm/arm64: Take mmap_sem in kvm_arch_prepare_memory_region Suzuki K Poulose (1): kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd arch/arm/kvm/mmu.c | 16 +--- 1 file changed, 13 insertions(+), 3 deletions(-) -- 2.7.4 ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
[PATCH 3/3] kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd
In kvm_free_stage2_pgd() we don't hold the kvm->mmu_lock while calling
unmap_stage2_range() on the entire memory range for the guest. This could
cause problems with other callers (e.g, munmap on a memslot) trying to
unmap a range.
Fixes: commit d5d8184d35c9 ("KVM: ARM: Memory virtualization setup")
Cc: sta...@vger.kernel.org # v3.10+
Cc: Marc Zyngier
Cc: Christoffer Dall
Signed-off-by: Suzuki K Poulose
---
arch/arm/kvm/mmu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 13b9c1f..b361f71 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -831,7 +831,10 @@ void kvm_free_stage2_pgd(struct kvm *kvm)
if (kvm->arch.pgd == NULL)
return;
+ spin_lock(&kvm->mmu_lock);
unmap_stage2_range(kvm, 0, KVM_PHYS_SIZE);
+ spin_unlock(&kvm->mmu_lock);
+
/* Free the HW pgd, one page at a time */
free_pages_exact(kvm->arch.pgd, S2_PGD_SIZE);
kvm->arch.pgd = NULL;
--
2.7.4
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
[PATCH 2/3] kvm: arm/arm64: Take mmap_sem in kvm_arch_prepare_memory_region
From: Marc Zyngier
We don't hold the mmap_sem while searching for VMAs (via find_vma), in
kvm_arch_prepare_memory_region, which can end up in expected failures.
Fixes: commit 8eef91239e57 ("arm/arm64: KVM: map MMIO regions at creation time")
Cc: Ard Biesheuvel
Cc: Christoffer Dall
Cc: Eric Auger
Cc: sta...@vger.kernel.org # v3.18+
Signed-off-by: Marc Zyngier
[ Handle dirty page logging failure case ]
Signed-off-by: Suzuki K Poulose
---
arch/arm/kvm/mmu.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index f2e2e0c..13b9c1f 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -1803,6 +1803,7 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
(KVM_PHYS_SIZE >> PAGE_SHIFT))
return -EFAULT;
+ down_read(¤t->mm->mmap_sem);
/*
* A memory region could potentially cover multiple VMAs, and any holes
* between them, so iterate over all of them to find out if we can map
@@ -1846,8 +1847,10 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
pa += vm_start - vma->vm_start;
/* IO region dirty page logging not allowed */
- if (memslot->flags & KVM_MEM_LOG_DIRTY_PAGES)
- return -EINVAL;
+ if (memslot->flags & KVM_MEM_LOG_DIRTY_PAGES) {
+ ret = -EINVAL;
+ goto out;
+ }
ret = kvm_phys_addr_ioremap(kvm, gpa, pa,
vm_end - vm_start,
@@ -1859,7 +1862,7 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
} while (hva < reg_end);
if (change == KVM_MR_FLAGS_ONLY)
- return ret;
+ goto out;
spin_lock(&kvm->mmu_lock);
if (ret)
@@ -1867,6 +1870,8 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
else
stage2_flush_memslot(kvm, memslot);
spin_unlock(&kvm->mmu_lock);
+out:
+ up_read(¤t->mm->mmap_sem);
return ret;
}
--
2.7.4
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v3 00/25] arm/arm64: KVM: Rework the hyp-stub API
On Tue, Mar 14, 2017 at 8:55 AM, Marc Zyngier wrote: [...] >> Tested for kexec booting with the patch series applied on linux-next. >> >> kexec is working nicely with HYP and SVC modes. Tested for both modes by >> using different u-boot for booting in HYP and SVC modes. Kexec works well. >> >> Tested on DRA7-EVM, AM57XX-EVM and KEYSTONE-K2E-EVM. >> >> Tested-by: Keerthy > > Thanks a lot. I assume this Tested-by applies to the 32bit patches in > this series? Yes, the above platform list from Keerthy are all A15 32bit platforms. --- Regards, Nishanth Menon ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v3 00/25] arm/arm64: KVM: Rework the hyp-stub API
On 14/03/17 13:38, Keerthy wrote: > > > On Monday 06 March 2017 07:54 PM, Marc Zyngier wrote: >> As noticed by RMK in this thread[1], the hyp-stub API on 32bit ARM >> could do with some TLC (it cannot perform a soft-restart at HYP, and >> has holes in the hyp-stub support in a number of places). In general, >> it would be desirable for the 32bit behaviour to align on 64bit, if >> only to ease maintenance. >> >> This series implements the following: >> - Add HVC_[GS]ET_VECTORS and HVC_SOFT_RESTART to the 32bit code >> - Add HVC_RESET_VECTORS to both arm and arm64, removing the need for >> __hyp_reset_vectors >> - Implement add the stub entry points in the KVM init code, which >> didn't implement any so far >> - Convert the HYP code to use the init code stubs directly >> - Some general cleanup as a result of these changes (which includes >> killing HVC_GET_VECTORS) >> - Add some API documentation that covers the above >> >> Patches 9 to 11 would be better squashed into 7 and 8, but I've kept >> separate so that I can take the blame for everything I've broken. > > Tested for kexec booting with the patch series applied on linux-next. > > kexec is working nicely with HYP and SVC modes. Tested for both modes by > using different u-boot for booting in HYP and SVC modes. Kexec works well. > > Tested on DRA7-EVM, AM57XX-EVM and KEYSTONE-K2E-EVM. > > Tested-by: Keerthy Thanks a lot. I assume this Tested-by applies to the 32bit patches in this series? Cheers, M. -- Jazz is not dead. It just smells funny... ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v3 00/25] arm/arm64: KVM: Rework the hyp-stub API
On Monday 06 March 2017 07:54 PM, Marc Zyngier wrote: > As noticed by RMK in this thread[1], the hyp-stub API on 32bit ARM > could do with some TLC (it cannot perform a soft-restart at HYP, and > has holes in the hyp-stub support in a number of places). In general, > it would be desirable for the 32bit behaviour to align on 64bit, if > only to ease maintenance. > > This series implements the following: > - Add HVC_[GS]ET_VECTORS and HVC_SOFT_RESTART to the 32bit code > - Add HVC_RESET_VECTORS to both arm and arm64, removing the need for > __hyp_reset_vectors > - Implement add the stub entry points in the KVM init code, which > didn't implement any so far > - Convert the HYP code to use the init code stubs directly > - Some general cleanup as a result of these changes (which includes > killing HVC_GET_VECTORS) > - Add some API documentation that covers the above > > Patches 9 to 11 would be better squashed into 7 and 8, but I've kept > separate so that I can take the blame for everything I've broken. Tested for kexec booting with the patch series applied on linux-next. kexec is working nicely with HYP and SVC modes. Tested for both modes by using different u-boot for booting in HYP and SVC modes. Kexec works well. Tested on DRA7-EVM, AM57XX-EVM and KEYSTONE-K2E-EVM. Tested-by: Keerthy > > This has been tested on arm (Cubietruck, Jetson TK1) and arm64 > (Seattle), both as host and guest. > > [1] > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/473472.html > > * From v2: > - Kill HVC_GET_VECTORS and the corresponding __hyp_get_vectors > > * From v1: > - Fixed some glaring bugs (reported by Ard and James) > - Tidy up stub vector export on 32bit (Ard) > - Nicer VA/PA conversion on 32bit (Ard) > - Updated cpu_v7_reset documentation > - Cleaned up HYP reset on PM events > - Minor stub documentation update > > Marc Zyngier (23): > arm64: hyp-stub: Implement HVC_RESET_VECTORS stub hypercall > arm64: KVM: Implement HVC_RESET_VECTORS stub hypercall > arm64: KVM: Implement HVC_GET_VECTORS in the init code > arm64: KVM: Allow the main HYP code to use the init hyp stub > implementation > arm64: KVM: Convert __cpu_reset_hyp_mode to using __hyp_reset_vectors > arm64: KVM: Implement HVC_SOFT_RESTART in the init code > ARM: KVM: Convert KVM to use HVC_GET_VECTORS > ARM: Update cpu_v7_reset documentation > ARM: hyp-stub: Use r1 for the soft-restart address > ARM: Expose the VA/IDMAP offset > ARM: hyp-stub: Implement HVC_RESET_VECTORS stub hypercall > ARM: KVM: Implement HVC_RESET_VECTORS stub hypercall > ARM: KVM: Implement HVC_GET_VECTORS in the init code > ARM: KVM: Allow the main HYP code to use the init hyp stub > implementation > ARM: KVM: Convert __cpu_reset_hyp_mode to using __hyp_reset_vectors > ARM: KVM: Implement HVC_SOFT_RESTART in the init code > arm/arm64: KVM: Use __hyp_reset_vectors() directly > arm/arm64: KVM: Remove kvm_get_idmap_start > arm/arm64: KVM: Use HVC_RESET_VECTORS to reinit HYP mode > ARM: decompressor: Remove __hyp_get_vectors usage > ARM: hyp-stub/KVM: Kill __hyp_get_vectors > arm64: hyp-stub/KVM: Kill __hyp_get_vectors > arm/arm64: Add hyp-stub API documentation > > Russell King (2): > ARM: hyp-stub: improve ABI > ARM: soft-reboot into same mode that we entered the kernel > > Documentation/virtual/kvm/arm/hyp-abi.txt | 45 > arch/arm/boot/compressed/head.S | 5 +++- > arch/arm/include/asm/kvm_asm.h| 2 -- > arch/arm/include/asm/kvm_host.h | 6 > arch/arm/include/asm/kvm_mmu.h| 1 - > arch/arm/include/asm/proc-fns.h | 4 +-- > arch/arm/include/asm/virt.h | 12 +++- > arch/arm/kernel/hyp-stub.S| 39 +++- > arch/arm/kernel/reboot.c | 7 +++-- > arch/arm/kvm/arm.c| 25 ++-- > arch/arm/kvm/hyp/hyp-entry.S | 29 ++ > arch/arm/kvm/init.S | 49 > ++- > arch/arm/kvm/interrupts.S | 4 --- > arch/arm/kvm/mmu.c| 5 > arch/arm/mm/mmu.c | 5 > arch/arm/mm/proc-v7.S | 15 ++ > arch/arm64/include/asm/kvm_asm.h | 1 - > arch/arm64/include/asm/kvm_host.h | 7 - > arch/arm64/include/asm/kvm_mmu.h | 1 - > arch/arm64/include/asm/virt.h | 17 +++ > arch/arm64/kernel/hyp-stub.S | 26 > arch/arm64/kvm/hyp-init.S | 45 +--- > arch/arm64/kvm/hyp.S | 2 +- > arch/arm64/kvm/hyp/hyp-entry.S| 39 > 24 files changed, 265 insertions(+), 126 deletions(-) > create mode 100644 Documentation/virtual/kvm/arm/hyp-abi.txt > _
Re: kvm/arm64: use-after-free in kvm_vm_ioctl/vmacache_update
On 14/03/17 11:03, Suzuki K Poulose wrote: > On 13/03/17 09:58, Marc Zyngier wrote: >> On 10/03/17 18:37, Suzuki K Poulose wrote: >>> On 10/03/17 15:50, Andrey Konovalov wrote: On Fri, Mar 10, 2017 at 2:38 PM, Andrey Konovalov wrote: > Hi, > > I've got the following error report while fuzzing the kernel with > syzkaller. > > On linux-next commit 56b8bad5e066c23e8fa273ef5fba50bd3da2ace8 (Mar 8). > > Unfortunately I can't reproduce it. > > == > BUG: KASAN: use-after-free in vmacache_update+0x114/0x118 mm/vmacache.c:63 > Read of size 8 at addr 80003b9a2040 by task syz-executor/26615 > > CPU: 1 PID: 26615 Comm: syz-executor Not tainted > 4.11.0-rc1-next-20170308-xc2-dirty #3 > Hardware name: Hardkernel ODROID-C2 (DT) > Call trace: > [] dump_backtrace+0x0/0x440 > arch/arm64/kernel/traps.c:505 > [] show_stack+0x20/0x30 arch/arm64/kernel/traps.c:228 > [] __dump_stack lib/dump_stack.c:16 [inline] > [] dump_stack+0x110/0x168 lib/dump_stack.c:52 > [] print_address_description+0x60/0x248 > mm/kasan/report.c:250 > [] kasan_report_error+0xe8/0x250 mm/kasan/report.c:349 > [] kasan_report mm/kasan/report.c:372 [inline] > [] __asan_report_load8_noabort+0x3c/0x48 > mm/kasan/report.c:393 > [] vmacache_update+0x114/0x118 mm/vmacache.c:63 > [] find_vma+0xf8/0x150 mm/mmap.c:2124 > [] kvm_arch_prepare_memory_region+0x2ac/0x488 > arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:1817 > [] __kvm_set_memory_region+0x3d8/0x12b8 > arch/arm64/kvm/../../../virt/kvm/kvm_main.c:1026 > [] kvm_set_memory_region+0x38/0x58 > arch/arm64/kvm/../../../virt/kvm/kvm_main.c:1075 > [] kvm_vm_ioctl_set_memory_region > arch/arm64/kvm/../../../virt/kvm/kvm_main.c:1087 [inline] > [] kvm_vm_ioctl+0xb94/0x1308 > arch/arm64/kvm/../../../virt/kvm/kvm_main.c:2960 > [] vfs_ioctl fs/ioctl.c:45 [inline] > [] do_vfs_ioctl+0x128/0xfc0 fs/ioctl.c:685 > [] SYSC_ioctl fs/ioctl.c:700 [inline] > [] SyS_ioctl+0xa8/0xb8 fs/ioctl.c:691 > [] el0_svc_naked+0x24/0x28 > > Allocated by task 26657: > save_stack_trace_tsk+0x0/0x330 arch/arm64/kernel/stacktrace.c:133 > save_stack_trace+0x20/0x30 arch/arm64/kernel/stacktrace.c:216 > save_stack mm/kasan/kasan.c:515 [inline] > set_track mm/kasan/kasan.c:527 [inline] > kasan_kmalloc+0xd4/0x180 mm/kasan/kasan.c:619 > kasan_slab_alloc+0x14/0x20 mm/kasan/kasan.c:557 > slab_post_alloc_hook mm/slab.h:456 [inline] > slab_alloc_node mm/slub.c:2718 [inline] > slab_alloc mm/slub.c:2726 [inline] > kmem_cache_alloc+0x144/0x230 mm/slub.c:2731 > __split_vma+0x118/0x608 mm/mmap.c:2515 > do_munmap+0x194/0x9b0 mm/mmap.c:2636 > Freed by task 26657: > save_stack_trace_tsk+0x0/0x330 arch/arm64/kernel/stacktrace.c:133 > save_stack_trace+0x20/0x30 arch/arm64/kernel/stacktrace.c:216 > save_stack mm/kasan/kasan.c:515 [inline] > set_track mm/kasan/kasan.c:527 [inline] > kasan_slab_free+0x84/0x198 mm/kasan/kasan.c:592 > slab_free_hook mm/slub.c:1357 [inline] > slab_free_freelist_hook mm/slub.c:1379 [inline] > slab_free mm/slub.c:2961 [inline] > kmem_cache_free+0x80/0x258 mm/slub.c:2983 > __vma_adjust+0x6b0/0xf mm/mmap.c:890] el0_svc_naked+0x24/0x28 > > The buggy address belongs to the object at 80003b9a2000 > which belongs to the cache vm_area_struct(647:session-6.scope) of size > 184 > The buggy address is located 64 bytes inside of > 184-byte region [80003b9a2000, 80003b9a20b8) > The buggy address belongs to the page: > page:7eee6880 count:1 mapcount:0 mapping: (null) > index:0x0 > flags: 0xfffc100(slab) > raw: 0fffc100 000180100010 > raw: 000c0001 80005a5cc600 80005ac99980 > page dumped because: kasan: bad access detected > page->mem_cgroup:80005ac99980 > > Memory state around the buggy address: > 80003b9a1f00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 80003b9a1f80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >> 80003b9a2000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >^ > 80003b9a2080: fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc fb > 80003b9a2100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > == Another one that looks related and doesn't have parts of stack traces missing: == BUG: KASAN: use-after-free in find_vma+0x140/0x150 mm/mmap.c:2114 Read of size 8 at addr 800031a03e90 by task syz-executor/4360 CP
Re: kvm/arm64: use-after-free in kvm_unmap_hva_handler/unmap_stage2_pmds
On 10/03/17 13:34, Andrey Konovalov wrote: Hi, I've got the following error report while fuzzing the kernel with syzkaller. On linux-next commit 56b8bad5e066c23e8fa273ef5fba50bd3da2ace8 (Mar 8). Unfortunately I can't reproduce it. == BUG: KASAN: use-after-free in put_page include/linux/compiler.h:243 [inline] BUG: KASAN: use-after-free in unmap_stage2_pmds arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:240 [inline] BUG: KASAN: use-after-free in unmap_stage2_puds arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:269 [inline] BUG: KASAN: use-after-free in unmap_stage2_range+0x884/0x938 arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:299 Read of size 8 at addr 80004585c000 by task syz-executor/5176 [] put_page include/linux/compiler.h:243 [inline] [] unmap_stage2_pmds arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:240 [inline] [] unmap_stage2_puds arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:269 [inline] [] unmap_stage2_range+0x884/0x938 arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:299 [] kvm_unmap_hva_handler+0x28/0x38 arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:1556 [] handle_hva_to_gpa+0x140/0x250 arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:1547 [] kvm_unmap_hva_range+0x60/0x80 arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:1579 [] kvm_mmu_notifier_invalidate_range_start+0x194/0x278 arch/arm64/kvm/../../../virt/kvm/kvm_main.c:357 [] __mmu_notifier_invalidate_range_start+0x1d0/0x2a0 mm/mmu_notifier.c:199 [] mmu_notifier_invalidate_range_start include/linux/mmu_notifier.h:282 [inline] [] unmap_vmas+0x12c/0x198 mm/memory.c:1372 [] unmap_region+0x128/0x230 mm/mmap.c:2460 [] update_hiwater_vm include/linux/mm.h:1483 [inline] [] remove_vma_list mm/mmap.c:2432 [inline] [] do_munmap+0x598/0x9b0 mm/mmap.c:2662 [] find_vma_links mm/mmap.c:495 [inline] [] mmap_region+0x138/0xc78 mm/mmap.c:1610 [] is_file_hugepages include/linux/hugetlb.h:269 [inline] [] do_mmap+0x3cc/0x848 mm/mmap.c:1446 [] do_mmap_pgoff include/linux/mm.h:2039 [inline] [] vm_mmap_pgoff+0xec/0x120 mm/util.c:305 [] SYSC_mmap_pgoff mm/mmap.c:1475 [inline] [] SyS_mmap_pgoff+0x220/0x420 mm/mmap.c:1458 [] sys_mmap+0x58/0x80 arch/arm64/kernel/sys.c:37 [] el0_svc_naked+0x24/0x28 We hold kvm->mmu_lock, while manipulating the stage2 ranges. However, I find that we don't take the lock, when we do it f rom kvm_free_stage2_pgd(), which could potentially have caused a problem with an munmap of a memslot ? Lightly tested... commit fa75684dbf0fe845cf8403517d6e0c2c3344a544 Author: Suzuki K Poulose Date: Tue Mar 14 10:26:54 2017 + kvm: arm: Fix locking for kvm_free_stage2_pgd In kvm_free_stage2_pgd() we don't hold the kvm->mmu_lock while calling unmap_stage2_range() on the entire memory range for the guest. This could cause problems with other callers (e.g, munmap on a memslot) trying to unmap a range. Cc: Marc Zyngier Cc: Christoffer Dall Signed-off-by: Suzuki K Poulose diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c index a07ce3e..7f97063 100644 --- a/arch/arm/kvm/mmu.c +++ b/arch/arm/kvm/mmu.c @@ -831,7 +831,10 @@ void kvm_free_stage2_pgd(struct kvm *kvm) if (kvm->arch.pgd == NULL) return; + spin_lock(&kvm->mmu_lock); unmap_stage2_range(kvm, 0, KVM_PHYS_SIZE); + spin_unlock(&kvm->mmu_lock); + /* Free the HW pgd, one page at a time */ free_pages_exact(kvm->arch.pgd, S2_PGD_SIZE); kvm->arch.pgd = NULL; The buggy address belongs to the page: page:7e0001161700 count:0 mapcount:0 mapping: (null) index:0x0 flags: 0xfffc000() raw: 0fffc000 raw: 7e00018c9120 7eea8b60 page dumped because: kasan: bad access detected Memory state around the buggy address: 80004585bf00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 80004585bf80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 80004585c000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ 80004585c080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 80004585c100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff == ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: kvm/arm64: use-after-free in kvm_vm_ioctl/vmacache_update
On 13/03/17 09:58, Marc Zyngier wrote: On 10/03/17 18:37, Suzuki K Poulose wrote: On 10/03/17 15:50, Andrey Konovalov wrote: On Fri, Mar 10, 2017 at 2:38 PM, Andrey Konovalov wrote: Hi, I've got the following error report while fuzzing the kernel with syzkaller. On linux-next commit 56b8bad5e066c23e8fa273ef5fba50bd3da2ace8 (Mar 8). Unfortunately I can't reproduce it. == BUG: KASAN: use-after-free in vmacache_update+0x114/0x118 mm/vmacache.c:63 Read of size 8 at addr 80003b9a2040 by task syz-executor/26615 CPU: 1 PID: 26615 Comm: syz-executor Not tainted 4.11.0-rc1-next-20170308-xc2-dirty #3 Hardware name: Hardkernel ODROID-C2 (DT) Call trace: [] dump_backtrace+0x0/0x440 arch/arm64/kernel/traps.c:505 [] show_stack+0x20/0x30 arch/arm64/kernel/traps.c:228 [] __dump_stack lib/dump_stack.c:16 [inline] [] dump_stack+0x110/0x168 lib/dump_stack.c:52 [] print_address_description+0x60/0x248 mm/kasan/report.c:250 [] kasan_report_error+0xe8/0x250 mm/kasan/report.c:349 [] kasan_report mm/kasan/report.c:372 [inline] [] __asan_report_load8_noabort+0x3c/0x48 mm/kasan/report.c:393 [] vmacache_update+0x114/0x118 mm/vmacache.c:63 [] find_vma+0xf8/0x150 mm/mmap.c:2124 [] kvm_arch_prepare_memory_region+0x2ac/0x488 arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:1817 [] __kvm_set_memory_region+0x3d8/0x12b8 arch/arm64/kvm/../../../virt/kvm/kvm_main.c:1026 [] kvm_set_memory_region+0x38/0x58 arch/arm64/kvm/../../../virt/kvm/kvm_main.c:1075 [] kvm_vm_ioctl_set_memory_region arch/arm64/kvm/../../../virt/kvm/kvm_main.c:1087 [inline] [] kvm_vm_ioctl+0xb94/0x1308 arch/arm64/kvm/../../../virt/kvm/kvm_main.c:2960 [] vfs_ioctl fs/ioctl.c:45 [inline] [] do_vfs_ioctl+0x128/0xfc0 fs/ioctl.c:685 [] SYSC_ioctl fs/ioctl.c:700 [inline] [] SyS_ioctl+0xa8/0xb8 fs/ioctl.c:691 [] el0_svc_naked+0x24/0x28 Allocated by task 26657: save_stack_trace_tsk+0x0/0x330 arch/arm64/kernel/stacktrace.c:133 save_stack_trace+0x20/0x30 arch/arm64/kernel/stacktrace.c:216 save_stack mm/kasan/kasan.c:515 [inline] set_track mm/kasan/kasan.c:527 [inline] kasan_kmalloc+0xd4/0x180 mm/kasan/kasan.c:619 kasan_slab_alloc+0x14/0x20 mm/kasan/kasan.c:557 slab_post_alloc_hook mm/slab.h:456 [inline] slab_alloc_node mm/slub.c:2718 [inline] slab_alloc mm/slub.c:2726 [inline] kmem_cache_alloc+0x144/0x230 mm/slub.c:2731 __split_vma+0x118/0x608 mm/mmap.c:2515 do_munmap+0x194/0x9b0 mm/mmap.c:2636 Freed by task 26657: save_stack_trace_tsk+0x0/0x330 arch/arm64/kernel/stacktrace.c:133 save_stack_trace+0x20/0x30 arch/arm64/kernel/stacktrace.c:216 save_stack mm/kasan/kasan.c:515 [inline] set_track mm/kasan/kasan.c:527 [inline] kasan_slab_free+0x84/0x198 mm/kasan/kasan.c:592 slab_free_hook mm/slub.c:1357 [inline] slab_free_freelist_hook mm/slub.c:1379 [inline] slab_free mm/slub.c:2961 [inline] kmem_cache_free+0x80/0x258 mm/slub.c:2983 __vma_adjust+0x6b0/0xf mm/mmap.c:890] el0_svc_naked+0x24/0x28 The buggy address belongs to the object at 80003b9a2000 which belongs to the cache vm_area_struct(647:session-6.scope) of size 184 The buggy address is located 64 bytes inside of 184-byte region [80003b9a2000, 80003b9a20b8) The buggy address belongs to the page: page:7eee6880 count:1 mapcount:0 mapping: (null) index:0x0 flags: 0xfffc100(slab) raw: 0fffc100 000180100010 raw: 000c0001 80005a5cc600 80005ac99980 page dumped because: kasan: bad access detected page->mem_cgroup:80005ac99980 Memory state around the buggy address: 80003b9a1f00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 80003b9a1f80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 80003b9a2000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ 80003b9a2080: fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc fb 80003b9a2100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb == Another one that looks related and doesn't have parts of stack traces missing: == BUG: KASAN: use-after-free in find_vma+0x140/0x150 mm/mmap.c:2114 Read of size 8 at addr 800031a03e90 by task syz-executor/4360 CPU: 2 PID: 4360 Comm: syz-executor Not tainted 4.11.0-rc1-next-20170308-xc2-dirty #3 Hardware name: Hardkernel ODROID-C2 (DT) Call trace: [] dump_backtrace+0x0/0x440 arch/arm64/kernel/traps.c:505 [] show_stack+0x20/0x30 arch/arm64/kernel/traps.c:228 [] __dump_stack lib/dump_stack.c:16 [inline] [] dump_stack+0x110/0x168 lib/dump_stack.c:52 [] print_address_description+0x60/0x248 mm/kasan/report.c:250 [] kasan_report_error+0xe8/0x250 mm/kasan/report.c:349 [] kasan_report mm/kasan/report.c:372 [inline] [] __asan_report_load8_noabort+0x3c/0x48 mm/kasan/report.c:393 [] find_vma+0x140/0x150 mm/mmap.c:2114 [] kvm_arch_prepare_memory_region+0x2ac/0x488 arc
Re: [PATCH V12 09/10] trace, ras: add ARM processor error trace event
Hi Steven,
Thanks for you comments. As your suggestion, I've changed it in v2.
>From c29c14c3b960f55beb4c4b22b7aced64fa7daf9a Mon Sep 17 00:00:00 2001
From: Xie XiuQi
Date: Mon, 13 Mar 2017 15:46:06 +0800
Subject: [PATCH v2] 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.
---
v2: add trace enabled condition as Steven's suggestion.
fix a typo.
Signed-off-by: Xie XiuQi
---
drivers/acpi/apei/ghes.c | 10 ++
include/linux/cper.h | 5 +++
include/ras/ras_event.h | 87
3 files changed, 102 insertions(+)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 251d7e0..bcb8160 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -518,9 +518,19 @@ static void ghes_do_proc(struct ghes *ghes,
else if (!uuid_le_cmp(sec_type, CPER_SEC_PROC_ARM) &&
trace_arm_event_enabled()) {
struct cper_sec_proc_arm *arm_err;
+ struct cper_arm_err_info *err_info;
+ int i;
arm_err = acpi_hest_generic_data_payload(gdata);
trace_arm_event(arm_err);
+
+ if (trace_arm_proc_err_enabled()) {
+ err_info = (struct cper_arm_err_info *)(arm_err
+ 1);
+ for (i = 0; i < arm_err->err_info_num; i++) {
+ trace_arm_proc_err(err_info);
+ err_info += 1;
+ }
+ }
} else if (trace_unknown_sec_event_enabled()) {
void *unknown_err =
acpi_hest_generic_data_payload(gdata);
trace_unknown_sec_event(&sec_type,
diff --git a/include/linux/cper.h b/include/linux/cper.h
index 85450f3..0cae900 100644
--- a/include/linux/cper.h
+++ b/include/linux/cper.h
@@ -270,6 +270,11 @@ enum {
#define CPER_ARM_INFO_VALID_VIRT_ADDR 0x0008
#define CPER_ARM_INFO_VALID_PHYSICAL_ADDR 0x0010
+#define CPER_ARM_INFO_TYPE_CACHE 0
+#define CPER_ARM_INFO_TYPE_TLB 1
+#define CPER_ARM_INFO_TYPE_BUS 2
+#define CPER_ARM_INFO_TYPE_UARCH 3
+
#define CPER_ARM_INFO_FLAGS_FIRST 0x0001
#define CPER_ARM_INFO_FLAGS_LAST 0x0002
#define CPER_ARM_INFO_FLAGS_PROPAGATED 0x0004
diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h
index b36db48..0f9f46e 100644
--- a/include/ras/ras_event.h
+++ b/include/ras/ras_event.h
@@ -195,6 +195,93 @@
__entry->running_state, __entry->psci_state)
);
+#define ARM_PROC_ERR_TYPE \
+ EM ( CPER_ARM_INFO_TYPE_CACHE, "cache error" ) \
+ EM ( CPER_ARM_INFO_TYPE_TLB, "TLB error" ) \
+ EM ( CPER_ARM_INFO_TYPE_BUS, "bus error" ) \
+ EMe ( CPER_ARM_INFO_TYPE_UARCH, "micro-architectural error" )
+
+#define ARM_PROC_ERR_FLAGS \
+ EM ( CPER_ARM_INFO_FLAGS_FIRST, "First error captured" )\
+ EM ( CPER_ARM_INFO_FLAGS_LAST, "Last error captured" ) \
+ EM ( CPER_ARM_INFO_FLAGS_PROPAGATED, "Propagated" ) \
+ EMe ( CPER_ARM_INFO_FLAGS_OVERFLOW, "Overflow" )
+
+/*
+ * First define the enums in MM_ACTION_RESULT to be exported to userspace
+ * via TRACE_DEFINE_ENUM().
+ */
+#undef EM
+#undef EMe
+#define EM(a, b) TRACE_DEFINE_ENUM(a);
+#define EMe(a, b) TRACE_DEFINE_ENUM(a);
+
+ARM_PROC_ERR_TYPE
+ARM_PROC_ERR_FLAGS
+
+/*
+ * Now redefine the EM() and EMe() macros to map the enums to the strings
+ * that will be printed in the output.
+ */
+#undef EM
+#undef EMe
+#define EM(a, b) { a, b },
+#define EMe(a, b) { a, b }
+
+TRACE_EVENT(arm_proc_err,
+
+ TP_PROTO(const struct cper_arm_err_info *err),
+
+ TP_ARGS(err),
+
+ TP_STRUCT__entry(
+ __field(u8, type)
+ __field(u16, multiple_error)
+ __field(u8, flags)
+ __field(u64, error_info)
+ __field(u64, virt_fault_addr)
+ __field(u64, physical_fault_addr)
+ ),
+
+ TP_fast_assign(
+ __entry->type = err->type;
+
+ if (err->validation_bits & CPER_ARM_INFO_VALID_MULTI_ERR)
+ __entry->multiple_error = err->multiple_error;
+ else
+ __entry->multiple_error = ~0;
+
+ if (err->validation_bits & CPER_ARM_INFO_VALID_FLAGS)
+ __entry->flags = err->flags;
+ else
+ __entry->flags = ~0;
+
+
