All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gavin Shan <gshan@redhat.com>
To: kvmarm@lists.cs.columbia.edu
Cc: linux-kernel@vger.kernel.org, eauger@redhat.com,
	oupton@google.com, Jonathan.Cameron@huawei.com,
	vkuznets@redhat.com, will@kernel.org, shannon.zhaosl@gmail.com,
	james.morse@arm.com, mark.rutland@arm.com, maz@kernel.org,
	pbonzini@redhat.com, shan.gavin@gmail.com
Subject: [PATCH v6 02/18] KVM: arm64: Route hypercalls based on their owner
Date: Sun,  3 Apr 2022 23:38:55 +0800	[thread overview]
Message-ID: <20220403153911.12332-3-gshan@redhat.com> (raw)
In-Reply-To: <20220403153911.12332-1-gshan@redhat.com>

kvm_hvc_call_handler() directly handles the incoming hypercall, or
and routes it based on its (function) ID. kvm_psci_call() becomes
the gate keeper to handle the hypercall that can't be handled by
any one else. It makes kvm_hvc_call_handler() a bit messy.

This reorgnizes the code to route the hypercall to the corresponding
handler based on its owner. The hypercall may be handled directly
in the handler or routed further to the corresponding functionality.
The (function) ID is always verified before it's routed to the
corresponding functionality. By the way, @func_id is repalced by
@func, to be consistent with by smccc_get_function().

PSCI is the only exception, those hypercalls defined by 0.2 or
beyond are routed to the handler for Standard Secure Service, but
those defined in 0.1 are routed to the handler for Standard
Hypervisor Service.

Suggested-by: Oliver Upton <oupton@google.com>
Signed-off-by: Gavin Shan <gshan@redhat.com>
---
 arch/arm64/kvm/hypercalls.c | 199 +++++++++++++++++++++++-------------
 1 file changed, 127 insertions(+), 72 deletions(-)

diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
index 8438fd79e3f0..b659387d8919 100644
--- a/arch/arm64/kvm/hypercalls.c
+++ b/arch/arm64/kvm/hypercalls.c
@@ -9,65 +9,14 @@
 #include <kvm/arm_hypercalls.h>
 #include <kvm/arm_psci.h>
 
