* [PATCH v11 0/4] set VSESR_EL2 by user space and support NOTIFY_SEI notification
@ 2018-04-09 21:36 ` Dongjiu Geng
0 siblings, 0 replies; 58+ messages in thread
From: Dongjiu Geng @ 2018-04-09 21:36 UTC (permalink / raw)
To: rkrcmar, corbet, christoffer.dall, marc.zyngier, james.morse,
linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc,
linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel
Cc: gengdongjiu, huangshaoyu, zhengxiang9
1. Detect whether KVM can set set guest SError syndrome
2. Support to Set VSESR_EL2 and inject SError by user space.
3. Support live migration to keep SError pending state and VSESR_EL2 value.
4. ACPI 6.1 adds support for NOTIFY_SEI as a GHES notification mechanism, so support this
notification in software, KVM or kernel ARCH code call handle_guest_sei() to let ACP driver
to handle this notification.
Change since V10:
Address James's comments, thanks James
1. Merge the helper function with the user.
2. Move the ISS_MASK into pend_guest_serror() to clear top bits
3. Make kvm_vcpu_events struct align to 4 bytes
4. Add something check in the kvm_arm_vcpu_set_events()
5. Check kvm_arm_vcpu_get/set_events()'s return value.
6. Initialise kvm_vcpu_events to 0 so that padding transferred to user-space doesn't
contain kernel stack.
Dongjiu Geng (4):
arm64: KVM: export the capability to set guest SError syndrome
arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS
ACPI / APEI: Add SEI notification type support for ARMv8
arm64: handle NOTIFY_SEI notification by the APEI driver
Documentation/virtual/kvm/api.txt | 39 ++++++++++++++++++++++++--
arch/arm/include/asm/kvm_host.h | 6 ++++
arch/arm/kvm/guest.c | 12 ++++++++
arch/arm64/include/asm/kvm_emulate.h | 5 ++++
arch/arm64/include/asm/kvm_host.h | 7 +++++
arch/arm64/include/asm/system_misc.h | 1 +
arch/arm64/include/uapi/asm/kvm.h | 12 ++++++++
arch/arm64/kernel/traps.c | 4 +++
arch/arm64/kvm/guest.c | 31 +++++++++++++++++++++
arch/arm64/kvm/inject_fault.c | 7 ++++-
arch/arm64/kvm/reset.c | 4 +++
arch/arm64/mm/fault.c | 10 +++++++
drivers/acpi/apei/Kconfig | 15 ++++++++++
drivers/acpi/apei/ghes.c | 53 ++++++++++++++++++++++++++++++++++++
include/acpi/ghes.h | 1 +
include/uapi/linux/kvm.h | 1 +
virt/kvm/arm/arm.c | 21 ++++++++++++++
17 files changed, 226 insertions(+), 3 deletions(-)
--
1.9.1
^ permalink raw reply [flat|nested] 58+ messages in thread* [Devel] [PATCH v11 0/4] set VSESR_EL2 by user space and support NOTIFY_SEI notification @ 2018-04-09 21:36 ` Dongjiu Geng 0 siblings, 0 replies; 58+ messages in thread From: Dongjiu Geng @ 2018-04-09 21:36 UTC (permalink / raw) To: devel [-- Attachment #1: Type: text/plain, Size: 2112 bytes --] 1. Detect whether KVM can set set guest SError syndrome 2. Support to Set VSESR_EL2 and inject SError by user space. 3. Support live migration to keep SError pending state and VSESR_EL2 value. 4. ACPI 6.1 adds support for NOTIFY_SEI as a GHES notification mechanism, so support this notification in software, KVM or kernel ARCH code call handle_guest_sei() to let ACP driver to handle this notification. Change since V10: Address James's comments, thanks James 1. Merge the helper function with the user. 2. Move the ISS_MASK into pend_guest_serror() to clear top bits 3. Make kvm_vcpu_events struct align to 4 bytes 4. Add something check in the kvm_arm_vcpu_set_events() 5. Check kvm_arm_vcpu_get/set_events()'s return value. 6. Initialise kvm_vcpu_events to 0 so that padding transferred to user-space doesn't contain kernel stack. Dongjiu Geng (4): arm64: KVM: export the capability to set guest SError syndrome arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS ACPI / APEI: Add SEI notification type support for ARMv8 arm64: handle NOTIFY_SEI notification by the APEI driver Documentation/virtual/kvm/api.txt | 39 ++++++++++++++++++++++++-- arch/arm/include/asm/kvm_host.h | 6 ++++ arch/arm/kvm/guest.c | 12 ++++++++ arch/arm64/include/asm/kvm_emulate.h | 5 ++++ arch/arm64/include/asm/kvm_host.h | 7 +++++ arch/arm64/include/asm/system_misc.h | 1 + arch/arm64/include/uapi/asm/kvm.h | 12 ++++++++ arch/arm64/kernel/traps.c | 4 +++ arch/arm64/kvm/guest.c | 31 +++++++++++++++++++++ arch/arm64/kvm/inject_fault.c | 7 ++++- arch/arm64/kvm/reset.c | 4 +++ arch/arm64/mm/fault.c | 10 +++++++ drivers/acpi/apei/Kconfig | 15 ++++++++++ drivers/acpi/apei/ghes.c | 53 ++++++++++++++++++++++++++++++++++++ include/acpi/ghes.h | 1 + include/uapi/linux/kvm.h | 1 + virt/kvm/arm/arm.c | 21 ++++++++++++++ 17 files changed, 226 insertions(+), 3 deletions(-) -- 1.9.1 ^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v11 0/4] set VSESR_EL2 by user space and support NOTIFY_SEI notification @ 2018-04-09 21:36 ` Dongjiu Geng 0 siblings, 0 replies; 58+ messages in thread From: Dongjiu Geng @ 2018-04-09 21:36 UTC (permalink / raw) To: linux-arm-kernel 1. Detect whether KVM can set set guest SError syndrome 2. Support to Set VSESR_EL2 and inject SError by user space. 3. Support live migration to keep SError pending state and VSESR_EL2 value. 4. ACPI 6.1 adds support for NOTIFY_SEI as a GHES notification mechanism, so support this notification in software, KVM or kernel ARCH code call handle_guest_sei() to let ACP driver to handle this notification. Change since V10: Address James's comments, thanks James 1. Merge the helper function with the user. 2. Move the ISS_MASK into pend_guest_serror() to clear top bits 3. Make kvm_vcpu_events struct align to 4 bytes 4. Add something check in the kvm_arm_vcpu_set_events() 5. Check kvm_arm_vcpu_get/set_events()'s return value. 6. Initialise kvm_vcpu_events to 0 so that padding transferred to user-space doesn't contain kernel stack. Dongjiu Geng (4): arm64: KVM: export the capability to set guest SError syndrome arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS ACPI / APEI: Add SEI notification type support for ARMv8 arm64: handle NOTIFY_SEI notification by the APEI driver Documentation/virtual/kvm/api.txt | 39 ++++++++++++++++++++++++-- arch/arm/include/asm/kvm_host.h | 6 ++++ arch/arm/kvm/guest.c | 12 ++++++++ arch/arm64/include/asm/kvm_emulate.h | 5 ++++ arch/arm64/include/asm/kvm_host.h | 7 +++++ arch/arm64/include/asm/system_misc.h | 1 + arch/arm64/include/uapi/asm/kvm.h | 12 ++++++++ arch/arm64/kernel/traps.c | 4 +++ arch/arm64/kvm/guest.c | 31 +++++++++++++++++++++ arch/arm64/kvm/inject_fault.c | 7 ++++- arch/arm64/kvm/reset.c | 4 +++ arch/arm64/mm/fault.c | 10 +++++++ drivers/acpi/apei/Kconfig | 15 ++++++++++ drivers/acpi/apei/ghes.c | 53 ++++++++++++++++++++++++++++++++++++ include/acpi/ghes.h | 1 + include/uapi/linux/kvm.h | 1 + virt/kvm/arm/arm.c | 21 ++++++++++++++ 17 files changed, 226 insertions(+), 3 deletions(-) -- 1.9.1 ^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v11 0/4] set VSESR_EL2 by user space and support NOTIFY_SEI notification @ 2018-04-09 21:36 ` Dongjiu Geng 0 siblings, 0 replies; 58+ messages in thread From: Dongjiu Geng @ 2018-04-09 21:36 UTC (permalink / raw) To: rkrcmar, corbet, christoffer.dall, marc.zyngier, james.morse, linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel Cc: gengdongjiu, huangshaoyu, zhengxiang9 1. Detect whether KVM can set set guest SError syndrome 2. Support to Set VSESR_EL2 and inject SError by user space. 3. Support live migration to keep SError pending state and VSESR_EL2 value. 4. ACPI 6.1 adds support for NOTIFY_SEI as a GHES notification mechanism, so support this notification in software, KVM or kernel ARCH code call handle_guest_sei() to let ACP driver to handle this notification. Change since V10: Address James's comments, thanks James 1. Merge the helper function with the user. 2. Move the ISS_MASK into pend_guest_serror() to clear top bits 3. Make kvm_vcpu_events struct align to 4 bytes 4. Add something check in the kvm_arm_vcpu_set_events() 5. Check kvm_arm_vcpu_get/set_events()'s return value. 6. Initialise kvm_vcpu_events to 0 so that padding transferred to user-space doesn't contain kernel stack. Dongjiu Geng (4): arm64: KVM: export the capability to set guest SError syndrome arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS ACPI / APEI: Add SEI notification type support for ARMv8 arm64: handle NOTIFY_SEI notification by the APEI driver Documentation/virtual/kvm/api.txt | 39 ++++++++++++++++++++++++-- arch/arm/include/asm/kvm_host.h | 6 ++++ arch/arm/kvm/guest.c | 12 ++++++++ arch/arm64/include/asm/kvm_emulate.h | 5 ++++ arch/arm64/include/asm/kvm_host.h | 7 +++++ arch/arm64/include/asm/system_misc.h | 1 + arch/arm64/include/uapi/asm/kvm.h | 12 ++++++++ arch/arm64/kernel/traps.c | 4 +++ arch/arm64/kvm/guest.c | 31 +++++++++++++++++++++ arch/arm64/kvm/inject_fault.c | 7 ++++- arch/arm64/kvm/reset.c | 4 +++ arch/arm64/mm/fault.c | 10 +++++++ drivers/acpi/apei/Kconfig | 15 ++++++++++ drivers/acpi/apei/ghes.c | 53 ++++++++++++++++++++++++++++++++++++ include/acpi/ghes.h | 1 + include/uapi/linux/kvm.h | 1 + virt/kvm/arm/arm.c | 21 ++++++++++++++ 17 files changed, 226 insertions(+), 3 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v11 0/4] set VSESR_EL2 by user space and support NOTIFY_SEI notification @ 2018-04-09 21:36 ` Dongjiu Geng 0 siblings, 0 replies; 58+ messages in thread From: Dongjiu Geng @ 2018-04-09 21:36 UTC (permalink / raw) To: rkrcmar, corbet, christoffer.dall, marc.zyngier, james.morse, linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel Cc: gengdongjiu, huangshaoyu, zhengxiang9 1. Detect whether KVM can set set guest SError syndrome 2. Support to Set VSESR_EL2 and inject SError by user space. 3. Support live migration to keep SError pending state and VSESR_EL2 value. 4. ACPI 6.1 adds support for NOTIFY_SEI as a GHES notification mechanism, so support this notification in software, KVM or kernel ARCH code call handle_guest_sei() to let ACP driver to handle this notification. Change since V10: Address James's comments, thanks James 1. Merge the helper function with the user. 2. Move the ISS_MASK into pend_guest_serror() to clear top bits 3. Make kvm_vcpu_events struct align to 4 bytes 4. Add something check in the kvm_arm_vcpu_set_events() 5. Check kvm_arm_vcpu_get/set_events()'s return value. 6. Initialise kvm_vcpu_events to 0 so that padding transferred to user-space doesn't contain kernel stack. Dongjiu Geng (4): arm64: KVM: export the capability to set guest SError syndrome arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS ACPI / APEI: Add SEI notification type support for ARMv8 arm64: handle NOTIFY_SEI notification by the APEI driver Documentation/virtual/kvm/api.txt | 39 ++++++++++++++++++++++++-- arch/arm/include/asm/kvm_host.h | 6 ++++ arch/arm/kvm/guest.c | 12 ++++++++ arch/arm64/include/asm/kvm_emulate.h | 5 ++++ arch/arm64/include/asm/kvm_host.h | 7 +++++ arch/arm64/include/asm/system_misc.h | 1 + arch/arm64/include/uapi/asm/kvm.h | 12 ++++++++ arch/arm64/kernel/traps.c | 4 +++ arch/arm64/kvm/guest.c | 31 +++++++++++++++++++++ arch/arm64/kvm/inject_fault.c | 7 ++++- arch/arm64/kvm/reset.c | 4 +++ arch/arm64/mm/fault.c | 10 +++++++ drivers/acpi/apei/Kconfig | 15 ++++++++++ drivers/acpi/apei/ghes.c | 53 ++++++++++++++++++++++++++++++++++++ include/acpi/ghes.h | 1 + include/uapi/linux/kvm.h | 1 + virt/kvm/arm/arm.c | 21 ++++++++++++++ 17 files changed, 226 insertions(+), 3 deletions(-) -- 1.9.1 ^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v11 1/4] arm64: KVM: export the capability to set guest SError syndrome 2018-04-09 21:36 ` Dongjiu Geng ` (2 preceding siblings ...) (?) @ 2018-04-09 21:36 ` Dongjiu Geng -1 siblings, 0 replies; 58+ messages in thread From: Dongjiu Geng @ 2018-04-09 21:36 UTC (permalink / raw) To: rkrcmar, corbet, christoffer.dall, marc.zyngier, james.morse, linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel Cc: gengdongjiu, huangshaoyu, zhengxiang9 Before user space injects a SError, it needs to know whether it can specify the guest Exception Syndrome, so KVM should tell user space whether it has such capability. Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com> --- Documentation/virtual/kvm/api.txt | 11 +++++++++++ arch/arm64/kvm/reset.c | 3 +++ include/uapi/linux/kvm.h | 1 + 3 files changed, 15 insertions(+) diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index fc3ae95..8a3d708 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -4415,3 +4415,14 @@ Parameters: none This capability indicates if the flic device will be able to get/set the AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and allows to discover this without having to create a flic device. + +8.14 KVM_CAP_ARM_SET_SERROR_ESR + +Architectures: arm, arm64 + +This capability indicates that userspace can specify syndrome value reported to +guest OS when guest takes a virtual SError interrupt exception. +If KVM has this capability, userspace can only specify the ISS field for the ESR +syndrome, can not specify the EC field which is not under control by KVM. +If this virtual SError is taken to EL1 using AArch64, this value will be reported +into ISS filed of ESR_EL1. diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c index 3256b92..38c8a64 100644 --- a/arch/arm64/kvm/reset.c +++ b/arch/arm64/kvm/reset.c @@ -77,6 +77,9 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext) case KVM_CAP_ARM_PMU_V3: r = kvm_arm_support_pmu_v3(); break; + case KVM_CAP_ARM_INJECT_SERROR_ESR: + r = cpus_have_const_cap(ARM64_HAS_RAS_EXTN); + break; case KVM_CAP_SET_GUEST_DEBUG: case KVM_CAP_VCPU_ATTRIBUTES: r = 1; diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index 8fb90a0..3587b33 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -934,6 +934,7 @@ struct kvm_ppc_resize_hpt { #define KVM_CAP_S390_AIS_MIGRATION 150 #define KVM_CAP_PPC_GET_CPU_CHAR 151 #define KVM_CAP_S390_BPB 152 +#define KVM_CAP_ARM_INJECT_SERROR_ESR 153 #ifdef KVM_CAP_IRQ_ROUTING -- 1.9.1 ^ permalink raw reply related [flat|nested] 58+ messages in thread
* [Devel] [PATCH v11 1/4] arm64: KVM: export the capability to set guest SError syndrome @ 2018-04-09 21:36 ` Dongjiu Geng 0 siblings, 0 replies; 58+ messages in thread From: Dongjiu Geng @ 2018-04-09 21:36 UTC (permalink / raw) To: devel [-- Attachment #1: Type: text/plain, Size: 2255 bytes --] Before user space injects a SError, it needs to know whether it can specify the guest Exception Syndrome, so KVM should tell user space whether it has such capability. Signed-off-by: Dongjiu Geng <gengdongjiu(a)huawei.com> --- Documentation/virtual/kvm/api.txt | 11 +++++++++++ arch/arm64/kvm/reset.c | 3 +++ include/uapi/linux/kvm.h | 1 + 3 files changed, 15 insertions(+) diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index fc3ae95..8a3d708 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -4415,3 +4415,14 @@ Parameters: none This capability indicates if the flic device will be able to get/set the AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and allows to discover this without having to create a flic device. + +8.14 KVM_CAP_ARM_SET_SERROR_ESR + +Architectures: arm, arm64 + +This capability indicates that userspace can specify syndrome value reported to +guest OS when guest takes a virtual SError interrupt exception. +If KVM has this capability, userspace can only specify the ISS field for the ESR +syndrome, can not specify the EC field which is not under control by KVM. +If this virtual SError is taken to EL1 using AArch64, this value will be reported +into ISS filed of ESR_EL1. diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c index 3256b92..38c8a64 100644 --- a/arch/arm64/kvm/reset.c +++ b/arch/arm64/kvm/reset.c @@ -77,6 +77,9 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext) case KVM_CAP_ARM_PMU_V3: r = kvm_arm_support_pmu_v3(); break; + case KVM_CAP_ARM_INJECT_SERROR_ESR: + r = cpus_have_const_cap(ARM64_HAS_RAS_EXTN); + break; case KVM_CAP_SET_GUEST_DEBUG: case KVM_CAP_VCPU_ATTRIBUTES: r = 1; diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index 8fb90a0..3587b33 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -934,6 +934,7 @@ struct kvm_ppc_resize_hpt { #define KVM_CAP_S390_AIS_MIGRATION 150 #define KVM_CAP_PPC_GET_CPU_CHAR 151 #define KVM_CAP_S390_BPB 152 +#define KVM_CAP_ARM_INJECT_SERROR_ESR 153 #ifdef KVM_CAP_IRQ_ROUTING -- 1.9.1 ^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v11 1/4] arm64: KVM: export the capability to set guest SError syndrome @ 2018-04-09 21:36 ` Dongjiu Geng 0 siblings, 0 replies; 58+ messages in thread From: Dongjiu Geng @ 2018-04-09 21:36 UTC (permalink / raw) To: linux-arm-kernel Before user space injects a SError, it needs to know whether it can specify the guest Exception Syndrome, so KVM should tell user space whether it has such capability. Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com> --- Documentation/virtual/kvm/api.txt | 11 +++++++++++ arch/arm64/kvm/reset.c | 3 +++ include/uapi/linux/kvm.h | 1 + 3 files changed, 15 insertions(+) diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index fc3ae95..8a3d708 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -4415,3 +4415,14 @@ Parameters: none This capability indicates if the flic device will be able to get/set the AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and allows to discover this without having to create a flic device. + +8.14 KVM_CAP_ARM_SET_SERROR_ESR + +Architectures: arm, arm64 + +This capability indicates that userspace can specify syndrome value reported to +guest OS when guest takes a virtual SError interrupt exception. +If KVM has this capability, userspace can only specify the ISS field for the ESR +syndrome, can not specify the EC field which is not under control by KVM. +If this virtual SError is taken to EL1 using AArch64, this value will be reported +into ISS filed of ESR_EL1. diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c index 3256b92..38c8a64 100644 --- a/arch/arm64/kvm/reset.c +++ b/arch/arm64/kvm/reset.c @@ -77,6 +77,9 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext) case KVM_CAP_ARM_PMU_V3: r = kvm_arm_support_pmu_v3(); break; + case KVM_CAP_ARM_INJECT_SERROR_ESR: + r = cpus_have_const_cap(ARM64_HAS_RAS_EXTN); + break; case KVM_CAP_SET_GUEST_DEBUG: case KVM_CAP_VCPU_ATTRIBUTES: r = 1; diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index 8fb90a0..3587b33 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -934,6 +934,7 @@ struct kvm_ppc_resize_hpt { #define KVM_CAP_S390_AIS_MIGRATION 150 #define KVM_CAP_PPC_GET_CPU_CHAR 151 #define KVM_CAP_S390_BPB 152 +#define KVM_CAP_ARM_INJECT_SERROR_ESR 153 #ifdef KVM_CAP_IRQ_ROUTING -- 1.9.1 ^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v11 1/4] arm64: KVM: export the capability to set guest SError syndrome @ 2018-04-09 21:36 ` Dongjiu Geng 0 siblings, 0 replies; 58+ messages in thread From: Dongjiu Geng @ 2018-04-09 21:36 UTC (permalink / raw) To: rkrcmar, corbet, christoffer.dall, marc.zyngier, james.morse, linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel Cc: gengdongjiu, huangshaoyu, zhengxiang9 Before user space injects a SError, it needs to know whether it can specify the guest Exception Syndrome, so KVM should tell user space whether it has such capability. Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com> --- Documentation/virtual/kvm/api.txt | 11 +++++++++++ arch/arm64/kvm/reset.c | 3 +++ include/uapi/linux/kvm.h | 1 + 3 files changed, 15 insertions(+) diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index fc3ae95..8a3d708 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -4415,3 +4415,14 @@ Parameters: none This capability indicates if the flic device will be able to get/set the AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and allows to discover this without having to create a flic device. + +8.14 KVM_CAP_ARM_SET_SERROR_ESR + +Architectures: arm, arm64 + +This capability indicates that userspace can specify syndrome value reported to +guest OS when guest takes a virtual SError interrupt exception. +If KVM has this capability, userspace can only specify the ISS field for the ESR +syndrome, can not specify the EC field which is not under control by KVM. +If this virtual SError is taken to EL1 using AArch64, this value will be reported +into ISS filed of ESR_EL1. diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c index 3256b92..38c8a64 100644 --- a/arch/arm64/kvm/reset.c +++ b/arch/arm64/kvm/reset.c @@ -77,6 +77,9 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext) case KVM_CAP_ARM_PMU_V3: r = kvm_arm_support_pmu_v3(); break; + case KVM_CAP_ARM_INJECT_SERROR_ESR: + r = cpus_have_const_cap(ARM64_HAS_RAS_EXTN); + break; case KVM_CAP_SET_GUEST_DEBUG: case KVM_CAP_VCPU_ATTRIBUTES: r = 1; diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index 8fb90a0..3587b33 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -934,6 +934,7 @@ struct kvm_ppc_resize_hpt { #define KVM_CAP_S390_AIS_MIGRATION 150 #define KVM_CAP_PPC_GET_CPU_CHAR 151 #define KVM_CAP_S390_BPB 152 +#define KVM_CAP_ARM_INJECT_SERROR_ESR 153 #ifdef KVM_CAP_IRQ_ROUTING -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v11 1/4] arm64: KVM: export the capability to set guest SError syndrome @ 2018-04-09 21:36 ` Dongjiu Geng 0 siblings, 0 replies; 58+ messages in thread From: Dongjiu Geng @ 2018-04-09 21:36 UTC (permalink / raw) To: rkrcmar, corbet, christoffer.dall, marc.zyngier, james.morse, linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel Cc: gengdongjiu, huangshaoyu, zhengxiang9 Before user space injects a SError, it needs to know whether it can specify the guest Exception Syndrome, so KVM should tell user space whether it has such capability. Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com> --- Documentation/virtual/kvm/api.txt | 11 +++++++++++ arch/arm64/kvm/reset.c | 3 +++ include/uapi/linux/kvm.h | 1 + 3 files changed, 15 insertions(+) diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index fc3ae95..8a3d708 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -4415,3 +4415,14 @@ Parameters: none This capability indicates if the flic device will be able to get/set the AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and allows to discover this without having to create a flic device. + +8.14 KVM_CAP_ARM_SET_SERROR_ESR + +Architectures: arm, arm64 + +This capability indicates that userspace can specify syndrome value reported to +guest OS when guest takes a virtual SError interrupt exception. +If KVM has this capability, userspace can only specify the ISS field for the ESR +syndrome, can not specify the EC field which is not under control by KVM. +If this virtual SError is taken to EL1 using AArch64, this value will be reported +into ISS filed of ESR_EL1. diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c index 3256b92..38c8a64 100644 --- a/arch/arm64/kvm/reset.c +++ b/arch/arm64/kvm/reset.c @@ -77,6 +77,9 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext) case KVM_CAP_ARM_PMU_V3: r = kvm_arm_support_pmu_v3(); break; + case KVM_CAP_ARM_INJECT_SERROR_ESR: + r = cpus_have_const_cap(ARM64_HAS_RAS_EXTN); + break; case KVM_CAP_SET_GUEST_DEBUG: case KVM_CAP_VCPU_ATTRIBUTES: r = 1; diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index 8fb90a0..3587b33 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -934,6 +934,7 @@ struct kvm_ppc_resize_hpt { #define KVM_CAP_S390_AIS_MIGRATION 150 #define KVM_CAP_PPC_GET_CPU_CHAR 151 #define KVM_CAP_S390_BPB 152 +#define KVM_CAP_ARM_INJECT_SERROR_ESR 153 #ifdef KVM_CAP_IRQ_ROUTING -- 1.9.1 ^ permalink raw reply related [flat|nested] 58+ messages in thread
* Re: [PATCH v11 1/4] arm64: KVM: export the capability to set guest SError syndrome 2018-04-09 21:36 ` Dongjiu Geng (?) (?) @ 2018-04-10 14:15 ` James Morse -1 siblings, 0 replies; 58+ messages in thread From: James Morse @ 2018-04-10 14:15 UTC (permalink / raw) To: Dongjiu Geng Cc: rkrcmar, corbet, christoffer.dall, marc.zyngier, linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel, huangshaoyu, zhengxiang9 Hi Dongjiu Geng, On 09/04/18 22:36, Dongjiu Geng wrote: > Before user space injects a SError, it needs to know whether it can > specify the guest Exception Syndrome, so KVM should tell user space > whether it has such capability. (you could improve the commit message by briefly explaining how/why user-space would want to do this. As this is patch 1, you don't have the context of the previous patch to say that some systems can provide an ESR with virtual-SError) > diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt > index fc3ae95..8a3d708 100644 > --- a/Documentation/virtual/kvm/api.txt > +++ b/Documentation/virtual/kvm/api.txt > @@ -4415,3 +4415,14 @@ Parameters: none > This capability indicates if the flic device will be able to get/set the > AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and allows > to discover this without having to create a flic device. > + > +8.14 KVM_CAP_ARM_SET_SERROR_ESR > + > +Architectures: arm, arm64 > + > +This capability indicates that userspace can specify syndrome value reported to (Nit: 'the syndrome value') > +guest OS when guest takes a virtual SError interrupt exception. (Nit: 'the guest') > +If KVM has this capability, userspace can only specify the ISS field for the ESR > +syndrome, can not specify the EC field which is not under control by KVM. (Nit: 'it can not specify...') > +If this virtual SError is taken to EL1 using AArch64, this value will be reported > +into ISS filed of ESR_EL1. (Nit: 'in the ISS field') > diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c > index 3256b92..38c8a64 100644 > --- a/arch/arm64/kvm/reset.c > +++ b/arch/arm64/kvm/reset.c > @@ -77,6 +77,9 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext) > case KVM_CAP_ARM_PMU_V3: > r = kvm_arm_support_pmu_v3(); > break; > + case KVM_CAP_ARM_INJECT_SERROR_ESR: > + r = cpus_have_const_cap(ARM64_HAS_RAS_EXTN); > + break; > case KVM_CAP_SET_GUEST_DEBUG: > case KVM_CAP_VCPU_ATTRIBUTES: > r = 1; 'dev_ioctl' feels a bit weird, but we already have cpu_has_32bit_el1() in here. > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > index 8fb90a0..3587b33 100644 > --- a/include/uapi/linux/kvm.h > +++ b/include/uapi/linux/kvm.h > @@ -934,6 +934,7 @@ struct kvm_ppc_resize_hpt { > #define KVM_CAP_S390_AIS_MIGRATION 150 > #define KVM_CAP_PPC_GET_CPU_CHAR 151 > #define KVM_CAP_S390_BPB 152 > +#define KVM_CAP_ARM_INJECT_SERROR_ESR 153 > > #ifdef KVM_CAP_IRQ_ROUTING (patch 1&2 should probably be swapped around, as on its own this does thing). Reviewed-by: James Morse <james.morse@arm.com> Thanks, James ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [Devel] [PATCH v11 1/4] arm64: KVM: export the capability to set guest SError syndrome @ 2018-04-10 14:15 ` James Morse 0 siblings, 0 replies; 58+ messages in thread From: James Morse @ 2018-04-10 14:15 UTC (permalink / raw) To: devel [-- Attachment #1: Type: text/plain, Size: 2763 bytes --] Hi Dongjiu Geng, On 09/04/18 22:36, Dongjiu Geng wrote: > Before user space injects a SError, it needs to know whether it can > specify the guest Exception Syndrome, so KVM should tell user space > whether it has such capability. (you could improve the commit message by briefly explaining how/why user-space would want to do this. As this is patch 1, you don't have the context of the previous patch to say that some systems can provide an ESR with virtual-SError) > diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt > index fc3ae95..8a3d708 100644 > --- a/Documentation/virtual/kvm/api.txt > +++ b/Documentation/virtual/kvm/api.txt > @@ -4415,3 +4415,14 @@ Parameters: none > This capability indicates if the flic device will be able to get/set the > AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and allows > to discover this without having to create a flic device. > + > +8.14 KVM_CAP_ARM_SET_SERROR_ESR > + > +Architectures: arm, arm64 > + > +This capability indicates that userspace can specify syndrome value reported to (Nit: 'the syndrome value') > +guest OS when guest takes a virtual SError interrupt exception. (Nit: 'the guest') > +If KVM has this capability, userspace can only specify the ISS field for the ESR > +syndrome, can not specify the EC field which is not under control by KVM. (Nit: 'it can not specify...') > +If this virtual SError is taken to EL1 using AArch64, this value will be reported > +into ISS filed of ESR_EL1. (Nit: 'in the ISS field') > diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c > index 3256b92..38c8a64 100644 > --- a/arch/arm64/kvm/reset.c > +++ b/arch/arm64/kvm/reset.c > @@ -77,6 +77,9 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext) > case KVM_CAP_ARM_PMU_V3: > r = kvm_arm_support_pmu_v3(); > break; > + case KVM_CAP_ARM_INJECT_SERROR_ESR: > + r = cpus_have_const_cap(ARM64_HAS_RAS_EXTN); > + break; > case KVM_CAP_SET_GUEST_DEBUG: > case KVM_CAP_VCPU_ATTRIBUTES: > r = 1; 'dev_ioctl' feels a bit weird, but we already have cpu_has_32bit_el1() in here. > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > index 8fb90a0..3587b33 100644 > --- a/include/uapi/linux/kvm.h > +++ b/include/uapi/linux/kvm.h > @@ -934,6 +934,7 @@ struct kvm_ppc_resize_hpt { > #define KVM_CAP_S390_AIS_MIGRATION 150 > #define KVM_CAP_PPC_GET_CPU_CHAR 151 > #define KVM_CAP_S390_BPB 152 > +#define KVM_CAP_ARM_INJECT_SERROR_ESR 153 > > #ifdef KVM_CAP_IRQ_ROUTING (patch 1&2 should probably be swapped around, as on its own this does thing). Reviewed-by: James Morse <james.morse(a)arm.com> Thanks, James ^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v11 1/4] arm64: KVM: export the capability to set guest SError syndrome @ 2018-04-10 14:15 ` James Morse 0 siblings, 0 replies; 58+ messages in thread From: James Morse @ 2018-04-10 14:15 UTC (permalink / raw) To: linux-arm-kernel Hi Dongjiu Geng, On 09/04/18 22:36, Dongjiu Geng wrote: > Before user space injects a SError, it needs to know whether it can > specify the guest Exception Syndrome, so KVM should tell user space > whether it has such capability. (you could improve the commit message by briefly explaining how/why user-space would want to do this. As this is patch 1, you don't have the context of the previous patch to say that some systems can provide an ESR with virtual-SError) > diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt > index fc3ae95..8a3d708 100644 > --- a/Documentation/virtual/kvm/api.txt > +++ b/Documentation/virtual/kvm/api.txt > @@ -4415,3 +4415,14 @@ Parameters: none > This capability indicates if the flic device will be able to get/set the > AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and allows > to discover this without having to create a flic device. > + > +8.14 KVM_CAP_ARM_SET_SERROR_ESR > + > +Architectures: arm, arm64 > + > +This capability indicates that userspace can specify syndrome value reported to (Nit: 'the syndrome value') > +guest OS when guest takes a virtual SError interrupt exception. (Nit: 'the guest') > +If KVM has this capability, userspace can only specify the ISS field for the ESR > +syndrome, can not specify the EC field which is not under control by KVM. (Nit: 'it can not specify...') > +If this virtual SError is taken to EL1 using AArch64, this value will be reported > +into ISS filed of ESR_EL1. (Nit: 'in the ISS field') > diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c > index 3256b92..38c8a64 100644 > --- a/arch/arm64/kvm/reset.c > +++ b/arch/arm64/kvm/reset.c > @@ -77,6 +77,9 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext) > case KVM_CAP_ARM_PMU_V3: > r = kvm_arm_support_pmu_v3(); > break; > + case KVM_CAP_ARM_INJECT_SERROR_ESR: > + r = cpus_have_const_cap(ARM64_HAS_RAS_EXTN); > + break; > case KVM_CAP_SET_GUEST_DEBUG: > case KVM_CAP_VCPU_ATTRIBUTES: > r = 1; 'dev_ioctl' feels a bit weird, but we already have cpu_has_32bit_el1() in here. > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > index 8fb90a0..3587b33 100644 > --- a/include/uapi/linux/kvm.h > +++ b/include/uapi/linux/kvm.h > @@ -934,6 +934,7 @@ struct kvm_ppc_resize_hpt { > #define KVM_CAP_S390_AIS_MIGRATION 150 > #define KVM_CAP_PPC_GET_CPU_CHAR 151 > #define KVM_CAP_S390_BPB 152 > +#define KVM_CAP_ARM_INJECT_SERROR_ESR 153 > > #ifdef KVM_CAP_IRQ_ROUTING (patch 1&2 should probably be swapped around, as on its own this does thing). Reviewed-by: James Morse <james.morse@arm.com> Thanks, James ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v11 1/4] arm64: KVM: export the capability to set guest SError syndrome @ 2018-04-10 14:15 ` James Morse 0 siblings, 0 replies; 58+ messages in thread From: James Morse @ 2018-04-10 14:15 UTC (permalink / raw) To: Dongjiu Geng Cc: rkrcmar, corbet, christoffer.dall, marc.zyngier, linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel, huangshaoyu, zhengxiang9 Hi Dongjiu Geng, On 09/04/18 22:36, Dongjiu Geng wrote: > Before user space injects a SError, it needs to know whether it can > specify the guest Exception Syndrome, so KVM should tell user space > whether it has such capability. (you could improve the commit message by briefly explaining how/why user-space would want to do this. As this is patch 1, you don't have the context of the previous patch to say that some systems can provide an ESR with virtual-SError) > diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt > index fc3ae95..8a3d708 100644 > --- a/Documentation/virtual/kvm/api.txt > +++ b/Documentation/virtual/kvm/api.txt > @@ -4415,3 +4415,14 @@ Parameters: none > This capability indicates if the flic device will be able to get/set the > AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and allows > to discover this without having to create a flic device. > + > +8.14 KVM_CAP_ARM_SET_SERROR_ESR > + > +Architectures: arm, arm64 > + > +This capability indicates that userspace can specify syndrome value reported to (Nit: 'the syndrome value') > +guest OS when guest takes a virtual SError interrupt exception. (Nit: 'the guest') > +If KVM has this capability, userspace can only specify the ISS field for the ESR > +syndrome, can not specify the EC field which is not under control by KVM. (Nit: 'it can not specify...') > +If this virtual SError is taken to EL1 using AArch64, this value will be reported > +into ISS filed of ESR_EL1. (Nit: 'in the ISS field') > diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c > index 3256b92..38c8a64 100644 > --- a/arch/arm64/kvm/reset.c > +++ b/arch/arm64/kvm/reset.c > @@ -77,6 +77,9 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext) > case KVM_CAP_ARM_PMU_V3: > r = kvm_arm_support_pmu_v3(); > break; > + case KVM_CAP_ARM_INJECT_SERROR_ESR: > + r = cpus_have_const_cap(ARM64_HAS_RAS_EXTN); > + break; > case KVM_CAP_SET_GUEST_DEBUG: > case KVM_CAP_VCPU_ATTRIBUTES: > r = 1; 'dev_ioctl' feels a bit weird, but we already have cpu_has_32bit_el1() in here. > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > index 8fb90a0..3587b33 100644 > --- a/include/uapi/linux/kvm.h > +++ b/include/uapi/linux/kvm.h > @@ -934,6 +934,7 @@ struct kvm_ppc_resize_hpt { > #define KVM_CAP_S390_AIS_MIGRATION 150 > #define KVM_CAP_PPC_GET_CPU_CHAR 151 > #define KVM_CAP_S390_BPB 152 > +#define KVM_CAP_ARM_INJECT_SERROR_ESR 153 > > #ifdef KVM_CAP_IRQ_ROUTING (patch 1&2 should probably be swapped around, as on its own this does thing). Reviewed-by: James Morse <james.morse@arm.com> Thanks, James -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v11 1/4] arm64: KVM: export the capability to set guest SError syndrome 2018-04-10 14:15 ` James Morse (?) @ 2018-04-12 12:55 ` gengdongjiu -1 siblings, 0 replies; 58+ messages in thread From: gengdongjiu @ 2018-04-12 12:55 UTC (permalink / raw) To: James Morse Cc: Dongjiu Geng, linux-doc, kvm, corbet, marc.zyngier, catalin.marinas, rjw, linux, linux-kernel, linux-acpi, zhengxiang9, bp, linux-arm-kernel, huangshaoyu, devel, kvmarm, christoffer.dall, lenb HI James, Thanks for the review. 2018-04-10 22:15 GMT+08:00, James Morse <james.morse@arm.com>: > Hi Dongjiu Geng, > > On 09/04/18 22:36, Dongjiu Geng wrote: >> Before user space injects a SError, it needs to know whether it can >> specify the guest Exception Syndrome, so KVM should tell user space >> whether it has such capability. > > (you could improve the commit message by briefly explaining how/why > user-space > would want to do this. As this is patch 1, you don't have the context of > the > previous patch to say that some systems can provide an ESR with > virtual-SError) Exactly, thanks for the good comments. > > >> diff --git a/Documentation/virtual/kvm/api.txt >> b/Documentation/virtual/kvm/api.txt >> index fc3ae95..8a3d708 100644 >> --- a/Documentation/virtual/kvm/api.txt >> +++ b/Documentation/virtual/kvm/api.txt >> @@ -4415,3 +4415,14 @@ Parameters: none >> This capability indicates if the flic device will be able to get/set the >> AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and >> allows >> to discover this without having to create a flic device. >> + >> +8.14 KVM_CAP_ARM_SET_SERROR_ESR >> + >> +Architectures: arm, arm64 >> + >> +This capability indicates that userspace can specify syndrome value >> reported to > > (Nit: 'the syndrome value') will fix it. > >> +guest OS when guest takes a virtual SError interrupt exception. > > (Nit: 'the guest') will fix it. > >> +If KVM has this capability, userspace can only specify the ISS field for >> the ESR >> +syndrome, can not specify the EC field which is not under control by >> KVM. > > (Nit: 'it can not specify...') will fix it. > >> +If this virtual SError is taken to EL1 using AArch64, this value will be >> reported >> +into ISS filed of ESR_EL1. > > (Nit: 'in the ISS field') will fix it. > > >> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c >> index 3256b92..38c8a64 100644 >> --- a/arch/arm64/kvm/reset.c >> +++ b/arch/arm64/kvm/reset.c >> @@ -77,6 +77,9 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, >> long ext) >> case KVM_CAP_ARM_PMU_V3: >> r = kvm_arm_support_pmu_v3(); >> break; >> + case KVM_CAP_ARM_INJECT_SERROR_ESR: >> + r = cpus_have_const_cap(ARM64_HAS_RAS_EXTN); >> + break; >> case KVM_CAP_SET_GUEST_DEBUG: >> case KVM_CAP_VCPU_ATTRIBUTES: >> r = 1; > > 'dev_ioctl' feels a bit weird, but we already have cpu_has_32bit_el1() in > here. Yes, although the name is "dev_ioctl", it does not have relationship with the device. here it mainly check vcpu capability, such as PMU, 32bit EL1 etc. > > >> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h >> index 8fb90a0..3587b33 100644 >> --- a/include/uapi/linux/kvm.h >> +++ b/include/uapi/linux/kvm.h >> @@ -934,6 +934,7 @@ struct kvm_ppc_resize_hpt { >> #define KVM_CAP_S390_AIS_MIGRATION 150 >> #define KVM_CAP_PPC_GET_CPU_CHAR 151 >> #define KVM_CAP_S390_BPB 152 >> +#define KVM_CAP_ARM_INJECT_SERROR_ESR 153 >> >> #ifdef KVM_CAP_IRQ_ROUTING > > (patch 1&2 should probably be swapped around, as on its own this does > thing). ok, I will do it. > > Reviewed-by: James Morse <james.morse@arm.com> thanks this Reviewed-by > > > Thanks, > > James > _______________________________________________ > kvmarm mailing list > kvmarm@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm > ^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v11 1/4] arm64: KVM: export the capability to set guest SError syndrome @ 2018-04-12 12:55 ` gengdongjiu 0 siblings, 0 replies; 58+ messages in thread From: gengdongjiu @ 2018-04-12 12:55 UTC (permalink / raw) To: linux-arm-kernel HI James, Thanks for the review. 2018-04-10 22:15 GMT+08:00, James Morse <james.morse@arm.com>: > Hi Dongjiu Geng, > > On 09/04/18 22:36, Dongjiu Geng wrote: >> Before user space injects a SError, it needs to know whether it can >> specify the guest Exception Syndrome, so KVM should tell user space >> whether it has such capability. > > (you could improve the commit message by briefly explaining how/why > user-space > would want to do this. As this is patch 1, you don't have the context of > the > previous patch to say that some systems can provide an ESR with > virtual-SError) Exactly, thanks for the good comments. > > >> diff --git a/Documentation/virtual/kvm/api.txt >> b/Documentation/virtual/kvm/api.txt >> index fc3ae95..8a3d708 100644 >> --- a/Documentation/virtual/kvm/api.txt >> +++ b/Documentation/virtual/kvm/api.txt >> @@ -4415,3 +4415,14 @@ Parameters: none >> This capability indicates if the flic device will be able to get/set the >> AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and >> allows >> to discover this without having to create a flic device. >> + >> +8.14 KVM_CAP_ARM_SET_SERROR_ESR >> + >> +Architectures: arm, arm64 >> + >> +This capability indicates that userspace can specify syndrome value >> reported to > > (Nit: 'the syndrome value') will fix it. > >> +guest OS when guest takes a virtual SError interrupt exception. > > (Nit: 'the guest') will fix it. > >> +If KVM has this capability, userspace can only specify the ISS field for >> the ESR >> +syndrome, can not specify the EC field which is not under control by >> KVM. > > (Nit: 'it can not specify...') will fix it. > >> +If this virtual SError is taken to EL1 using AArch64, this value will be >> reported >> +into ISS filed of ESR_EL1. > > (Nit: 'in the ISS field') will fix it. > > >> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c >> index 3256b92..38c8a64 100644 >> --- a/arch/arm64/kvm/reset.c >> +++ b/arch/arm64/kvm/reset.c >> @@ -77,6 +77,9 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, >> long ext) >> case KVM_CAP_ARM_PMU_V3: >> r = kvm_arm_support_pmu_v3(); >> break; >> + case KVM_CAP_ARM_INJECT_SERROR_ESR: >> + r = cpus_have_const_cap(ARM64_HAS_RAS_EXTN); >> + break; >> case KVM_CAP_SET_GUEST_DEBUG: >> case KVM_CAP_VCPU_ATTRIBUTES: >> r = 1; > > 'dev_ioctl' feels a bit weird, but we already have cpu_has_32bit_el1() in > here. Yes, although the name is "dev_ioctl", it does not have relationship with the device. here it mainly check vcpu capability, such as PMU, 32bit EL1 etc. > > >> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h >> index 8fb90a0..3587b33 100644 >> --- a/include/uapi/linux/kvm.h >> +++ b/include/uapi/linux/kvm.h >> @@ -934,6 +934,7 @@ struct kvm_ppc_resize_hpt { >> #define KVM_CAP_S390_AIS_MIGRATION 150 >> #define KVM_CAP_PPC_GET_CPU_CHAR 151 >> #define KVM_CAP_S390_BPB 152 >> +#define KVM_CAP_ARM_INJECT_SERROR_ESR 153 >> >> #ifdef KVM_CAP_IRQ_ROUTING > > (patch 1&2 should probably be swapped around, as on its own this does > thing). ok, I will do it. > > Reviewed-by: James Morse <james.morse@arm.com> thanks this Reviewed-by > > > Thanks, > > James > _______________________________________________ > kvmarm mailing list > kvmarm at lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm > ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v11 1/4] arm64: KVM: export the capability to set guest SError syndrome @ 2018-04-12 12:55 ` gengdongjiu 0 siblings, 0 replies; 58+ messages in thread From: gengdongjiu @ 2018-04-12 12:55 UTC (permalink / raw) To: James Morse Cc: Dongjiu Geng, linux-doc, kvm, corbet, marc.zyngier, catalin.marinas, rjw, linux, linux-kernel, linux-acpi, zhengxiang9, bp, linux-arm-kernel, huangshaoyu, devel, kvmarm, christoffer.dall, lenb HI James, Thanks for the review. 2018-04-10 22:15 GMT+08:00, James Morse <james.morse@arm.com>: > Hi Dongjiu Geng, > > On 09/04/18 22:36, Dongjiu Geng wrote: >> Before user space injects a SError, it needs to know whether it can >> specify the guest Exception Syndrome, so KVM should tell user space >> whether it has such capability. > > (you could improve the commit message by briefly explaining how/why > user-space > would want to do this. As this is patch 1, you don't have the context of > the > previous patch to say that some systems can provide an ESR with > virtual-SError) Exactly, thanks for the good comments. > > >> diff --git a/Documentation/virtual/kvm/api.txt >> b/Documentation/virtual/kvm/api.txt >> index fc3ae95..8a3d708 100644 >> --- a/Documentation/virtual/kvm/api.txt >> +++ b/Documentation/virtual/kvm/api.txt >> @@ -4415,3 +4415,14 @@ Parameters: none >> This capability indicates if the flic device will be able to get/set the >> AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and >> allows >> to discover this without having to create a flic device. >> + >> +8.14 KVM_CAP_ARM_SET_SERROR_ESR >> + >> +Architectures: arm, arm64 >> + >> +This capability indicates that userspace can specify syndrome value >> reported to > > (Nit: 'the syndrome value') will fix it. > >> +guest OS when guest takes a virtual SError interrupt exception. > > (Nit: 'the guest') will fix it. > >> +If KVM has this capability, userspace can only specify the ISS field for >> the ESR >> +syndrome, can not specify the EC field which is not under control by >> KVM. > > (Nit: 'it can not specify...') will fix it. > >> +If this virtual SError is taken to EL1 using AArch64, this value will be >> reported >> +into ISS filed of ESR_EL1. > > (Nit: 'in the ISS field') will fix it. > > >> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c >> index 3256b92..38c8a64 100644 >> --- a/arch/arm64/kvm/reset.c >> +++ b/arch/arm64/kvm/reset.c >> @@ -77,6 +77,9 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, >> long ext) >> case KVM_CAP_ARM_PMU_V3: >> r = kvm_arm_support_pmu_v3(); >> break; >> + case KVM_CAP_ARM_INJECT_SERROR_ESR: >> + r = cpus_have_const_cap(ARM64_HAS_RAS_EXTN); >> + break; >> case KVM_CAP_SET_GUEST_DEBUG: >> case KVM_CAP_VCPU_ATTRIBUTES: >> r = 1; > > 'dev_ioctl' feels a bit weird, but we already have cpu_has_32bit_el1() in > here. Yes, although the name is "dev_ioctl", it does not have relationship with the device. here it mainly check vcpu capability, such as PMU, 32bit EL1 etc. > > >> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h >> index 8fb90a0..3587b33 100644 >> --- a/include/uapi/linux/kvm.h >> +++ b/include/uapi/linux/kvm.h >> @@ -934,6 +934,7 @@ struct kvm_ppc_resize_hpt { >> #define KVM_CAP_S390_AIS_MIGRATION 150 >> #define KVM_CAP_PPC_GET_CPU_CHAR 151 >> #define KVM_CAP_S390_BPB 152 >> +#define KVM_CAP_ARM_INJECT_SERROR_ESR 153 >> >> #ifdef KVM_CAP_IRQ_ROUTING > > (patch 1&2 should probably be swapped around, as on its own this does > thing). ok, I will do it. > > Reviewed-by: James Morse <james.morse@arm.com> thanks this Reviewed-by > > > Thanks, > > James > _______________________________________________ > kvmarm mailing list > kvmarm@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v11 2/4] arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS 2018-04-09 21:36 ` Dongjiu Geng ` (2 preceding siblings ...) (?) @ 2018-04-09 21:36 ` Dongjiu Geng -1 siblings, 0 replies; 58+ messages in thread From: Dongjiu Geng @ 2018-04-09 21:36 UTC (permalink / raw) To: rkrcmar, corbet, christoffer.dall, marc.zyngier, james.morse, linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel Cc: gengdongjiu, huangshaoyu, zhengxiang9 This new IOCTL exports user-invisible states related to SError. Together with appropriate user space changes, it can inject SError with specified syndrome to guest by setup kvm_vcpu_events value. Also it can support live migration. Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com> Change since V10: Address James's comments, thanks James 1. Merge the helper function with the user. 2. Move the ISS_MASK into pend_guest_serror() to clear top bits 3. Make kvm_vcpu_events struct align to 4 bytes 4. Add something check in the kvm_arm_vcpu_set_events() 5. Check kvm_arm_vcpu_get/set_events()'s return value. 6. Initialise kvm_vcpu_events to 0 so that padding transferred to user-space doesn't contain kernel stack. --- Documentation/virtual/kvm/api.txt | 28 ++++++++++++++++++++++++++-- arch/arm/include/asm/kvm_host.h | 6 ++++++ arch/arm/kvm/guest.c | 12 ++++++++++++ arch/arm64/include/asm/kvm_emulate.h | 5 +++++ arch/arm64/include/asm/kvm_host.h | 7 +++++++ arch/arm64/include/uapi/asm/kvm.h | 12 ++++++++++++ arch/arm64/kvm/guest.c | 31 +++++++++++++++++++++++++++++++ arch/arm64/kvm/inject_fault.c | 7 ++++++- arch/arm64/kvm/reset.c | 1 + virt/kvm/arm/arm.c | 21 +++++++++++++++++++++ 10 files changed, 127 insertions(+), 3 deletions(-) diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index 8a3d708..45719b4 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -819,11 +819,13 @@ struct kvm_clock_data { Capability: KVM_CAP_VCPU_EVENTS Extended by: KVM_CAP_INTR_SHADOW -Architectures: x86 +Architectures: x86, arm, arm64 Type: vm ioctl Parameters: struct kvm_vcpu_event (out) Returns: 0 on success, -1 on error +X86: + Gets currently pending exceptions, interrupts, and NMIs as well as related states of the vcpu. @@ -865,15 +867,31 @@ Only two fields are defined in the flags field: - KVM_VCPUEVENT_VALID_SMM may be set in the flags field to signal that smi contains a valid state. +ARM, ARM64: + +Gets currently pending SError exceptions as well as related states of the vcpu. + +struct kvm_vcpu_events { + struct { + __u8 serror_pending; + __u8 serror_has_esr; + /* Align it to 4 bytes */ + __u8 pad[2]; + __u64 serror_esr; + } exception; +}; + 4.32 KVM_SET_VCPU_EVENTS Capability: KVM_CAP_VCPU_EVENTS Extended by: KVM_CAP_INTR_SHADOW -Architectures: x86 +Architectures: x86, arm, arm64 Type: vm ioctl Parameters: struct kvm_vcpu_event (in) Returns: 0 on success, -1 on error +X86: + Set pending exceptions, interrupts, and NMIs as well as related states of the vcpu. @@ -894,6 +912,12 @@ shall be written into the VCPU. KVM_VCPUEVENT_VALID_SMM can only be set if KVM_CAP_X86_SMM is available. +ARM, ARM64: + +Set pending SError exceptions as well as related states of the vcpu. + +See KVM_GET_VCPU_EVENTS for the data structure. + 4.33 KVM_GET_DEBUGREGS diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h index ef54013..d81621e 100644 --- a/arch/arm/include/asm/kvm_host.h +++ b/arch/arm/include/asm/kvm_host.h @@ -211,6 +211,12 @@ struct kvm_vcpu_stat { int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices); int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg); int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg); +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events); + +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events); + unsigned long kvm_call_hyp(void *hypfn, ...); void force_vm_exit(const cpumask_t *mask); diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c index 1e0784e..39f895d 100644 --- a/arch/arm/kvm/guest.c +++ b/arch/arm/kvm/guest.c @@ -248,6 +248,18 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu, return -EINVAL; } +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events) +{ + return -EINVAL; +} + +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events) +{ + return -EINVAL; +} + int __attribute_const__ kvm_target_cpu(void) { switch (read_cpuid_part()) { diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h index 413dc82..3294885 100644 --- a/arch/arm64/include/asm/kvm_emulate.h +++ b/arch/arm64/include/asm/kvm_emulate.h @@ -71,6 +71,11 @@ static inline void vcpu_set_hcr(struct kvm_vcpu *vcpu, unsigned long hcr) vcpu->arch.hcr_el2 = hcr; } +static inline unsigned long vcpu_get_vsesr(struct kvm_vcpu *vcpu) +{ + return vcpu->arch.vsesr_el2; +} + static inline void vcpu_set_vsesr(struct kvm_vcpu *vcpu, u64 vsesr) { vcpu->arch.vsesr_el2 = vsesr; diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h index a73f63a..1125540 100644 --- a/arch/arm64/include/asm/kvm_host.h +++ b/arch/arm64/include/asm/kvm_host.h @@ -326,6 +326,11 @@ struct kvm_vcpu_stat { int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices); int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg); int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg); +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events); + +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events); #define KVM_ARCH_WANT_MMU_NOTIFIER int kvm_unmap_hva(struct kvm *kvm, unsigned long hva); @@ -354,6 +359,8 @@ void handle_exit_early(struct kvm_vcpu *vcpu, struct kvm_run *run, int kvm_perf_init(void); int kvm_perf_teardown(void); +void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome); + struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr); static inline void __cpu_init_hyp_mode(phys_addr_t pgd_ptr, diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h index 9abbf30..855cc9a 100644 --- a/arch/arm64/include/uapi/asm/kvm.h +++ b/arch/arm64/include/uapi/asm/kvm.h @@ -39,6 +39,7 @@ #define __KVM_HAVE_GUEST_DEBUG #define __KVM_HAVE_IRQ_LINE #define __KVM_HAVE_READONLY_MEM +#define __KVM_HAVE_VCPU_EVENTS #define KVM_COALESCED_MMIO_PAGE_OFFSET 1 @@ -153,6 +154,17 @@ struct kvm_sync_regs { struct kvm_arch_memory_slot { }; +/* for KVM_GET/SET_VCPU_EVENTS */ +struct kvm_vcpu_events { + struct { + __u8 serror_pending; + __u8 serror_has_esr; + /* Align it to 4 bytes */ + __u8 pad[2]; + __u64 serror_esr; + } exception; +}; + /* If you need to interpret the index values, here is the key: */ #define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000 #define KVM_REG_ARM_COPROC_SHIFT 16 diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c index 5c7f657..42e1222 100644 --- a/arch/arm64/kvm/guest.c +++ b/arch/arm64/kvm/guest.c @@ -277,6 +277,37 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu, return -EINVAL; } +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events) +{ + events->exception.serror_pending = (vcpu_get_hcr(vcpu) & HCR_VSE); + events->exception.serror_has_esr = + cpus_have_const_cap(ARM64_HAS_RAS_EXTN) && + (!!vcpu_get_vsesr(vcpu)); + events->exception.serror_esr = vcpu_get_vsesr(vcpu); + + return 0; +} + +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events) +{ + bool injected = events->exception.serror_pending; + bool has_esr = events->exception.serror_has_esr; + + if (injected && has_esr) { + if (!cpus_have_const_cap(ARM64_HAS_RAS_EXTN)) + return -EINVAL; + + kvm_set_sei_esr(vcpu, events->exception.serror_esr); + + } else if (injected) { + kvm_inject_vabt(vcpu); + } + + return 0; +} + int __attribute_const__ kvm_target_cpu(void) { unsigned long implementor = read_cpuid_implementor(); diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c index 60666a0..aa0358a 100644 --- a/arch/arm64/kvm/inject_fault.c +++ b/arch/arm64/kvm/inject_fault.c @@ -166,7 +166,7 @@ void kvm_inject_undefined(struct kvm_vcpu *vcpu) static void pend_guest_serror(struct kvm_vcpu *vcpu, u64 esr) { - vcpu_set_vsesr(vcpu, esr); + vcpu_set_vsesr(vcpu, esr & ESR_ELx_ISS_MASK); vcpu_set_hcr(vcpu, vcpu_get_hcr(vcpu) | HCR_VSE); } @@ -186,3 +186,8 @@ void kvm_inject_vabt(struct kvm_vcpu *vcpu) { pend_guest_serror(vcpu, ESR_ELx_ISV); } + +void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome) +{ + pend_guest_serror(vcpu, syndrome); +} diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c index 38c8a64..20e919a 100644 --- a/arch/arm64/kvm/reset.c +++ b/arch/arm64/kvm/reset.c @@ -82,6 +82,7 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext) break; case KVM_CAP_SET_GUEST_DEBUG: case KVM_CAP_VCPU_ATTRIBUTES: + case KVM_CAP_VCPU_EVENTS: r = 1; break; default: diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c index 7e3941f..945655d 100644 --- a/virt/kvm/arm/arm.c +++ b/virt/kvm/arm/arm.c @@ -1051,6 +1051,27 @@ long kvm_arch_vcpu_ioctl(struct file *filp, return -EFAULT; return kvm_arm_vcpu_has_attr(vcpu, &attr); } + case KVM_GET_VCPU_EVENTS: { + struct kvm_vcpu_events events; + + memset(&events, 0, sizeof(struct kvm_vcpu_events)); + if (kvm_arm_vcpu_get_events(vcpu, &events)) + return -EINVAL; + + if (copy_to_user(argp, &events, sizeof(struct kvm_vcpu_events))) + return -EFAULT; + + return 0; + } + case KVM_SET_VCPU_EVENTS: { + struct kvm_vcpu_events events; + + if (copy_from_user(&events, argp, + sizeof(struct kvm_vcpu_events))) + return -EFAULT; + + return kvm_arm_vcpu_set_events(vcpu, &events); + } default: return -EINVAL; } -- 1.9.1 ^ permalink raw reply related [flat|nested] 58+ messages in thread
* [Devel] [PATCH v11 2/4] arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS @ 2018-04-09 21:36 ` Dongjiu Geng 0 siblings, 0 replies; 58+ messages in thread From: Dongjiu Geng @ 2018-04-09 21:36 UTC (permalink / raw) To: devel [-- Attachment #1: Type: text/plain, Size: 10030 bytes --] This new IOCTL exports user-invisible states related to SError. Together with appropriate user space changes, it can inject SError with specified syndrome to guest by setup kvm_vcpu_events value. Also it can support live migration. Signed-off-by: Dongjiu Geng <gengdongjiu(a)huawei.com> Change since V10: Address James's comments, thanks James 1. Merge the helper function with the user. 2. Move the ISS_MASK into pend_guest_serror() to clear top bits 3. Make kvm_vcpu_events struct align to 4 bytes 4. Add something check in the kvm_arm_vcpu_set_events() 5. Check kvm_arm_vcpu_get/set_events()'s return value. 6. Initialise kvm_vcpu_events to 0 so that padding transferred to user-space doesn't contain kernel stack. --- Documentation/virtual/kvm/api.txt | 28 ++++++++++++++++++++++++++-- arch/arm/include/asm/kvm_host.h | 6 ++++++ arch/arm/kvm/guest.c | 12 ++++++++++++ arch/arm64/include/asm/kvm_emulate.h | 5 +++++ arch/arm64/include/asm/kvm_host.h | 7 +++++++ arch/arm64/include/uapi/asm/kvm.h | 12 ++++++++++++ arch/arm64/kvm/guest.c | 31 +++++++++++++++++++++++++++++++ arch/arm64/kvm/inject_fault.c | 7 ++++++- arch/arm64/kvm/reset.c | 1 + virt/kvm/arm/arm.c | 21 +++++++++++++++++++++ 10 files changed, 127 insertions(+), 3 deletions(-) diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index 8a3d708..45719b4 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -819,11 +819,13 @@ struct kvm_clock_data { Capability: KVM_CAP_VCPU_EVENTS Extended by: KVM_CAP_INTR_SHADOW -Architectures: x86 +Architectures: x86, arm, arm64 Type: vm ioctl Parameters: struct kvm_vcpu_event (out) Returns: 0 on success, -1 on error +X86: + Gets currently pending exceptions, interrupts, and NMIs as well as related states of the vcpu. @@ -865,15 +867,31 @@ Only two fields are defined in the flags field: - KVM_VCPUEVENT_VALID_SMM may be set in the flags field to signal that smi contains a valid state. +ARM, ARM64: + +Gets currently pending SError exceptions as well as related states of the vcpu. + +struct kvm_vcpu_events { + struct { + __u8 serror_pending; + __u8 serror_has_esr; + /* Align it to 4 bytes */ + __u8 pad[2]; + __u64 serror_esr; + } exception; +}; + 4.32 KVM_SET_VCPU_EVENTS Capability: KVM_CAP_VCPU_EVENTS Extended by: KVM_CAP_INTR_SHADOW -Architectures: x86 +Architectures: x86, arm, arm64 Type: vm ioctl Parameters: struct kvm_vcpu_event (in) Returns: 0 on success, -1 on error +X86: + Set pending exceptions, interrupts, and NMIs as well as related states of the vcpu. @@ -894,6 +912,12 @@ shall be written into the VCPU. KVM_VCPUEVENT_VALID_SMM can only be set if KVM_CAP_X86_SMM is available. +ARM, ARM64: + +Set pending SError exceptions as well as related states of the vcpu. + +See KVM_GET_VCPU_EVENTS for the data structure. + 4.33 KVM_GET_DEBUGREGS diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h index ef54013..d81621e 100644 --- a/arch/arm/include/asm/kvm_host.h +++ b/arch/arm/include/asm/kvm_host.h @@ -211,6 +211,12 @@ struct kvm_vcpu_stat { int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices); int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg); int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg); +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events); + +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events); + unsigned long kvm_call_hyp(void *hypfn, ...); void force_vm_exit(const cpumask_t *mask); diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c index 1e0784e..39f895d 100644 --- a/arch/arm/kvm/guest.c +++ b/arch/arm/kvm/guest.c @@ -248,6 +248,18 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu, return -EINVAL; } +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events) +{ + return -EINVAL; +} + +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events) +{ + return -EINVAL; +} + int __attribute_const__ kvm_target_cpu(void) { switch (read_cpuid_part()) { diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h index 413dc82..3294885 100644 --- a/arch/arm64/include/asm/kvm_emulate.h +++ b/arch/arm64/include/asm/kvm_emulate.h @@ -71,6 +71,11 @@ static inline void vcpu_set_hcr(struct kvm_vcpu *vcpu, unsigned long hcr) vcpu->arch.hcr_el2 = hcr; } +static inline unsigned long vcpu_get_vsesr(struct kvm_vcpu *vcpu) +{ + return vcpu->arch.vsesr_el2; +} + static inline void vcpu_set_vsesr(struct kvm_vcpu *vcpu, u64 vsesr) { vcpu->arch.vsesr_el2 = vsesr; diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h index a73f63a..1125540 100644 --- a/arch/arm64/include/asm/kvm_host.h +++ b/arch/arm64/include/asm/kvm_host.h @@ -326,6 +326,11 @@ struct kvm_vcpu_stat { int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices); int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg); int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg); +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events); + +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events); #define KVM_ARCH_WANT_MMU_NOTIFIER int kvm_unmap_hva(struct kvm *kvm, unsigned long hva); @@ -354,6 +359,8 @@ void handle_exit_early(struct kvm_vcpu *vcpu, struct kvm_run *run, int kvm_perf_init(void); int kvm_perf_teardown(void); +void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome); + struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr); static inline void __cpu_init_hyp_mode(phys_addr_t pgd_ptr, diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h index 9abbf30..855cc9a 100644 --- a/arch/arm64/include/uapi/asm/kvm.h +++ b/arch/arm64/include/uapi/asm/kvm.h @@ -39,6 +39,7 @@ #define __KVM_HAVE_GUEST_DEBUG #define __KVM_HAVE_IRQ_LINE #define __KVM_HAVE_READONLY_MEM +#define __KVM_HAVE_VCPU_EVENTS #define KVM_COALESCED_MMIO_PAGE_OFFSET 1 @@ -153,6 +154,17 @@ struct kvm_sync_regs { struct kvm_arch_memory_slot { }; +/* for KVM_GET/SET_VCPU_EVENTS */ +struct kvm_vcpu_events { + struct { + __u8 serror_pending; + __u8 serror_has_esr; + /* Align it to 4 bytes */ + __u8 pad[2]; + __u64 serror_esr; + } exception; +}; + /* If you need to interpret the index values, here is the key: */ #define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000 #define KVM_REG_ARM_COPROC_SHIFT 16 diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c index 5c7f657..42e1222 100644 --- a/arch/arm64/kvm/guest.c +++ b/arch/arm64/kvm/guest.c @@ -277,6 +277,37 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu, return -EINVAL; } +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events) +{ + events->exception.serror_pending = (vcpu_get_hcr(vcpu) & HCR_VSE); + events->exception.serror_has_esr = + cpus_have_const_cap(ARM64_HAS_RAS_EXTN) && + (!!vcpu_get_vsesr(vcpu)); + events->exception.serror_esr = vcpu_get_vsesr(vcpu); + + return 0; +} + +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events) +{ + bool injected = events->exception.serror_pending; + bool has_esr = events->exception.serror_has_esr; + + if (injected && has_esr) { + if (!cpus_have_const_cap(ARM64_HAS_RAS_EXTN)) + return -EINVAL; + + kvm_set_sei_esr(vcpu, events->exception.serror_esr); + + } else if (injected) { + kvm_inject_vabt(vcpu); + } + + return 0; +} + int __attribute_const__ kvm_target_cpu(void) { unsigned long implementor = read_cpuid_implementor(); diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c index 60666a0..aa0358a 100644 --- a/arch/arm64/kvm/inject_fault.c +++ b/arch/arm64/kvm/inject_fault.c @@ -166,7 +166,7 @@ void kvm_inject_undefined(struct kvm_vcpu *vcpu) static void pend_guest_serror(struct kvm_vcpu *vcpu, u64 esr) { - vcpu_set_vsesr(vcpu, esr); + vcpu_set_vsesr(vcpu, esr & ESR_ELx_ISS_MASK); vcpu_set_hcr(vcpu, vcpu_get_hcr(vcpu) | HCR_VSE); } @@ -186,3 +186,8 @@ void kvm_inject_vabt(struct kvm_vcpu *vcpu) { pend_guest_serror(vcpu, ESR_ELx_ISV); } + +void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome) +{ + pend_guest_serror(vcpu, syndrome); +} diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c index 38c8a64..20e919a 100644 --- a/arch/arm64/kvm/reset.c +++ b/arch/arm64/kvm/reset.c @@ -82,6 +82,7 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext) break; case KVM_CAP_SET_GUEST_DEBUG: case KVM_CAP_VCPU_ATTRIBUTES: + case KVM_CAP_VCPU_EVENTS: r = 1; break; default: diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c index 7e3941f..945655d 100644 --- a/virt/kvm/arm/arm.c +++ b/virt/kvm/arm/arm.c @@ -1051,6 +1051,27 @@ long kvm_arch_vcpu_ioctl(struct file *filp, return -EFAULT; return kvm_arm_vcpu_has_attr(vcpu, &attr); } + case KVM_GET_VCPU_EVENTS: { + struct kvm_vcpu_events events; + + memset(&events, 0, sizeof(struct kvm_vcpu_events)); + if (kvm_arm_vcpu_get_events(vcpu, &events)) + return -EINVAL; + + if (copy_to_user(argp, &events, sizeof(struct kvm_vcpu_events))) + return -EFAULT; + + return 0; + } + case KVM_SET_VCPU_EVENTS: { + struct kvm_vcpu_events events; + + if (copy_from_user(&events, argp, + sizeof(struct kvm_vcpu_events))) + return -EFAULT; + + return kvm_arm_vcpu_set_events(vcpu, &events); + } default: return -EINVAL; } -- 1.9.1 ^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v11 2/4] arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS @ 2018-04-09 21:36 ` Dongjiu Geng 0 siblings, 0 replies; 58+ messages in thread From: Dongjiu Geng @ 2018-04-09 21:36 UTC (permalink / raw) To: linux-arm-kernel This new IOCTL exports user-invisible states related to SError. Together with appropriate user space changes, it can inject SError with specified syndrome to guest by setup kvm_vcpu_events value. Also it can support live migration. Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com> Change since V10: Address James's comments, thanks James 1. Merge the helper function with the user. 2. Move the ISS_MASK into pend_guest_serror() to clear top bits 3. Make kvm_vcpu_events struct align to 4 bytes 4. Add something check in the kvm_arm_vcpu_set_events() 5. Check kvm_arm_vcpu_get/set_events()'s return value. 6. Initialise kvm_vcpu_events to 0 so that padding transferred to user-space doesn't contain kernel stack. --- Documentation/virtual/kvm/api.txt | 28 ++++++++++++++++++++++++++-- arch/arm/include/asm/kvm_host.h | 6 ++++++ arch/arm/kvm/guest.c | 12 ++++++++++++ arch/arm64/include/asm/kvm_emulate.h | 5 +++++ arch/arm64/include/asm/kvm_host.h | 7 +++++++ arch/arm64/include/uapi/asm/kvm.h | 12 ++++++++++++ arch/arm64/kvm/guest.c | 31 +++++++++++++++++++++++++++++++ arch/arm64/kvm/inject_fault.c | 7 ++++++- arch/arm64/kvm/reset.c | 1 + virt/kvm/arm/arm.c | 21 +++++++++++++++++++++ 10 files changed, 127 insertions(+), 3 deletions(-) diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index 8a3d708..45719b4 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -819,11 +819,13 @@ struct kvm_clock_data { Capability: KVM_CAP_VCPU_EVENTS Extended by: KVM_CAP_INTR_SHADOW -Architectures: x86 +Architectures: x86, arm, arm64 Type: vm ioctl Parameters: struct kvm_vcpu_event (out) Returns: 0 on success, -1 on error +X86: + Gets currently pending exceptions, interrupts, and NMIs as well as related states of the vcpu. @@ -865,15 +867,31 @@ Only two fields are defined in the flags field: - KVM_VCPUEVENT_VALID_SMM may be set in the flags field to signal that smi contains a valid state. +ARM, ARM64: + +Gets currently pending SError exceptions as well as related states of the vcpu. + +struct kvm_vcpu_events { + struct { + __u8 serror_pending; + __u8 serror_has_esr; + /* Align it to 4 bytes */ + __u8 pad[2]; + __u64 serror_esr; + } exception; +}; + 4.32 KVM_SET_VCPU_EVENTS Capability: KVM_CAP_VCPU_EVENTS Extended by: KVM_CAP_INTR_SHADOW -Architectures: x86 +Architectures: x86, arm, arm64 Type: vm ioctl Parameters: struct kvm_vcpu_event (in) Returns: 0 on success, -1 on error +X86: + Set pending exceptions, interrupts, and NMIs as well as related states of the vcpu. @@ -894,6 +912,12 @@ shall be written into the VCPU. KVM_VCPUEVENT_VALID_SMM can only be set if KVM_CAP_X86_SMM is available. +ARM, ARM64: + +Set pending SError exceptions as well as related states of the vcpu. + +See KVM_GET_VCPU_EVENTS for the data structure. + 4.33 KVM_GET_DEBUGREGS diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h index ef54013..d81621e 100644 --- a/arch/arm/include/asm/kvm_host.h +++ b/arch/arm/include/asm/kvm_host.h @@ -211,6 +211,12 @@ struct kvm_vcpu_stat { int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices); int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg); int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg); +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events); + +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events); + unsigned long kvm_call_hyp(void *hypfn, ...); void force_vm_exit(const cpumask_t *mask); diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c index 1e0784e..39f895d 100644 --- a/arch/arm/kvm/guest.c +++ b/arch/arm/kvm/guest.c @@ -248,6 +248,18 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu, return -EINVAL; } +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events) +{ + return -EINVAL; +} + +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events) +{ + return -EINVAL; +} + int __attribute_const__ kvm_target_cpu(void) { switch (read_cpuid_part()) { diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h index 413dc82..3294885 100644 --- a/arch/arm64/include/asm/kvm_emulate.h +++ b/arch/arm64/include/asm/kvm_emulate.h @@ -71,6 +71,11 @@ static inline void vcpu_set_hcr(struct kvm_vcpu *vcpu, unsigned long hcr) vcpu->arch.hcr_el2 = hcr; } +static inline unsigned long vcpu_get_vsesr(struct kvm_vcpu *vcpu) +{ + return vcpu->arch.vsesr_el2; +} + static inline void vcpu_set_vsesr(struct kvm_vcpu *vcpu, u64 vsesr) { vcpu->arch.vsesr_el2 = vsesr; diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h index a73f63a..1125540 100644 --- a/arch/arm64/include/asm/kvm_host.h +++ b/arch/arm64/include/asm/kvm_host.h @@ -326,6 +326,11 @@ struct kvm_vcpu_stat { int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices); int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg); int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg); +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events); + +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events); #define KVM_ARCH_WANT_MMU_NOTIFIER int kvm_unmap_hva(struct kvm *kvm, unsigned long hva); @@ -354,6 +359,8 @@ void handle_exit_early(struct kvm_vcpu *vcpu, struct kvm_run *run, int kvm_perf_init(void); int kvm_perf_teardown(void); +void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome); + struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr); static inline void __cpu_init_hyp_mode(phys_addr_t pgd_ptr, diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h index 9abbf30..855cc9a 100644 --- a/arch/arm64/include/uapi/asm/kvm.h +++ b/arch/arm64/include/uapi/asm/kvm.h @@ -39,6 +39,7 @@ #define __KVM_HAVE_GUEST_DEBUG #define __KVM_HAVE_IRQ_LINE #define __KVM_HAVE_READONLY_MEM +#define __KVM_HAVE_VCPU_EVENTS #define KVM_COALESCED_MMIO_PAGE_OFFSET 1 @@ -153,6 +154,17 @@ struct kvm_sync_regs { struct kvm_arch_memory_slot { }; +/* for KVM_GET/SET_VCPU_EVENTS */ +struct kvm_vcpu_events { + struct { + __u8 serror_pending; + __u8 serror_has_esr; + /* Align it to 4 bytes */ + __u8 pad[2]; + __u64 serror_esr; + } exception; +}; + /* If you need to interpret the index values, here is the key: */ #define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000 #define KVM_REG_ARM_COPROC_SHIFT 16 diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c index 5c7f657..42e1222 100644 --- a/arch/arm64/kvm/guest.c +++ b/arch/arm64/kvm/guest.c @@ -277,6 +277,37 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu, return -EINVAL; } +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events) +{ + events->exception.serror_pending = (vcpu_get_hcr(vcpu) & HCR_VSE); + events->exception.serror_has_esr = + cpus_have_const_cap(ARM64_HAS_RAS_EXTN) && + (!!vcpu_get_vsesr(vcpu)); + events->exception.serror_esr = vcpu_get_vsesr(vcpu); + + return 0; +} + +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events) +{ + bool injected = events->exception.serror_pending; + bool has_esr = events->exception.serror_has_esr; + + if (injected && has_esr) { + if (!cpus_have_const_cap(ARM64_HAS_RAS_EXTN)) + return -EINVAL; + + kvm_set_sei_esr(vcpu, events->exception.serror_esr); + + } else if (injected) { + kvm_inject_vabt(vcpu); + } + + return 0; +} + int __attribute_const__ kvm_target_cpu(void) { unsigned long implementor = read_cpuid_implementor(); diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c index 60666a0..aa0358a 100644 --- a/arch/arm64/kvm/inject_fault.c +++ b/arch/arm64/kvm/inject_fault.c @@ -166,7 +166,7 @@ void kvm_inject_undefined(struct kvm_vcpu *vcpu) static void pend_guest_serror(struct kvm_vcpu *vcpu, u64 esr) { - vcpu_set_vsesr(vcpu, esr); + vcpu_set_vsesr(vcpu, esr & ESR_ELx_ISS_MASK); vcpu_set_hcr(vcpu, vcpu_get_hcr(vcpu) | HCR_VSE); } @@ -186,3 +186,8 @@ void kvm_inject_vabt(struct kvm_vcpu *vcpu) { pend_guest_serror(vcpu, ESR_ELx_ISV); } + +void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome) +{ + pend_guest_serror(vcpu, syndrome); +} diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c index 38c8a64..20e919a 100644 --- a/arch/arm64/kvm/reset.c +++ b/arch/arm64/kvm/reset.c @@ -82,6 +82,7 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext) break; case KVM_CAP_SET_GUEST_DEBUG: case KVM_CAP_VCPU_ATTRIBUTES: + case KVM_CAP_VCPU_EVENTS: r = 1; break; default: diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c index 7e3941f..945655d 100644 --- a/virt/kvm/arm/arm.c +++ b/virt/kvm/arm/arm.c @@ -1051,6 +1051,27 @@ long kvm_arch_vcpu_ioctl(struct file *filp, return -EFAULT; return kvm_arm_vcpu_has_attr(vcpu, &attr); } + case KVM_GET_VCPU_EVENTS: { + struct kvm_vcpu_events events; + + memset(&events, 0, sizeof(struct kvm_vcpu_events)); + if (kvm_arm_vcpu_get_events(vcpu, &events)) + return -EINVAL; + + if (copy_to_user(argp, &events, sizeof(struct kvm_vcpu_events))) + return -EFAULT; + + return 0; + } + case KVM_SET_VCPU_EVENTS: { + struct kvm_vcpu_events events; + + if (copy_from_user(&events, argp, + sizeof(struct kvm_vcpu_events))) + return -EFAULT; + + return kvm_arm_vcpu_set_events(vcpu, &events); + } default: return -EINVAL; } -- 1.9.1 ^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v11 2/4] arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS @ 2018-04-09 21:36 ` Dongjiu Geng 0 siblings, 0 replies; 58+ messages in thread From: Dongjiu Geng @ 2018-04-09 21:36 UTC (permalink / raw) To: rkrcmar, corbet, christoffer.dall, marc.zyngier, james.morse, linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel Cc: gengdongjiu, huangshaoyu, zhengxiang9 This new IOCTL exports user-invisible states related to SError. Together with appropriate user space changes, it can inject SError with specified syndrome to guest by setup kvm_vcpu_events value. Also it can support live migration. Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com> Change since V10: Address James's comments, thanks James 1. Merge the helper function with the user. 2. Move the ISS_MASK into pend_guest_serror() to clear top bits 3. Make kvm_vcpu_events struct align to 4 bytes 4. Add something check in the kvm_arm_vcpu_set_events() 5. Check kvm_arm_vcpu_get/set_events()'s return value. 6. Initialise kvm_vcpu_events to 0 so that padding transferred to user-space doesn't contain kernel stack. --- Documentation/virtual/kvm/api.txt | 28 ++++++++++++++++++++++++++-- arch/arm/include/asm/kvm_host.h | 6 ++++++ arch/arm/kvm/guest.c | 12 ++++++++++++ arch/arm64/include/asm/kvm_emulate.h | 5 +++++ arch/arm64/include/asm/kvm_host.h | 7 +++++++ arch/arm64/include/uapi/asm/kvm.h | 12 ++++++++++++ arch/arm64/kvm/guest.c | 31 +++++++++++++++++++++++++++++++ arch/arm64/kvm/inject_fault.c | 7 ++++++- arch/arm64/kvm/reset.c | 1 + virt/kvm/arm/arm.c | 21 +++++++++++++++++++++ 10 files changed, 127 insertions(+), 3 deletions(-) diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index 8a3d708..45719b4 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -819,11 +819,13 @@ struct kvm_clock_data { Capability: KVM_CAP_VCPU_EVENTS Extended by: KVM_CAP_INTR_SHADOW -Architectures: x86 +Architectures: x86, arm, arm64 Type: vm ioctl Parameters: struct kvm_vcpu_event (out) Returns: 0 on success, -1 on error +X86: + Gets currently pending exceptions, interrupts, and NMIs as well as related states of the vcpu. @@ -865,15 +867,31 @@ Only two fields are defined in the flags field: - KVM_VCPUEVENT_VALID_SMM may be set in the flags field to signal that smi contains a valid state. +ARM, ARM64: + +Gets currently pending SError exceptions as well as related states of the vcpu. + +struct kvm_vcpu_events { + struct { + __u8 serror_pending; + __u8 serror_has_esr; + /* Align it to 4 bytes */ + __u8 pad[2]; + __u64 serror_esr; + } exception; +}; + 4.32 KVM_SET_VCPU_EVENTS Capability: KVM_CAP_VCPU_EVENTS Extended by: KVM_CAP_INTR_SHADOW -Architectures: x86 +Architectures: x86, arm, arm64 Type: vm ioctl Parameters: struct kvm_vcpu_event (in) Returns: 0 on success, -1 on error +X86: + Set pending exceptions, interrupts, and NMIs as well as related states of the vcpu. @@ -894,6 +912,12 @@ shall be written into the VCPU. KVM_VCPUEVENT_VALID_SMM can only be set if KVM_CAP_X86_SMM is available. +ARM, ARM64: + +Set pending SError exceptions as well as related states of the vcpu. + +See KVM_GET_VCPU_EVENTS for the data structure. + 4.33 KVM_GET_DEBUGREGS diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h index ef54013..d81621e 100644 --- a/arch/arm/include/asm/kvm_host.h +++ b/arch/arm/include/asm/kvm_host.h @@ -211,6 +211,12 @@ struct kvm_vcpu_stat { int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices); int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg); int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg); +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events); + +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events); + unsigned long kvm_call_hyp(void *hypfn, ...); void force_vm_exit(const cpumask_t *mask); diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c index 1e0784e..39f895d 100644 --- a/arch/arm/kvm/guest.c +++ b/arch/arm/kvm/guest.c @@ -248,6 +248,18 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu, return -EINVAL; } +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events) +{ + return -EINVAL; +} + +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events) +{ + return -EINVAL; +} + int __attribute_const__ kvm_target_cpu(void) { switch (read_cpuid_part()) { diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h index 413dc82..3294885 100644 --- a/arch/arm64/include/asm/kvm_emulate.h +++ b/arch/arm64/include/asm/kvm_emulate.h @@ -71,6 +71,11 @@ static inline void vcpu_set_hcr(struct kvm_vcpu *vcpu, unsigned long hcr) vcpu->arch.hcr_el2 = hcr; } +static inline unsigned long vcpu_get_vsesr(struct kvm_vcpu *vcpu) +{ + return vcpu->arch.vsesr_el2; +} + static inline void vcpu_set_vsesr(struct kvm_vcpu *vcpu, u64 vsesr) { vcpu->arch.vsesr_el2 = vsesr; diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h index a73f63a..1125540 100644 --- a/arch/arm64/include/asm/kvm_host.h +++ b/arch/arm64/include/asm/kvm_host.h @@ -326,6 +326,11 @@ struct kvm_vcpu_stat { int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices); int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg); int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg); +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events); + +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events); #define KVM_ARCH_WANT_MMU_NOTIFIER int kvm_unmap_hva(struct kvm *kvm, unsigned long hva); @@ -354,6 +359,8 @@ void handle_exit_early(struct kvm_vcpu *vcpu, struct kvm_run *run, int kvm_perf_init(void); int kvm_perf_teardown(void); +void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome); + struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr); static inline void __cpu_init_hyp_mode(phys_addr_t pgd_ptr, diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h index 9abbf30..855cc9a 100644 --- a/arch/arm64/include/uapi/asm/kvm.h +++ b/arch/arm64/include/uapi/asm/kvm.h @@ -39,6 +39,7 @@ #define __KVM_HAVE_GUEST_DEBUG #define __KVM_HAVE_IRQ_LINE #define __KVM_HAVE_READONLY_MEM +#define __KVM_HAVE_VCPU_EVENTS #define KVM_COALESCED_MMIO_PAGE_OFFSET 1 @@ -153,6 +154,17 @@ struct kvm_sync_regs { struct kvm_arch_memory_slot { }; +/* for KVM_GET/SET_VCPU_EVENTS */ +struct kvm_vcpu_events { + struct { + __u8 serror_pending; + __u8 serror_has_esr; + /* Align it to 4 bytes */ + __u8 pad[2]; + __u64 serror_esr; + } exception; +}; + /* If you need to interpret the index values, here is the key: */ #define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000 #define KVM_REG_ARM_COPROC_SHIFT 16 diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c index 5c7f657..42e1222 100644 --- a/arch/arm64/kvm/guest.c +++ b/arch/arm64/kvm/guest.c @@ -277,6 +277,37 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu, return -EINVAL; } +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events) +{ + events->exception.serror_pending = (vcpu_get_hcr(vcpu) & HCR_VSE); + events->exception.serror_has_esr = + cpus_have_const_cap(ARM64_HAS_RAS_EXTN) && + (!!vcpu_get_vsesr(vcpu)); + events->exception.serror_esr = vcpu_get_vsesr(vcpu); + + return 0; +} + +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events) +{ + bool injected = events->exception.serror_pending; + bool has_esr = events->exception.serror_has_esr; + + if (injected && has_esr) { + if (!cpus_have_const_cap(ARM64_HAS_RAS_EXTN)) + return -EINVAL; + + kvm_set_sei_esr(vcpu, events->exception.serror_esr); + + } else if (injected) { + kvm_inject_vabt(vcpu); + } + + return 0; +} + int __attribute_const__ kvm_target_cpu(void) { unsigned long implementor = read_cpuid_implementor(); diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c index 60666a0..aa0358a 100644 --- a/arch/arm64/kvm/inject_fault.c +++ b/arch/arm64/kvm/inject_fault.c @@ -166,7 +166,7 @@ void kvm_inject_undefined(struct kvm_vcpu *vcpu) static void pend_guest_serror(struct kvm_vcpu *vcpu, u64 esr) { - vcpu_set_vsesr(vcpu, esr); + vcpu_set_vsesr(vcpu, esr & ESR_ELx_ISS_MASK); vcpu_set_hcr(vcpu, vcpu_get_hcr(vcpu) | HCR_VSE); } @@ -186,3 +186,8 @@ void kvm_inject_vabt(struct kvm_vcpu *vcpu) { pend_guest_serror(vcpu, ESR_ELx_ISV); } + +void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome) +{ + pend_guest_serror(vcpu, syndrome); +} diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c index 38c8a64..20e919a 100644 --- a/arch/arm64/kvm/reset.c +++ b/arch/arm64/kvm/reset.c @@ -82,6 +82,7 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext) break; case KVM_CAP_SET_GUEST_DEBUG: case KVM_CAP_VCPU_ATTRIBUTES: + case KVM_CAP_VCPU_EVENTS: r = 1; break; default: diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c index 7e3941f..945655d 100644 --- a/virt/kvm/arm/arm.c +++ b/virt/kvm/arm/arm.c @@ -1051,6 +1051,27 @@ long kvm_arch_vcpu_ioctl(struct file *filp, return -EFAULT; return kvm_arm_vcpu_has_attr(vcpu, &attr); } + case KVM_GET_VCPU_EVENTS: { + struct kvm_vcpu_events events; + + memset(&events, 0, sizeof(struct kvm_vcpu_events)); + if (kvm_arm_vcpu_get_events(vcpu, &events)) + return -EINVAL; + + if (copy_to_user(argp, &events, sizeof(struct kvm_vcpu_events))) + return -EFAULT; + + return 0; + } + case KVM_SET_VCPU_EVENTS: { + struct kvm_vcpu_events events; + + if (copy_from_user(&events, argp, + sizeof(struct kvm_vcpu_events))) + return -EFAULT; + + return kvm_arm_vcpu_set_events(vcpu, &events); + } default: return -EINVAL; } -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v11 2/4] arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS @ 2018-04-09 21:36 ` Dongjiu Geng 0 siblings, 0 replies; 58+ messages in thread From: Dongjiu Geng @ 2018-04-09 21:36 UTC (permalink / raw) To: rkrcmar, corbet, christoffer.dall, marc.zyngier, james.morse, linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel Cc: gengdongjiu, huangshaoyu, zhengxiang9 This new IOCTL exports user-invisible states related to SError. Together with appropriate user space changes, it can inject SError with specified syndrome to guest by setup kvm_vcpu_events value. Also it can support live migration. Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com> Change since V10: Address James's comments, thanks James 1. Merge the helper function with the user. 2. Move the ISS_MASK into pend_guest_serror() to clear top bits 3. Make kvm_vcpu_events struct align to 4 bytes 4. Add something check in the kvm_arm_vcpu_set_events() 5. Check kvm_arm_vcpu_get/set_events()'s return value. 6. Initialise kvm_vcpu_events to 0 so that padding transferred to user-space doesn't contain kernel stack. --- Documentation/virtual/kvm/api.txt | 28 ++++++++++++++++++++++++++-- arch/arm/include/asm/kvm_host.h | 6 ++++++ arch/arm/kvm/guest.c | 12 ++++++++++++ arch/arm64/include/asm/kvm_emulate.h | 5 +++++ arch/arm64/include/asm/kvm_host.h | 7 +++++++ arch/arm64/include/uapi/asm/kvm.h | 12 ++++++++++++ arch/arm64/kvm/guest.c | 31 +++++++++++++++++++++++++++++++ arch/arm64/kvm/inject_fault.c | 7 ++++++- arch/arm64/kvm/reset.c | 1 + virt/kvm/arm/arm.c | 21 +++++++++++++++++++++ 10 files changed, 127 insertions(+), 3 deletions(-) diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index 8a3d708..45719b4 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -819,11 +819,13 @@ struct kvm_clock_data { Capability: KVM_CAP_VCPU_EVENTS Extended by: KVM_CAP_INTR_SHADOW -Architectures: x86 +Architectures: x86, arm, arm64 Type: vm ioctl Parameters: struct kvm_vcpu_event (out) Returns: 0 on success, -1 on error +X86: + Gets currently pending exceptions, interrupts, and NMIs as well as related states of the vcpu. @@ -865,15 +867,31 @@ Only two fields are defined in the flags field: - KVM_VCPUEVENT_VALID_SMM may be set in the flags field to signal that smi contains a valid state. +ARM, ARM64: + +Gets currently pending SError exceptions as well as related states of the vcpu. + +struct kvm_vcpu_events { + struct { + __u8 serror_pending; + __u8 serror_has_esr; + /* Align it to 4 bytes */ + __u8 pad[2]; + __u64 serror_esr; + } exception; +}; + 4.32 KVM_SET_VCPU_EVENTS Capability: KVM_CAP_VCPU_EVENTS Extended by: KVM_CAP_INTR_SHADOW -Architectures: x86 +Architectures: x86, arm, arm64 Type: vm ioctl Parameters: struct kvm_vcpu_event (in) Returns: 0 on success, -1 on error +X86: + Set pending exceptions, interrupts, and NMIs as well as related states of the vcpu. @@ -894,6 +912,12 @@ shall be written into the VCPU. KVM_VCPUEVENT_VALID_SMM can only be set if KVM_CAP_X86_SMM is available. +ARM, ARM64: + +Set pending SError exceptions as well as related states of the vcpu. + +See KVM_GET_VCPU_EVENTS for the data structure. + 4.33 KVM_GET_DEBUGREGS diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h index ef54013..d81621e 100644 --- a/arch/arm/include/asm/kvm_host.h +++ b/arch/arm/include/asm/kvm_host.h @@ -211,6 +211,12 @@ struct kvm_vcpu_stat { int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices); int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg); int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg); +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events); + +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events); + unsigned long kvm_call_hyp(void *hypfn, ...); void force_vm_exit(const cpumask_t *mask); diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c index 1e0784e..39f895d 100644 --- a/arch/arm/kvm/guest.c +++ b/arch/arm/kvm/guest.c @@ -248,6 +248,18 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu, return -EINVAL; } +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events) +{ + return -EINVAL; +} + +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events) +{ + return -EINVAL; +} + int __attribute_const__ kvm_target_cpu(void) { switch (read_cpuid_part()) { diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h index 413dc82..3294885 100644 --- a/arch/arm64/include/asm/kvm_emulate.h +++ b/arch/arm64/include/asm/kvm_emulate.h @@ -71,6 +71,11 @@ static inline void vcpu_set_hcr(struct kvm_vcpu *vcpu, unsigned long hcr) vcpu->arch.hcr_el2 = hcr; } +static inline unsigned long vcpu_get_vsesr(struct kvm_vcpu *vcpu) +{ + return vcpu->arch.vsesr_el2; +} + static inline void vcpu_set_vsesr(struct kvm_vcpu *vcpu, u64 vsesr) { vcpu->arch.vsesr_el2 = vsesr; diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h index a73f63a..1125540 100644 --- a/arch/arm64/include/asm/kvm_host.h +++ b/arch/arm64/include/asm/kvm_host.h @@ -326,6 +326,11 @@ struct kvm_vcpu_stat { int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices); int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg); int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg); +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events); + +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events); #define KVM_ARCH_WANT_MMU_NOTIFIER int kvm_unmap_hva(struct kvm *kvm, unsigned long hva); @@ -354,6 +359,8 @@ void handle_exit_early(struct kvm_vcpu *vcpu, struct kvm_run *run, int kvm_perf_init(void); int kvm_perf_teardown(void); +void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome); + struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr); static inline void __cpu_init_hyp_mode(phys_addr_t pgd_ptr, diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h index 9abbf30..855cc9a 100644 --- a/arch/arm64/include/uapi/asm/kvm.h +++ b/arch/arm64/include/uapi/asm/kvm.h @@ -39,6 +39,7 @@ #define __KVM_HAVE_GUEST_DEBUG #define __KVM_HAVE_IRQ_LINE #define __KVM_HAVE_READONLY_MEM +#define __KVM_HAVE_VCPU_EVENTS #define KVM_COALESCED_MMIO_PAGE_OFFSET 1 @@ -153,6 +154,17 @@ struct kvm_sync_regs { struct kvm_arch_memory_slot { }; +/* for KVM_GET/SET_VCPU_EVENTS */ +struct kvm_vcpu_events { + struct { + __u8 serror_pending; + __u8 serror_has_esr; + /* Align it to 4 bytes */ + __u8 pad[2]; + __u64 serror_esr; + } exception; +}; + /* If you need to interpret the index values, here is the key: */ #define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000 #define KVM_REG_ARM_COPROC_SHIFT 16 diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c index 5c7f657..42e1222 100644 --- a/arch/arm64/kvm/guest.c +++ b/arch/arm64/kvm/guest.c @@ -277,6 +277,37 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu, return -EINVAL; } +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events) +{ + events->exception.serror_pending = (vcpu_get_hcr(vcpu) & HCR_VSE); + events->exception.serror_has_esr = + cpus_have_const_cap(ARM64_HAS_RAS_EXTN) && + (!!vcpu_get_vsesr(vcpu)); + events->exception.serror_esr = vcpu_get_vsesr(vcpu); + + return 0; +} + +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu, + struct kvm_vcpu_events *events) +{ + bool injected = events->exception.serror_pending; + bool has_esr = events->exception.serror_has_esr; + + if (injected && has_esr) { + if (!cpus_have_const_cap(ARM64_HAS_RAS_EXTN)) + return -EINVAL; + + kvm_set_sei_esr(vcpu, events->exception.serror_esr); + + } else if (injected) { + kvm_inject_vabt(vcpu); + } + + return 0; +} + int __attribute_const__ kvm_target_cpu(void) { unsigned long implementor = read_cpuid_implementor(); diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c index 60666a0..aa0358a 100644 --- a/arch/arm64/kvm/inject_fault.c +++ b/arch/arm64/kvm/inject_fault.c @@ -166,7 +166,7 @@ void kvm_inject_undefined(struct kvm_vcpu *vcpu) static void pend_guest_serror(struct kvm_vcpu *vcpu, u64 esr) { - vcpu_set_vsesr(vcpu, esr); + vcpu_set_vsesr(vcpu, esr & ESR_ELx_ISS_MASK); vcpu_set_hcr(vcpu, vcpu_get_hcr(vcpu) | HCR_VSE); } @@ -186,3 +186,8 @@ void kvm_inject_vabt(struct kvm_vcpu *vcpu) { pend_guest_serror(vcpu, ESR_ELx_ISV); } + +void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome) +{ + pend_guest_serror(vcpu, syndrome); +} diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c index 38c8a64..20e919a 100644 --- a/arch/arm64/kvm/reset.c +++ b/arch/arm64/kvm/reset.c @@ -82,6 +82,7 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext) break; case KVM_CAP_SET_GUEST_DEBUG: case KVM_CAP_VCPU_ATTRIBUTES: + case KVM_CAP_VCPU_EVENTS: r = 1; break; default: diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c index 7e3941f..945655d 100644 --- a/virt/kvm/arm/arm.c +++ b/virt/kvm/arm/arm.c @@ -1051,6 +1051,27 @@ long kvm_arch_vcpu_ioctl(struct file *filp, return -EFAULT; return kvm_arm_vcpu_has_attr(vcpu, &attr); } + case KVM_GET_VCPU_EVENTS: { + struct kvm_vcpu_events events; + + memset(&events, 0, sizeof(struct kvm_vcpu_events)); + if (kvm_arm_vcpu_get_events(vcpu, &events)) + return -EINVAL; + + if (copy_to_user(argp, &events, sizeof(struct kvm_vcpu_events))) + return -EFAULT; + + return 0; + } + case KVM_SET_VCPU_EVENTS: { + struct kvm_vcpu_events events; + + if (copy_from_user(&events, argp, + sizeof(struct kvm_vcpu_events))) + return -EFAULT; + + return kvm_arm_vcpu_set_events(vcpu, &events); + } default: return -EINVAL; } -- 1.9.1 ^ permalink raw reply related [flat|nested] 58+ messages in thread
* Re: [PATCH v11 2/4] arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS 2018-04-09 21:36 ` Dongjiu Geng (?) (?) @ 2018-04-10 14:15 ` James Morse -1 siblings, 0 replies; 58+ messages in thread From: James Morse @ 2018-04-10 14:15 UTC (permalink / raw) To: Dongjiu Geng, devel Cc: rkrcmar, corbet, christoffer.dall, marc.zyngier, linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, huangshaoyu, zhengxiang9 Hi Dongjiu Geng, On 09/04/18 22:36, Dongjiu Geng wrote: > This new IOCTL exports user-invisible states related to SError. > Together with appropriate user space changes, it can inject > SError with specified syndrome to guest by setup kvm_vcpu_events > value. > Also it can support live migration. Could you explain what user-space is expected to do for this? (this is also relevant for snapshot-ing/suspending VMs) It's probably worth noting that this solves an existing problem: KVM may make an SError pending, but user-space has no way to discover/migrate this. > diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt > index 8a3d708..45719b4 100644 > --- a/Documentation/virtual/kvm/api.txt > +++ b/Documentation/virtual/kvm/api.txt > @@ -819,11 +819,13 @@ struct kvm_clock_data { > > Capability: KVM_CAP_VCPU_EVENTS > Extended by: KVM_CAP_INTR_SHADOW > -Architectures: x86 > +Architectures: x86, arm, arm64 > Type: vm ioctl > Parameters: struct kvm_vcpu_event (out) > Returns: 0 on success, -1 on error > > +X86: > + > Gets currently pending exceptions, interrupts, and NMIs as well as related > states of the vcpu. > > @@ -865,15 +867,31 @@ Only two fields are defined in the flags field: > - KVM_VCPUEVENT_VALID_SMM may be set in the flags field to signal that > smi contains a valid state. > > +ARM, ARM64: > + > +Gets currently pending SError exceptions as well as related states of the vcpu. > + > +struct kvm_vcpu_events { > + struct { > + __u8 serror_pending; > + __u8 serror_has_esr; > + /* Align it to 4 bytes */ > + __u8 pad[2]; > + __u64 serror_esr; > + } exception; > +}; > + I'm not convinced we should change this struct from the layout/size x86 has. Its confusing for the documentation, is this API call really the same on all architectures? What if we want to add some future interrupt, NMI or related state? We've found ourselves needing to add this API, it seems odd to remove its other uses on x86. We can't put them back in the future. Having a different layout would force user-space to ifdef/duplicate any code that accesses this between architectures. The compiler will want that __u64 to be naturally aligned to 8-bytes, so your 4-byte padding still causes some secret compiler-padding to be inserted. Different versions of the compiler may put it in different places. > 4.32 KVM_SET_VCPU_EVENTS > > Capability: KVM_CAP_VCPU_EVENTS > Extended by: KVM_CAP_INTR_SHADOW > -Architectures: x86 > +Architectures: x86, arm, arm64 > Type: vm ioctl > Parameters: struct kvm_vcpu_event (in) > Returns: 0 on success, -1 on error > > +X86: > + > Set pending exceptions, interrupts, and NMIs as well as related states of the > vcpu. > > @@ -894,6 +912,12 @@ shall be written into the VCPU. > > KVM_VCPUEVENT_VALID_SMM can only be set if KVM_CAP_X86_SMM is available. > > +ARM, ARM64: > + > +Set pending SError exceptions as well as related states of the vcpu. > + > +See KVM_GET_VCPU_EVENTS for the data structure. > + > > 4.33 KVM_GET_DEBUGREGS > > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h > index 9abbf30..855cc9a 100644 > --- a/arch/arm64/include/uapi/asm/kvm.h > +++ b/arch/arm64/include/uapi/asm/kvm.h > @@ -39,6 +39,7 @@ > #define __KVM_HAVE_GUEST_DEBUG > #define __KVM_HAVE_IRQ_LINE > #define __KVM_HAVE_READONLY_MEM > +#define __KVM_HAVE_VCPU_EVENTS > > #define KVM_COALESCED_MMIO_PAGE_OFFSET 1 > > @@ -153,6 +154,17 @@ struct kvm_sync_regs { > struct kvm_arch_memory_slot { > }; > > +/* for KVM_GET/SET_VCPU_EVENTS */ > +struct kvm_vcpu_events { > + struct { > + __u8 serror_pending; > + __u8 serror_has_esr; > + /* Align it to 4 bytes */ > + __u8 pad[2]; (padding noted above) > + __u64 serror_esr; > + } exception; > +}; > + > /* If you need to interpret the index values, here is the key: */ > #define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000 > #define KVM_REG_ARM_COPROC_SHIFT 16 > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c > index 5c7f657..42e1222 100644 > --- a/arch/arm64/kvm/guest.c > +++ b/arch/arm64/kvm/guest.c > @@ -277,6 +277,37 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu, > return -EINVAL; > } > > +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu, > + struct kvm_vcpu_events *events) > +{ > + events->exception.serror_pending = (vcpu_get_hcr(vcpu) & HCR_VSE); > + events->exception.serror_has_esr = > + cpus_have_const_cap(ARM64_HAS_RAS_EXTN) && > + (!!vcpu_get_vsesr(vcpu)); > + events->exception.serror_esr = vcpu_get_vsesr(vcpu); This will return a stale ESR even if nothing is pending. On systems without the RAS extensions it will return 'ESR_ELx_ISV' if kvm_inject_vabt() has ever been called for this CPU. Could we hide this behind (pending && has_esr), setting it to 0 otherwise. This is just to avoid exposing the stale value. > + > + return 0; > +} > +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu, > + struct kvm_vcpu_events *events) > +{ > + bool injected = events->exception.serror_pending; > + bool has_esr = events->exception.serror_has_esr; > + > + if (injected && has_esr) { > + if (!cpus_have_const_cap(ARM64_HAS_RAS_EXTN)) > + return -EINVAL; > + > + kvm_set_sei_esr(vcpu, events->exception.serror_esr); > + > + } else if (injected) { > + kvm_inject_vabt(vcpu); Nit: looks like 'injected' is misnamed. > + } > + > + return 0; > +} > + > int __attribute_const__ kvm_target_cpu(void) > { > unsigned long implementor = read_cpuid_implementor(); > diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c > index 38c8a64..20e919a 100644 > --- a/arch/arm64/kvm/reset.c > +++ b/arch/arm64/kvm/reset.c > @@ -82,6 +82,7 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext) > break; > case KVM_CAP_SET_GUEST_DEBUG: > case KVM_CAP_VCPU_ATTRIBUTES: > + case KVM_CAP_VCPU_EVENTS: > r = 1; > break; > default: > diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c > index 7e3941f..945655d 100644 > --- a/virt/kvm/arm/arm.c > +++ b/virt/kvm/arm/arm.c > @@ -1051,6 +1051,27 @@ long kvm_arch_vcpu_ioctl(struct file *filp, > return -EFAULT; > return kvm_arm_vcpu_has_attr(vcpu, &attr); > } > + case KVM_GET_VCPU_EVENTS: { > + struct kvm_vcpu_events events; > + > + memset(&events, 0, sizeof(struct kvm_vcpu_events)); sizeof(events) is the normal style here, it means if someone changes event's type we don't get any surprises... > + if (kvm_arm_vcpu_get_events(vcpu, &events)) > + return -EINVAL; > + > + if (copy_to_user(argp, &events, sizeof(struct kvm_vcpu_events))) sizeof(events) > + return -EFAULT; > + > + return 0; > + } > + case KVM_SET_VCPU_EVENTS: { > + struct kvm_vcpu_events events; > + > + if (copy_from_user(&events, argp, > + sizeof(struct kvm_vcpu_events))) > + return -EFAULT; > + > + return kvm_arm_vcpu_set_events(vcpu, &events); > + } > default: > return -EINVAL; > } > Despite KVM_CAP_VCPU_EVENTS not being advertised on 32bit, any attempt to call it will still end up in here, but will always fail as the {g,s}et_events() calls always return -EINVAL. I don't think this will cause us any problems. Thanks, James ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [Devel] [PATCH v11 2/4] arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS @ 2018-04-10 14:15 ` James Morse 0 siblings, 0 replies; 58+ messages in thread From: James Morse @ 2018-04-10 14:15 UTC (permalink / raw) To: devel [-- Attachment #1: Type: text/plain, Size: 7459 bytes --] Hi Dongjiu Geng, On 09/04/18 22:36, Dongjiu Geng wrote: > This new IOCTL exports user-invisible states related to SError. > Together with appropriate user space changes, it can inject > SError with specified syndrome to guest by setup kvm_vcpu_events > value. > Also it can support live migration. Could you explain what user-space is expected to do for this? (this is also relevant for snapshot-ing/suspending VMs) It's probably worth noting that this solves an existing problem: KVM may make an SError pending, but user-space has no way to discover/migrate this. > diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt > index 8a3d708..45719b4 100644 > --- a/Documentation/virtual/kvm/api.txt > +++ b/Documentation/virtual/kvm/api.txt > @@ -819,11 +819,13 @@ struct kvm_clock_data { > > Capability: KVM_CAP_VCPU_EVENTS > Extended by: KVM_CAP_INTR_SHADOW > -Architectures: x86 > +Architectures: x86, arm, arm64 > Type: vm ioctl > Parameters: struct kvm_vcpu_event (out) > Returns: 0 on success, -1 on error > > +X86: > + > Gets currently pending exceptions, interrupts, and NMIs as well as related > states of the vcpu. > > @@ -865,15 +867,31 @@ Only two fields are defined in the flags field: > - KVM_VCPUEVENT_VALID_SMM may be set in the flags field to signal that > smi contains a valid state. > > +ARM, ARM64: > + > +Gets currently pending SError exceptions as well as related states of the vcpu. > + > +struct kvm_vcpu_events { > + struct { > + __u8 serror_pending; > + __u8 serror_has_esr; > + /* Align it to 4 bytes */ > + __u8 pad[2]; > + __u64 serror_esr; > + } exception; > +}; > + I'm not convinced we should change this struct from the layout/size x86 has. Its confusing for the documentation, is this API call really the same on all architectures? What if we want to add some future interrupt, NMI or related state? We've found ourselves needing to add this API, it seems odd to remove its other uses on x86. We can't put them back in the future. Having a different layout would force user-space to ifdef/duplicate any code that accesses this between architectures. The compiler will want that __u64 to be naturally aligned to 8-bytes, so your 4-byte padding still causes some secret compiler-padding to be inserted. Different versions of the compiler may put it in different places. > 4.32 KVM_SET_VCPU_EVENTS > > Capability: KVM_CAP_VCPU_EVENTS > Extended by: KVM_CAP_INTR_SHADOW > -Architectures: x86 > +Architectures: x86, arm, arm64 > Type: vm ioctl > Parameters: struct kvm_vcpu_event (in) > Returns: 0 on success, -1 on error > > +X86: > + > Set pending exceptions, interrupts, and NMIs as well as related states of the > vcpu. > > @@ -894,6 +912,12 @@ shall be written into the VCPU. > > KVM_VCPUEVENT_VALID_SMM can only be set if KVM_CAP_X86_SMM is available. > > +ARM, ARM64: > + > +Set pending SError exceptions as well as related states of the vcpu. > + > +See KVM_GET_VCPU_EVENTS for the data structure. > + > > 4.33 KVM_GET_DEBUGREGS > > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h > index 9abbf30..855cc9a 100644 > --- a/arch/arm64/include/uapi/asm/kvm.h > +++ b/arch/arm64/include/uapi/asm/kvm.h > @@ -39,6 +39,7 @@ > #define __KVM_HAVE_GUEST_DEBUG > #define __KVM_HAVE_IRQ_LINE > #define __KVM_HAVE_READONLY_MEM > +#define __KVM_HAVE_VCPU_EVENTS > > #define KVM_COALESCED_MMIO_PAGE_OFFSET 1 > > @@ -153,6 +154,17 @@ struct kvm_sync_regs { > struct kvm_arch_memory_slot { > }; > > +/* for KVM_GET/SET_VCPU_EVENTS */ > +struct kvm_vcpu_events { > + struct { > + __u8 serror_pending; > + __u8 serror_has_esr; > + /* Align it to 4 bytes */ > + __u8 pad[2]; (padding noted above) > + __u64 serror_esr; > + } exception; > +}; > + > /* If you need to interpret the index values, here is the key: */ > #define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000 > #define KVM_REG_ARM_COPROC_SHIFT 16 > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c > index 5c7f657..42e1222 100644 > --- a/arch/arm64/kvm/guest.c > +++ b/arch/arm64/kvm/guest.c > @@ -277,6 +277,37 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu, > return -EINVAL; > } > > +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu, > + struct kvm_vcpu_events *events) > +{ > + events->exception.serror_pending = (vcpu_get_hcr(vcpu) & HCR_VSE); > + events->exception.serror_has_esr = > + cpus_have_const_cap(ARM64_HAS_RAS_EXTN) && > + (!!vcpu_get_vsesr(vcpu)); > + events->exception.serror_esr = vcpu_get_vsesr(vcpu); This will return a stale ESR even if nothing is pending. On systems without the RAS extensions it will return 'ESR_ELx_ISV' if kvm_inject_vabt() has ever been called for this CPU. Could we hide this behind (pending && has_esr), setting it to 0 otherwise. This is just to avoid exposing the stale value. > + > + return 0; > +} > +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu, > + struct kvm_vcpu_events *events) > +{ > + bool injected = events->exception.serror_pending; > + bool has_esr = events->exception.serror_has_esr; > + > + if (injected && has_esr) { > + if (!cpus_have_const_cap(ARM64_HAS_RAS_EXTN)) > + return -EINVAL; > + > + kvm_set_sei_esr(vcpu, events->exception.serror_esr); > + > + } else if (injected) { > + kvm_inject_vabt(vcpu); Nit: looks like 'injected' is misnamed. > + } > + > + return 0; > +} > + > int __attribute_const__ kvm_target_cpu(void) > { > unsigned long implementor = read_cpuid_implementor(); > diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c > index 38c8a64..20e919a 100644 > --- a/arch/arm64/kvm/reset.c > +++ b/arch/arm64/kvm/reset.c > @@ -82,6 +82,7 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext) > break; > case KVM_CAP_SET_GUEST_DEBUG: > case KVM_CAP_VCPU_ATTRIBUTES: > + case KVM_CAP_VCPU_EVENTS: > r = 1; > break; > default: > diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c > index 7e3941f..945655d 100644 > --- a/virt/kvm/arm/arm.c > +++ b/virt/kvm/arm/arm.c > @@ -1051,6 +1051,27 @@ long kvm_arch_vcpu_ioctl(struct file *filp, > return -EFAULT; > return kvm_arm_vcpu_has_attr(vcpu, &attr); > } > + case KVM_GET_VCPU_EVENTS: { > + struct kvm_vcpu_events events; > + > + memset(&events, 0, sizeof(struct kvm_vcpu_events)); sizeof(events) is the normal style here, it means if someone changes event's type we don't get any surprises... > + if (kvm_arm_vcpu_get_events(vcpu, &events)) > + return -EINVAL; > + > + if (copy_to_user(argp, &events, sizeof(struct kvm_vcpu_events))) sizeof(events) > + return -EFAULT; > + > + return 0; > + } > + case KVM_SET_VCPU_EVENTS: { > + struct kvm_vcpu_events events; > + > + if (copy_from_user(&events, argp, > + sizeof(struct kvm_vcpu_events))) > + return -EFAULT; > + > + return kvm_arm_vcpu_set_events(vcpu, &events); > + } > default: > return -EINVAL; > } > Despite KVM_CAP_VCPU_EVENTS not being advertised on 32bit, any attempt to call it will still end up in here, but will always fail as the {g,s}et_events() calls always return -EINVAL. I don't think this will cause us any problems. Thanks, James ^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v11 2/4] arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS @ 2018-04-10 14:15 ` James Morse 0 siblings, 0 replies; 58+ messages in thread From: James Morse @ 2018-04-10 14:15 UTC (permalink / raw) To: linux-arm-kernel Hi Dongjiu Geng, On 09/04/18 22:36, Dongjiu Geng wrote: > This new IOCTL exports user-invisible states related to SError. > Together with appropriate user space changes, it can inject > SError with specified syndrome to guest by setup kvm_vcpu_events > value. > Also it can support live migration. Could you explain what user-space is expected to do for this? (this is also relevant for snapshot-ing/suspending VMs) It's probably worth noting that this solves an existing problem: KVM may make an SError pending, but user-space has no way to discover/migrate this. > diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt > index 8a3d708..45719b4 100644 > --- a/Documentation/virtual/kvm/api.txt > +++ b/Documentation/virtual/kvm/api.txt > @@ -819,11 +819,13 @@ struct kvm_clock_data { > > Capability: KVM_CAP_VCPU_EVENTS > Extended by: KVM_CAP_INTR_SHADOW > -Architectures: x86 > +Architectures: x86, arm, arm64 > Type: vm ioctl > Parameters: struct kvm_vcpu_event (out) > Returns: 0 on success, -1 on error > > +X86: > + > Gets currently pending exceptions, interrupts, and NMIs as well as related > states of the vcpu. > > @@ -865,15 +867,31 @@ Only two fields are defined in the flags field: > - KVM_VCPUEVENT_VALID_SMM may be set in the flags field to signal that > smi contains a valid state. > > +ARM, ARM64: > + > +Gets currently pending SError exceptions as well as related states of the vcpu. > + > +struct kvm_vcpu_events { > + struct { > + __u8 serror_pending; > + __u8 serror_has_esr; > + /* Align it to 4 bytes */ > + __u8 pad[2]; > + __u64 serror_esr; > + } exception; > +}; > + I'm not convinced we should change this struct from the layout/size x86 has. Its confusing for the documentation, is this API call really the same on all architectures? What if we want to add some future interrupt, NMI or related state? We've found ourselves needing to add this API, it seems odd to remove its other uses on x86. We can't put them back in the future. Having a different layout would force user-space to ifdef/duplicate any code that accesses this between architectures. The compiler will want that __u64 to be naturally aligned to 8-bytes, so your 4-byte padding still causes some secret compiler-padding to be inserted. Different versions of the compiler may put it in different places. > 4.32 KVM_SET_VCPU_EVENTS > > Capability: KVM_CAP_VCPU_EVENTS > Extended by: KVM_CAP_INTR_SHADOW > -Architectures: x86 > +Architectures: x86, arm, arm64 > Type: vm ioctl > Parameters: struct kvm_vcpu_event (in) > Returns: 0 on success, -1 on error > > +X86: > + > Set pending exceptions, interrupts, and NMIs as well as related states of the > vcpu. > > @@ -894,6 +912,12 @@ shall be written into the VCPU. > > KVM_VCPUEVENT_VALID_SMM can only be set if KVM_CAP_X86_SMM is available. > > +ARM, ARM64: > + > +Set pending SError exceptions as well as related states of the vcpu. > + > +See KVM_GET_VCPU_EVENTS for the data structure. > + > > 4.33 KVM_GET_DEBUGREGS > > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h > index 9abbf30..855cc9a 100644 > --- a/arch/arm64/include/uapi/asm/kvm.h > +++ b/arch/arm64/include/uapi/asm/kvm.h > @@ -39,6 +39,7 @@ > #define __KVM_HAVE_GUEST_DEBUG > #define __KVM_HAVE_IRQ_LINE > #define __KVM_HAVE_READONLY_MEM > +#define __KVM_HAVE_VCPU_EVENTS > > #define KVM_COALESCED_MMIO_PAGE_OFFSET 1 > > @@ -153,6 +154,17 @@ struct kvm_sync_regs { > struct kvm_arch_memory_slot { > }; > > +/* for KVM_GET/SET_VCPU_EVENTS */ > +struct kvm_vcpu_events { > + struct { > + __u8 serror_pending; > + __u8 serror_has_esr; > + /* Align it to 4 bytes */ > + __u8 pad[2]; (padding noted above) > + __u64 serror_esr; > + } exception; > +}; > + > /* If you need to interpret the index values, here is the key: */ > #define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000 > #define KVM_REG_ARM_COPROC_SHIFT 16 > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c > index 5c7f657..42e1222 100644 > --- a/arch/arm64/kvm/guest.c > +++ b/arch/arm64/kvm/guest.c > @@ -277,6 +277,37 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu, > return -EINVAL; > } > > +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu, > + struct kvm_vcpu_events *events) > +{ > + events->exception.serror_pending = (vcpu_get_hcr(vcpu) & HCR_VSE); > + events->exception.serror_has_esr = > + cpus_have_const_cap(ARM64_HAS_RAS_EXTN) && > + (!!vcpu_get_vsesr(vcpu)); > + events->exception.serror_esr = vcpu_get_vsesr(vcpu); This will return a stale ESR even if nothing is pending. On systems without the RAS extensions it will return 'ESR_ELx_ISV' if kvm_inject_vabt() has ever been called for this CPU. Could we hide this behind (pending && has_esr), setting it to 0 otherwise. This is just to avoid exposing the stale value. > + > + return 0; > +} > +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu, > + struct kvm_vcpu_events *events) > +{ > + bool injected = events->exception.serror_pending; > + bool has_esr = events->exception.serror_has_esr; > + > + if (injected && has_esr) { > + if (!cpus_have_const_cap(ARM64_HAS_RAS_EXTN)) > + return -EINVAL; > + > + kvm_set_sei_esr(vcpu, events->exception.serror_esr); > + > + } else if (injected) { > + kvm_inject_vabt(vcpu); Nit: looks like 'injected' is misnamed. > + } > + > + return 0; > +} > + > int __attribute_const__ kvm_target_cpu(void) > { > unsigned long implementor = read_cpuid_implementor(); > diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c > index 38c8a64..20e919a 100644 > --- a/arch/arm64/kvm/reset.c > +++ b/arch/arm64/kvm/reset.c > @@ -82,6 +82,7 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext) > break; > case KVM_CAP_SET_GUEST_DEBUG: > case KVM_CAP_VCPU_ATTRIBUTES: > + case KVM_CAP_VCPU_EVENTS: > r = 1; > break; > default: > diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c > index 7e3941f..945655d 100644 > --- a/virt/kvm/arm/arm.c > +++ b/virt/kvm/arm/arm.c > @@ -1051,6 +1051,27 @@ long kvm_arch_vcpu_ioctl(struct file *filp, > return -EFAULT; > return kvm_arm_vcpu_has_attr(vcpu, &attr); > } > + case KVM_GET_VCPU_EVENTS: { > + struct kvm_vcpu_events events; > + > + memset(&events, 0, sizeof(struct kvm_vcpu_events)); sizeof(events) is the normal style here, it means if someone changes event's type we don't get any surprises... > + if (kvm_arm_vcpu_get_events(vcpu, &events)) > + return -EINVAL; > + > + if (copy_to_user(argp, &events, sizeof(struct kvm_vcpu_events))) sizeof(events) > + return -EFAULT; > + > + return 0; > + } > + case KVM_SET_VCPU_EVENTS: { > + struct kvm_vcpu_events events; > + > + if (copy_from_user(&events, argp, > + sizeof(struct kvm_vcpu_events))) > + return -EFAULT; > + > + return kvm_arm_vcpu_set_events(vcpu, &events); > + } > default: > return -EINVAL; > } > Despite KVM_CAP_VCPU_EVENTS not being advertised on 32bit, any attempt to call it will still end up in here, but will always fail as the {g,s}et_events() calls always return -EINVAL. I don't think this will cause us any problems. Thanks, James ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v11 2/4] arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS @ 2018-04-10 14:15 ` James Morse 0 siblings, 0 replies; 58+ messages in thread From: James Morse @ 2018-04-10 14:15 UTC (permalink / raw) To: Dongjiu Geng, devel Cc: rkrcmar, corbet, christoffer.dall, marc.zyngier, linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, huangshaoyu, zhengxiang9 Hi Dongjiu Geng, On 09/04/18 22:36, Dongjiu Geng wrote: > This new IOCTL exports user-invisible states related to SError. > Together with appropriate user space changes, it can inject > SError with specified syndrome to guest by setup kvm_vcpu_events > value. > Also it can support live migration. Could you explain what user-space is expected to do for this? (this is also relevant for snapshot-ing/suspending VMs) It's probably worth noting that this solves an existing problem: KVM may make an SError pending, but user-space has no way to discover/migrate this. > diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt > index 8a3d708..45719b4 100644 > --- a/Documentation/virtual/kvm/api.txt > +++ b/Documentation/virtual/kvm/api.txt > @@ -819,11 +819,13 @@ struct kvm_clock_data { > > Capability: KVM_CAP_VCPU_EVENTS > Extended by: KVM_CAP_INTR_SHADOW > -Architectures: x86 > +Architectures: x86, arm, arm64 > Type: vm ioctl > Parameters: struct kvm_vcpu_event (out) > Returns: 0 on success, -1 on error > > +X86: > + > Gets currently pending exceptions, interrupts, and NMIs as well as related > states of the vcpu. > > @@ -865,15 +867,31 @@ Only two fields are defined in the flags field: > - KVM_VCPUEVENT_VALID_SMM may be set in the flags field to signal that > smi contains a valid state. > > +ARM, ARM64: > + > +Gets currently pending SError exceptions as well as related states of the vcpu. > + > +struct kvm_vcpu_events { > + struct { > + __u8 serror_pending; > + __u8 serror_has_esr; > + /* Align it to 4 bytes */ > + __u8 pad[2]; > + __u64 serror_esr; > + } exception; > +}; > + I'm not convinced we should change this struct from the layout/size x86 has. Its confusing for the documentation, is this API call really the same on all architectures? What if we want to add some future interrupt, NMI or related state? We've found ourselves needing to add this API, it seems odd to remove its other uses on x86. We can't put them back in the future. Having a different layout would force user-space to ifdef/duplicate any code that accesses this between architectures. The compiler will want that __u64 to be naturally aligned to 8-bytes, so your 4-byte padding still causes some secret compiler-padding to be inserted. Different versions of the compiler may put it in different places. > 4.32 KVM_SET_VCPU_EVENTS > > Capability: KVM_CAP_VCPU_EVENTS > Extended by: KVM_CAP_INTR_SHADOW > -Architectures: x86 > +Architectures: x86, arm, arm64 > Type: vm ioctl > Parameters: struct kvm_vcpu_event (in) > Returns: 0 on success, -1 on error > > +X86: > + > Set pending exceptions, interrupts, and NMIs as well as related states of the > vcpu. > > @@ -894,6 +912,12 @@ shall be written into the VCPU. > > KVM_VCPUEVENT_VALID_SMM can only be set if KVM_CAP_X86_SMM is available. > > +ARM, ARM64: > + > +Set pending SError exceptions as well as related states of the vcpu. > + > +See KVM_GET_VCPU_EVENTS for the data structure. > + > > 4.33 KVM_GET_DEBUGREGS > > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h > index 9abbf30..855cc9a 100644 > --- a/arch/arm64/include/uapi/asm/kvm.h > +++ b/arch/arm64/include/uapi/asm/kvm.h > @@ -39,6 +39,7 @@ > #define __KVM_HAVE_GUEST_DEBUG > #define __KVM_HAVE_IRQ_LINE > #define __KVM_HAVE_READONLY_MEM > +#define __KVM_HAVE_VCPU_EVENTS > > #define KVM_COALESCED_MMIO_PAGE_OFFSET 1 > > @@ -153,6 +154,17 @@ struct kvm_sync_regs { > struct kvm_arch_memory_slot { > }; > > +/* for KVM_GET/SET_VCPU_EVENTS */ > +struct kvm_vcpu_events { > + struct { > + __u8 serror_pending; > + __u8 serror_has_esr; > + /* Align it to 4 bytes */ > + __u8 pad[2]; (padding noted above) > + __u64 serror_esr; > + } exception; > +}; > + > /* If you need to interpret the index values, here is the key: */ > #define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000 > #define KVM_REG_ARM_COPROC_SHIFT 16 > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c > index 5c7f657..42e1222 100644 > --- a/arch/arm64/kvm/guest.c > +++ b/arch/arm64/kvm/guest.c > @@ -277,6 +277,37 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu, > return -EINVAL; > } > > +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu, > + struct kvm_vcpu_events *events) > +{ > + events->exception.serror_pending = (vcpu_get_hcr(vcpu) & HCR_VSE); > + events->exception.serror_has_esr = > + cpus_have_const_cap(ARM64_HAS_RAS_EXTN) && > + (!!vcpu_get_vsesr(vcpu)); > + events->exception.serror_esr = vcpu_get_vsesr(vcpu); This will return a stale ESR even if nothing is pending. On systems without the RAS extensions it will return 'ESR_ELx_ISV' if kvm_inject_vabt() has ever been called for this CPU. Could we hide this behind (pending && has_esr), setting it to 0 otherwise. This is just to avoid exposing the stale value. > + > + return 0; > +} > +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu, > + struct kvm_vcpu_events *events) > +{ > + bool injected = events->exception.serror_pending; > + bool has_esr = events->exception.serror_has_esr; > + > + if (injected && has_esr) { > + if (!cpus_have_const_cap(ARM64_HAS_RAS_EXTN)) > + return -EINVAL; > + > + kvm_set_sei_esr(vcpu, events->exception.serror_esr); > + > + } else if (injected) { > + kvm_inject_vabt(vcpu); Nit: looks like 'injected' is misnamed. > + } > + > + return 0; > +} > + > int __attribute_const__ kvm_target_cpu(void) > { > unsigned long implementor = read_cpuid_implementor(); > diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c > index 38c8a64..20e919a 100644 > --- a/arch/arm64/kvm/reset.c > +++ b/arch/arm64/kvm/reset.c > @@ -82,6 +82,7 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext) > break; > case KVM_CAP_SET_GUEST_DEBUG: > case KVM_CAP_VCPU_ATTRIBUTES: > + case KVM_CAP_VCPU_EVENTS: > r = 1; > break; > default: > diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c > index 7e3941f..945655d 100644 > --- a/virt/kvm/arm/arm.c > +++ b/virt/kvm/arm/arm.c > @@ -1051,6 +1051,27 @@ long kvm_arch_vcpu_ioctl(struct file *filp, > return -EFAULT; > return kvm_arm_vcpu_has_attr(vcpu, &attr); > } > + case KVM_GET_VCPU_EVENTS: { > + struct kvm_vcpu_events events; > + > + memset(&events, 0, sizeof(struct kvm_vcpu_events)); sizeof(events) is the normal style here, it means if someone changes event's type we don't get any surprises... > + if (kvm_arm_vcpu_get_events(vcpu, &events)) > + return -EINVAL; > + > + if (copy_to_user(argp, &events, sizeof(struct kvm_vcpu_events))) sizeof(events) > + return -EFAULT; > + > + return 0; > + } > + case KVM_SET_VCPU_EVENTS: { > + struct kvm_vcpu_events events; > + > + if (copy_from_user(&events, argp, > + sizeof(struct kvm_vcpu_events))) > + return -EFAULT; > + > + return kvm_arm_vcpu_set_events(vcpu, &events); > + } > default: > return -EINVAL; > } > Despite KVM_CAP_VCPU_EVENTS not being advertised on 32bit, any attempt to call it will still end up in here, but will always fail as the {g,s}et_events() calls always return -EINVAL. I don't think this will cause us any problems. Thanks, James -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v11 2/4] arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS 2018-04-10 14:15 ` James Morse (?) @ 2018-04-12 15:11 ` gengdongjiu -1 siblings, 0 replies; 58+ messages in thread From: gengdongjiu @ 2018-04-12 15:11 UTC (permalink / raw) To: James Morse, cdall Cc: Dongjiu Geng, devel, linux-doc, kvm, corbet, marc.zyngier, catalin.marinas, rjw, linux, linux-kernel, linux-acpi, zhengxiang9, bp, linux-arm-kernel, huangshaoyu, kvmarm, christoffer.dall, lenb Hi James, Thanks for the comments. 2018-04-10 22:15 GMT+08:00, James Morse <james.morse@arm.com>: > Hi Dongjiu Geng, > > On 09/04/18 22:36, Dongjiu Geng wrote: >> This new IOCTL exports user-invisible states related to SError. >> Together with appropriate user space changes, it can inject >> SError with specified syndrome to guest by setup kvm_vcpu_events >> value. > >> Also it can support live migration. > > Could you explain what user-space is expected to do for this? > (this is also relevant for snapshot-ing/suspending VMs) Ok. > > It's probably worth noting that this solves an existing problem: KVM may > make an > SError pending, but user-space has no way to discover/migrate this. if KVM make an SError pending, when user-space do migration, it get the kvm_vcpu_events through KVM_GET_VCPU_EVENTS, then can find that pending status. What are the things you're worried about? > > >> diff --git a/Documentation/virtual/kvm/api.txt >> b/Documentation/virtual/kvm/api.txt >> index 8a3d708..45719b4 100644 >> --- a/Documentation/virtual/kvm/api.txt >> +++ b/Documentation/virtual/kvm/api.txt >> @@ -819,11 +819,13 @@ struct kvm_clock_data { >> >> Capability: KVM_CAP_VCPU_EVENTS >> Extended by: KVM_CAP_INTR_SHADOW >> -Architectures: x86 >> +Architectures: x86, arm, arm64 >> Type: vm ioctl >> Parameters: struct kvm_vcpu_event (out) >> Returns: 0 on success, -1 on error >> >> +X86: >> + >> Gets currently pending exceptions, interrupts, and NMIs as well as >> related >> states of the vcpu. >> >> @@ -865,15 +867,31 @@ Only two fields are defined in the flags field: >> - KVM_VCPUEVENT_VALID_SMM may be set in the flags field to signal that >> smi contains a valid state. >> >> +ARM, ARM64: >> + >> +Gets currently pending SError exceptions as well as related states of the >> vcpu. >> + >> +struct kvm_vcpu_events { >> + struct { >> + __u8 serror_pending; >> + __u8 serror_has_esr; >> + /* Align it to 4 bytes */ >> + __u8 pad[2]; >> + __u64 serror_esr; >> + } exception; >> +}; >> + > > I'm not convinced we should change this struct from the layout/size x86 has. > Its > confusing for the documentation, is this API call really the same on all > architectures? > > What if we want to add some future interrupt, NMI or related state? We've > found > ourselves needing to add this API, it seems odd to remove its other uses on > x86. > We can't put them back in the future. > > Having a different layout would force user-space to ifdef/duplicate any > code > that accesses this between architectures. In x86 and arm64 user space code, the handling logic of KVM_GET/SET_VCPU_EVENTS is in different ARCH folder, maybe it is not necessary to share the handling code in the user space. > > > > The compiler will want that __u64 to be naturally aligned to 8-bytes, so > your > 4-byte padding still causes some secret compiler-padding to be inserted. > Different versions of the compiler may put it in different places. > > >> 4.32 KVM_SET_VCPU_EVENTS >> >> Capability: KVM_CAP_VCPU_EVENTS >> Extended by: KVM_CAP_INTR_SHADOW >> -Architectures: x86 >> +Architectures: x86, arm, arm64 >> Type: vm ioctl >> Parameters: struct kvm_vcpu_event (in) >> Returns: 0 on success, -1 on error >> >> +X86: >> + >> Set pending exceptions, interrupts, and NMIs as well as related states of >> the >> vcpu. >> >> @@ -894,6 +912,12 @@ shall be written into the VCPU. >> >> KVM_VCPUEVENT_VALID_SMM can only be set if KVM_CAP_X86_SMM is available. >> >> +ARM, ARM64: >> + >> +Set pending SError exceptions as well as related states of the vcpu. >> + >> +See KVM_GET_VCPU_EVENTS for the data structure. >> + >> >> 4.33 KVM_GET_DEBUGREGS >> > > >> diff --git a/arch/arm64/include/uapi/asm/kvm.h >> b/arch/arm64/include/uapi/asm/kvm.h >> index 9abbf30..855cc9a 100644 >> --- a/arch/arm64/include/uapi/asm/kvm.h >> +++ b/arch/arm64/include/uapi/asm/kvm.h >> @@ -39,6 +39,7 @@ >> #define __KVM_HAVE_GUEST_DEBUG >> #define __KVM_HAVE_IRQ_LINE >> #define __KVM_HAVE_READONLY_MEM >> +#define __KVM_HAVE_VCPU_EVENTS >> >> #define KVM_COALESCED_MMIO_PAGE_OFFSET 1 >> >> @@ -153,6 +154,17 @@ struct kvm_sync_regs { >> struct kvm_arch_memory_slot { >> }; >> >> +/* for KVM_GET/SET_VCPU_EVENTS */ >> +struct kvm_vcpu_events { >> + struct { >> + __u8 serror_pending; >> + __u8 serror_has_esr; > >> + /* Align it to 4 bytes */ >> + __u8 pad[2]; > > (padding noted above) > > >> + __u64 serror_esr; >> + } exception; >> +}; >> + >> /* If you need to interpret the index values, here is the key: */ >> #define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000 >> #define KVM_REG_ARM_COPROC_SHIFT 16 > > >> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c >> index 5c7f657..42e1222 100644 >> --- a/arch/arm64/kvm/guest.c >> +++ b/arch/arm64/kvm/guest.c >> @@ -277,6 +277,37 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu >> *vcpu, >> return -EINVAL; >> } >> >> +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu, >> + struct kvm_vcpu_events *events) >> +{ >> + events->exception.serror_pending = (vcpu_get_hcr(vcpu) & HCR_VSE); >> + events->exception.serror_has_esr = >> + cpus_have_const_cap(ARM64_HAS_RAS_EXTN) && >> + (!!vcpu_get_vsesr(vcpu)); > >> + events->exception.serror_esr = vcpu_get_vsesr(vcpu); > > This will return a stale ESR even if nothing is pending. On systems without > the > RAS extensions it will return 'ESR_ELx_ISV' if kvm_inject_vabt() has ever > been > called for this CPU. > > Could we hide this behind (pending && has_esr), setting it to 0 otherwise. > This > is just to avoid exposing the stale value. Exactly, it is indeed. > > >> + >> + return 0; >> +} > >> +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu, >> + struct kvm_vcpu_events *events) >> +{ >> + bool injected = events->exception.serror_pending; >> + bool has_esr = events->exception.serror_has_esr; >> + >> + if (injected && has_esr) { >> + if (!cpus_have_const_cap(ARM64_HAS_RAS_EXTN)) >> + return -EINVAL; >> + >> + kvm_set_sei_esr(vcpu, events->exception.serror_esr); >> + >> + } else if (injected) { >> + kvm_inject_vabt(vcpu); > > Nit: looks like 'injected' is misnamed. "injected" change to "pending"? > > >> + } >> + >> + return 0; >> +} >> + >> int __attribute_const__ kvm_target_cpu(void) >> { >> unsigned long implementor = read_cpuid_implementor(); > > >> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c >> index 38c8a64..20e919a 100644 >> --- a/arch/arm64/kvm/reset.c >> +++ b/arch/arm64/kvm/reset.c >> @@ -82,6 +82,7 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, >> long ext) >> break; >> case KVM_CAP_SET_GUEST_DEBUG: >> case KVM_CAP_VCPU_ATTRIBUTES: >> + case KVM_CAP_VCPU_EVENTS: >> r = 1; >> break; >> default: > >> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c >> index 7e3941f..945655d 100644 >> --- a/virt/kvm/arm/arm.c >> +++ b/virt/kvm/arm/arm.c >> @@ -1051,6 +1051,27 @@ long kvm_arch_vcpu_ioctl(struct file *filp, >> return -EFAULT; >> return kvm_arm_vcpu_has_attr(vcpu, &attr); >> } >> + case KVM_GET_VCPU_EVENTS: { >> + struct kvm_vcpu_events events; >> + >> + memset(&events, 0, sizeof(struct kvm_vcpu_events)); > > sizeof(events) is the normal style here, it means if someone changes > event's > type we don't get any surprises... Ok, thanks > > >> + if (kvm_arm_vcpu_get_events(vcpu, &events)) >> + return -EINVAL; >> + >> + if (copy_to_user(argp, &events, sizeof(struct kvm_vcpu_events))) > > sizeof(events) thanks > > >> + return -EFAULT; >> + >> + return 0; >> + } >> + case KVM_SET_VCPU_EVENTS: { >> + struct kvm_vcpu_events events; >> + >> + if (copy_from_user(&events, argp, >> + sizeof(struct kvm_vcpu_events))) >> + return -EFAULT; >> + >> + return kvm_arm_vcpu_set_events(vcpu, &events); >> + } >> default: >> return -EINVAL; >> } >> > > Despite KVM_CAP_VCPU_EVENTS not being advertised on 32bit, any attempt to > call > it will still end up in here, but will always fail as the {g,s}et_events() > calls > always return -EINVAL. I don't think this will cause us any problems. What are the things you're worried about? > > > Thanks, > > James > _______________________________________________ > kvmarm mailing list > kvmarm@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm > ^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v11 2/4] arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS @ 2018-04-12 15:11 ` gengdongjiu 0 siblings, 0 replies; 58+ messages in thread From: gengdongjiu @ 2018-04-12 15:11 UTC (permalink / raw) To: linux-arm-kernel Hi James, Thanks for the comments. 2018-04-10 22:15 GMT+08:00, James Morse <james.morse@arm.com>: > Hi Dongjiu Geng, > > On 09/04/18 22:36, Dongjiu Geng wrote: >> This new IOCTL exports user-invisible states related to SError. >> Together with appropriate user space changes, it can inject >> SError with specified syndrome to guest by setup kvm_vcpu_events >> value. > >> Also it can support live migration. > > Could you explain what user-space is expected to do for this? > (this is also relevant for snapshot-ing/suspending VMs) Ok. > > It's probably worth noting that this solves an existing problem: KVM may > make an > SError pending, but user-space has no way to discover/migrate this. if KVM make an SError pending, when user-space do migration, it get the kvm_vcpu_events through KVM_GET_VCPU_EVENTS, then can find that pending status. What are the things you're worried about? > > >> diff --git a/Documentation/virtual/kvm/api.txt >> b/Documentation/virtual/kvm/api.txt >> index 8a3d708..45719b4 100644 >> --- a/Documentation/virtual/kvm/api.txt >> +++ b/Documentation/virtual/kvm/api.txt >> @@ -819,11 +819,13 @@ struct kvm_clock_data { >> >> Capability: KVM_CAP_VCPU_EVENTS >> Extended by: KVM_CAP_INTR_SHADOW >> -Architectures: x86 >> +Architectures: x86, arm, arm64 >> Type: vm ioctl >> Parameters: struct kvm_vcpu_event (out) >> Returns: 0 on success, -1 on error >> >> +X86: >> + >> Gets currently pending exceptions, interrupts, and NMIs as well as >> related >> states of the vcpu. >> >> @@ -865,15 +867,31 @@ Only two fields are defined in the flags field: >> - KVM_VCPUEVENT_VALID_SMM may be set in the flags field to signal that >> smi contains a valid state. >> >> +ARM, ARM64: >> + >> +Gets currently pending SError exceptions as well as related states of the >> vcpu. >> + >> +struct kvm_vcpu_events { >> + struct { >> + __u8 serror_pending; >> + __u8 serror_has_esr; >> + /* Align it to 4 bytes */ >> + __u8 pad[2]; >> + __u64 serror_esr; >> + } exception; >> +}; >> + > > I'm not convinced we should change this struct from the layout/size x86 has. > Its > confusing for the documentation, is this API call really the same on all > architectures? > > What if we want to add some future interrupt, NMI or related state? We've > found > ourselves needing to add this API, it seems odd to remove its other uses on > x86. > We can't put them back in the future. > > Having a different layout would force user-space to ifdef/duplicate any > code > that accesses this between architectures. In x86 and arm64 user space code, the handling logic of KVM_GET/SET_VCPU_EVENTS is in different ARCH folder, maybe it is not necessary to share the handling code in the user space. > > > > The compiler will want that __u64 to be naturally aligned to 8-bytes, so > your > 4-byte padding still causes some secret compiler-padding to be inserted. > Different versions of the compiler may put it in different places. > > >> 4.32 KVM_SET_VCPU_EVENTS >> >> Capability: KVM_CAP_VCPU_EVENTS >> Extended by: KVM_CAP_INTR_SHADOW >> -Architectures: x86 >> +Architectures: x86, arm, arm64 >> Type: vm ioctl >> Parameters: struct kvm_vcpu_event (in) >> Returns: 0 on success, -1 on error >> >> +X86: >> + >> Set pending exceptions, interrupts, and NMIs as well as related states of >> the >> vcpu. >> >> @@ -894,6 +912,12 @@ shall be written into the VCPU. >> >> KVM_VCPUEVENT_VALID_SMM can only be set if KVM_CAP_X86_SMM is available. >> >> +ARM, ARM64: >> + >> +Set pending SError exceptions as well as related states of the vcpu. >> + >> +See KVM_GET_VCPU_EVENTS for the data structure. >> + >> >> 4.33 KVM_GET_DEBUGREGS >> > > >> diff --git a/arch/arm64/include/uapi/asm/kvm.h >> b/arch/arm64/include/uapi/asm/kvm.h >> index 9abbf30..855cc9a 100644 >> --- a/arch/arm64/include/uapi/asm/kvm.h >> +++ b/arch/arm64/include/uapi/asm/kvm.h >> @@ -39,6 +39,7 @@ >> #define __KVM_HAVE_GUEST_DEBUG >> #define __KVM_HAVE_IRQ_LINE >> #define __KVM_HAVE_READONLY_MEM >> +#define __KVM_HAVE_VCPU_EVENTS >> >> #define KVM_COALESCED_MMIO_PAGE_OFFSET 1 >> >> @@ -153,6 +154,17 @@ struct kvm_sync_regs { >> struct kvm_arch_memory_slot { >> }; >> >> +/* for KVM_GET/SET_VCPU_EVENTS */ >> +struct kvm_vcpu_events { >> + struct { >> + __u8 serror_pending; >> + __u8 serror_has_esr; > >> + /* Align it to 4 bytes */ >> + __u8 pad[2]; > > (padding noted above) > > >> + __u64 serror_esr; >> + } exception; >> +}; >> + >> /* If you need to interpret the index values, here is the key: */ >> #define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000 >> #define KVM_REG_ARM_COPROC_SHIFT 16 > > >> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c >> index 5c7f657..42e1222 100644 >> --- a/arch/arm64/kvm/guest.c >> +++ b/arch/arm64/kvm/guest.c >> @@ -277,6 +277,37 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu >> *vcpu, >> return -EINVAL; >> } >> >> +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu, >> + struct kvm_vcpu_events *events) >> +{ >> + events->exception.serror_pending = (vcpu_get_hcr(vcpu) & HCR_VSE); >> + events->exception.serror_has_esr = >> + cpus_have_const_cap(ARM64_HAS_RAS_EXTN) && >> + (!!vcpu_get_vsesr(vcpu)); > >> + events->exception.serror_esr = vcpu_get_vsesr(vcpu); > > This will return a stale ESR even if nothing is pending. On systems without > the > RAS extensions it will return 'ESR_ELx_ISV' if kvm_inject_vabt() has ever > been > called for this CPU. > > Could we hide this behind (pending && has_esr), setting it to 0 otherwise. > This > is just to avoid exposing the stale value. Exactly, it is indeed. > > >> + >> + return 0; >> +} > >> +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu, >> + struct kvm_vcpu_events *events) >> +{ >> + bool injected = events->exception.serror_pending; >> + bool has_esr = events->exception.serror_has_esr; >> + >> + if (injected && has_esr) { >> + if (!cpus_have_const_cap(ARM64_HAS_RAS_EXTN)) >> + return -EINVAL; >> + >> + kvm_set_sei_esr(vcpu, events->exception.serror_esr); >> + >> + } else if (injected) { >> + kvm_inject_vabt(vcpu); > > Nit: looks like 'injected' is misnamed. "injected" change to "pending"? > > >> + } >> + >> + return 0; >> +} >> + >> int __attribute_const__ kvm_target_cpu(void) >> { >> unsigned long implementor = read_cpuid_implementor(); > > >> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c >> index 38c8a64..20e919a 100644 >> --- a/arch/arm64/kvm/reset.c >> +++ b/arch/arm64/kvm/reset.c >> @@ -82,6 +82,7 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, >> long ext) >> break; >> case KVM_CAP_SET_GUEST_DEBUG: >> case KVM_CAP_VCPU_ATTRIBUTES: >> + case KVM_CAP_VCPU_EVENTS: >> r = 1; >> break; >> default: > >> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c >> index 7e3941f..945655d 100644 >> --- a/virt/kvm/arm/arm.c >> +++ b/virt/kvm/arm/arm.c >> @@ -1051,6 +1051,27 @@ long kvm_arch_vcpu_ioctl(struct file *filp, >> return -EFAULT; >> return kvm_arm_vcpu_has_attr(vcpu, &attr); >> } >> + case KVM_GET_VCPU_EVENTS: { >> + struct kvm_vcpu_events events; >> + >> + memset(&events, 0, sizeof(struct kvm_vcpu_events)); > > sizeof(events) is the normal style here, it means if someone changes > event's > type we don't get any surprises... Ok, thanks > > >> + if (kvm_arm_vcpu_get_events(vcpu, &events)) >> + return -EINVAL; >> + >> + if (copy_to_user(argp, &events, sizeof(struct kvm_vcpu_events))) > > sizeof(events) thanks > > >> + return -EFAULT; >> + >> + return 0; >> + } >> + case KVM_SET_VCPU_EVENTS: { >> + struct kvm_vcpu_events events; >> + >> + if (copy_from_user(&events, argp, >> + sizeof(struct kvm_vcpu_events))) >> + return -EFAULT; >> + >> + return kvm_arm_vcpu_set_events(vcpu, &events); >> + } >> default: >> return -EINVAL; >> } >> > > Despite KVM_CAP_VCPU_EVENTS not being advertised on 32bit, any attempt to > call > it will still end up in here, but will always fail as the {g,s}et_events() > calls > always return -EINVAL. I don't think this will cause us any problems. What are the things you're worried about? > > > Thanks, > > James > _______________________________________________ > kvmarm mailing list > kvmarm at lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm > ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v11 2/4] arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS @ 2018-04-12 15:11 ` gengdongjiu 0 siblings, 0 replies; 58+ messages in thread From: gengdongjiu @ 2018-04-12 15:11 UTC (permalink / raw) To: James Morse, cdall Cc: Dongjiu Geng, devel, linux-doc, kvm, corbet, marc.zyngier, catalin.marinas, rjw, linux, linux-kernel, linux-acpi, zhengxiang9, bp, linux-arm-kernel, huangshaoyu, kvmarm, christoffer.dall, lenb Hi James, Thanks for the comments. 2018-04-10 22:15 GMT+08:00, James Morse <james.morse@arm.com>: > Hi Dongjiu Geng, > > On 09/04/18 22:36, Dongjiu Geng wrote: >> This new IOCTL exports user-invisible states related to SError. >> Together with appropriate user space changes, it can inject >> SError with specified syndrome to guest by setup kvm_vcpu_events >> value. > >> Also it can support live migration. > > Could you explain what user-space is expected to do for this? > (this is also relevant for snapshot-ing/suspending VMs) Ok. > > It's probably worth noting that this solves an existing problem: KVM may > make an > SError pending, but user-space has no way to discover/migrate this. if KVM make an SError pending, when user-space do migration, it get the kvm_vcpu_events through KVM_GET_VCPU_EVENTS, then can find that pending status. What are the things you're worried about? > > >> diff --git a/Documentation/virtual/kvm/api.txt >> b/Documentation/virtual/kvm/api.txt >> index 8a3d708..45719b4 100644 >> --- a/Documentation/virtual/kvm/api.txt >> +++ b/Documentation/virtual/kvm/api.txt >> @@ -819,11 +819,13 @@ struct kvm_clock_data { >> >> Capability: KVM_CAP_VCPU_EVENTS >> Extended by: KVM_CAP_INTR_SHADOW >> -Architectures: x86 >> +Architectures: x86, arm, arm64 >> Type: vm ioctl >> Parameters: struct kvm_vcpu_event (out) >> Returns: 0 on success, -1 on error >> >> +X86: >> + >> Gets currently pending exceptions, interrupts, and NMIs as well as >> related >> states of the vcpu. >> >> @@ -865,15 +867,31 @@ Only two fields are defined in the flags field: >> - KVM_VCPUEVENT_VALID_SMM may be set in the flags field to signal that >> smi contains a valid state. >> >> +ARM, ARM64: >> + >> +Gets currently pending SError exceptions as well as related states of the >> vcpu. >> + >> +struct kvm_vcpu_events { >> + struct { >> + __u8 serror_pending; >> + __u8 serror_has_esr; >> + /* Align it to 4 bytes */ >> + __u8 pad[2]; >> + __u64 serror_esr; >> + } exception; >> +}; >> + > > I'm not convinced we should change this struct from the layout/size x86 has. > Its > confusing for the documentation, is this API call really the same on all > architectures? > > What if we want to add some future interrupt, NMI or related state? We've > found > ourselves needing to add this API, it seems odd to remove its other uses on > x86. > We can't put them back in the future. > > Having a different layout would force user-space to ifdef/duplicate any > code > that accesses this between architectures. In x86 and arm64 user space code, the handling logic of KVM_GET/SET_VCPU_EVENTS is in different ARCH folder, maybe it is not necessary to share the handling code in the user space. > > > > The compiler will want that __u64 to be naturally aligned to 8-bytes, so > your > 4-byte padding still causes some secret compiler-padding to be inserted. > Different versions of the compiler may put it in different places. > > >> 4.32 KVM_SET_VCPU_EVENTS >> >> Capability: KVM_CAP_VCPU_EVENTS >> Extended by: KVM_CAP_INTR_SHADOW >> -Architectures: x86 >> +Architectures: x86, arm, arm64 >> Type: vm ioctl >> Parameters: struct kvm_vcpu_event (in) >> Returns: 0 on success, -1 on error >> >> +X86: >> + >> Set pending exceptions, interrupts, and NMIs as well as related states of >> the >> vcpu. >> >> @@ -894,6 +912,12 @@ shall be written into the VCPU. >> >> KVM_VCPUEVENT_VALID_SMM can only be set if KVM_CAP_X86_SMM is available. >> >> +ARM, ARM64: >> + >> +Set pending SError exceptions as well as related states of the vcpu. >> + >> +See KVM_GET_VCPU_EVENTS for the data structure. >> + >> >> 4.33 KVM_GET_DEBUGREGS >> > > >> diff --git a/arch/arm64/include/uapi/asm/kvm.h >> b/arch/arm64/include/uapi/asm/kvm.h >> index 9abbf30..855cc9a 100644 >> --- a/arch/arm64/include/uapi/asm/kvm.h >> +++ b/arch/arm64/include/uapi/asm/kvm.h >> @@ -39,6 +39,7 @@ >> #define __KVM_HAVE_GUEST_DEBUG >> #define __KVM_HAVE_IRQ_LINE >> #define __KVM_HAVE_READONLY_MEM >> +#define __KVM_HAVE_VCPU_EVENTS >> >> #define KVM_COALESCED_MMIO_PAGE_OFFSET 1 >> >> @@ -153,6 +154,17 @@ struct kvm_sync_regs { >> struct kvm_arch_memory_slot { >> }; >> >> +/* for KVM_GET/SET_VCPU_EVENTS */ >> +struct kvm_vcpu_events { >> + struct { >> + __u8 serror_pending; >> + __u8 serror_has_esr; > >> + /* Align it to 4 bytes */ >> + __u8 pad[2]; > > (padding noted above) > > >> + __u64 serror_esr; >> + } exception; >> +}; >> + >> /* If you need to interpret the index values, here is the key: */ >> #define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000 >> #define KVM_REG_ARM_COPROC_SHIFT 16 > > >> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c >> index 5c7f657..42e1222 100644 >> --- a/arch/arm64/kvm/guest.c >> +++ b/arch/arm64/kvm/guest.c >> @@ -277,6 +277,37 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu >> *vcpu, >> return -EINVAL; >> } >> >> +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu, >> + struct kvm_vcpu_events *events) >> +{ >> + events->exception.serror_pending = (vcpu_get_hcr(vcpu) & HCR_VSE); >> + events->exception.serror_has_esr = >> + cpus_have_const_cap(ARM64_HAS_RAS_EXTN) && >> + (!!vcpu_get_vsesr(vcpu)); > >> + events->exception.serror_esr = vcpu_get_vsesr(vcpu); > > This will return a stale ESR even if nothing is pending. On systems without > the > RAS extensions it will return 'ESR_ELx_ISV' if kvm_inject_vabt() has ever > been > called for this CPU. > > Could we hide this behind (pending && has_esr), setting it to 0 otherwise. > This > is just to avoid exposing the stale value. Exactly, it is indeed. > > >> + >> + return 0; >> +} > >> +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu, >> + struct kvm_vcpu_events *events) >> +{ >> + bool injected = events->exception.serror_pending; >> + bool has_esr = events->exception.serror_has_esr; >> + >> + if (injected && has_esr) { >> + if (!cpus_have_const_cap(ARM64_HAS_RAS_EXTN)) >> + return -EINVAL; >> + >> + kvm_set_sei_esr(vcpu, events->exception.serror_esr); >> + >> + } else if (injected) { >> + kvm_inject_vabt(vcpu); > > Nit: looks like 'injected' is misnamed. "injected" change to "pending"? > > >> + } >> + >> + return 0; >> +} >> + >> int __attribute_const__ kvm_target_cpu(void) >> { >> unsigned long implementor = read_cpuid_implementor(); > > >> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c >> index 38c8a64..20e919a 100644 >> --- a/arch/arm64/kvm/reset.c >> +++ b/arch/arm64/kvm/reset.c >> @@ -82,6 +82,7 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, >> long ext) >> break; >> case KVM_CAP_SET_GUEST_DEBUG: >> case KVM_CAP_VCPU_ATTRIBUTES: >> + case KVM_CAP_VCPU_EVENTS: >> r = 1; >> break; >> default: > >> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c >> index 7e3941f..945655d 100644 >> --- a/virt/kvm/arm/arm.c >> +++ b/virt/kvm/arm/arm.c >> @@ -1051,6 +1051,27 @@ long kvm_arch_vcpu_ioctl(struct file *filp, >> return -EFAULT; >> return kvm_arm_vcpu_has_attr(vcpu, &attr); >> } >> + case KVM_GET_VCPU_EVENTS: { >> + struct kvm_vcpu_events events; >> + >> + memset(&events, 0, sizeof(struct kvm_vcpu_events)); > > sizeof(events) is the normal style here, it means if someone changes > event's > type we don't get any surprises... Ok, thanks > > >> + if (kvm_arm_vcpu_get_events(vcpu, &events)) >> + return -EINVAL; >> + >> + if (copy_to_user(argp, &events, sizeof(struct kvm_vcpu_events))) > > sizeof(events) thanks > > >> + return -EFAULT; >> + >> + return 0; >> + } >> + case KVM_SET_VCPU_EVENTS: { >> + struct kvm_vcpu_events events; >> + >> + if (copy_from_user(&events, argp, >> + sizeof(struct kvm_vcpu_events))) >> + return -EFAULT; >> + >> + return kvm_arm_vcpu_set_events(vcpu, &events); >> + } >> default: >> return -EINVAL; >> } >> > > Despite KVM_CAP_VCPU_EVENTS not being advertised on 32bit, any attempt to > call > it will still end up in here, but will always fail as the {g,s}et_events() > calls > always return -EINVAL. I don't think this will cause us any problems. What are the things you're worried about? > > > Thanks, > > James > _______________________________________________ > kvmarm mailing list > kvmarm@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v11 3/4] ACPI / APEI: Add SEI notification type support for ARMv8 2018-04-09 21:36 ` Dongjiu Geng ` (2 preceding siblings ...) (?) @ 2018-04-09 21:36 ` Dongjiu Geng -1 siblings, 0 replies; 58+ messages in thread From: Dongjiu Geng @ 2018-04-09 21:36 UTC (permalink / raw) To: rkrcmar, corbet, christoffer.dall, marc.zyngier, james.morse, linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel Cc: gengdongjiu, huangshaoyu, zhengxiang9 ACPI 6.x adds support for NOTIFY_SEI as a GHES notification mechanism, so add new GHES notification handling functions. Expose API ghes_notify_sei() to arch code, arch code will call this API when it gets this NOTIFY_SEI. Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com> --- drivers/acpi/apei/Kconfig | 15 ++++++++++++++ drivers/acpi/apei/ghes.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++ include/acpi/ghes.h | 1 + 3 files changed, 69 insertions(+) diff --git a/drivers/acpi/apei/Kconfig b/drivers/acpi/apei/Kconfig index 52ae543..ff4afc3 100644 --- a/drivers/acpi/apei/Kconfig +++ b/drivers/acpi/apei/Kconfig @@ -55,6 +55,21 @@ config ACPI_APEI_SEA option allows the OS to look for such hardware error record, and take appropriate action. +config ACPI_APEI_SEI + bool "APEI SError(System Error) Interrupt logging/recovering support" + depends on ARM64 && ACPI_APEI_GHES + default y + help + This option should be enabled if the system supports + firmware first handling of SEI (SError interrupt). + + SEI happens with asynchronous external abort for errors on device + memory reads on ARMv8 systems. If a system supports firmware first + handling of SEI, the platform analyzes and handles hardware error + notifications from SEI, and it may then form a hardware error record for + the OS to parse and handle. This option allows the OS to look for + such hardware error record, and take appropriate action. + config ACPI_APEI_MEMORY_FAILURE bool "APEI memory error recovering support" depends on ACPI_APEI && MEMORY_FAILURE diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index 1efefe9..33f77ae 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -827,6 +827,46 @@ static inline void ghes_sea_add(struct ghes *ghes) { } static inline void ghes_sea_remove(struct ghes *ghes) { } #endif /* CONFIG_ACPI_APEI_SEA */ +#ifdef CONFIG_ACPI_APEI_SEI +static LIST_HEAD(ghes_sei); + +/* + * Return 0 only if one of the SEI error sources successfully reported an error + * record sent from the firmware. + */ +int ghes_notify_sei(void) +{ + struct ghes *ghes; + int ret = -ENOENT; + + rcu_read_lock(); + list_for_each_entry_rcu(ghes, &ghes_sei, list) { + if (!ghes_proc(ghes)) + ret = 0; + } + rcu_read_unlock(); + return ret; +} + +static void ghes_sei_add(struct ghes *ghes) +{ + mutex_lock(&ghes_list_mutex); + list_add_rcu(&ghes->list, &ghes_sei); + mutex_unlock(&ghes_list_mutex); +} + +static void ghes_sei_remove(struct ghes *ghes) +{ + mutex_lock(&ghes_list_mutex); + list_del_rcu(&ghes->list); + mutex_unlock(&ghes_list_mutex); + synchronize_rcu(); +} +#else /* CONFIG_ACPI_APEI_SEI */ +static inline void ghes_sei_add(struct ghes *ghes) { } +static inline void ghes_sei_remove(struct ghes *ghes) { } +#endif /* CONFIG_ACPI_APEI_SEI */ + #ifdef CONFIG_HAVE_ACPI_APEI_NMI /* * printk is not safe in NMI context. So in NMI handler, we allocate @@ -1055,6 +1095,13 @@ static int ghes_probe(struct platform_device *ghes_dev) goto err; } break; + case ACPI_HEST_NOTIFY_SEI: + if (!IS_ENABLED(CONFIG_ACPI_APEI_SEI)) { + pr_warn(GHES_PFX "Generic hardware error source: %d notified via SEI is not supported!\n", + generic->header.source_id); + goto err; + } + break; case ACPI_HEST_NOTIFY_NMI: if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_NMI)) { pr_warn(GHES_PFX "Generic hardware error source: %d notified via NMI interrupt is not supported!\n", @@ -1126,6 +1173,9 @@ static int ghes_probe(struct platform_device *ghes_dev) case ACPI_HEST_NOTIFY_SEA: ghes_sea_add(ghes); break; + case ACPI_HEST_NOTIFY_SEI: + ghes_sei_add(ghes); + break; case ACPI_HEST_NOTIFY_NMI: ghes_nmi_add(ghes); break; @@ -1179,6 +1229,9 @@ static int ghes_remove(struct platform_device *ghes_dev) case ACPI_HEST_NOTIFY_SEA: ghes_sea_remove(ghes); break; + case ACPI_HEST_NOTIFY_SEI: + ghes_sei_remove(ghes); + break; case ACPI_HEST_NOTIFY_NMI: ghes_nmi_remove(ghes); break; diff --git a/include/acpi/ghes.h b/include/acpi/ghes.h index 8feb0c8..9ba59e2 100644 --- a/include/acpi/ghes.h +++ b/include/acpi/ghes.h @@ -120,5 +120,6 @@ static inline void *acpi_hest_get_next(struct acpi_hest_generic_data *gdata) section = acpi_hest_get_next(section)) int ghes_notify_sea(void); +int ghes_notify_sei(void); #endif /* GHES_H */ -- 1.9.1 ^ permalink raw reply related [flat|nested] 58+ messages in thread
* [Devel] [PATCH v11 3/4] ACPI / APEI: Add SEI notification type support for ARMv8 @ 2018-04-09 21:36 ` Dongjiu Geng 0 siblings, 0 replies; 58+ messages in thread From: Dongjiu Geng @ 2018-04-09 21:36 UTC (permalink / raw) To: devel [-- Attachment #1: Type: text/plain, Size: 4514 bytes --] ACPI 6.x adds support for NOTIFY_SEI as a GHES notification mechanism, so add new GHES notification handling functions. Expose API ghes_notify_sei() to arch code, arch code will call this API when it gets this NOTIFY_SEI. Signed-off-by: Dongjiu Geng <gengdongjiu(a)huawei.com> --- drivers/acpi/apei/Kconfig | 15 ++++++++++++++ drivers/acpi/apei/ghes.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++ include/acpi/ghes.h | 1 + 3 files changed, 69 insertions(+) diff --git a/drivers/acpi/apei/Kconfig b/drivers/acpi/apei/Kconfig index 52ae543..ff4afc3 100644 --- a/drivers/acpi/apei/Kconfig +++ b/drivers/acpi/apei/Kconfig @@ -55,6 +55,21 @@ config ACPI_APEI_SEA option allows the OS to look for such hardware error record, and take appropriate action. +config ACPI_APEI_SEI + bool "APEI SError(System Error) Interrupt logging/recovering support" + depends on ARM64 && ACPI_APEI_GHES + default y + help + This option should be enabled if the system supports + firmware first handling of SEI (SError interrupt). + + SEI happens with asynchronous external abort for errors on device + memory reads on ARMv8 systems. If a system supports firmware first + handling of SEI, the platform analyzes and handles hardware error + notifications from SEI, and it may then form a hardware error record for + the OS to parse and handle. This option allows the OS to look for + such hardware error record, and take appropriate action. + config ACPI_APEI_MEMORY_FAILURE bool "APEI memory error recovering support" depends on ACPI_APEI && MEMORY_FAILURE diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index 1efefe9..33f77ae 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -827,6 +827,46 @@ static inline void ghes_sea_add(struct ghes *ghes) { } static inline void ghes_sea_remove(struct ghes *ghes) { } #endif /* CONFIG_ACPI_APEI_SEA */ +#ifdef CONFIG_ACPI_APEI_SEI +static LIST_HEAD(ghes_sei); + +/* + * Return 0 only if one of the SEI error sources successfully reported an error + * record sent from the firmware. + */ +int ghes_notify_sei(void) +{ + struct ghes *ghes; + int ret = -ENOENT; + + rcu_read_lock(); + list_for_each_entry_rcu(ghes, &ghes_sei, list) { + if (!ghes_proc(ghes)) + ret = 0; + } + rcu_read_unlock(); + return ret; +} + +static void ghes_sei_add(struct ghes *ghes) +{ + mutex_lock(&ghes_list_mutex); + list_add_rcu(&ghes->list, &ghes_sei); + mutex_unlock(&ghes_list_mutex); +} + +static void ghes_sei_remove(struct ghes *ghes) +{ + mutex_lock(&ghes_list_mutex); + list_del_rcu(&ghes->list); + mutex_unlock(&ghes_list_mutex); + synchronize_rcu(); +} +#else /* CONFIG_ACPI_APEI_SEI */ +static inline void ghes_sei_add(struct ghes *ghes) { } +static inline void ghes_sei_remove(struct ghes *ghes) { } +#endif /* CONFIG_ACPI_APEI_SEI */ + #ifdef CONFIG_HAVE_ACPI_APEI_NMI /* * printk is not safe in NMI context. So in NMI handler, we allocate @@ -1055,6 +1095,13 @@ static int ghes_probe(struct platform_device *ghes_dev) goto err; } break; + case ACPI_HEST_NOTIFY_SEI: + if (!IS_ENABLED(CONFIG_ACPI_APEI_SEI)) { + pr_warn(GHES_PFX "Generic hardware error source: %d notified via SEI is not supported!\n", + generic->header.source_id); + goto err; + } + break; case ACPI_HEST_NOTIFY_NMI: if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_NMI)) { pr_warn(GHES_PFX "Generic hardware error source: %d notified via NMI interrupt is not supported!\n", @@ -1126,6 +1173,9 @@ static int ghes_probe(struct platform_device *ghes_dev) case ACPI_HEST_NOTIFY_SEA: ghes_sea_add(ghes); break; + case ACPI_HEST_NOTIFY_SEI: + ghes_sei_add(ghes); + break; case ACPI_HEST_NOTIFY_NMI: ghes_nmi_add(ghes); break; @@ -1179,6 +1229,9 @@ static int ghes_remove(struct platform_device *ghes_dev) case ACPI_HEST_NOTIFY_SEA: ghes_sea_remove(ghes); break; + case ACPI_HEST_NOTIFY_SEI: + ghes_sei_remove(ghes); + break; case ACPI_HEST_NOTIFY_NMI: ghes_nmi_remove(ghes); break; diff --git a/include/acpi/ghes.h b/include/acpi/ghes.h index 8feb0c8..9ba59e2 100644 --- a/include/acpi/ghes.h +++ b/include/acpi/ghes.h @@ -120,5 +120,6 @@ static inline void *acpi_hest_get_next(struct acpi_hest_generic_data *gdata) section = acpi_hest_get_next(section)) int ghes_notify_sea(void); +int ghes_notify_sei(void); #endif /* GHES_H */ -- 1.9.1 ^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v11 3/4] ACPI / APEI: Add SEI notification type support for ARMv8 @ 2018-04-09 21:36 ` Dongjiu Geng 0 siblings, 0 replies; 58+ messages in thread From: Dongjiu Geng @ 2018-04-09 21:36 UTC (permalink / raw) To: linux-arm-kernel ACPI 6.x adds support for NOTIFY_SEI as a GHES notification mechanism, so add new GHES notification handling functions. Expose API ghes_notify_sei() to arch code, arch code will call this API when it gets this NOTIFY_SEI. Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com> --- drivers/acpi/apei/Kconfig | 15 ++++++++++++++ drivers/acpi/apei/ghes.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++ include/acpi/ghes.h | 1 + 3 files changed, 69 insertions(+) diff --git a/drivers/acpi/apei/Kconfig b/drivers/acpi/apei/Kconfig index 52ae543..ff4afc3 100644 --- a/drivers/acpi/apei/Kconfig +++ b/drivers/acpi/apei/Kconfig @@ -55,6 +55,21 @@ config ACPI_APEI_SEA option allows the OS to look for such hardware error record, and take appropriate action. +config ACPI_APEI_SEI + bool "APEI SError(System Error) Interrupt logging/recovering support" + depends on ARM64 && ACPI_APEI_GHES + default y + help + This option should be enabled if the system supports + firmware first handling of SEI (SError interrupt). + + SEI happens with asynchronous external abort for errors on device + memory reads on ARMv8 systems. If a system supports firmware first + handling of SEI, the platform analyzes and handles hardware error + notifications from SEI, and it may then form a hardware error record for + the OS to parse and handle. This option allows the OS to look for + such hardware error record, and take appropriate action. + config ACPI_APEI_MEMORY_FAILURE bool "APEI memory error recovering support" depends on ACPI_APEI && MEMORY_FAILURE diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index 1efefe9..33f77ae 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -827,6 +827,46 @@ static inline void ghes_sea_add(struct ghes *ghes) { } static inline void ghes_sea_remove(struct ghes *ghes) { } #endif /* CONFIG_ACPI_APEI_SEA */ +#ifdef CONFIG_ACPI_APEI_SEI +static LIST_HEAD(ghes_sei); + +/* + * Return 0 only if one of the SEI error sources successfully reported an error + * record sent from the firmware. + */ +int ghes_notify_sei(void) +{ + struct ghes *ghes; + int ret = -ENOENT; + + rcu_read_lock(); + list_for_each_entry_rcu(ghes, &ghes_sei, list) { + if (!ghes_proc(ghes)) + ret = 0; + } + rcu_read_unlock(); + return ret; +} + +static void ghes_sei_add(struct ghes *ghes) +{ + mutex_lock(&ghes_list_mutex); + list_add_rcu(&ghes->list, &ghes_sei); + mutex_unlock(&ghes_list_mutex); +} + +static void ghes_sei_remove(struct ghes *ghes) +{ + mutex_lock(&ghes_list_mutex); + list_del_rcu(&ghes->list); + mutex_unlock(&ghes_list_mutex); + synchronize_rcu(); +} +#else /* CONFIG_ACPI_APEI_SEI */ +static inline void ghes_sei_add(struct ghes *ghes) { } +static inline void ghes_sei_remove(struct ghes *ghes) { } +#endif /* CONFIG_ACPI_APEI_SEI */ + #ifdef CONFIG_HAVE_ACPI_APEI_NMI /* * printk is not safe in NMI context. So in NMI handler, we allocate @@ -1055,6 +1095,13 @@ static int ghes_probe(struct platform_device *ghes_dev) goto err; } break; + case ACPI_HEST_NOTIFY_SEI: + if (!IS_ENABLED(CONFIG_ACPI_APEI_SEI)) { + pr_warn(GHES_PFX "Generic hardware error source: %d notified via SEI is not supported!\n", + generic->header.source_id); + goto err; + } + break; case ACPI_HEST_NOTIFY_NMI: if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_NMI)) { pr_warn(GHES_PFX "Generic hardware error source: %d notified via NMI interrupt is not supported!\n", @@ -1126,6 +1173,9 @@ static int ghes_probe(struct platform_device *ghes_dev) case ACPI_HEST_NOTIFY_SEA: ghes_sea_add(ghes); break; + case ACPI_HEST_NOTIFY_SEI: + ghes_sei_add(ghes); + break; case ACPI_HEST_NOTIFY_NMI: ghes_nmi_add(ghes); break; @@ -1179,6 +1229,9 @@ static int ghes_remove(struct platform_device *ghes_dev) case ACPI_HEST_NOTIFY_SEA: ghes_sea_remove(ghes); break; + case ACPI_HEST_NOTIFY_SEI: + ghes_sei_remove(ghes); + break; case ACPI_HEST_NOTIFY_NMI: ghes_nmi_remove(ghes); break; diff --git a/include/acpi/ghes.h b/include/acpi/ghes.h index 8feb0c8..9ba59e2 100644 --- a/include/acpi/ghes.h +++ b/include/acpi/ghes.h @@ -120,5 +120,6 @@ static inline void *acpi_hest_get_next(struct acpi_hest_generic_data *gdata) section = acpi_hest_get_next(section)) int ghes_notify_sea(void); +int ghes_notify_sei(void); #endif /* GHES_H */ -- 1.9.1 ^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v11 3/4] ACPI / APEI: Add SEI notification type support for ARMv8 @ 2018-04-09 21:36 ` Dongjiu Geng 0 siblings, 0 replies; 58+ messages in thread From: Dongjiu Geng @ 2018-04-09 21:36 UTC (permalink / raw) To: rkrcmar, corbet, christoffer.dall, marc.zyngier, james.morse, linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel Cc: gengdongjiu, huangshaoyu, zhengxiang9 ACPI 6.x adds support for NOTIFY_SEI as a GHES notification mechanism, so add new GHES notification handling functions. Expose API ghes_notify_sei() to arch code, arch code will call this API when it gets this NOTIFY_SEI. Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com> --- drivers/acpi/apei/Kconfig | 15 ++++++++++++++ drivers/acpi/apei/ghes.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++ include/acpi/ghes.h | 1 + 3 files changed, 69 insertions(+) diff --git a/drivers/acpi/apei/Kconfig b/drivers/acpi/apei/Kconfig index 52ae543..ff4afc3 100644 --- a/drivers/acpi/apei/Kconfig +++ b/drivers/acpi/apei/Kconfig @@ -55,6 +55,21 @@ config ACPI_APEI_SEA option allows the OS to look for such hardware error record, and take appropriate action. +config ACPI_APEI_SEI + bool "APEI SError(System Error) Interrupt logging/recovering support" + depends on ARM64 && ACPI_APEI_GHES + default y + help + This option should be enabled if the system supports + firmware first handling of SEI (SError interrupt). + + SEI happens with asynchronous external abort for errors on device + memory reads on ARMv8 systems. If a system supports firmware first + handling of SEI, the platform analyzes and handles hardware error + notifications from SEI, and it may then form a hardware error record for + the OS to parse and handle. This option allows the OS to look for + such hardware error record, and take appropriate action. + config ACPI_APEI_MEMORY_FAILURE bool "APEI memory error recovering support" depends on ACPI_APEI && MEMORY_FAILURE diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index 1efefe9..33f77ae 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -827,6 +827,46 @@ static inline void ghes_sea_add(struct ghes *ghes) { } static inline void ghes_sea_remove(struct ghes *ghes) { } #endif /* CONFIG_ACPI_APEI_SEA */ +#ifdef CONFIG_ACPI_APEI_SEI +static LIST_HEAD(ghes_sei); + +/* + * Return 0 only if one of the SEI error sources successfully reported an error + * record sent from the firmware. + */ +int ghes_notify_sei(void) +{ + struct ghes *ghes; + int ret = -ENOENT; + + rcu_read_lock(); + list_for_each_entry_rcu(ghes, &ghes_sei, list) { + if (!ghes_proc(ghes)) + ret = 0; + } + rcu_read_unlock(); + return ret; +} + +static void ghes_sei_add(struct ghes *ghes) +{ + mutex_lock(&ghes_list_mutex); + list_add_rcu(&ghes->list, &ghes_sei); + mutex_unlock(&ghes_list_mutex); +} + +static void ghes_sei_remove(struct ghes *ghes) +{ + mutex_lock(&ghes_list_mutex); + list_del_rcu(&ghes->list); + mutex_unlock(&ghes_list_mutex); + synchronize_rcu(); +} +#else /* CONFIG_ACPI_APEI_SEI */ +static inline void ghes_sei_add(struct ghes *ghes) { } +static inline void ghes_sei_remove(struct ghes *ghes) { } +#endif /* CONFIG_ACPI_APEI_SEI */ + #ifdef CONFIG_HAVE_ACPI_APEI_NMI /* * printk is not safe in NMI context. So in NMI handler, we allocate @@ -1055,6 +1095,13 @@ static int ghes_probe(struct platform_device *ghes_dev) goto err; } break; + case ACPI_HEST_NOTIFY_SEI: + if (!IS_ENABLED(CONFIG_ACPI_APEI_SEI)) { + pr_warn(GHES_PFX "Generic hardware error source: %d notified via SEI is not supported!\n", + generic->header.source_id); + goto err; + } + break; case ACPI_HEST_NOTIFY_NMI: if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_NMI)) { pr_warn(GHES_PFX "Generic hardware error source: %d notified via NMI interrupt is not supported!\n", @@ -1126,6 +1173,9 @@ static int ghes_probe(struct platform_device *ghes_dev) case ACPI_HEST_NOTIFY_SEA: ghes_sea_add(ghes); break; + case ACPI_HEST_NOTIFY_SEI: + ghes_sei_add(ghes); + break; case ACPI_HEST_NOTIFY_NMI: ghes_nmi_add(ghes); break; @@ -1179,6 +1229,9 @@ static int ghes_remove(struct platform_device *ghes_dev) case ACPI_HEST_NOTIFY_SEA: ghes_sea_remove(ghes); break; + case ACPI_HEST_NOTIFY_SEI: + ghes_sei_remove(ghes); + break; case ACPI_HEST_NOTIFY_NMI: ghes_nmi_remove(ghes); break; diff --git a/include/acpi/ghes.h b/include/acpi/ghes.h index 8feb0c8..9ba59e2 100644 --- a/include/acpi/ghes.h +++ b/include/acpi/ghes.h @@ -120,5 +120,6 @@ static inline void *acpi_hest_get_next(struct acpi_hest_generic_data *gdata) section = acpi_hest_get_next(section)) int ghes_notify_sea(void); +int ghes_notify_sei(void); #endif /* GHES_H */ -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v11 3/4] ACPI / APEI: Add SEI notification type support for ARMv8 @ 2018-04-09 21:36 ` Dongjiu Geng 0 siblings, 0 replies; 58+ messages in thread From: Dongjiu Geng @ 2018-04-09 21:36 UTC (permalink / raw) To: rkrcmar, corbet, christoffer.dall, marc.zyngier, james.morse, linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel Cc: gengdongjiu, huangshaoyu, zhengxiang9 ACPI 6.x adds support for NOTIFY_SEI as a GHES notification mechanism, so add new GHES notification handling functions. Expose API ghes_notify_sei() to arch code, arch code will call this API when it gets this NOTIFY_SEI. Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com> --- drivers/acpi/apei/Kconfig | 15 ++++++++++++++ drivers/acpi/apei/ghes.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++ include/acpi/ghes.h | 1 + 3 files changed, 69 insertions(+) diff --git a/drivers/acpi/apei/Kconfig b/drivers/acpi/apei/Kconfig index 52ae543..ff4afc3 100644 --- a/drivers/acpi/apei/Kconfig +++ b/drivers/acpi/apei/Kconfig @@ -55,6 +55,21 @@ config ACPI_APEI_SEA option allows the OS to look for such hardware error record, and take appropriate action. +config ACPI_APEI_SEI + bool "APEI SError(System Error) Interrupt logging/recovering support" + depends on ARM64 && ACPI_APEI_GHES + default y + help + This option should be enabled if the system supports + firmware first handling of SEI (SError interrupt). + + SEI happens with asynchronous external abort for errors on device + memory reads on ARMv8 systems. If a system supports firmware first + handling of SEI, the platform analyzes and handles hardware error + notifications from SEI, and it may then form a hardware error record for + the OS to parse and handle. This option allows the OS to look for + such hardware error record, and take appropriate action. + config ACPI_APEI_MEMORY_FAILURE bool "APEI memory error recovering support" depends on ACPI_APEI && MEMORY_FAILURE diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index 1efefe9..33f77ae 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -827,6 +827,46 @@ static inline void ghes_sea_add(struct ghes *ghes) { } static inline void ghes_sea_remove(struct ghes *ghes) { } #endif /* CONFIG_ACPI_APEI_SEA */ +#ifdef CONFIG_ACPI_APEI_SEI +static LIST_HEAD(ghes_sei); + +/* + * Return 0 only if one of the SEI error sources successfully reported an error + * record sent from the firmware. + */ +int ghes_notify_sei(void) +{ + struct ghes *ghes; + int ret = -ENOENT; + + rcu_read_lock(); + list_for_each_entry_rcu(ghes, &ghes_sei, list) { + if (!ghes_proc(ghes)) + ret = 0; + } + rcu_read_unlock(); + return ret; +} + +static void ghes_sei_add(struct ghes *ghes) +{ + mutex_lock(&ghes_list_mutex); + list_add_rcu(&ghes->list, &ghes_sei); + mutex_unlock(&ghes_list_mutex); +} + +static void ghes_sei_remove(struct ghes *ghes) +{ + mutex_lock(&ghes_list_mutex); + list_del_rcu(&ghes->list); + mutex_unlock(&ghes_list_mutex); + synchronize_rcu(); +} +#else /* CONFIG_ACPI_APEI_SEI */ +static inline void ghes_sei_add(struct ghes *ghes) { } +static inline void ghes_sei_remove(struct ghes *ghes) { } +#endif /* CONFIG_ACPI_APEI_SEI */ + #ifdef CONFIG_HAVE_ACPI_APEI_NMI /* * printk is not safe in NMI context. So in NMI handler, we allocate @@ -1055,6 +1095,13 @@ static int ghes_probe(struct platform_device *ghes_dev) goto err; } break; + case ACPI_HEST_NOTIFY_SEI: + if (!IS_ENABLED(CONFIG_ACPI_APEI_SEI)) { + pr_warn(GHES_PFX "Generic hardware error source: %d notified via SEI is not supported!\n", + generic->header.source_id); + goto err; + } + break; case ACPI_HEST_NOTIFY_NMI: if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_NMI)) { pr_warn(GHES_PFX "Generic hardware error source: %d notified via NMI interrupt is not supported!\n", @@ -1126,6 +1173,9 @@ static int ghes_probe(struct platform_device *ghes_dev) case ACPI_HEST_NOTIFY_SEA: ghes_sea_add(ghes); break; + case ACPI_HEST_NOTIFY_SEI: + ghes_sei_add(ghes); + break; case ACPI_HEST_NOTIFY_NMI: ghes_nmi_add(ghes); break; @@ -1179,6 +1229,9 @@ static int ghes_remove(struct platform_device *ghes_dev) case ACPI_HEST_NOTIFY_SEA: ghes_sea_remove(ghes); break; + case ACPI_HEST_NOTIFY_SEI: + ghes_sei_remove(ghes); + break; case ACPI_HEST_NOTIFY_NMI: ghes_nmi_remove(ghes); break; diff --git a/include/acpi/ghes.h b/include/acpi/ghes.h index 8feb0c8..9ba59e2 100644 --- a/include/acpi/ghes.h +++ b/include/acpi/ghes.h @@ -120,5 +120,6 @@ static inline void *acpi_hest_get_next(struct acpi_hest_generic_data *gdata) section = acpi_hest_get_next(section)) int ghes_notify_sea(void); +int ghes_notify_sei(void); #endif /* GHES_H */ -- 1.9.1 ^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v11 4/4] arm64: handle NOTIFY_SEI notification by the APEI driver 2018-04-09 21:36 ` Dongjiu Geng ` (3 preceding siblings ...) (?) @ 2018-04-09 21:36 ` Dongjiu Geng -1 siblings, 0 replies; 58+ messages in thread From: Dongjiu Geng @ 2018-04-09 21:36 UTC (permalink / raw) To: rkrcmar, corbet, christoffer.dall, marc.zyngier, james.morse, linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel Cc: zhengxiang9, huangshaoyu, gengdongjiu Add a helper to handle the NOTIFY_SEI notification, when kernel gets the NOTIFY_SEI notification, call this helper and let APEI driver to handle this notification. Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com> --- arch/arm64/include/asm/system_misc.h | 1 + arch/arm64/kernel/traps.c | 4 ++++ arch/arm64/mm/fault.c | 10 ++++++++++ 3 files changed, 15 insertions(+) diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h index 07aa8e3..9ee13ad 100644 --- a/arch/arm64/include/asm/system_misc.h +++ b/arch/arm64/include/asm/system_misc.h @@ -57,6 +57,7 @@ void hook_debug_fault_code(int nr, int (*fn)(unsigned long, unsigned int, }) int handle_guest_sea(phys_addr_t addr, unsigned int esr); +int handle_guest_sei(void); #endif /* __ASSEMBLY__ */ diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c index bbb0fde..d888eb2 100644 --- a/arch/arm64/kernel/traps.c +++ b/arch/arm64/kernel/traps.c @@ -681,6 +681,10 @@ bool arm64_is_fatal_ras_serror(struct pt_regs *regs, unsigned int esr) { u32 aet = arm64_ras_serror_get_severity(esr); + /* The APEI driver may handle this RAS error. */ + if (!handle_guest_sei()) + return false; + switch (aet) { case ESR_ELx_AET_CE: /* corrected error */ case ESR_ELx_AET_UEO: /* restartable, not yet consumed */ diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c index f76bb2c..8f29bd8 100644 --- a/arch/arm64/mm/fault.c +++ b/arch/arm64/mm/fault.c @@ -683,6 +683,16 @@ int handle_guest_sea(phys_addr_t addr, unsigned int esr) return ret; } +int handle_guest_sei(void) +{ + int ret = -ENOENT; + + if (IS_ENABLED(CONFIG_ACPI_APEI_SEI)) + ret = ghes_notify_sei(); + + return ret; +} + asmlinkage void __exception do_mem_abort(unsigned long addr, unsigned int esr, struct pt_regs *regs) { -- 1.9.1 ^ permalink raw reply related [flat|nested] 58+ messages in thread
* [Devel] [PATCH v11 4/4] arm64: handle NOTIFY_SEI notification by the APEI driver @ 2018-04-09 21:36 ` Dongjiu Geng 0 siblings, 0 replies; 58+ messages in thread From: Dongjiu Geng @ 2018-04-09 21:36 UTC (permalink / raw) To: devel [-- Attachment #1: Type: text/plain, Size: 1924 bytes --] Add a helper to handle the NOTIFY_SEI notification, when kernel gets the NOTIFY_SEI notification, call this helper and let APEI driver to handle this notification. Signed-off-by: Dongjiu Geng <gengdongjiu(a)huawei.com> --- arch/arm64/include/asm/system_misc.h | 1 + arch/arm64/kernel/traps.c | 4 ++++ arch/arm64/mm/fault.c | 10 ++++++++++ 3 files changed, 15 insertions(+) diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h index 07aa8e3..9ee13ad 100644 --- a/arch/arm64/include/asm/system_misc.h +++ b/arch/arm64/include/asm/system_misc.h @@ -57,6 +57,7 @@ void hook_debug_fault_code(int nr, int (*fn)(unsigned long, unsigned int, }) int handle_guest_sea(phys_addr_t addr, unsigned int esr); +int handle_guest_sei(void); #endif /* __ASSEMBLY__ */ diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c index bbb0fde..d888eb2 100644 --- a/arch/arm64/kernel/traps.c +++ b/arch/arm64/kernel/traps.c @@ -681,6 +681,10 @@ bool arm64_is_fatal_ras_serror(struct pt_regs *regs, unsigned int esr) { u32 aet = arm64_ras_serror_get_severity(esr); + /* The APEI driver may handle this RAS error. */ + if (!handle_guest_sei()) + return false; + switch (aet) { case ESR_ELx_AET_CE: /* corrected error */ case ESR_ELx_AET_UEO: /* restartable, not yet consumed */ diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c index f76bb2c..8f29bd8 100644 --- a/arch/arm64/mm/fault.c +++ b/arch/arm64/mm/fault.c @@ -683,6 +683,16 @@ int handle_guest_sea(phys_addr_t addr, unsigned int esr) return ret; } +int handle_guest_sei(void) +{ + int ret = -ENOENT; + + if (IS_ENABLED(CONFIG_ACPI_APEI_SEI)) + ret = ghes_notify_sei(); + + return ret; +} + asmlinkage void __exception do_mem_abort(unsigned long addr, unsigned int esr, struct pt_regs *regs) { -- 1.9.1 ^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v11 4/4] arm64: handle NOTIFY_SEI notification by the APEI driver @ 2018-04-09 21:36 ` Dongjiu Geng 0 siblings, 0 replies; 58+ messages in thread From: Dongjiu Geng @ 2018-04-09 21:36 UTC (permalink / raw) To: linux-arm-kernel Add a helper to handle the NOTIFY_SEI notification, when kernel gets the NOTIFY_SEI notification, call this helper and let APEI driver to handle this notification. Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com> --- arch/arm64/include/asm/system_misc.h | 1 + arch/arm64/kernel/traps.c | 4 ++++ arch/arm64/mm/fault.c | 10 ++++++++++ 3 files changed, 15 insertions(+) diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h index 07aa8e3..9ee13ad 100644 --- a/arch/arm64/include/asm/system_misc.h +++ b/arch/arm64/include/asm/system_misc.h @@ -57,6 +57,7 @@ void hook_debug_fault_code(int nr, int (*fn)(unsigned long, unsigned int, }) int handle_guest_sea(phys_addr_t addr, unsigned int esr); +int handle_guest_sei(void); #endif /* __ASSEMBLY__ */ diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c index bbb0fde..d888eb2 100644 --- a/arch/arm64/kernel/traps.c +++ b/arch/arm64/kernel/traps.c @@ -681,6 +681,10 @@ bool arm64_is_fatal_ras_serror(struct pt_regs *regs, unsigned int esr) { u32 aet = arm64_ras_serror_get_severity(esr); + /* The APEI driver may handle this RAS error. */ + if (!handle_guest_sei()) + return false; + switch (aet) { case ESR_ELx_AET_CE: /* corrected error */ case ESR_ELx_AET_UEO: /* restartable, not yet consumed */ diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c index f76bb2c..8f29bd8 100644 --- a/arch/arm64/mm/fault.c +++ b/arch/arm64/mm/fault.c @@ -683,6 +683,16 @@ int handle_guest_sea(phys_addr_t addr, unsigned int esr) return ret; } +int handle_guest_sei(void) +{ + int ret = -ENOENT; + + if (IS_ENABLED(CONFIG_ACPI_APEI_SEI)) + ret = ghes_notify_sei(); + + return ret; +} + asmlinkage void __exception do_mem_abort(unsigned long addr, unsigned int esr, struct pt_regs *regs) { -- 1.9.1 ^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v11 4/4] arm64: handle NOTIFY_SEI notification by the APEI driver @ 2018-04-09 21:36 ` Dongjiu Geng 0 siblings, 0 replies; 58+ messages in thread From: Dongjiu Geng @ 2018-04-09 21:36 UTC (permalink / raw) To: rkrcmar, corbet, christoffer.dall, marc.zyngier, james.morse, linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel Cc: zhengxiang9, huangshaoyu, gengdongjiu Add a helper to handle the NOTIFY_SEI notification, when kernel gets the NOTIFY_SEI notification, call this helper and let APEI driver to handle this notification. Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com> --- arch/arm64/include/asm/system_misc.h | 1 + arch/arm64/kernel/traps.c | 4 ++++ arch/arm64/mm/fault.c | 10 ++++++++++ 3 files changed, 15 insertions(+) diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h index 07aa8e3..9ee13ad 100644 --- a/arch/arm64/include/asm/system_misc.h +++ b/arch/arm64/include/asm/system_misc.h @@ -57,6 +57,7 @@ void hook_debug_fault_code(int nr, int (*fn)(unsigned long, unsigned int, }) int handle_guest_sea(phys_addr_t addr, unsigned int esr); +int handle_guest_sei(void); #endif /* __ASSEMBLY__ */ diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c index bbb0fde..d888eb2 100644 --- a/arch/arm64/kernel/traps.c +++ b/arch/arm64/kernel/traps.c @@ -681,6 +681,10 @@ bool arm64_is_fatal_ras_serror(struct pt_regs *regs, unsigned int esr) { u32 aet = arm64_ras_serror_get_severity(esr); + /* The APEI driver may handle this RAS error. */ + if (!handle_guest_sei()) + return false; + switch (aet) { case ESR_ELx_AET_CE: /* corrected error */ case ESR_ELx_AET_UEO: /* restartable, not yet consumed */ diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c index f76bb2c..8f29bd8 100644 --- a/arch/arm64/mm/fault.c +++ b/arch/arm64/mm/fault.c @@ -683,6 +683,16 @@ int handle_guest_sea(phys_addr_t addr, unsigned int esr) return ret; } +int handle_guest_sei(void) +{ + int ret = -ENOENT; + + if (IS_ENABLED(CONFIG_ACPI_APEI_SEI)) + ret = ghes_notify_sei(); + + return ret; +} + asmlinkage void __exception do_mem_abort(unsigned long addr, unsigned int esr, struct pt_regs *regs) { -- 1.9.1 ^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v11 4/4] arm64: handle NOTIFY_SEI notification by the APEI driver @ 2018-04-09 21:36 ` Dongjiu Geng 0 siblings, 0 replies; 58+ messages in thread From: Dongjiu Geng @ 2018-04-09 21:36 UTC (permalink / raw) To: rkrcmar, corbet, christoffer.dall, marc.zyngier, james.morse, linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel Cc: gengdongjiu, huangshaoyu, zhengxiang9 Add a helper to handle the NOTIFY_SEI notification, when kernel gets the NOTIFY_SEI notification, call this helper and let APEI driver to handle this notification. Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com> --- arch/arm64/include/asm/system_misc.h | 1 + arch/arm64/kernel/traps.c | 4 ++++ arch/arm64/mm/fault.c | 10 ++++++++++ 3 files changed, 15 insertions(+) diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h index 07aa8e3..9ee13ad 100644 --- a/arch/arm64/include/asm/system_misc.h +++ b/arch/arm64/include/asm/system_misc.h @@ -57,6 +57,7 @@ void hook_debug_fault_code(int nr, int (*fn)(unsigned long, unsigned int, }) int handle_guest_sea(phys_addr_t addr, unsigned int esr); +int handle_guest_sei(void); #endif /* __ASSEMBLY__ */ diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c index bbb0fde..d888eb2 100644 --- a/arch/arm64/kernel/traps.c +++ b/arch/arm64/kernel/traps.c @@ -681,6 +681,10 @@ bool arm64_is_fatal_ras_serror(struct pt_regs *regs, unsigned int esr) { u32 aet = arm64_ras_serror_get_severity(esr); + /* The APEI driver may handle this RAS error. */ + if (!handle_guest_sei()) + return false; + switch (aet) { case ESR_ELx_AET_CE: /* corrected error */ case ESR_ELx_AET_UEO: /* restartable, not yet consumed */ diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c index f76bb2c..8f29bd8 100644 --- a/arch/arm64/mm/fault.c +++ b/arch/arm64/mm/fault.c @@ -683,6 +683,16 @@ int handle_guest_sea(phys_addr_t addr, unsigned int esr) return ret; } +int handle_guest_sei(void) +{ + int ret = -ENOENT; + + if (IS_ENABLED(CONFIG_ACPI_APEI_SEI)) + ret = ghes_notify_sei(); + + return ret; +} + asmlinkage void __exception do_mem_abort(unsigned long addr, unsigned int esr, struct pt_regs *regs) { -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v11 4/4] arm64: handle NOTIFY_SEI notification by the APEI driver @ 2018-04-09 21:36 ` Dongjiu Geng 0 siblings, 0 replies; 58+ messages in thread From: Dongjiu Geng @ 2018-04-09 21:36 UTC (permalink / raw) To: rkrcmar, corbet, christoffer.dall, marc.zyngier, james.morse, linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel Cc: gengdongjiu, huangshaoyu, zhengxiang9 Add a helper to handle the NOTIFY_SEI notification, when kernel gets the NOTIFY_SEI notification, call this helper and let APEI driver to handle this notification. Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com> --- arch/arm64/include/asm/system_misc.h | 1 + arch/arm64/kernel/traps.c | 4 ++++ arch/arm64/mm/fault.c | 10 ++++++++++ 3 files changed, 15 insertions(+) diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h index 07aa8e3..9ee13ad 100644 --- a/arch/arm64/include/asm/system_misc.h +++ b/arch/arm64/include/asm/system_misc.h @@ -57,6 +57,7 @@ void hook_debug_fault_code(int nr, int (*fn)(unsigned long, unsigned int, }) int handle_guest_sea(phys_addr_t addr, unsigned int esr); +int handle_guest_sei(void); #endif /* __ASSEMBLY__ */ diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c index bbb0fde..d888eb2 100644 --- a/arch/arm64/kernel/traps.c +++ b/arch/arm64/kernel/traps.c @@ -681,6 +681,10 @@ bool arm64_is_fatal_ras_serror(struct pt_regs *regs, unsigned int esr) { u32 aet = arm64_ras_serror_get_severity(esr); + /* The APEI driver may handle this RAS error. */ + if (!handle_guest_sei()) + return false; + switch (aet) { case ESR_ELx_AET_CE: /* corrected error */ case ESR_ELx_AET_UEO: /* restartable, not yet consumed */ diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c index f76bb2c..8f29bd8 100644 --- a/arch/arm64/mm/fault.c +++ b/arch/arm64/mm/fault.c @@ -683,6 +683,16 @@ int handle_guest_sea(phys_addr_t addr, unsigned int esr) return ret; } +int handle_guest_sei(void) +{ + int ret = -ENOENT; + + if (IS_ENABLED(CONFIG_ACPI_APEI_SEI)) + ret = ghes_notify_sei(); + + return ret; +} + asmlinkage void __exception do_mem_abort(unsigned long addr, unsigned int esr, struct pt_regs *regs) { -- 1.9.1 ^ permalink raw reply related [flat|nested] 58+ messages in thread
* Re: [PATCH v11 0/4] set VSESR_EL2 by user space and support NOTIFY_SEI notification 2018-04-09 21:36 ` Dongjiu Geng (?) (?) @ 2018-04-10 14:15 ` James Morse -1 siblings, 0 replies; 58+ messages in thread From: James Morse @ 2018-04-10 14:15 UTC (permalink / raw) To: Dongjiu Geng Cc: rkrcmar, corbet, christoffer.dall, marc.zyngier, linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel, huangshaoyu, zhengxiang9 Hi Dongjiu Geng, On 09/04/18 22:36, Dongjiu Geng wrote: > 1. Detect whether KVM can set set guest SError syndrome > 2. Support to Set VSESR_EL2 and inject SError by user space. > 3. Support live migration to keep SError pending state and VSESR_EL2 value. > 4. ACPI 6.1 adds support for NOTIFY_SEI as a GHES notification mechanism, so support this > notification in software, KVM or kernel ARCH code call handle_guest_sei() to let ACP driver > to handle this notification. Please don't post code during the merge-window, will this apply to v4.17-rc1? We can't know until its tagged. This series is doing two separate things, please split it into two series. But on the ACPI front: I don't see how any OS can support your NOTIFY_SEI when firmware is ignoring the normal world's PSTATE.A. The latest lobe of that discussion was on the list here: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1611496.html As it is, we would need to spot SError being delivered while SError is masked, spray nasty messages about firmware being horrifically buggy, then panic(). For a corrected error, this looks bad, but its preferable to letting firmware silently overwrite the exception registers, causing linux to spin through the vectors 'eret' with all exceptions masked. I still think its best to wait for firmware that does the right thing. Thanks, James ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [Devel] [PATCH v11 0/4] set VSESR_EL2 by user space and support NOTIFY_SEI notification @ 2018-04-10 14:15 ` James Morse 0 siblings, 0 replies; 58+ messages in thread From: James Morse @ 2018-04-10 14:15 UTC (permalink / raw) To: devel [-- Attachment #1: Type: text/plain, Size: 1409 bytes --] Hi Dongjiu Geng, On 09/04/18 22:36, Dongjiu Geng wrote: > 1. Detect whether KVM can set set guest SError syndrome > 2. Support to Set VSESR_EL2 and inject SError by user space. > 3. Support live migration to keep SError pending state and VSESR_EL2 value. > 4. ACPI 6.1 adds support for NOTIFY_SEI as a GHES notification mechanism, so support this > notification in software, KVM or kernel ARCH code call handle_guest_sei() to let ACP driver > to handle this notification. Please don't post code during the merge-window, will this apply to v4.17-rc1? We can't know until its tagged. This series is doing two separate things, please split it into two series. But on the ACPI front: I don't see how any OS can support your NOTIFY_SEI when firmware is ignoring the normal world's PSTATE.A. The latest lobe of that discussion was on the list here: https://www.mail-archive.com/linux-kernel(a)vger.kernel.org/msg1611496.html As it is, we would need to spot SError being delivered while SError is masked, spray nasty messages about firmware being horrifically buggy, then panic(). For a corrected error, this looks bad, but its preferable to letting firmware silently overwrite the exception registers, causing linux to spin through the vectors 'eret' with all exceptions masked. I still think its best to wait for firmware that does the right thing. Thanks, James ^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v11 0/4] set VSESR_EL2 by user space and support NOTIFY_SEI notification @ 2018-04-10 14:15 ` James Morse 0 siblings, 0 replies; 58+ messages in thread From: James Morse @ 2018-04-10 14:15 UTC (permalink / raw) To: linux-arm-kernel Hi Dongjiu Geng, On 09/04/18 22:36, Dongjiu Geng wrote: > 1. Detect whether KVM can set set guest SError syndrome > 2. Support to Set VSESR_EL2 and inject SError by user space. > 3. Support live migration to keep SError pending state and VSESR_EL2 value. > 4. ACPI 6.1 adds support for NOTIFY_SEI as a GHES notification mechanism, so support this > notification in software, KVM or kernel ARCH code call handle_guest_sei() to let ACP driver > to handle this notification. Please don't post code during the merge-window, will this apply to v4.17-rc1? We can't know until its tagged. This series is doing two separate things, please split it into two series. But on the ACPI front: I don't see how any OS can support your NOTIFY_SEI when firmware is ignoring the normal world's PSTATE.A. The latest lobe of that discussion was on the list here: https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1611496.html As it is, we would need to spot SError being delivered while SError is masked, spray nasty messages about firmware being horrifically buggy, then panic(). For a corrected error, this looks bad, but its preferable to letting firmware silently overwrite the exception registers, causing linux to spin through the vectors 'eret' with all exceptions masked. I still think its best to wait for firmware that does the right thing. Thanks, James ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v11 0/4] set VSESR_EL2 by user space and support NOTIFY_SEI notification @ 2018-04-10 14:15 ` James Morse 0 siblings, 0 replies; 58+ messages in thread From: James Morse @ 2018-04-10 14:15 UTC (permalink / raw) To: Dongjiu Geng Cc: rkrcmar, corbet, christoffer.dall, marc.zyngier, linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel, huangshaoyu, zhengxiang9 Hi Dongjiu Geng, On 09/04/18 22:36, Dongjiu Geng wrote: > 1. Detect whether KVM can set set guest SError syndrome > 2. Support to Set VSESR_EL2 and inject SError by user space. > 3. Support live migration to keep SError pending state and VSESR_EL2 value. > 4. ACPI 6.1 adds support for NOTIFY_SEI as a GHES notification mechanism, so support this > notification in software, KVM or kernel ARCH code call handle_guest_sei() to let ACP driver > to handle this notification. Please don't post code during the merge-window, will this apply to v4.17-rc1? We can't know until its tagged. This series is doing two separate things, please split it into two series. But on the ACPI front: I don't see how any OS can support your NOTIFY_SEI when firmware is ignoring the normal world's PSTATE.A. The latest lobe of that discussion was on the list here: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1611496.html As it is, we would need to spot SError being delivered while SError is masked, spray nasty messages about firmware being horrifically buggy, then panic(). For a corrected error, this looks bad, but its preferable to letting firmware silently overwrite the exception registers, causing linux to spin through the vectors 'eret' with all exceptions masked. I still think its best to wait for firmware that does the right thing. Thanks, James -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v11 0/4] set VSESR_EL2 by user space and support NOTIFY_SEI notification 2018-04-10 14:15 ` James Morse ` (2 preceding siblings ...) (?) @ 2018-04-12 6:09 ` gengdongjiu -1 siblings, 0 replies; 58+ messages in thread From: gengdongjiu @ 2018-04-12 6:09 UTC (permalink / raw) To: James Morse Cc: rkrcmar, corbet, christoffer.dall, marc.zyngier, linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel, huangshaoyu, zhengxiang9 Hi James， thanks for this mail. On 2018/4/10 22:15, James Morse wrote: > Hi Dongjiu Geng, > > On 09/04/18 22:36, Dongjiu Geng wrote: >> 1. Detect whether KVM can set set guest SError syndrome >> 2. Support to Set VSESR_EL2 and inject SError by user space. >> 3. Support live migration to keep SError pending state and VSESR_EL2 value. >> 4. ACPI 6.1 adds support for NOTIFY_SEI as a GHES notification mechanism, so support this >> notification in software, KVM or kernel ARCH code call handle_guest_sei() to let ACP driver >> to handle this notification. > > Please don't post code during the merge-window, will this apply to v4.17-rc1? We > can't know until its tagged. I do not know when it is merge-window. About the apply version, it does not have limited. > > > This series is doing two separate things, please split it into two series. OK, thanks! > > But on the ACPI front: I don't see how any OS can support your NOTIFY_SEI when > firmware is ignoring the normal world's PSTATE.A. > > The latest lobe of that discussion was on the list here: > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1611496.html I have replied the mail. I still have some questions that need to clarify with you. After clarification, we will follow that. The question is in the reply of this mail "https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1611496.html" > > > As it is, we would need to spot SError being delivered while SError is masked, > spray nasty messages about firmware being horrifically buggy, then panic(). For > a corrected error, this looks bad, but its preferable to letting firmware > silently overwrite the exception registers, causing linux to spin through the > vectors 'eret' with all exceptions masked. > I still think its best to wait for firmware that does the right thing. Let us discuss that in another mail. In a summary, I think firmware follow below rule can be OK, right? 1. The exception came from the EL that SError should be routed to(according to hcr_EL2.{AMO, TGE}),but PSTATE.A was set, EL3 firmware can't deliver SError; 2. The exception came from the EL that SError should not be routed to(according to hcr_EL2.{AMO, TGE}),even though the PSTATE.A was set,EL3 firmware still deliver SError > > > Thanks, > > James > > . > ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [Devel] [PATCH v11 0/4] set VSESR_EL2 by user space and support NOTIFY_SEI notification @ 2018-04-12 6:09 ` gengdongjiu 0 siblings, 0 replies; 58+ messages in thread From: gengdongjiu @ 2018-04-12 6:09 UTC (permalink / raw) To: devel [-- Attachment #1: Type: text/plain, Size: 2364 bytes --] Hi James， thanks for this mail. On 2018/4/10 22:15, James Morse wrote: > Hi Dongjiu Geng, > > On 09/04/18 22:36, Dongjiu Geng wrote: >> 1. Detect whether KVM can set set guest SError syndrome >> 2. Support to Set VSESR_EL2 and inject SError by user space. >> 3. Support live migration to keep SError pending state and VSESR_EL2 value. >> 4. ACPI 6.1 adds support for NOTIFY_SEI as a GHES notification mechanism, so support this >> notification in software, KVM or kernel ARCH code call handle_guest_sei() to let ACP driver >> to handle this notification. > > Please don't post code during the merge-window, will this apply to v4.17-rc1? We > can't know until its tagged. I do not know when it is merge-window. About the apply version, it does not have limited. > > > This series is doing two separate things, please split it into two series. OK, thanks! > > But on the ACPI front: I don't see how any OS can support your NOTIFY_SEI when > firmware is ignoring the normal world's PSTATE.A. > > The latest lobe of that discussion was on the list here: > https://www.mail-archive.com/linux-kernel(a)vger.kernel.org/msg1611496.html I have replied the mail. I still have some questions that need to clarify with you. After clarification, we will follow that. The question is in the reply of this mail "https://www.mail-archive.com/linux-kernel(a)vger.kernel.org/msg1611496.html" > > > As it is, we would need to spot SError being delivered while SError is masked, > spray nasty messages about firmware being horrifically buggy, then panic(). For > a corrected error, this looks bad, but its preferable to letting firmware > silently overwrite the exception registers, causing linux to spin through the > vectors 'eret' with all exceptions masked. > I still think its best to wait for firmware that does the right thing. Let us discuss that in another mail. In a summary, I think firmware follow below rule can be OK, right? 1. The exception came from the EL that SError should be routed to(according to hcr_EL2.{AMO, TGE}),but PSTATE.A was set, EL3 firmware can't deliver SError; 2. The exception came from the EL that SError should not be routed to(according to hcr_EL2.{AMO, TGE}),even though the PSTATE.A was set,EL3 firmware still deliver SError > > > Thanks, > > James > > . > ^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v11 0/4] set VSESR_EL2 by user space and support NOTIFY_SEI notification @ 2018-04-12 6:09 ` gengdongjiu 0 siblings, 0 replies; 58+ messages in thread From: gengdongjiu @ 2018-04-12 6:09 UTC (permalink / raw) To: linux-arm-kernel Hi James? thanks for this mail. On 2018/4/10 22:15, James Morse wrote: > Hi Dongjiu Geng, > > On 09/04/18 22:36, Dongjiu Geng wrote: >> 1. Detect whether KVM can set set guest SError syndrome >> 2. Support to Set VSESR_EL2 and inject SError by user space. >> 3. Support live migration to keep SError pending state and VSESR_EL2 value. >> 4. ACPI 6.1 adds support for NOTIFY_SEI as a GHES notification mechanism, so support this >> notification in software, KVM or kernel ARCH code call handle_guest_sei() to let ACP driver >> to handle this notification. > > Please don't post code during the merge-window, will this apply to v4.17-rc1? We > can't know until its tagged. I do not know when it is merge-window. About the apply version, it does not have limited. > > > This series is doing two separate things, please split it into two series. OK, thanks! > > But on the ACPI front: I don't see how any OS can support your NOTIFY_SEI when > firmware is ignoring the normal world's PSTATE.A. > > The latest lobe of that discussion was on the list here: > https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1611496.html I have replied the mail. I still have some questions that need to clarify with you. After clarification, we will follow that. The question is in the reply of this mail "https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1611496.html" > > > As it is, we would need to spot SError being delivered while SError is masked, > spray nasty messages about firmware being horrifically buggy, then panic(). For > a corrected error, this looks bad, but its preferable to letting firmware > silently overwrite the exception registers, causing linux to spin through the > vectors 'eret' with all exceptions masked. > I still think its best to wait for firmware that does the right thing. Let us discuss that in another mail. In a summary, I think firmware follow below rule can be OK, right? 1. The exception came from the EL that SError should be routed to(according to hcr_EL2.{AMO, TGE}),but PSTATE.A was set, EL3 firmware can't deliver SError; 2. The exception came from the EL that SError should not be routed to(according to hcr_EL2.{AMO, TGE}),even though the PSTATE.A was set,EL3 firmware still deliver SError > > > Thanks, > > James > > . > ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v11 0/4] set VSESR_EL2 by user space and support NOTIFY_SEI notification @ 2018-04-12 6:09 ` gengdongjiu 0 siblings, 0 replies; 58+ messages in thread From: gengdongjiu @ 2018-04-12 6:09 UTC (permalink / raw) To: James Morse Cc: rkrcmar, corbet, christoffer.dall, marc.zyngier, linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel, huangshaoyu, zhengxiang9 Hi James， thanks for this mail. On 2018/4/10 22:15, James Morse wrote: > Hi Dongjiu Geng, > > On 09/04/18 22:36, Dongjiu Geng wrote: >> 1. Detect whether KVM can set set guest SError syndrome >> 2. Support to Set VSESR_EL2 and inject SError by user space. >> 3. Support live migration to keep SError pending state and VSESR_EL2 value. >> 4. ACPI 6.1 adds support for NOTIFY_SEI as a GHES notification mechanism, so support this >> notification in software, KVM or kernel ARCH code call handle_guest_sei() to let ACP driver >> to handle this notification. > > Please don't post code during the merge-window, will this apply to v4.17-rc1? We > can't know until its tagged. I do not know when it is merge-window. About the apply version, it does not have limited. > > > This series is doing two separate things, please split it into two series. OK, thanks! > > But on the ACPI front: I don't see how any OS can support your NOTIFY_SEI when > firmware is ignoring the normal world's PSTATE.A. > > The latest lobe of that discussion was on the list here: > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1611496.html I have replied the mail. I still have some questions that need to clarify with you. After clarification, we will follow that. The question is in the reply of this mail "https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1611496.html" > > > As it is, we would need to spot SError being delivered while SError is masked, > spray nasty messages about firmware being horrifically buggy, then panic(). For > a corrected error, this looks bad, but its preferable to letting firmware > silently overwrite the exception registers, causing linux to spin through the > vectors 'eret' with all exceptions masked. > I still think its best to wait for firmware that does the right thing. Let us discuss that in another mail. In a summary, I think firmware follow below rule can be OK, right? 1. The exception came from the EL that SError should be routed to(according to hcr_EL2.{AMO, TGE}),but PSTATE.A was set, EL3 firmware can't deliver SError; 2. The exception came from the EL that SError should not be routed to(according to hcr_EL2.{AMO, TGE}),even though the PSTATE.A was set,EL3 firmware still deliver SError > > > Thanks, > > James > > . > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v11 0/4] set VSESR_EL2 by user space and support NOTIFY_SEI notification @ 2018-04-12 6:09 ` gengdongjiu 0 siblings, 0 replies; 58+ messages in thread From: gengdongjiu @ 2018-04-12 6:09 UTC (permalink / raw) To: James Morse Cc: rkrcmar, corbet, christoffer.dall, marc.zyngier, linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel, huangshaoyu, zhengxiang9 Hi James， thanks for this mail. On 2018/4/10 22:15, James Morse wrote: > Hi Dongjiu Geng, > > On 09/04/18 22:36, Dongjiu Geng wrote: >> 1. Detect whether KVM can set set guest SError syndrome >> 2. Support to Set VSESR_EL2 and inject SError by user space. >> 3. Support live migration to keep SError pending state and VSESR_EL2 value. >> 4. ACPI 6.1 adds support for NOTIFY_SEI as a GHES notification mechanism, so support this >> notification in software, KVM or kernel ARCH code call handle_guest_sei() to let ACP driver >> to handle this notification. > > Please don't post code during the merge-window, will this apply to v4.17-rc1? We > can't know until its tagged. I do not know when it is merge-window. About the apply version, it does not have limited. > > > This series is doing two separate things, please split it into two series. OK, thanks! > > But on the ACPI front: I don't see how any OS can support your NOTIFY_SEI when > firmware is ignoring the normal world's PSTATE.A. > > The latest lobe of that discussion was on the list here: > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1611496.html I have replied the mail. I still have some questions that need to clarify with you. After clarification, we will follow that. The question is in the reply of this mail "https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1611496.html" > > > As it is, we would need to spot SError being delivered while SError is masked, > spray nasty messages about firmware being horrifically buggy, then panic(). For > a corrected error, this looks bad, but its preferable to letting firmware > silently overwrite the exception registers, causing linux to spin through the > vectors 'eret' with all exceptions masked. > I still think its best to wait for firmware that does the right thing. Let us discuss that in another mail. In a summary, I think firmware follow below rule can be OK, right? 1. The exception came from the EL that SError should be routed to(according to hcr_EL2.{AMO, TGE}),but PSTATE.A was set, EL3 firmware can't deliver SError; 2. The exception came from the EL that SError should not be routed to(according to hcr_EL2.{AMO, TGE}),even though the PSTATE.A was set,EL3 firmware still deliver SError > > > Thanks, > > James > > . > ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v11 0/4] set VSESR_EL2 by user space and support NOTIFY_SEI notification 2018-04-12 6:09 ` gengdongjiu (?) (?) @ 2018-04-12 16:14 ` James Morse -1 siblings, 0 replies; 58+ messages in thread From: James Morse @ 2018-04-12 16:14 UTC (permalink / raw) To: gengdongjiu Cc: rkrcmar, corbet, christoffer.dall, marc.zyngier, linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel, huangshaoyu, zhengxiang9 Hi gengdongjiu, On 12/04/18 07:09, gengdongjiu wrote: > On 2018/4/10 22:15, James Morse wrote: >> On 09/04/18 22:36, Dongjiu Geng wrote: >>> 1. Detect whether KVM can set set guest SError syndrome >>> 2. Support to Set VSESR_EL2 and inject SError by user space. >>> 3. Support live migration to keep SError pending state and VSESR_EL2 value. >>> 4. ACPI 6.1 adds support for NOTIFY_SEI as a GHES notification mechanism, so support this >>> notification in software, KVM or kernel ARCH code call handle_guest_sei() to let ACP driver >>> to handle this notification. >> >> Please don't post code during the merge-window, will this apply to v4.17-rc1? We >> can't know until its tagged. Posting code during the merge-window isn't helpful as the kernel is a moving target, its better to wait for an 'rc' to base it on. > I do not know when it is merge-window. About the apply version, it does not have limited. 'git fetch' Linus' tree and look at the tags. 'v4.16' lost its '-rc' suffixes, and there isn't a 'v4.17-rc1' yet, so we are still in the merge window. Linus sends a message to LKML. eg: https://lkml.org/lkml/2018/4/1/175 net-next closes shortly before the merge window, and re-opens afterwards. There is a handy web page: http://vger.kernel.org/~davem/net-next.html >> This series is doing two separate things, please split it into two series. > OK, thanks! > >> >> But on the ACPI front: I don't see how any OS can support your NOTIFY_SEI when >> firmware is ignoring the normal world's PSTATE.A. >> >> The latest lobe of that discussion was on the list here: >> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1611496.html > I have replied the mail. > I still have some questions that need to clarify with you. > After clarification, we will follow that. > The question is in the reply of this mail "https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1611496.html" Lets keep that discussion on v9 then. >> As it is, we would need to spot SError being delivered while SError is masked, >> spray nasty messages about firmware being horrifically buggy, then panic(). For >> a corrected error, this looks bad, but its preferable to letting firmware >> silently overwrite the exception registers, causing linux to spin through the >> vectors 'eret' with all exceptions masked. >> I still think its best to wait for firmware that does the right thing. > Let us discuss that in another mail. > In a summary, I think firmware follow below rule can be OK, right? > 1. The exception came from the EL that SError should be routed to(according to hcr_EL2.{AMO, TGE}),but PSTATE.A was set, EL3 firmware can't deliver SError; > 2. The exception came from the EL that SError should not be routed to(according to hcr_EL2.{AMO, TGE}),even though the PSTATE.A was set,EL3 firmware still deliver SError Problem here, more on v9. Thanks, James ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [Devel] [PATCH v11 0/4] set VSESR_EL2 by user space and support NOTIFY_SEI notification @ 2018-04-12 16:14 ` James Morse 0 siblings, 0 replies; 58+ messages in thread From: James Morse @ 2018-04-12 16:14 UTC (permalink / raw) To: devel [-- Attachment #1: Type: text/plain, Size: 2952 bytes --] Hi gengdongjiu, On 12/04/18 07:09, gengdongjiu wrote: > On 2018/4/10 22:15, James Morse wrote: >> On 09/04/18 22:36, Dongjiu Geng wrote: >>> 1. Detect whether KVM can set set guest SError syndrome >>> 2. Support to Set VSESR_EL2 and inject SError by user space. >>> 3. Support live migration to keep SError pending state and VSESR_EL2 value. >>> 4. ACPI 6.1 adds support for NOTIFY_SEI as a GHES notification mechanism, so support this >>> notification in software, KVM or kernel ARCH code call handle_guest_sei() to let ACP driver >>> to handle this notification. >> >> Please don't post code during the merge-window, will this apply to v4.17-rc1? We >> can't know until its tagged. Posting code during the merge-window isn't helpful as the kernel is a moving target, its better to wait for an 'rc' to base it on. > I do not know when it is merge-window. About the apply version, it does not have limited. 'git fetch' Linus' tree and look at the tags. 'v4.16' lost its '-rc' suffixes, and there isn't a 'v4.17-rc1' yet, so we are still in the merge window. Linus sends a message to LKML. eg: https://lkml.org/lkml/2018/4/1/175 net-next closes shortly before the merge window, and re-opens afterwards. There is a handy web page: http://vger.kernel.org/~davem/net-next.html >> This series is doing two separate things, please split it into two series. > OK, thanks! > >> >> But on the ACPI front: I don't see how any OS can support your NOTIFY_SEI when >> firmware is ignoring the normal world's PSTATE.A. >> >> The latest lobe of that discussion was on the list here: >> https://www.mail-archive.com/linux-kernel(a)vger.kernel.org/msg1611496.html > I have replied the mail. > I still have some questions that need to clarify with you. > After clarification, we will follow that. > The question is in the reply of this mail "https://www.mail-archive.com/linux-kernel(a)vger.kernel.org/msg1611496.html" Lets keep that discussion on v9 then. >> As it is, we would need to spot SError being delivered while SError is masked, >> spray nasty messages about firmware being horrifically buggy, then panic(). For >> a corrected error, this looks bad, but its preferable to letting firmware >> silently overwrite the exception registers, causing linux to spin through the >> vectors 'eret' with all exceptions masked. >> I still think its best to wait for firmware that does the right thing. > Let us discuss that in another mail. > In a summary, I think firmware follow below rule can be OK, right? > 1. The exception came from the EL that SError should be routed to(according to hcr_EL2.{AMO, TGE}),but PSTATE.A was set, EL3 firmware can't deliver SError; > 2. The exception came from the EL that SError should not be routed to(according to hcr_EL2.{AMO, TGE}),even though the PSTATE.A was set,EL3 firmware still deliver SError Problem here, more on v9. Thanks, James ^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v11 0/4] set VSESR_EL2 by user space and support NOTIFY_SEI notification @ 2018-04-12 16:14 ` James Morse 0 siblings, 0 replies; 58+ messages in thread From: James Morse @ 2018-04-12 16:14 UTC (permalink / raw) To: linux-arm-kernel Hi gengdongjiu, On 12/04/18 07:09, gengdongjiu wrote: > On 2018/4/10 22:15, James Morse wrote: >> On 09/04/18 22:36, Dongjiu Geng wrote: >>> 1. Detect whether KVM can set set guest SError syndrome >>> 2. Support to Set VSESR_EL2 and inject SError by user space. >>> 3. Support live migration to keep SError pending state and VSESR_EL2 value. >>> 4. ACPI 6.1 adds support for NOTIFY_SEI as a GHES notification mechanism, so support this >>> notification in software, KVM or kernel ARCH code call handle_guest_sei() to let ACP driver >>> to handle this notification. >> >> Please don't post code during the merge-window, will this apply to v4.17-rc1? We >> can't know until its tagged. Posting code during the merge-window isn't helpful as the kernel is a moving target, its better to wait for an 'rc' to base it on. > I do not know when it is merge-window. About the apply version, it does not have limited. 'git fetch' Linus' tree and look at the tags. 'v4.16' lost its '-rc' suffixes, and there isn't a 'v4.17-rc1' yet, so we are still in the merge window. Linus sends a message to LKML. eg: https://lkml.org/lkml/2018/4/1/175 net-next closes shortly before the merge window, and re-opens afterwards. There is a handy web page: http://vger.kernel.org/~davem/net-next.html >> This series is doing two separate things, please split it into two series. > OK, thanks! > >> >> But on the ACPI front: I don't see how any OS can support your NOTIFY_SEI when >> firmware is ignoring the normal world's PSTATE.A. >> >> The latest lobe of that discussion was on the list here: >> https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1611496.html > I have replied the mail. > I still have some questions that need to clarify with you. > After clarification, we will follow that. > The question is in the reply of this mail "https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1611496.html" Lets keep that discussion on v9 then. >> As it is, we would need to spot SError being delivered while SError is masked, >> spray nasty messages about firmware being horrifically buggy, then panic(). For >> a corrected error, this looks bad, but its preferable to letting firmware >> silently overwrite the exception registers, causing linux to spin through the >> vectors 'eret' with all exceptions masked. >> I still think its best to wait for firmware that does the right thing. > Let us discuss that in another mail. > In a summary, I think firmware follow below rule can be OK, right? > 1. The exception came from the EL that SError should be routed to(according to hcr_EL2.{AMO, TGE}),but PSTATE.A was set, EL3 firmware can't deliver SError; > 2. The exception came from the EL that SError should not be routed to(according to hcr_EL2.{AMO, TGE}),even though the PSTATE.A was set,EL3 firmware still deliver SError Problem here, more on v9. Thanks, James ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v11 0/4] set VSESR_EL2 by user space and support NOTIFY_SEI notification @ 2018-04-12 16:14 ` James Morse 0 siblings, 0 replies; 58+ messages in thread From: James Morse @ 2018-04-12 16:14 UTC (permalink / raw) To: gengdongjiu Cc: rkrcmar, corbet, christoffer.dall, marc.zyngier, linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel, huangshaoyu, zhengxiang9 Hi gengdongjiu, On 12/04/18 07:09, gengdongjiu wrote: > On 2018/4/10 22:15, James Morse wrote: >> On 09/04/18 22:36, Dongjiu Geng wrote: >>> 1. Detect whether KVM can set set guest SError syndrome >>> 2. Support to Set VSESR_EL2 and inject SError by user space. >>> 3. Support live migration to keep SError pending state and VSESR_EL2 value. >>> 4. ACPI 6.1 adds support for NOTIFY_SEI as a GHES notification mechanism, so support this >>> notification in software, KVM or kernel ARCH code call handle_guest_sei() to let ACP driver >>> to handle this notification. >> >> Please don't post code during the merge-window, will this apply to v4.17-rc1? We >> can't know until its tagged. Posting code during the merge-window isn't helpful as the kernel is a moving target, its better to wait for an 'rc' to base it on. > I do not know when it is merge-window. About the apply version, it does not have limited. 'git fetch' Linus' tree and look at the tags. 'v4.16' lost its '-rc' suffixes, and there isn't a 'v4.17-rc1' yet, so we are still in the merge window. Linus sends a message to LKML. eg: https://lkml.org/lkml/2018/4/1/175 net-next closes shortly before the merge window, and re-opens afterwards. There is a handy web page: http://vger.kernel.org/~davem/net-next.html >> This series is doing two separate things, please split it into two series. > OK, thanks! > >> >> But on the ACPI front: I don't see how any OS can support your NOTIFY_SEI when >> firmware is ignoring the normal world's PSTATE.A. >> >> The latest lobe of that discussion was on the list here: >> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1611496.html > I have replied the mail. > I still have some questions that need to clarify with you. > After clarification, we will follow that. > The question is in the reply of this mail "https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1611496.html" Lets keep that discussion on v9 then. >> As it is, we would need to spot SError being delivered while SError is masked, >> spray nasty messages about firmware being horrifically buggy, then panic(). For >> a corrected error, this looks bad, but its preferable to letting firmware >> silently overwrite the exception registers, causing linux to spin through the >> vectors 'eret' with all exceptions masked. >> I still think its best to wait for firmware that does the right thing. > Let us discuss that in another mail. > In a summary, I think firmware follow below rule can be OK, right? > 1. The exception came from the EL that SError should be routed to(according to hcr_EL2.{AMO, TGE}),but PSTATE.A was set, EL3 firmware can't deliver SError; > 2. The exception came from the EL that SError should not be routed to(according to hcr_EL2.{AMO, TGE}),even though the PSTATE.A was set,EL3 firmware still deliver SError Problem here, more on v9. Thanks, James -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v11 0/4] set VSESR_EL2 by user space and support NOTIFY_SEI notification 2018-04-12 16:14 ` James Morse ` (2 preceding siblings ...) (?) @ 2018-04-19 4:09 ` gengdongjiu -1 siblings, 0 replies; 58+ messages in thread From: gengdongjiu @ 2018-04-19 4:09 UTC (permalink / raw) To: James Morse Cc: rkrcmar, corbet, christoffer.dall, marc.zyngier, linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel, huangshaoyu, zhengxiang9 James, > >> I do not know when it is merge-window. About the apply version, it does not have limited. > > 'git fetch' Linus' tree and look at the tags. 'v4.16' lost its '-rc' suffixes, > and there isn't a 'v4.17-rc1' yet, so we are still in the merge window. > > Linus sends a message to LKML. eg: > https://lkml.org/lkml/2018/4/1/175 > > net-next closes shortly before the merge window, and re-opens afterwards. There > is a handy web page: > http://vger.kernel.org/~davem/net-next.html Thanks for this information, got it. ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [Devel] [PATCH v11 0/4] set VSESR_EL2 by user space and support NOTIFY_SEI notification @ 2018-04-19 4:09 ` gengdongjiu 0 siblings, 0 replies; 58+ messages in thread From: gengdongjiu @ 2018-04-19 4:09 UTC (permalink / raw) To: devel [-- Attachment #1: Type: text/plain, Size: 550 bytes --] James, > >> I do not know when it is merge-window. About the apply version, it does not have limited. > > 'git fetch' Linus' tree and look at the tags. 'v4.16' lost its '-rc' suffixes, > and there isn't a 'v4.17-rc1' yet, so we are still in the merge window. > > Linus sends a message to LKML. eg: > https://lkml.org/lkml/2018/4/1/175 > > net-next closes shortly before the merge window, and re-opens afterwards. There > is a handy web page: > http://vger.kernel.org/~davem/net-next.html Thanks for this information, got it. ^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v11 0/4] set VSESR_EL2 by user space and support NOTIFY_SEI notification @ 2018-04-19 4:09 ` gengdongjiu 0 siblings, 0 replies; 58+ messages in thread From: gengdongjiu @ 2018-04-19 4:09 UTC (permalink / raw) To: linux-arm-kernel James, > >> I do not know when it is merge-window. About the apply version, it does not have limited. > > 'git fetch' Linus' tree and look at the tags. 'v4.16' lost its '-rc' suffixes, > and there isn't a 'v4.17-rc1' yet, so we are still in the merge window. > > Linus sends a message to LKML. eg: > https://lkml.org/lkml/2018/4/1/175 > > net-next closes shortly before the merge window, and re-opens afterwards. There > is a handy web page: > http://vger.kernel.org/~davem/net-next.html Thanks for this information, got it. ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v11 0/4] set VSESR_EL2 by user space and support NOTIFY_SEI notification @ 2018-04-19 4:09 ` gengdongjiu 0 siblings, 0 replies; 58+ messages in thread From: gengdongjiu @ 2018-04-19 4:09 UTC (permalink / raw) To: James Morse Cc: rkrcmar, corbet, christoffer.dall, marc.zyngier, linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel, huangshaoyu, zhengxiang9 James, > >> I do not know when it is merge-window. About the apply version, it does not have limited. > > 'git fetch' Linus' tree and look at the tags. 'v4.16' lost its '-rc' suffixes, > and there isn't a 'v4.17-rc1' yet, so we are still in the merge window. > > Linus sends a message to LKML. eg: > https://lkml.org/lkml/2018/4/1/175 > > net-next closes shortly before the merge window, and re-opens afterwards. There > is a handy web page: > http://vger.kernel.org/~davem/net-next.html Thanks for this information, got it. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v11 0/4] set VSESR_EL2 by user space and support NOTIFY_SEI notification @ 2018-04-19 4:09 ` gengdongjiu 0 siblings, 0 replies; 58+ messages in thread From: gengdongjiu @ 2018-04-19 4:09 UTC (permalink / raw) To: James Morse Cc: rkrcmar, corbet, christoffer.dall, marc.zyngier, linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel, huangshaoyu, zhengxiang9 James, > >> I do not know when it is merge-window. About the apply version, it does not have limited. > > 'git fetch' Linus' tree and look at the tags. 'v4.16' lost its '-rc' suffixes, > and there isn't a 'v4.17-rc1' yet, so we are still in the merge window. > > Linus sends a message to LKML. eg: > https://lkml.org/lkml/2018/4/1/175 > > net-next closes shortly before the merge window, and re-opens afterwards. There > is a handy web page: > http://vger.kernel.org/~davem/net-next.html Thanks for this information, got it. ^ permalink raw reply [flat|nested] 58+ messages in thread
end of thread, other threads:[~2018-04-19 4:10 UTC | newest] Thread overview: 58+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-04-09 21:36 [PATCH v11 0/4] set VSESR_EL2 by user space and support NOTIFY_SEI notification Dongjiu Geng 2018-04-09 21:36 ` [Devel] " Dongjiu Geng 2018-04-09 21:36 ` Dongjiu Geng 2018-04-09 21:36 ` Dongjiu Geng 2018-04-09 21:36 ` Dongjiu Geng 2018-04-09 21:36 ` [PATCH v11 1/4] arm64: KVM: export the capability to set guest SError syndrome Dongjiu Geng 2018-04-09 21:36 ` [Devel] " Dongjiu Geng 2018-04-09 21:36 ` Dongjiu Geng 2018-04-09 21:36 ` Dongjiu Geng 2018-04-09 21:36 ` Dongjiu Geng 2018-04-10 14:15 ` James Morse 2018-04-10 14:15 ` [Devel] " James Morse 2018-04-10 14:15 ` James Morse 2018-04-10 14:15 ` James Morse 2018-04-12 12:55 ` gengdongjiu 2018-04-12 12:55 ` gengdongjiu 2018-04-12 12:55 ` gengdongjiu 2018-04-09 21:36 ` [PATCH v11 2/4] arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS Dongjiu Geng 2018-04-09 21:36 ` [Devel] " Dongjiu Geng 2018-04-09 21:36 ` Dongjiu Geng 2018-04-09 21:36 ` Dongjiu Geng 2018-04-09 21:36 ` Dongjiu Geng 2018-04-10 14:15 ` James Morse 2018-04-10 14:15 ` [Devel] " James Morse 2018-04-10 14:15 ` James Morse 2018-04-10 14:15 ` James Morse 2018-04-12 15:11 ` gengdongjiu 2018-04-12 15:11 ` gengdongjiu 2018-04-12 15:11 ` gengdongjiu 2018-04-09 21:36 ` [PATCH v11 3/4] ACPI / APEI: Add SEI notification type support for ARMv8 Dongjiu Geng 2018-04-09 21:36 ` [Devel] " Dongjiu Geng 2018-04-09 21:36 ` Dongjiu Geng 2018-04-09 21:36 ` Dongjiu Geng 2018-04-09 21:36 ` Dongjiu Geng 2018-04-09 21:36 ` [PATCH v11 4/4] arm64: handle NOTIFY_SEI notification by the APEI driver Dongjiu Geng 2018-04-09 21:36 ` [Devel] " Dongjiu Geng 2018-04-09 21:36 ` Dongjiu Geng 2018-04-09 21:36 ` Dongjiu Geng 2018-04-09 21:36 ` Dongjiu Geng 2018-04-09 21:36 ` Dongjiu Geng 2018-04-10 14:15 ` [PATCH v11 0/4] set VSESR_EL2 by user space and support NOTIFY_SEI notification James Morse 2018-04-10 14:15 ` [Devel] " James Morse 2018-04-10 14:15 ` James Morse 2018-04-10 14:15 ` James Morse 2018-04-12 6:09 ` gengdongjiu 2018-04-12 6:09 ` [Devel] " gengdongjiu 2018-04-12 6:09 ` gengdongjiu 2018-04-12 6:09 ` gengdongjiu 2018-04-12 6:09 ` gengdongjiu 2018-04-12 16:14 ` James Morse 2018-04-12 16:14 ` [Devel] " James Morse 2018-04-12 16:14 ` James Morse 2018-04-12 16:14 ` James Morse 2018-04-19 4:09 ` gengdongjiu 2018-04-19 4:09 ` [Devel] " gengdongjiu 2018-04-19 4:09 ` gengdongjiu 2018-04-19 4:09 ` gengdongjiu 2018-04-19 4:09 ` gengdongjiu
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.