[PATCH v3 0/2] PSCI system off and reset for KVM ARM/ARM64

On Wed, Dec 18 2013 at 03:52:29 PM, Anup Patel [off-list ref] wrote:

On Wed, Dec 18, 2013 at 9:11 PM, Marc Zyngier [off-list ref] wrote:

quoted

Hi Anup,

On Wed, Dec 18 2013 at 03:03:43 PM, Anup Patel [off-list ref] wrote:

quoted

On Wed, Dec 18, 2013 at 8:08 PM, Marc Zyngier [off-list ref] wrote:

quoted

Christoffer Dall [off-list ref] writes:

quoted

On Tue, Dec 17, 2013 at 05:05:34PM +0530, Anup Patel wrote:

quoted

The Power State and Coordination Interface (PSCI) specification defines
SYSTEM_OFF and SYSTEM_RESET functions for system poweroff and reboot.

This patchset adds emulation of PSCI SYSTEM_OFF and SYSTEM_RESET functions
in KVM ARM/ARM64 by forwarding them to user space (QEMU or KVMTOOL) using
KVM_EXIT_SYSTEM_EVENT exit reason.

To try this patch from guest kernel, we will need PSCI-based restart and
poweroff support in the guest kenel for both ARM and ARM64.

Rob Herring has already submitted patches for PSCI-based restart and
poweroff in ARM kernel but these are not merged yet due unstable device
tree bindings of kernel PSCI support. We will be having similar patches
for PSCI-based restart and poweroff in ARM64 kernel.
(Refer http://www.spinics.net/lists/arm-kernel/msg262217.html)
(Refer http://www.spinics.net/lists/devicetree/msg05348.html)

Reviewed-by: Christoffer Dall <redacted>

I can merge this series if Marc acks it as well.

The patches themselves are mostly fine. One issue though: They implement
part of the v0.2 spec, but keep on using the range of function IDs that
we made up for v0.1.

I just had a chat with the person responsible for the spec, and realized
that the Function IDs mentionned in the v0.2 spec are not optional, and
not using them would be in direct violation of the spec (the new numbers
now come directly from the SMC calling convention).

Should we emulate PSCI_VERSION call to help Guest determine
the spec version emulated by KVM (i.e. v0.1 or v0.2) ??

I think that'd be a nice to have, but the guest is likely to get its
information from the DT anyway. Plus I don't think the original PSCI
spec specified PSCI_VERSION, which only make it useful for whatever
comes after v0.2.

So I think we need to:
- Use the new range for PSCI v0.2 (while still supporting v0.1 and the
old range)

Does this mean we should have first isolate v0.2 ID range
from v0.1 ID range?

Yes.

And then...

Rebase this patchset based on new v0.2 ID range?

Indeed.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny.

On Wed, Dec 18, 2013 at 11:41 PM, Marc Zyngier [off-list ref] wrote:

On Wed, Dec 18 2013 at 03:52:29 PM, Anup Patel [off-list ref] wrote:

quoted

On Wed, Dec 18, 2013 at 9:11 PM, Marc Zyngier [off-list ref] wrote:

quoted

Hi Anup,

On Wed, Dec 18 2013 at 03:03:43 PM, Anup Patel [off-list ref] wrote:

quoted

On Wed, Dec 18, 2013 at 8:08 PM, Marc Zyngier [off-list ref] wrote:

quoted

Christoffer Dall [off-list ref] writes:

quoted

On Tue, Dec 17, 2013 at 05:05:34PM +0530, Anup Patel wrote:

quoted

The Power State and Coordination Interface (PSCI) specification defines
SYSTEM_OFF and SYSTEM_RESET functions for system poweroff and reboot.

This patchset adds emulation of PSCI SYSTEM_OFF and SYSTEM_RESET functions
in KVM ARM/ARM64 by forwarding them to user space (QEMU or KVMTOOL) using
KVM_EXIT_SYSTEM_EVENT exit reason.

To try this patch from guest kernel, we will need PSCI-based restart and
poweroff support in the guest kenel for both ARM and ARM64.

Rob Herring has already submitted patches for PSCI-based restart and
poweroff in ARM kernel but these are not merged yet due unstable device
tree bindings of kernel PSCI support. We will be having similar patches
for PSCI-based restart and poweroff in ARM64 kernel.
(Refer http://www.spinics.net/lists/arm-kernel/msg262217.html)
(Refer http://www.spinics.net/lists/devicetree/msg05348.html)

Reviewed-by: Christoffer Dall <redacted>

I can merge this series if Marc acks it as well.

The patches themselves are mostly fine. One issue though: They implement
part of the v0.2 spec, but keep on using the range of function IDs that
we made up for v0.1.

I just had a chat with the person responsible for the spec, and realized
that the Function IDs mentionned in the v0.2 spec are not optional, and
not using them would be in direct violation of the spec (the new numbers
now come directly from the SMC calling convention).

Should we emulate PSCI_VERSION call to help Guest determine
the spec version emulated by KVM (i.e. v0.1 or v0.2) ??

I think that'd be a nice to have, but the guest is likely to get its
information from the DT anyway. Plus I don't think the original PSCI
spec specified PSCI_VERSION, which only make it useful for whatever
comes after v0.2.

So I think we need to:
- Use the new range for PSCI v0.2 (while still supporting v0.1 and the
old range)

Does this mean we should have first isolate v0.2 ID range
from v0.1 ID range?

Yes.

Are you planning to do it ?
OR
Do you expect me to do it because this patchset would depend on that?

quoted

And then...

Rebase this patchset based on new v0.2 ID range?

Indeed.

Thanks,

        M.
--
Jazz is not dead. It just smells funny.

Regards,
Anup