-static void kvm_ptp_get_time(struct kvm_vcpu *vcpu, u64 *val)
-{
-	struct system_time_snapshot systime_snapshot;
-	u64 cycles = ~0UL;
-	u32 feature;
-
-	/*
-	 * system time and counter value must captured at the same
-	 * time to keep consistency and precision.
-	 */
-	ktime_get_snapshot(&systime_snapshot);
-
-	/*
-	 * This is only valid if the current clocksource is the
-	 * architected counter, as this is the only one the guest
-	 * can see.
-	 */
-	if (systime_snapshot.cs_id != CSID_ARM_ARCH_COUNTER)
-		return;
-
-	/*
-	 * The guest selects one of the two reference counters
-	 * (virtual or physical) with the first argument of the SMCCC
-	 * call. In case the identifier is not supported, error out.
-	 */
-	feature = smccc_get_arg(vcpu, 1);
-	switch (feature) {
-	case KVM_PTP_VIRT_COUNTER:
-		cycles = systime_snapshot.cycles - vcpu_read_sys_reg(vcpu, CNTVOFF_EL2);
-		break;
-	case KVM_PTP_PHYS_COUNTER:
-		cycles = systime_snapshot.cycles;
-		break;
-	default:
-		return;
-	}
-
-	/*
-	 * This relies on the top bit of val[0] never being set for
-	 * valid values of system time, because that is *really* far
-	 * in the future (about 292 years from 1970, and at that stage
-	 * nobody will give a damn about it).
-	 */
-	val[0] = upper_32_bits(systime_snapshot.real);
-	val[1] = lower_32_bits(systime_snapshot.real);
-	val[2] = upper_32_bits(cycles);
-	val[3] = lower_32_bits(cycles);
-}
-
-int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
+static int kvm_hvc_arch(struct kvm_vcpu *vcpu, u32 func)
 {
-	u32 func_id = smccc_get_function(vcpu);
-	u64 val[4] = {SMCCC_RET_NOT_SUPPORTED};
+	u64 val = SMCCC_RET_NOT_SUPPORTED;
 	u32 feature;
-	gpa_t gpa;
 
-	switch (func_id) {
+	switch (func) {
 	case ARM_SMCCC_VERSION_FUNC_ID:
-		val[0] = ARM_SMCCC_VERSION_1_1;
+		val = ARM_SMCCC_VERSION_1_1;
 		break;
 	case ARM_SMCCC_ARCH_FEATURES_FUNC_ID:
 		feature = smccc_get_arg(vcpu, 1);
@@ -77,10 +26,10 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
 			case SPECTRE_VULNERABLE:
 				break;
 			case SPECTRE_MITIGATED:
-				val[0] = SMCCC_RET_SUCCESS;
+				val = SMCCC_RET_SUCCESS;
 				break;
 			case SPECTRE_UNAFFECTED:
-				val[0] = SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED;
+				val = SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED;
 				break;
 			}
 			break;
@@ -103,7 +52,7 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
 					break;
 				fallthrough;
 			case SPECTRE_UNAFFECTED:
-				val[0] = SMCCC_RET_NOT_REQUIRED;
+				val = SMCCC_RET_NOT_REQUIRED;
 				break;
 			}
 			break;
@@ -112,26 +61,120 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
 			case SPECTRE_VULNERABLE:
 				break;
 			case SPECTRE_MITIGATED:
-				val[0] = SMCCC_RET_SUCCESS;
+				val = SMCCC_RET_SUCCESS;
 				break;
 			case SPECTRE_UNAFFECTED:
-				val[0] = SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED;
+				val = SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED;
 				break;
 			}
 			break;
 		case ARM_SMCCC_HV_PV_TIME_FEATURES:
-			val[0] = SMCCC_RET_SUCCESS;
+			val = SMCCC_RET_SUCCESS;
 			break;
 		}
