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

[Rob Herring]

On Wed, Dec 18, 2013 at 12:25 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On Wed, Dec 18 2013 at 06:18:54 PM, Anup Patel <anup at brainfault.org> wrote:
>> On Wed, Dec 18, 2013 at 11:41 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>> On Wed, Dec 18 2013 at 03:52:29 PM, Anup Patel <anup at brainfault.org> wrote:
>>>> On Wed, Dec 18, 2013 at 9:11 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>>>> Hi Anup,
>>>>>
>>>>> On Wed, Dec 18 2013 at 03:03:43 PM, Anup Patel <anup at brainfault.org> wrote:
>>>>>> On Wed, Dec 18, 2013 at 8:08 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>>>>>> Christoffer Dall <christoffer.dall at linaro.org> writes:
>>>>>>>
>>>>>>>> On Tue, Dec 17, 2013 at 05:05:34PM +0530, Anup Patel wrote:
>>>>>>>>> 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 <christoffer.dall at linaro.org>
>>>>>>>>
>>>>>>>> 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?
>
> 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.

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

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

Rob