PSCI system off and reset for KVM ARM/ARM64

Am 17.12.2013 um 12:35 schrieb Anup Patel <[email protected]>:

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)

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)

Quoted 10 lines · Anup Patel

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.

Quoted 6 lines

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 <[email protected]>

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

Quoted 18 lines · Christoffer Dall

Quoted 10 lines · Anup Patel

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.

Quoted 6 lines

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)

Quoted 3 lines

Reviewed-by Christoffer Dall <[email protected]>

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).

So I rekon we need to create a separate range for those. Also, I'd like to progress the DT and kernel side of things as well (otherwise this is all a bit pointless).

Rob: what are your plans regarding your PSCI v0.2 patches?

Thanks,

        M.

--
Jazz is not dead. It just smells funny.
_______________________________________________
kvmarm mailing list
kvmarm at lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm

Quoted 28 lines · Marc Zyngier

Quoted 18 lines · Christoffer Dall

Quoted 10 lines · Anup Patel

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.

Quoted 6 lines

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)

Quoted 3 lines

Reviewed-by Christoffer Dall <[email protected]>

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.

Quoted 4 lines

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) ??

Hi Anup,

Quoted 29 lines · Anup Patel

Quoted 28 lines · Marc Zyngier

Quoted 18 lines · Christoffer Dall

Quoted 10 lines · Anup Patel

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.

Quoted 6 lines

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)

Quoted 3 lines

Reviewed-by Christoffer Dall <[email protected]>

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.

Quoted 7 lines

Quoted 4 lines

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)

- Get the kernel and DT bindings into shape
- Merge all of that at the same time

Cheers,

        M.

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

Quoted 45 lines · Marc Zyngier

Hi Anup,

Quoted 29 lines · Anup Patel

Quoted 28 lines · Marc Zyngier

Quoted 18 lines · Christoffer Dall

Quoted 10 lines · Anup Patel

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.

Quoted 6 lines

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)

Quoted 3 lines

Reviewed-by Christoffer Dall <[email protected]>

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.

Quoted 7 lines

Quoted 4 lines

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.

Quoted 3 lines

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?

And then...

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

Quoted 46 lines · Anup Patel

Quoted 45 lines · Marc Zyngier

Hi Anup,

Quoted 29 lines · Anup Patel

Quoted 28 lines · Marc Zyngier

Quoted 18 lines · Christoffer Dall

Quoted 10 lines · Anup Patel

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.

Quoted 6 lines

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)

Quoted 3 lines

Reviewed-by Christoffer Dall <[email protected]>

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.

Quoted 7 lines

Quoted 4 lines

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.

Quoted 6 lines

Quoted 3 lines

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.

Quoted 4 lines

And then...

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

Indeed.

Thanks,

        M.

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

Quoted 51 lines · Marc Zyngier

Quoted 50 lines · Anup Patel

Quoted 48 lines · Marc Zyngier

Hi Anup,

Quoted 29 lines · Anup Patel

Quoted 28 lines · Marc Zyngier

Quoted 18 lines · Christoffer Dall

Quoted 10 lines · Anup Patel

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.

Quoted 6 lines

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)

Quoted 3 lines

Reviewed-by Christoffer Dall <[email protected]>

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.

Quoted 7 lines

Quoted 4 lines

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)

Quoted 4 lines

Quoted 2 lines

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 52 lines · Anup Patel

Quoted 51 lines · Marc Zyngier

Quoted 50 lines · Anup Patel

Quoted 48 lines · Marc Zyngier

Hi Anup,

Quoted 29 lines · Anup Patel

Quoted 28 lines · Marc Zyngier

Quoted 18 lines · Christoffer Dall

Quoted 10 lines · Anup Patel

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.

Quoted 6 lines

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)

Quoted 3 lines

Reviewed-by Christoffer Dall <[email protected]>

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.

Quoted 7 lines

Quoted 4 lines

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)

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

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?