-		break;
+	}
+
+	smccc_set_retval(vcpu, val, 0, 0, 0);
+	return 1;
+}
+
+static int kvm_hvc_standard(struct kvm_vcpu *vcpu, u32 func)
+{
+	u64 val = SMCCC_RET_NOT_SUPPORTED;
+
+	switch (func) {
+	case ARM_SMCCC_TRNG_VERSION ... ARM_SMCCC_TRNG_RND32:
+	case ARM_SMCCC_TRNG_RND64:
+		return kvm_trng_call(vcpu);
+	case PSCI_0_2_FN_PSCI_VERSION ... PSCI_0_2_FN_SYSTEM_RESET:
+	case PSCI_0_2_FN64_CPU_SUSPEND ... PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU:
+	case PSCI_1_0_FN_PSCI_FEATURES ... PSCI_1_0_FN_SET_SUSPEND_MODE:
+	case PSCI_1_0_FN64_SYSTEM_SUSPEND:
+	case PSCI_1_1_FN_SYSTEM_RESET2:
+	case PSCI_1_1_FN64_SYSTEM_RESET2:
+		return kvm_psci_call(vcpu);
+	}
+
+	smccc_set_retval(vcpu, val, 0, 0, 0);
+	return 1;
+}
+
+static int kvm_hvc_standard_hyp(struct kvm_vcpu *vcpu, u32 func)
+{
+	u64 val = SMCCC_RET_NOT_SUPPORTED;
+	gpa_t gpa;
+
+	switch (func) {
 	case ARM_SMCCC_HV_PV_TIME_FEATURES:
-		val[0] = kvm_hypercall_pv_features(vcpu);
+		val = kvm_hypercall_pv_features(vcpu);
 		break;
 	case ARM_SMCCC_HV_PV_TIME_ST:
 		gpa = kvm_init_stolen_time(vcpu);
 		if (gpa != GPA_INVALID)
-			val[0] = gpa;
+			val = gpa;
 		break;
+	case KVM_PSCI_FN_CPU_SUSPEND ... KVM_PSCI_FN_MIGRATE:
+		return kvm_psci_call(vcpu);
+	}
+
+	smccc_set_retval(vcpu, val, 0, 0, 0);
+	return 1;
+}
+
+static void kvm_ptp_get_time(struct kvm_vcpu *vcpu, u64 *val)
+{
+	struct system_time_snapshot systime_snapshot;
+	u64 cycles = ~0UL;
+	u32 feature;
+
+	/*
+	 * system time and counter value must captured at the same
+	 * time to keep consistency and precision.
+	 */
+	ktime_get_snapshot(&systime_snapshot);
+
+	/*
+	 * This is only valid if the current clocksource is the
+	 * architected counter, as this is the only one the guest
+	 * can see.
+	 */
+	if (systime_snapshot.cs_id != CSID_ARM_ARCH_COUNTER)
+		return;
+
+	/*
+	 * The guest selects one of the two reference counters
+	 * (virtual or physical) with the first argument of the SMCCC
+	 * call. In case the identifier is not supported, error out.
+	 */
+	feature = smccc_get_arg(vcpu, 1);
+	switch (feature) {
+	case KVM_PTP_VIRT_COUNTER:
+		cycles = systime_snapshot.cycles - vcpu_read_sys_reg(vcpu, CNTVOFF_EL2);
+		break;
+	case KVM_PTP_PHYS_COUNTER:
+		cycles = systime_snapshot.cycles;
+		break;
+	default:
+		return;
+	}
+
+	/*
+	 * This relies on the top bit of val[0] never being set for
+	 * valid values of system time, because that is *really* far
+	 * in the future (about 292 years from 1970, and at that stage
+	 * nobody will give a damn about it).
+	 */
+	val[0] = upper_32_bits(systime_snapshot.real);
+	val[1] = lower_32_bits(systime_snapshot.real);
+	val[2] = upper_32_bits(cycles);
+	val[3] = lower_32_bits(cycles);
+}
+
+static int kvm_hvc_vendor_hyp(struct kvm_vcpu *vcpu, u32 func)
+{
+	u64 val[4] = { SMCCC_RET_NOT_SUPPORTED };
+
+	switch (func) {
 	case ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID:
 		val[0] = ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_0;
 		val[1] = ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_1;
@@ -145,16 +188,28 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
 	case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
 		kvm_ptp_get_time(vcpu, val);
 		break;
-	case ARM_SMCCC_TRNG_VERSION:
-	case ARM_SMCCC_TRNG_FEATURES:
-	case ARM_SMCCC_TRNG_GET_UUID:
-	case ARM_SMCCC_TRNG_RND32:
-	case ARM_SMCCC_TRNG_RND64:
-		return kvm_trng_call(vcpu);
-	default:
-		return kvm_psci_call(vcpu);
 	}
 
 	smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
 	return 1;
 }
+
+int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
+{
+	u32 func = smccc_get_function(vcpu);
+	u64 val = SMCCC_RET_NOT_SUPPORTED;
+
+	switch (ARM_SMCCC_OWNER_NUM(func)) {
+	case ARM_SMCCC_OWNER_ARCH:
+		return kvm_hvc_arch(vcpu, func);
+	case ARM_SMCCC_OWNER_STANDARD:
+		return kvm_hvc_standard(vcpu, func);
+	case ARM_SMCCC_OWNER_STANDARD_HYP:
+		return kvm_hvc_standard_hyp(vcpu, func);
+	case ARM_SMCCC_OWNER_VENDOR_HYP:
+		return kvm_hvc_vendor_hyp(vcpu, func);
+	}
+
+	smccc_set_retval(vcpu, val, 0, 0, 0);
+	return 1;
+}
-- 
2.23.0


WARNING: multiple messages have this Message-ID (diff)
From: Gavin Shan <gshan@redhat.com>
To: kvmarm@lists.cs.columbia.edu
Cc: maz@kernel.org, linux-kernel@vger.kernel.org, eauger@redhat.com,
	shan.gavin@gmail.com, Jonathan.Cameron@huawei.com,
	pbonzini@redhat.com, vkuznets@redhat.com, will@kernel.org
