On Wed, Dec 18 2013 at 03:52:29 PM, Anup Patel <anup@xxxxxxxxxxxxxx> wrote: > On Wed, Dec 18, 2013 at 9:11 PM, Marc Zyngier <marc.zyngier@xxxxxxx> wrote: >> Hi Anup, >> >> On Wed, Dec 18 2013 at 03:03:43 PM, Anup Patel <anup@xxxxxxxxxxxxxx> wrote: >>> On Wed, Dec 18, 2013 at 8:08 PM, Marc Zyngier <marc.zyngier@xxxxxxx> wrote: >>>> Christoffer Dall <christoffer.dall@xxxxxxxxxx> 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@xxxxxxxxxx> >>>>> >>>>> 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. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