First, I want to understand the objections that were raised against using the Function IDs as defined in the spec.

Then, assuming we move in that direction, I'd expect you to create a separate range of IDs and update the PSCI code to handle both PSCI versions.

But as this has direct implication with userspace (DT generation), I'd rather take it slow and first try to understand the issues Mark raised.

Quoted 69 lines · Marc Zyngier

Quoted 52 lines · Anup Patel

Quoted 51 lines · Marc Zyngier

Quoted 50 lines · Anup Patel

Quoted 48 lines · Marc Zyngier

Hi Anup,

Quoted 29 lines · Anup Patel

Quoted 28 lines · Marc Zyngier

Quoted 18 lines · Christoffer Dall

Quoted 10 lines · Anup Patel

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.

Quoted 6 lines

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)

Quoted 3 lines

Reviewed-by Christoffer Dall <[email protected]>

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.

Quoted 7 lines

Quoted 4 lines

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)

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

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?

First, I want to understand the objections that were raised against using the Function IDs as defined in the spec.

Then, assuming we move in that direction, I'd expect you to create a separate range of IDs and update the PSCI code to handle both PSCI versions.

Quoted 2 lines

But as this has direct implication with userspace (DT generation), I'd rather take it slow and first try to understand the issues Mark raised.

Here is the thread where relying on SMC calling convention was discussed:

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/188057.html

From reading that thread and the PSCI and SMC calling convention docs I

Hi Anup,

Quoted 29 lines · Anup Patel

Quoted 28 lines · Marc Zyngier

Quoted 18 lines · Christoffer Dall

Quoted 10 lines · Anup Patel

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.

Quoted 6 lines

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)

Quoted 3 lines

Reviewed-by Christoffer Dall <[email protected]>

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.

Quoted 7 lines

Quoted 4 lines

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)
- Get the kernel and DT bindings into shape
- Merge all of that at the same time

Quoted 7 lines

Quoted 7 lines

So I think we need to:
- Use the new range for PSCI v0.2 (while still supporting v0.1 and the old range)
- Get the kernel and DT bindings into shape
- Merge all of that at the same time

Don't we also need a way for user space to tell KVM if it should emulate v0.1 or v0.2 of PSCI so we don't break backwards compatibility with tools that spit out a device tree and use guest kernels based on v0.1?

This could be a new feature for KVM_ARM_VCPU_INIT, but perhaps it should be something on the VM level, hmmm.

Quoted 18 lines · Christoffer Dall

Quoted 10 lines · Anup Patel

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.

Quoted 6 lines

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)

Quoted 3 lines

Reviewed-by Christoffer Dall <[email protected]>

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).

So I rekon we need to create a separate range for those. Also, I'd like to progress the DT and kernel side of things as well (otherwise this is all a bit pointless).

Rob: what are your plans regarding your PSCI v0.2 patches?

Adding Mark Rutland.

Quoted 24 lines · Marc Zyngier

Quoted 18 lines · Christoffer Dall

Quoted 10 lines · Anup Patel

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.

Quoted 6 lines

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)

Quoted 3 lines

Reviewed-by Christoffer Dall <[email protected]>

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

Quoted 8 lines

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).

News to me. That is exactly the opposite of what Mark Rutland told me. This would certainly simplify things since the SMC calling convention IDs encode the size and there would be no reason to put the IDs into DT.

Quoted 5 lines

So I rekon we need to create a separate range for those. Also, I'd like to progress the DT and kernel side of things as well (otherwise this is all a bit pointless).

Rob: what are your plans regarding your PSCI v0.2 patches?

My plan was to simply add 2 optional properties for reset/off and be done with it like is done here. I'll leave it to ARM to sort out all of v0.2 ID and 32-bit vs. 64-bit issues.

Hi Rob,

Quoted 40 lines · Rob Herring

Adding Mark Rutland.

Quoted 24 lines · Marc Zyngier

Quoted 18 lines · Christoffer Dall