Subject: [PATCH v6 02/18] KVM: arm64: Route hypercalls based on their owner
Date: Sun,  3 Apr 2022 23:38:55 +0800	[thread overview]
Message-ID: <20220403153911.12332-3-gshan@redhat.com> (raw)
In-Reply-To: <20220403153911.12332-1-gshan@redhat.com>

kvm_hvc_call_handler() directly handles the incoming hypercall, or
and routes it based on its (function) ID. kvm_psci_call() becomes
the gate keeper to handle the hypercall that can't be handled by
any one else. It makes kvm_hvc_call_handler() a bit messy.

This reorgnizes the code to route the hypercall to the corresponding
handler based on its owner. The hypercall may be handled directly
in the handler or routed further to the corresponding functionality.
The (function) ID is always verified before it's routed to the
corresponding functionality. By the way, @func_id is repalced by
@func, to be consistent with by smccc_get_function().

PSCI is the only exception, those hypercalls defined by 0.2 or
beyond are routed to the handler for Standard Secure Service, but
those defined in 0.1 are routed to the handler for Standard
Hypervisor Service.

Suggested-by: Oliver Upton <oupton@google.com>
Signed-off-by: Gavin Shan <gshan@redhat.com>
---
 arch/arm64/kvm/hypercalls.c | 199 +++++++++++++++++++++++-------------
 1 file changed, 127 insertions(+), 72 deletions(-)

diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
index 8438fd79e3f0..b659387d8919 100644
--- a/arch/arm64/kvm/hypercalls.c
+++ b/arch/arm64/kvm/hypercalls.c
@@ -9,65 +9,14 @@
 #include <kvm/arm_hypercalls.h>
 #include <kvm/arm_psci.h>
 
-static void kvm_ptp_get_time(struct kvm_vcpu *vcpu, u64 *val)
-{
-	struct system_time_snapshot systime_snapshot;
-	u64 cycles = ~0UL;
-	u32 feature;
-
-	/*
-	 * system time and counter value must captured at the same
-	 * time to keep consistency and precision.
-	 */
-	ktime_get_snapshot(&systime_snapshot);
-
-	/*
-	 * This is only valid if the current clocksource is the
-	 * architected counter, as this is the only one the guest
-	 * can see.
-	 */
-	if (systime_snapshot.cs_id != CSID_ARM_ARCH_COUNTER)
-		return;
-
-	/*
-	 * The guest selects one of the two reference counters
-	 * (virtual or physical) with the first argument of the SMCCC
-	 * call. In case the identifier is not supported, error out.
-	 */
-	feature = smccc_get_arg(vcpu, 1);
-	switch (feature) {
-	case KVM_PTP_VIRT_COUNTER:
-		cycles = systime_snapshot.cycles - vcpu_read_sys_reg(vcpu, CNTVOFF_EL2);
-		break;
-	case KVM_PTP_PHYS_COUNTER:
-		cycles = systime_snapshot.cycles;
-		break;
-	default:
-		return;
-	}
-
-	/*
-	 * This relies on the top bit of val[0] never being set for
-	 * valid values of system time, because that is *really* far
-	 * in the future (about 292 years from 1970, and at that stage
-	 * nobody will give a damn about it).
-	 */
-	val[0] = upper_32_bits(systime_snapshot.real);
-	val[1] = lower_32_bits(systime_snapshot.real);
-	val[2] = upper_32_bits(cycles);
-	val[3] = lower_32_bits(cycles);
-}
-
-int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
+static int kvm_hvc_arch(struct kvm_vcpu *vcpu, u32 func)
 {
-	u32 func_id = smccc_get_function(vcpu);
-	u64 val[4] = {SMCCC_RET_NOT_SUPPORTED};
+	u64 val = SMCCC_RET_NOT_SUPPORTED;
 	u32 feature;
-	gpa_t gpa;
 
-	switch (func_id) {
+	switch (func) {
 	case ARM_SMCCC_VERSION_FUNC_ID:
-		val[0] = ARM_SMCCC_VERSION_1_1;
+		val = ARM_SMCCC_VERSION_1_1;
 		break;
 	case ARM_SMCCC_ARCH_FEATURES_FUNC_ID:
 		feature = smccc_get_arg(vcpu, 1);
@@ -77,10 +26,10 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
 			case SPECTRE_VULNERABLE:
 				break;
 			case SPECTRE_MITIGATED:
-				val[0] = SMCCC_RET_SUCCESS;
+				val = SMCCC_RET_SUCCESS;
 				break;
 			case SPECTRE_UNAFFECTED:
-				val[0] = SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED;
+				val = SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED;
 				break;
 			}
 			break;
@@ -103,7 +52,7 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
 					break;
 				fallthrough;
 			case SPECTRE_UNAFFECTED:
-				val[0] = SMCCC_RET_NOT_REQUIRED;
+				val = SMCCC_RET_NOT_REQUIRED;
 				break;
 			}
 			break;
@@ -112,26 +61,120 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
 			case SPECTRE_VULNERABLE:
 				break;
 			case SPECTRE_MITIGATED:
-				val[0] = SMCCC_RET_SUCCESS;
+				val = SMCCC_RET_SUCCESS;
 				break;
 			case SPECTRE_UNAFFECTED:
-				val[0] = SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED;
+				val = SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED;
 				break;
 			}
 			break;
 		case ARM_SMCCC_HV_PV_TIME_FEATURES:
