Re: [Xen-devel] [PATCH v2 3/3] xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c
On 06.02.18 17:39, Julien Grall wrote:
On 02/06/2018 03:28 PM, Volodymyr Babchuk wrote:
Hi Julien,
On 06.02.18 16:45, Julien Grall wrote:
[...]
+/*
+ * PSCI 0.2 or later calls. It will return false if the function
ID is
+ * not handled.
+ */
+bool do_vpsci_0_2_call(struct cpu_user_regs *regs, uint32_t fid)
+{
+ /*
+ * /!\ VPSCI_NR_FUNCS (in asm-arm/vpsci.h) should be updated
when
+ * adding/removing a function
+ */
Should we also update revision of SSSC interface as well? SMCCC
requires this.
Meh, you can't rely on the SSSC revision most of the time as the
version for PSCI is done through PSCI_get_version. I can add a
comment if you want.
Yes, I agree with you. But section 5.4 of SMCCC 1.0 applies to SSSC
as well. So you can write something like "ARM SMCCC requires that
SSSC revision and function call count should be updated every time
you add or remove a function"
Usually we update versioning number only once per release. I would
follow the same approach for this one. So I would suggest
It is not stated clearly in SMCCC, but I've got a felling that
revision belongs not to product version, but to SMC interface version.
So I see no reason to change revision, if there was no changes to
interface itself.
I'm okay witch changing revision only one time per release, but only
if there was changes to PSCI interface. On other hand, person
responsible for release need to track if there was any changes in PSCI
and act accordingly. This is not very convenient.
So, I would prefer to change revision in the same patch (or patch
series) which alters the interface.
At the end of the day this is closely tie to product revision. A new
revision may produce change in the implementation and therefore the
version will be bumped. But there are always exception when you do a
release just for bug fix.
This is the same for Xen, we only change interface version if something
major as changed. If nothing, then the version stays the same.
Then I'm okay with this. I just wanted to sure that we are on the same page.
"VPSCI_NR_FUNCS (in asm-arm/vpsci.h) should be updated when adding
removing a function. SSCCC_SMCCC_*_REVISION should be updated once
per Xen release".
And who will be responsible for this?
The first patch modifying the SMCCC implementation after the tree is
re-opened. This is how we deal the rest of the versions in Xen, and it
works.
I'm good with this then.
--
Volodymyr Babchuk
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 3/3] xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c
On 02/06/2018 03:28 PM, Volodymyr Babchuk wrote:
Hi Julien,
On 06.02.18 16:45, Julien Grall wrote:
[...]
+/*
+ * PSCI 0.2 or later calls. It will return false if the function
ID is
+ * not handled.
+ */
+bool do_vpsci_0_2_call(struct cpu_user_regs *regs, uint32_t fid)
+{
+ /*
+ * /!\ VPSCI_NR_FUNCS (in asm-arm/vpsci.h) should be updated
when
+ * adding/removing a function
+ */
Should we also update revision of SSSC interface as well? SMCCC
requires this.
Meh, you can't rely on the SSSC revision most of the time as the
version for PSCI is done through PSCI_get_version. I can add a
comment if you want.
Yes, I agree with you. But section 5.4 of SMCCC 1.0 applies to SSSC
as well. So you can write something like "ARM SMCCC requires that
SSSC revision and function call count should be updated every time
you add or remove a function"
Usually we update versioning number only once per release. I would
follow the same approach for this one. So I would suggest
It is not stated clearly in SMCCC, but I've got a felling that revision
belongs not to product version, but to SMC interface version. So I see
no reason to change revision, if there was no changes to interface itself.
I'm okay witch changing revision only one time per release, but only
if there was changes to PSCI interface. On other hand, person
responsible for release need to track if there was any changes in PSCI
and act accordingly. This is not very convenient.
So, I would prefer to change revision in the same patch (or patch
series) which alters the interface.
At the end of the day this is closely tie to product revision. A new
revision may produce change in the implementation and therefore the
version will be bumped. But there are always exception when you do a
release just for bug fix.
This is the same for Xen, we only change interface version if something
major as changed. If nothing, then the version stays the same.
"VPSCI_NR_FUNCS (in asm-arm/vpsci.h) should be updated when adding
removing a function. SSCCC_SMCCC_*_REVISION should be updated once per
Xen release".
And who will be responsible for this?
The first patch modifying the SMCCC implementation after the tree is
re-opened. This is how we deal the rest of the versions in Xen, and it
works.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 3/3] xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c
Hi Julien,
On 06.02.18 16:45, Julien Grall wrote:
[...]
+/*
+ * PSCI 0.2 or later calls. It will return false if the function
ID is
+ * not handled.
+ */
+bool do_vpsci_0_2_call(struct cpu_user_regs *regs, uint32_t fid)
+{
+ /*
+ * /!\ VPSCI_NR_FUNCS (in asm-arm/vpsci.h) should be updated when
+ * adding/removing a function
+ */
Should we also update revision of SSSC interface as well? SMCCC
requires this.
Meh, you can't rely on the SSSC revision most of the time as the
version for PSCI is done through PSCI_get_version. I can add a
comment if you want.
Yes, I agree with you. But section 5.4 of SMCCC 1.0 applies to SSSC as
well. So you can write something like "ARM SMCCC requires that SSSC
revision and function call count should be updated every time you add
or remove a function"
Usually we update versioning number only once per release. I would
follow the same approach for this one. So I would suggest
It is not stated clearly in SMCCC, but I've got a felling that revision
belongs not to product version, but to SMC interface version. So I see
no reason to change revision, if there was no changes to interface itself.
I'm okay witch changing revision only one time per release, but only
if there was changes to PSCI interface. On other hand, person
responsible for release need to track if there was any changes in PSCI
and act accordingly. This is not very convenient.
So, I would prefer to change revision in the same patch (or patch
series) which alters the interface.
"VPSCI_NR_FUNCS (in asm-arm/vpsci.h) should be updated when adding
removing a function. SSCCC_SMCCC_*_REVISION should be updated once per
Xen release".
And who will be responsible for this?
--
Volodymyr Babchuk
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 3/3] xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c
On 02/02/2018 03:40 PM, Volodymyr Babchuk wrote:
Hi
Hi,
On 02.02.18 16:31, Julien Grall wrote:
Hi,
On 02/02/18 14:23, Volodymyr Babchuk wrote:
On 02.02.18 13:41, Julien Grall wrote:
At the moment PSCI function dispatching is done in vsmc.c and the
function implementation in vpsci.c. Some bits of the implementation is
even done in vsmc.c (see PSCI_SYSTEM_RESET).
This means that it is difficult to follow the implementation and also
requires to export functions for each PSCI functions.
Therefore move PSCI dispatching in two new functions do_vpsci_0_1_call
and do_vpsci_0_2_call. The former will handle PSCI 0.1 call while
the latter
0.2 or later call.
At the same time, a new header vpsci.h was created to contain all
definitions for virtual PSCI and avoid confusion with the host PSCI.
Signed-off-by: Julien Grall
I'm okay with this generally, you can have my r-b:
`Reviewed-by: Volodymyr Babchuk `
I would not have gave a reviewed-by with the comments you gave below ;).
Point taken :)
+/*
+ * PSCI 0.2 or later calls. It will return false if the function ID is
+ * not handled.
+ */
+bool do_vpsci_0_2_call(struct cpu_user_regs *regs, uint32_t fid)
+{
+ /*
+ * /!\ VPSCI_NR_FUNCS (in asm-arm/vpsci.h) should be updated when
+ * adding/removing a function
+ */
Should we also update revision of SSSC interface as well? SMCCC
requires this.
Meh, you can't rely on the SSSC revision most of the time as the
version for PSCI is done through PSCI_get_version. I can add a comment
if you want.
Yes, I agree with you. But section 5.4 of SMCCC 1.0 applies to SSSC as
well. So you can write something like "ARM SMCCC requires that SSSC
revision and function call count should be updated every time you add or
remove a function"
Usually we update versioning number only once per release. I would
follow the same approach for this one. So I would suggest
"VPSCI_NR_FUNCS (in asm-arm/vpsci.h) should be updated when adding
removing a function. SSCCC_SMCCC_*_REVISION should be updated once per
Xen release".
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 3/3] xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c
Hi
On 02.02.18 16:31, Julien Grall wrote:
Hi,
On 02/02/18 14:23, Volodymyr Babchuk wrote:
On 02.02.18 13:41, Julien Grall wrote:
At the moment PSCI function dispatching is done in vsmc.c and the
function implementation in vpsci.c. Some bits of the implementation is
even done in vsmc.c (see PSCI_SYSTEM_RESET).
This means that it is difficult to follow the implementation and also
requires to export functions for each PSCI functions.
Therefore move PSCI dispatching in two new functions do_vpsci_0_1_call
and do_vpsci_0_2_call. The former will handle PSCI 0.1 call while the
latter
0.2 or later call.
At the same time, a new header vpsci.h was created to contain all
definitions for virtual PSCI and avoid confusion with the host PSCI.
Signed-off-by: Julien Grall
I'm okay with this generally, you can have my r-b:
`Reviewed-by: Volodymyr Babchuk `
I would not have gave a reviewed-by with the comments you gave below ;).
Point taken :)
+/*
+ * PSCI 0.2 or later calls. It will return false if the function ID is
+ * not handled.
+ */
+bool do_vpsci_0_2_call(struct cpu_user_regs *regs, uint32_t fid)
+{
+ /*
+ * /!\ VPSCI_NR_FUNCS (in asm-arm/vpsci.h) should be updated when
+ * adding/removing a function
+ */
Should we also update revision of SSSC interface as well? SMCCC
requires this.
Meh, you can't rely on the SSSC revision most of the time as the version
for PSCI is done through PSCI_get_version. I can add a comment if you want.
Yes, I agree with you. But section 5.4 of SMCCC 1.0 applies to SSSC as
well. So you can write something like "ARM SMCCC requires that SSSC
revision and function call count should be updated every time you add or
remove a function"
[...]
--
Volodymyr Babchuk
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 3/3] xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c
Hi,
On 02/02/18 14:23, Volodymyr Babchuk wrote:
On 02.02.18 13:41, Julien Grall wrote:
At the moment PSCI function dispatching is done in vsmc.c and the
function implementation in vpsci.c. Some bits of the implementation is
even done in vsmc.c (see PSCI_SYSTEM_RESET).
This means that it is difficult to follow the implementation and also
requires to export functions for each PSCI functions.
Therefore move PSCI dispatching in two new functions do_vpsci_0_1_call
and do_vpsci_0_2_call. The former will handle PSCI 0.1 call while the
latter
0.2 or later call.
At the same time, a new header vpsci.h was created to contain all
definitions for virtual PSCI and avoid confusion with the host PSCI.
Signed-off-by: Julien Grall
I'm okay with this generally, you can have my r-b:
`Reviewed-by: Volodymyr Babchuk `
I would not have gave a reviewed-by with the comments you gave below ;).
+/*
+ * PSCI 0.2 or later calls. It will return false if the function ID is
+ * not handled.
+ */
+bool do_vpsci_0_2_call(struct cpu_user_regs *regs, uint32_t fid)
+{
+ /*
+ * /!\ VPSCI_NR_FUNCS (in asm-arm/vpsci.h) should be updated when
+ * adding/removing a function
+ */
Should we also update revision of SSSC interface as well? SMCCC requires
this.
Meh, you can't rely on the SSSC revision most of the time as the version
for PSCI is done through PSCI_get_version. I can add a comment if you want.
[...]
diff --git a/xen/include/asm-arm/vpsci.h b/xen/include/asm-arm/vpsci.h
new file mode 100644
index 00..d6a890f6a2
--- /dev/null
+++ b/xen/include/asm-arm/vpsci.h
@@ -0,0 +1,13 @@
I'm not sure, should you add license information?
I think so.
+#ifndef __ASM_VPSCI_H__
+#define __ASM_VPSCI_H__
+
+#include
+
+/* Number of function implemented by virtual PSCI (only 0.2 or later) */
+#define VPSCI_NR_FUNCS 11
+
+/* Functions handle PSCI calls from the guests */
+bool do_vpsci_0_1_call(struct cpu_user_regs *regs, uint32_t fid);
+bool do_vpsci_0_2_call(struct cpu_user_regs *regs, uint32_t fid);
+
+#endif /* __ASM_VPSCI_H__ */
And the same about Emacs tags.
Good catch. I will send a new version with the comments addressed.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 3/3] xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c
On 02.02.18 13:41, Julien Grall wrote:
At the moment PSCI function dispatching is done in vsmc.c and the
function implementation in vpsci.c. Some bits of the implementation is
even done in vsmc.c (see PSCI_SYSTEM_RESET).
This means that it is difficult to follow the implementation and also
requires to export functions for each PSCI functions.
Therefore move PSCI dispatching in two new functions do_vpsci_0_1_call
and do_vpsci_0_2_call. The former will handle PSCI 0.1 call while the latter
0.2 or later call.
At the same time, a new header vpsci.h was created to contain all
definitions for virtual PSCI and avoid confusion with the host PSCI.
Signed-off-by: Julien Grall
I'm okay with this generally, you can have my r-b:
`Reviewed-by: Volodymyr Babchuk `
But there are couple of minor questions below.
---
Changes in v2:
- Add a 'v' in the function names to help distinguish virtual vs
physical PSCI
- Introduce vpsci.h and VSCPI_NR_FUNCS
---
xen/arch/arm/vpsci.c| 147 +++-
xen/arch/arm/vsmc.c | 99 ++---
xen/include/asm-arm/psci.h | 19 --
xen/include/asm-arm/vpsci.h | 13
4 files changed, 152 insertions(+), 126 deletions(-)
create mode 100644 xen/include/asm-arm/vpsci.h
diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index 979d32ed6d..884f0fa710 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -16,7 +16,7 @@
#include
#include
-#include
+#include
#include
#include
@@ -91,12 +91,12 @@ static int do_common_cpu_on(register_t target_cpu,
register_t entry_point,
return PSCI_SUCCESS;
}
-int32_t do_psci_cpu_on(uint32_t vcpuid, register_t entry_point)
+static int32_t do_psci_cpu_on(uint32_t vcpuid, register_t entry_point)
{
return do_common_cpu_on(vcpuid, entry_point, 0 , PSCI_VERSION(0, 1));
}
-int32_t do_psci_cpu_off(uint32_t power_state)
+static int32_t do_psci_cpu_off(uint32_t power_state)
{
struct vcpu *v = current;
if ( !test_and_set_bit(_VPF_down, &v->pause_flags) )
@@ -104,13 +104,14 @@ int32_t do_psci_cpu_off(uint32_t power_state)
return PSCI_SUCCESS;
}
-uint32_t do_psci_0_2_version(void)
+static uint32_t do_psci_0_2_version(void)
{
return PSCI_VERSION(0, 2);
}
-register_t do_psci_0_2_cpu_suspend(uint32_t power_state, register_t entry_point,
-register_t context_id)
+static register_t do_psci_0_2_cpu_suspend(uint32_t power_state,
+ register_t entry_point,
+ register_t context_id)
{
struct vcpu *v = current;
@@ -123,13 +124,14 @@ register_t do_psci_0_2_cpu_suspend(uint32_t power_state, register_t entry_point,
return PSCI_SUCCESS;
}
-int32_t do_psci_0_2_cpu_off(void)
+static int32_t do_psci_0_2_cpu_off(void)
{
return do_psci_cpu_off(0);
}
-int32_t do_psci_0_2_cpu_on(register_t target_cpu, register_t entry_point,
- register_t context_id)
+static int32_t do_psci_0_2_cpu_on(register_t target_cpu,
+ register_t entry_point,
+ register_t context_id)
{
return do_common_cpu_on(target_cpu, entry_point, context_id,
PSCI_VERSION(0, 2));
@@ -144,8 +146,8 @@ static const unsigned long target_affinity_mask[] = {
#endif
};
-int32_t do_psci_0_2_affinity_info(register_t target_affinity,
- uint32_t lowest_affinity_level)
+static int32_t do_psci_0_2_affinity_info(register_t target_affinity,
+ uint32_t lowest_affinity_level)
{
struct domain *d = current->domain;
struct vcpu *v;
@@ -172,23 +174,140 @@ int32_t do_psci_0_2_affinity_info(register_t
target_affinity,
return PSCI_0_2_AFFINITY_LEVEL_OFF;
}
-uint32_t do_psci_0_2_migrate_info_type(void)
+static uint32_t do_psci_0_2_migrate_info_type(void)
{
return PSCI_0_2_TOS_MP_OR_NOT_PRESENT;
}
-void do_psci_0_2_system_off( void )
+static void do_psci_0_2_system_off( void )
{
struct domain *d = current->domain;
domain_shutdown(d,SHUTDOWN_poweroff);
}
-void do_psci_0_2_system_reset(void)
+static void do_psci_0_2_system_reset(void)
{
struct domain *d = current->domain;
domain_shutdown(d,SHUTDOWN_reboot);
}
+#define PSCI_SET_RESULT(reg, val) set_user_reg(reg, 0, val)
+#define PSCI_ARG(reg, n) get_user_reg(reg, n)
+
+#ifdef CONFIG_ARM_64
+#define PSCI_ARG32(reg, n) (uint32_t)(get_user_reg(reg, n))
+#else
+#define PSCI_ARG32(reg, n) PSCI_ARG(reg, n)
+#endif
+
+/*
+ * PSCI 0.1 calls. It will return false if the function ID is not
+ * handled.
+ */
+bool do_vpsci_0_1_call(struct cpu_user_regs *regs, uint32_t fid)
+{
+switch ( (uint32_t)get_user_reg(regs, 0) )
+{
+case PSCI_cpu_off:
+{
+uint32_t p
[Xen-devel] [PATCH v2 3/3] xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c
At the moment PSCI function dispatching is done in vsmc.c and the
function implementation in vpsci.c. Some bits of the implementation is
even done in vsmc.c (see PSCI_SYSTEM_RESET).
This means that it is difficult to follow the implementation and also
requires to export functions for each PSCI functions.
Therefore move PSCI dispatching in two new functions do_vpsci_0_1_call
and do_vpsci_0_2_call. The former will handle PSCI 0.1 call while the latter
0.2 or later call.
At the same time, a new header vpsci.h was created to contain all
definitions for virtual PSCI and avoid confusion with the host PSCI.
Signed-off-by: Julien Grall
---
Changes in v2:
- Add a 'v' in the function names to help distinguish virtual vs
physical PSCI
- Introduce vpsci.h and VSCPI_NR_FUNCS
---
xen/arch/arm/vpsci.c| 147 +++-
xen/arch/arm/vsmc.c | 99 ++---
xen/include/asm-arm/psci.h | 19 --
xen/include/asm-arm/vpsci.h | 13
4 files changed, 152 insertions(+), 126 deletions(-)
create mode 100644 xen/include/asm-arm/vpsci.h
diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index 979d32ed6d..884f0fa710 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -16,7 +16,7 @@
#include
#include
-#include
+#include
#include
#include
@@ -91,12 +91,12 @@ static int do_common_cpu_on(register_t target_cpu,
register_t entry_point,
return PSCI_SUCCESS;
}
-int32_t do_psci_cpu_on(uint32_t vcpuid, register_t entry_point)
+static int32_t do_psci_cpu_on(uint32_t vcpuid, register_t entry_point)
{
return do_common_cpu_on(vcpuid, entry_point, 0 , PSCI_VERSION(0, 1));
}
-int32_t do_psci_cpu_off(uint32_t power_state)
+static int32_t do_psci_cpu_off(uint32_t power_state)
{
struct vcpu *v = current;
if ( !test_and_set_bit(_VPF_down, &v->pause_flags) )
@@ -104,13 +104,14 @@ int32_t do_psci_cpu_off(uint32_t power_state)
return PSCI_SUCCESS;
}
-uint32_t do_psci_0_2_version(void)
+static uint32_t do_psci_0_2_version(void)
{
return PSCI_VERSION(0, 2);
}
-register_t do_psci_0_2_cpu_suspend(uint32_t power_state, register_t
entry_point,
-register_t context_id)
+static register_t do_psci_0_2_cpu_suspend(uint32_t power_state,
+ register_t entry_point,
+ register_t context_id)
{
struct vcpu *v = current;
@@ -123,13 +124,14 @@ register_t do_psci_0_2_cpu_suspend(uint32_t power_state,
register_t entry_point,
return PSCI_SUCCESS;
}
-int32_t do_psci_0_2_cpu_off(void)
+static int32_t do_psci_0_2_cpu_off(void)
{
return do_psci_cpu_off(0);
}
-int32_t do_psci_0_2_cpu_on(register_t target_cpu, register_t entry_point,
- register_t context_id)
+static int32_t do_psci_0_2_cpu_on(register_t target_cpu,
+ register_t entry_point,
+ register_t context_id)
{
return do_common_cpu_on(target_cpu, entry_point, context_id,
PSCI_VERSION(0, 2));
@@ -144,8 +146,8 @@ static const unsigned long target_affinity_mask[] = {
#endif
};
-int32_t do_psci_0_2_affinity_info(register_t target_affinity,
- uint32_t lowest_affinity_level)
+static int32_t do_psci_0_2_affinity_info(register_t target_affinity,
+ uint32_t lowest_affinity_level)
{
struct domain *d = current->domain;
struct vcpu *v;
@@ -172,23 +174,140 @@ int32_t do_psci_0_2_affinity_info(register_t
target_affinity,
return PSCI_0_2_AFFINITY_LEVEL_OFF;
}
-uint32_t do_psci_0_2_migrate_info_type(void)
+static uint32_t do_psci_0_2_migrate_info_type(void)
{
return PSCI_0_2_TOS_MP_OR_NOT_PRESENT;
}
-void do_psci_0_2_system_off( void )
+static void do_psci_0_2_system_off( void )
{
struct domain *d = current->domain;
domain_shutdown(d,SHUTDOWN_poweroff);
}
-void do_psci_0_2_system_reset(void)
+static void do_psci_0_2_system_reset(void)
{
struct domain *d = current->domain;
domain_shutdown(d,SHUTDOWN_reboot);
}
+#define PSCI_SET_RESULT(reg, val) set_user_reg(reg, 0, val)
+#define PSCI_ARG(reg, n) get_user_reg(reg, n)
+
+#ifdef CONFIG_ARM_64
+#define PSCI_ARG32(reg, n) (uint32_t)(get_user_reg(reg, n))
+#else
+#define PSCI_ARG32(reg, n) PSCI_ARG(reg, n)
+#endif
+
+/*
+ * PSCI 0.1 calls. It will return false if the function ID is not
+ * handled.
+ */
+bool do_vpsci_0_1_call(struct cpu_user_regs *regs, uint32_t fid)
+{
+switch ( (uint32_t)get_user_reg(regs, 0) )
+{
+case PSCI_cpu_off:
+{
+uint32_t pstate = PSCI_ARG32(regs, 1);
+
+perfc_incr(vpsci_cpu_off);
+PSCI_SET_RESULT(regs, do_psci_cpu_off(pstate));
+return true;
+}
+case PSCI_cpu_on:
+{
+uint32_t vcpuid = PSCI_ARG32(regs, 1);
+register_t epoint =