Quoted 10 lines · Anup Patel

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.

Quoted 6 lines

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)

Quoted 3 lines

Reviewed-by Christoffer Dall <[email protected]>

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

Quoted 8 lines

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).

News to me. That is exactly the opposite of what Mark Rutland told me. This would certainly simplify things since the SMC calling convention IDs encode the size and there would be no reason to put the IDs into DT.

Hmmm. I'd hate to contredict Mark. But as he's on holiday (and hopefully unlikely to reply immediately), I win the argument! ;-)

More seriously, given that we have a document specifying the IDs, I'd be inclined to follow it. It is not that often that ARM actually *mandates* something... ;-)

Mark (assuming you're reading this): what were your objections about following the ID mentioned in the spec?

Quoted 10 lines

Quoted 6 lines

So I rekon we need to create a separate range for those. Also, I'd like to progress the DT and kernel side of things as well (otherwise this is all a bit pointless).

Rob: what are your plans regarding your PSCI v0.2 patches?

My plan was to simply add 2 optional properties for reset/off and be done with it like is done here. I'll leave it to ARM to sort out all of v0.2 ID and 32-bit vs. 64-bit issues.

Quoted 43 lines · Marc Zyngier

Hi Rob,

Quoted 40 lines · Rob Herring

Adding Mark Rutland.

Quoted 24 lines · Marc Zyngier

Quoted 18 lines · Christoffer Dall

Quoted 10 lines · Anup Patel

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.

Quoted 6 lines

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)

Quoted 3 lines

Reviewed-by Christoffer Dall <[email protected]>

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

Quoted 8 lines

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).

News to me. That is exactly the opposite of what Mark Rutland told me. This would certainly simplify things since the SMC calling convention IDs encode the size and there would be no reason to put the IDs into DT.

Hi Rob,

Sorry for the confusion here. My position changed over the course of the discussion, so I'm probably arguing against my original side now.

I think the key point was that I wanted a PSCI 0.2 system to function with an existing kernel if possible, as all the existing calls still exist. That implied placing the numbers (redundantly) into the DT. This is important for extending KVM with PSCI 0.2 support without breaking support for existing guests and having to have a load of messy flags depending on the guest you want to boot.

I agree that we should use the specified function IDs, and therefore we do not need to specify the IDs. A new system that old kernels can't run on anyway can just have:

psci {
	compatible = "arm,psci-0.2";
	methoc = "smc";
};

However, it would be nice to have a set of function IDs in the DT for existing clients as a fallback. Preferably in the same node (we have the compatible list, we may as well use it and make it clear we expect clients to use one or the other):

psci {
	compatible = "arm,psci-0.2", "arm,psci";
	method = "smc";

	/* 
	 * The mandated PSCI 0.2 IDs are used by the client if it
	 * understands PSCI 0.2. These IDs are for older clients that
	 * only support the kernel's old PSCI version.
	 *
	 * These IDs might not match any of the PSCI 0.2 IDs, and are
	 * purely here for compatibility with existing software.
	 */
	cpu_off = <...>;
	cpu_on = <...>;
	cpu_suspend = <...>;
};

I believe KVM currently uses the same ID numbers regardless of guest register-width, which is unfortunately different from what PSCI 0.2 says it should. As KVM can figure out the register width of the caller it might be able to do the right thing (unless that's in conflict with PSCI 0.2). At worst we should be able to allocate a third set of width-agnostic IDs for older clients that imply the current behaviour.

Does that sound reasonable? Sorry for leading you in circles.

Quoted 10 lines

Hmmm. I'd hate to contredict Mark. But as he's on holiday (and hopefully unlikely to reply immediately), I win the argument! ;-)

More seriously, given that we have a document specifying the IDs, I'd be inclined to follow it. It is not that often that ARM actually *mandates* something... ;-)