-			val[0] = SMCCC_RET_SUCCESS;
+			val = SMCCC_RET_SUCCESS;
 			break;
 		}
-		break;
+	}
+
+	smccc_set_retval(vcpu, val, 0, 0, 0);
+	return 1;
+}
+
+static int kvm_hvc_standard(struct kvm_vcpu *vcpu, u32 func)
+{
+	u64 val = SMCCC_RET_NOT_SUPPORTED;
+
+	switch (func) {
+	case ARM_SMCCC_TRNG_VERSION ... ARM_SMCCC_TRNG_RND32:
+	case ARM_SMCCC_TRNG_RND64:
+		return kvm_trng_call(vcpu);
+	case PSCI_0_2_FN_PSCI_VERSION ... PSCI_0_2_FN_SYSTEM_RESET:
+	case PSCI_0_2_FN64_CPU_SUSPEND ... PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU:
+	case PSCI_1_0_FN_PSCI_FEATURES ... PSCI_1_0_FN_SET_SUSPEND_MODE:
+	case PSCI_1_0_FN64_SYSTEM_SUSPEND:
+	case PSCI_1_1_FN_SYSTEM_RESET2:
+	case PSCI_1_1_FN64_SYSTEM_RESET2:
+		return kvm_psci_call(vcpu);
+	}
+
+	smccc_set_retval(vcpu, val, 0, 0, 0);
+	return 1;
+}
+
+static int kvm_hvc_standard_hyp(struct kvm_vcpu *vcpu, u32 func)
+{
+	u64 val = SMCCC_RET_NOT_SUPPORTED;
+	gpa_t gpa;
+
+	switch (func) {
 	case ARM_SMCCC_HV_PV_TIME_FEATURES:
-		val[0] = kvm_hypercall_pv_features(vcpu);
+		val = kvm_hypercall_pv_features(vcpu);
 		break;
 	case ARM_SMCCC_HV_PV_TIME_ST:
 		gpa = kvm_init_stolen_time(vcpu);
 		if (gpa != GPA_INVALID)
-			val[0] = gpa;
+			val = gpa;
 		break;
+	case KVM_PSCI_FN_CPU_SUSPEND ... KVM_PSCI_FN_MIGRATE:
+		return kvm_psci_call(vcpu);
+	}
+
+	smccc_set_retval(vcpu, val, 0, 0, 0);
+	return 1;
+}
+
+static void kvm_ptp_get_time(struct kvm_vcpu *vcpu, u64 *val)
+{
+	struct system_time_snapshot systime_snapshot;
+	u64 cycles = ~0UL;
+	u32 feature;
+
+	/*
+	 * system time and counter value must captured at the same
+	 * time to keep consistency and precision.
+	 */
+	ktime_get_snapshot(&systime_snapshot);
+
+	/*
+	 * This is only valid if the current clocksource is the
+	 * architected counter, as this is the only one the guest
+	 * can see.
+	 */
+	if (systime_snapshot.cs_id != CSID_ARM_ARCH_COUNTER)
+		return;
+
+	/*
+	 * The guest selects one of the two reference counters
+	 * (virtual or physical) with the first argument of the SMCCC
+	 * call. In case the identifier is not supported, error out.
+	 */
+	feature = smccc_get_arg(vcpu, 1);
+	switch (feature) {
+	case KVM_PTP_VIRT_COUNTER:
+		cycles = systime_snapshot.cycles - vcpu_read_sys_reg(vcpu, CNTVOFF_EL2);
+		break;
+	case KVM_PTP_PHYS_COUNTER:
+		cycles = systime_snapshot.cycles;
+		break;
+	default:
+		return;
+	}
+
+	/*
+	 * This relies on the top bit of val[0] never being set for
+	 * valid values of system time, because that is *really* far
+	 * in the future (about 292 years from 1970, and at that stage
+	 * nobody will give a damn about it).
+	 */
+	val[0] = upper_32_bits(systime_snapshot.real);
+	val[1] = lower_32_bits(systime_snapshot.real);
+	val[2] = upper_32_bits(cycles);
+	val[3] = lower_32_bits(cycles);
+}
+
+static int kvm_hvc_vendor_hyp(struct kvm_vcpu *vcpu, u32 func)
+{
+	u64 val[4] = { SMCCC_RET_NOT_SUPPORTED };
+
+	switch (func) {
 	case ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID:
 		val[0] = ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_0;
 		val[1] = ARM_SMCCC_VENDOR_HYP_UID_KVM_REG_1;
@@ -145,16 +188,28 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
 	case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
 		kvm_ptp_get_time(vcpu, val);
 		break;
-	case ARM_SMCCC_TRNG_VERSION:
-	case ARM_SMCCC_TRNG_FEATURES:
-	case ARM_SMCCC_TRNG_GET_UUID:
-	case ARM_SMCCC_TRNG_RND32:
-	case ARM_SMCCC_TRNG_RND64:
-		return kvm_trng_call(vcpu);
-	default:
-		return kvm_psci_call(vcpu);
 	}
 
 	smccc_set_retval(vcpu, val[0], val[1], val[2], val[3]);
 	return 1;
 }