Mark (assuming you're reading this): what were your objections about following the ID mentioned in the spec?

Originally I was worried about more spectacularly bad implementations with wrong IDs or a subset of IDs supported. Now I agree that we can handle those later if and when they arise, and using the correct IDs is a far better option.

The other issue was KVM forwards-compatibility, but I think the above covers that.

Quoted 10 lines

Quoted 10 lines

Quoted 6 lines

So I rekon we need to create a separate range for those. Also, I'd like to progress the DT and kernel side of things as well (otherwise this is all a bit pointless).

Rob: what are your plans regarding your PSCI v0.2 patches?

My plan was to simply add 2 optional properties for reset/off and be done with it like is done here. I'll leave it to ARM to sort out all of v0.2 ID and 32-bit vs. 64-bit issues.

Does the above sound OK for adding that support?

Thanks,
Mark.

Quoted 43 lines · Marc Zyngier

Hi Rob,

Quoted 40 lines · Rob Herring

Adding Mark Rutland.

Quoted 24 lines · Marc Zyngier

Quoted 18 lines · Christoffer Dall

Quoted 10 lines · Anup Patel

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.

Quoted 6 lines

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)

Quoted 3 lines

Reviewed-by Christoffer Dall <[email protected]>

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

Quoted 8 lines

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).

News to me. That is exactly the opposite of what Mark Rutland told me. This would certainly simplify things since the SMC calling convention IDs encode the size and there would be no reason to put the IDs into DT.

Hi Rob,

Sorry for the confusion here. My position changed over the course of the discussion, so I'm probably arguing against my original side now.

I think the key point was that I wanted a PSCI 0.2 system to function with an existing kernel if possible, as all the existing calls still exist. That implied placing the numbers (redundantly) into the DT. This is important for extending KVM with PSCI 0.2 support without breaking support for existing guests and having to have a load of messy flags depending on the guest you want to boot.

I agree that we should use the specified function IDs, and therefore we do not need to specify the IDs. A new system that old kernels can't run on anyway can just have:

psci {
        compatible = "arm,psci-0.2";
        methoc = "smc";
};

However, it would be nice to have a set of function IDs in the DT for existing clients as a fallback. Preferably in the same node (we have the compatible list, we may as well use it and make it clear we expect clients to use one or the other):

psci {
        compatible = "arm,psci-0.2", "arm,psci";
        method = "smc";

        /*
         * The mandated PSCI 0.2 IDs are used by the client if it
         * understands PSCI 0.2. These IDs are for older clients that
         * only support the kernel's old PSCI version.
         *
         * These IDs might not match any of the PSCI 0.2 IDs, and are
         * purely here for compatibility with existing software.
         */
        cpu_off = <...>;
        cpu_on = <...>;
        cpu_suspend = <...>;
};

I believe KVM currently uses the same ID numbers regardless of guest register-width, which is unfortunately different from what PSCI 0.2 says it should. As KVM can figure out the register width of the caller it might be able to do the right thing (unless that's in conflict with PSCI 0.2). At worst we should be able to allocate a third set of width-agnostic IDs for older clients that imply the current behaviour.

Does that sound reasonable? Sorry for leading you in circles.

Quoted 3 lines

Mark (assuming you're reading this): what were your objections about following the ID mentioned in the spec?

Originally I was worried about more spectacularly bad implementations with wrong IDs or a subset of IDs supported. Now I agree that we can handle those later if and when they arise, and using the correct IDs is a far better option.

The other issue was KVM forwards-compatibility, but I think the above covers that.

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

So I rekon we need to create a separate range for those. Also, I'd like to progress the DT and kernel side of things as well (otherwise this is all a bit pointless).

Quoted 5 lines

Quoted 5 lines

Quoted 1 line

Rob: what are your plans regarding your PSCI v0.2 patches?

My plan was to simply add 2 optional properties for reset/off and be done with it like is done here. I'll leave it to ARM to sort out all of v0.2 ID and 32-bit vs. 64-bit issues.

Does the above sound OK for adding that support?