+
+int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
+{
+	u32 func = smccc_get_function(vcpu);
+	u64 val = SMCCC_RET_NOT_SUPPORTED;
+
+	switch (ARM_SMCCC_OWNER_NUM(func)) {
+	case ARM_SMCCC_OWNER_ARCH:
+		return kvm_hvc_arch(vcpu, func);
+	case ARM_SMCCC_OWNER_STANDARD:
+		return kvm_hvc_standard(vcpu, func);
+	case ARM_SMCCC_OWNER_STANDARD_HYP:
+		return kvm_hvc_standard_hyp(vcpu, func);
+	case ARM_SMCCC_OWNER_VENDOR_HYP:
+		return kvm_hvc_vendor_hyp(vcpu, func);
+	}
+
+	smccc_set_retval(vcpu, val, 0, 0, 0);
+	return 1;
+}
-- 
2.23.0

_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

  parent reply	other threads:[~2022-04-03 15:39 UTC|newest]

Thread overview: 111+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-03 15:38 [PATCH v6 00/18] Support SDEI Virtualization Gavin Shan
2022-04-03 15:38 ` Gavin Shan
2022-04-03 15:38 ` [PATCH v6 01/18] KVM: arm64: Extend smccc_get_argx() Gavin Shan
2022-04-03 15:38   ` Gavin Shan
2022-04-03 15:38 ` Gavin Shan [this message]
2022-04-03 15:38   ` [PATCH v6 02/18] KVM: arm64: Route hypercalls based on their owner Gavin Shan
2022-04-21  8:19   ` Oliver Upton
2022-04-21  8:19     ` Oliver Upton
2022-04-22 12:20     ` Gavin Shan
2022-04-22 12:20       ` Gavin Shan
2022-04-22 17:59       ` Oliver Upton
2022-04-22 17:59         ` Oliver Upton
2022-04-23 12:48         ` Gavin Shan
2022-04-23 12:48           ` Gavin Shan
2022-04-03 15:38 ` [PATCH v6 03/18] KVM: arm64: Add SDEI virtualization infrastructure Gavin Shan
2022-04-03 15:38   ` Gavin Shan
2022-04-22 21:48   ` Oliver Upton
2022-04-22 21:48     ` Oliver Upton
2022-04-23 14:18     ` Gavin Shan
2022-04-23 14:18       ` Gavin Shan
2022-04-23 18:43       ` Oliver Upton
2022-04-23 18:43         ` Oliver Upton
2022-04-24  3:00         ` Gavin Shan
2022-04-24  3:00           ` Gavin Shan
2022-04-28 20:28           ` Oliver Upton
2022-04-28 20:28             ` Oliver Upton
2022-04-30 11:38             ` Gavin Shan
2022-04-30 11:38               ` Gavin Shan
2022-04-30 14:16               ` Oliver Upton
2022-04-30 14:16                 ` Oliver Upton
2022-05-02  2:35                 ` Gavin Shan
2022-05-02  2:35                   ` Gavin Shan
2022-05-02  3:40                   ` Oliver Upton
2022-05-02  3:40                     ` Oliver Upton
2022-05-02  7:25                     ` Gavin Shan
2022-05-02  7:25                       ` Gavin Shan
2022-05-02  7:57                       ` Oliver Upton
2022-05-02  7:57                         ` Oliver Upton
2022-05-02  8:23                         ` Gavin Shan
2022-05-02  8:23                           ` Gavin Shan
2022-04-03 15:38 ` [PATCH v6 04/18] KVM: arm64: Support SDEI_EVENT_REGISTER hypercall Gavin Shan
2022-04-03 15:38   ` Gavin Shan
2022-04-30 14:54   ` Oliver Upton
2022-04-30 14:54     ` Oliver Upton
2022-05-02  2:55     ` Gavin Shan
2022-05-02  2:55       ` Gavin Shan
2022-05-02  3:43       ` Oliver Upton
2022-05-02  3:43         ` Oliver Upton
2022-05-02  7:28         ` Gavin Shan
2022-05-02  7:28           ` Gavin Shan
2022-04-03 15:38 ` [PATCH v6 05/18] KVM: arm64: Support SDEI_EVENT_{ENABLE, DISABLE} Gavin Shan
2022-04-03 15:38   ` Gavin Shan
2022-04-03 15:38 ` [PATCH v6 06/18] KVM: arm64: Support SDEI_EVENT_CONTEXT hypercall Gavin Shan
2022-04-03 15:38   ` Gavin Shan
2022-04-30 15:03   ` Oliver Upton
2022-04-30 15:03     ` Oliver Upton
2022-05-02  2:57     ` Gavin Shan
2022-05-02  2:57       ` Gavin Shan
2022-04-03 15:39 ` [PATCH v6 07/18] KVM: arm64: Support SDEI_EVENT_UNREGISTER hypercall Gavin Shan
2022-04-03 15:39   ` Gavin Shan
2022-04-03 15:39 ` [PATCH v6 08/18] KVM: arm64: Support SDEI_EVENT_STATUS hypercall Gavin Shan
2022-04-03 15:39   ` Gavin Shan
2022-04-03 15:39 ` [PATCH v6 09/18] KVM: arm64: Support SDEI_EVENT_GET_INFO hypercall Gavin Shan
2022-04-03 15:39   ` Gavin Shan
2022-04-03 15:39 ` [PATCH v6 10/18] KVM: arm64: Support SDEI_PE_{MASK, UNMASK} hypercall Gavin Shan
2022-04-03 15:39   ` Gavin Shan
2022-04-04 10:26   ` [PATCH] KVM: arm64: fix returnvar.cocci warnings kernel test robot
2022-04-04 10:26     ` kernel test robot
2022-04-04 10:54     ` Gavin Shan
2022-04-04 10:54       ` Gavin Shan
2022-04-04 10:54       ` Gavin Shan
2022-04-04 10:29   ` [PATCH v6 10/18] KVM: arm64: Support SDEI_PE_{MASK, UNMASK} hypercall kernel test robot
2022-04-04 10:29     ` kernel test robot
2022-04-03 15:39 ` [PATCH v6 11/18] KVM: arm64: Support SDEI_{PRIVATE, SHARED}_RESET Gavin Shan
2022-04-03 15:39   ` Gavin Shan
2022-04-03 15:39 ` [PATCH v6 12/18] KVM: arm64: Support SDEI event injection, delivery Gavin Shan
2022-04-03 15:39   ` Gavin Shan
2022-04-03 15:39 ` [PATCH v6 13/18] KVM: arm64: Support SDEI_EVENT_{COMPLETE,COMPLETE_AND_RESUME} hypercall Gavin Shan
2022-04-03 15:39   ` [PATCH v6 13/18] KVM: arm64: Support SDEI_EVENT_{COMPLETE, COMPLETE_AND_RESUME} hypercall Gavin Shan
2022-05-01  6:50   ` [PATCH v6 13/18] KVM: arm64: Support SDEI_EVENT_{COMPLETE,COMPLETE_AND_RESUME} hypercall Oliver Upton
2022-05-01  6:50     ` Oliver Upton
2022-05-02  6:19     ` Gavin Shan
2022-05-02  6:19       ` Gavin Shan
2022-05-02  7:38       ` Oliver Upton
2022-05-02  7:38         ` Oliver Upton
2022-05-02  7:51         ` Gavin Shan
2022-05-02  7:51           ` Gavin Shan
2022-04-03 15:39 ` [PATCH v6 14/18] KVM: arm64: Support SDEI_EVENT_SIGNAL hypercall Gavin Shan
2022-04-03 15:39   ` Gavin Shan
2022-04-30 21:32   ` Oliver Upton
2022-04-30 21:32     ` Oliver Upton
2022-05-02  3:04     ` Gavin Shan
2022-05-02  3:04       ` Gavin Shan
2022-04-03 15:39 ` [PATCH v6 15/18] KVM: arm64: Support SDEI_FEATURES hypercall Gavin Shan
2022-04-03 15:39   ` Gavin Shan
2022-05-01  6:55   ` Oliver Upton
2022-05-01  6:55     ` Oliver Upton
2022-05-02  3:05     ` Gavin Shan
2022-05-02  3:05       ` Gavin Shan
2022-04-03 15:39 ` [PATCH v6 16/18] KVM: arm64: Support SDEI_VERSION hypercall Gavin Shan
2022-04-03 15:39   ` Gavin Shan
2022-04-03 15:39 ` [PATCH v6 17/18] KVM: arm64: Expose SDEI capability Gavin Shan
2022-04-03 15:39   ` Gavin Shan
2022-04-03 15:39 ` [PATCH v6 18/18] KVM: selftests: Add SDEI test case Gavin Shan
2022-04-03 15:39   ` Gavin Shan
2022-04-03 15:47 ` [PATCH v6 00/18] Support SDEI Virtualization Gavin Shan
2022-04-03 15:47   ` Gavin Shan
2022-04-04  6:09   ` Oliver Upton
2022-04-04  6:09     ` Oliver Upton
2022-04-04 10:53     ` Gavin Shan
2022-04-04 10:53       ` Gavin Shan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220403153911.12332-3-gshan@redhat.com \
    --to=gshan@redhat.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=eauger@redhat.com \
    --cc=james.morse@arm.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=oupton@google.com \
    --cc=pbonzini@redhat.com \
    --cc=shan.gavin@gmail.com \
    --cc=shannon.zhaosl@gmail.com \
    --cc=vkuznets@redhat.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.