Re: [Qemu-devel] [RFC PATCH 0/7] PSCI v0.2 support for KVM ARM/ARM64

Re: [Qemu-devel] [RFC PATCH 0/7] PSCI v0.2 support for KVM ARM/ARM64

[Pranavkumar Sawargaonkar]

On 27 February 2014 12:21, Pranavkumar Sawargaonkar
<pranavkumar@linaro.org> wrote:
> Recentely patches have been posted for in-kernel emulation of PSCI v0.2
> http://www.spinics.net/lists/arm-kernel/msg305467.html
> This patchset adds the QEMU side changes for providing PSCI v0.2 to VM.
>
> Pranavkumar Sawargaonkar (7):
>   linux-headers: Update KVM headers from v3.14-rc3
>   target-arm: Try X-Gene Potenza target type for KVM Aarch64
>   target-arm: Handle exit reason KVM_EXIT_SYSTEM_EVENT
>   target-arm: Provide PSCI v0.2 constants to generic QEMU code
>   target-arm: Enable KVM_ARM_VCPU_PSCI_0_2 feature when possible
>   hw/arm/virt: Use PSCI v0.2 function IDs when kernel supports its
>   target-arm: Hacky implementation of kvm_arch_reset_vcpu() for KVM
>     ARM64
>
>  hw/arm/virt.c                 |   25 ++++++++++++----
>  linux-headers/asm-arm/kvm.h   |   63 ++++++++++++++++++++++++++++++++++++++-
>  linux-headers/asm-arm64/kvm.h |   65 +++++++++++++++++++++++++++++++++++++++--
>  linux-headers/linux/kvm.h     |   10 +++++++
>  target-arm/kvm-consts.h       |   41 ++++++++++++++++++++++++++
>  target-arm/kvm.c              |   30 ++++++++++++++++++-
>  target-arm/kvm32.c            |    5 +++-
>  target-arm/kvm64.c            |   14 ++++++++-
>  8 files changed, 242 insertions(+), 11 deletions(-)
>
> --
> 1.7.9.5
>

Sorry for mentioning wrong qemu devel mail id in my previous mail.
Correcting correct qemu-devel  id.

Thanks,
Pranav

Re: [Qemu-devel] [RFC PATCH 1/7] linux-headers: Update KVM headers from v3.14-rc3

[Pranavkumar Sawargaonkar]

On 27 February 2014 12:21, Pranavkumar Sawargaonkar
<pranavkumar@linaro.org> wrote:
> Syncup KVM related linux headers from v3.14-rc3.
>
> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
> Signed-off-by: Anup Patel <anup.patel@linaro.org>
> ---
>  linux-headers/asm-arm/kvm.h   |   63 ++++++++++++++++++++++++++++++++++++++-
>  linux-headers/asm-arm64/kvm.h |   65 +++++++++++++++++++++++++++++++++++++++--
>  linux-headers/linux/kvm.h     |   10 +++++++
>  3 files changed, 135 insertions(+), 3 deletions(-)
>
> diff --git a/linux-headers/asm-arm/kvm.h b/linux-headers/asm-arm/kvm.h
> index c498b60..1c5acfe 100644
> --- a/linux-headers/asm-arm/kvm.h
> +++ b/linux-headers/asm-arm/kvm.h
> @@ -83,6 +83,7 @@ struct kvm_regs {
>  #define KVM_VGIC_V2_CPU_SIZE           0x2000
>
>  #define KVM_ARM_VCPU_POWER_OFF         0 /* CPU is started in OFF state */
> +#define KVM_ARM_VCPU_PSCI_0_2          1 /* CPU uses PSCI v0.2 */
>
>  struct kvm_vcpu_init {
>         __u32 target;
> @@ -119,6 +120,26 @@ struct kvm_arch_memory_slot {
>  #define KVM_REG_ARM_32_CRN_MASK                0x0000000000007800
>  #define KVM_REG_ARM_32_CRN_SHIFT       11
>
> +#define ARM_CP15_REG_SHIFT_MASK(x,n) \
> +       (((x) << KVM_REG_ARM_ ## n ## _SHIFT) & KVM_REG_ARM_ ## n ## _MASK)
> +
> +#define __ARM_CP15_REG(op1,crn,crm,op2) \
> +       (KVM_REG_ARM | (15 << KVM_REG_ARM_COPROC_SHIFT) | \
> +       ARM_CP15_REG_SHIFT_MASK(op1, OPC1) | \
> +       ARM_CP15_REG_SHIFT_MASK(crn, 32_CRN) | \
> +       ARM_CP15_REG_SHIFT_MASK(crm, CRM) | \
> +       ARM_CP15_REG_SHIFT_MASK(op2, 32_OPC2))
> +
> +#define ARM_CP15_REG32(...) (__ARM_CP15_REG(__VA_ARGS__) | KVM_REG_SIZE_U32)
> +
> +#define __ARM_CP15_REG64(op1,crm) \
> +       (__ARM_CP15_REG(op1, 0, crm, 0) | KVM_REG_SIZE_U64)
> +#define ARM_CP15_REG64(...) __ARM_CP15_REG64(__VA_ARGS__)
> +
> +#define KVM_REG_ARM_TIMER_CTL          ARM_CP15_REG32(0, 14, 3, 1)
> +#define KVM_REG_ARM_TIMER_CNT          ARM_CP15_REG64(1, 14)
> +#define KVM_REG_ARM_TIMER_CVAL         ARM_CP15_REG64(3, 14)
> +
>  /* Normal registers are mapped as coprocessor 16. */
>  #define KVM_REG_ARM_CORE               (0x0010 << KVM_REG_ARM_COPROC_SHIFT)
>  #define KVM_REG_ARM_CORE_REG(name)     (offsetof(struct kvm_regs, name) / 4)
> @@ -143,6 +164,14 @@ struct kvm_arch_memory_slot {
>  #define KVM_REG_ARM_VFP_FPINST         0x1009
>  #define KVM_REG_ARM_VFP_FPINST2                0x100A
>
> +/* Device Control API: ARM VGIC */
> +#define KVM_DEV_ARM_VGIC_GRP_ADDR      0
> +#define KVM_DEV_ARM_VGIC_GRP_DIST_REGS 1
> +#define KVM_DEV_ARM_VGIC_GRP_CPU_REGS  2
> +#define   KVM_DEV_ARM_VGIC_CPUID_SHIFT 32
> +#define   KVM_DEV_ARM_VGIC_CPUID_MASK  (0xffULL << KVM_DEV_ARM_VGIC_CPUID_SHIFT)
> +#define   KVM_DEV_ARM_VGIC_OFFSET_SHIFT        0
> +#define   KVM_DEV_ARM_VGIC_OFFSET_MASK (0xffffffffULL << KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
>
>  /* KVM_IRQ_LINE irq field index values */
>  #define KVM_ARM_IRQ_TYPE_SHIFT         24
> @@ -164,7 +193,7 @@ struct kvm_arch_memory_slot {
>  /* Highest supported SPI, from VGIC_NR_IRQS */
>  #define KVM_ARM_IRQ_GIC_MAX            127
>
> -/* PSCI interface */
> +/* PSCI v0.1 interface */
>  #define KVM_PSCI_FN_BASE               0x95c1ba5e
>  #define KVM_PSCI_FN(n)                 (KVM_PSCI_FN_BASE + (n))
>
> @@ -173,9 +202,41 @@ struct kvm_arch_memory_slot {
>  #define KVM_PSCI_FN_CPU_ON             KVM_PSCI_FN(2)
>  #define KVM_PSCI_FN_MIGRATE            KVM_PSCI_FN(3)
>
> +/* PSCI v0.2 interface */
> +#define KVM_PSCI_0_2_FN_BASE           0x84000000
> +#define KVM_PSCI_0_2_FN(n)             (KVM_PSCI_0_2_FN_BASE + (n))
> +#define KVM_PSCI_0_2_FN64_BASE         0xC4000000
> +#define KVM_PSCI_0_2_FN64(n)           (KVM_PSCI_0_2_FN64_BASE + (n))
> +
> +#define KVM_PSCI_0_2_FN_PSCI_VERSION   KVM_PSCI_0_2_FN(0)
> +#define KVM_PSCI_0_2_FN_CPU_SUSPEND    KVM_PSCI_0_2_FN(1)
> +#define KVM_PSCI_0_2_FN_CPU_OFF                KVM_PSCI_0_2_FN(2)
> +#define KVM_PSCI_0_2_FN_CPU_ON         KVM_PSCI_0_2_FN(3)
> +#define KVM_PSCI_0_2_FN_AFFINITY_INFO  KVM_PSCI_0_2_FN(4)
> +#define KVM_PSCI_0_2_FN_MIGRATE                KVM_PSCI_0_2_FN(5)
> +#define KVM_PSCI_0_2_FN_MIGRATE_INFO_TYPE \
> +                                       KVM_PSCI_0_2_FN(6)
> +#define KVM_PSCI_0_2_FN_MIGRATE_INFO_UP_CPU \
> +                                       KVM_PSCI_0_2_FN(7)
> +#define KVM_PSCI_0_2_FN_SYSTEM_OFF     KVM_PSCI_0_2_FN(8)
> +#define KVM_PSCI_0_2_FN_SYSTEM_RESET   KVM_PSCI_0_2_FN(9)
> +
> +#define KVM_PSCI_0_2_FN64_CPU_SUSPEND  KVM_PSCI_0_2_FN64(1)
> +#define KVM_PSCI_0_2_FN64_CPU_ON       KVM_PSCI_0_2_FN64(3)
> +#define KVM_PSCI_0_2_FN64_AFFINITY_INFO        KVM_PSCI_0_2_FN64(4)
> +#define KVM_PSCI_0_2_FN64_MIGRATE      KVM_PSCI_0_2_FN64(5)
> +#define KVM_PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU \
> +                                       KVM_PSCI_0_2_FN64(7)
> +
> +/* PSCI return values */
>  #define KVM_PSCI_RET_SUCCESS           0
>  #define KVM_PSCI_RET_NI                        ((unsigned long)-1)
>  #define KVM_PSCI_RET_INVAL             ((unsigned long)-2)
>  #define KVM_PSCI_RET_DENIED            ((unsigned long)-3)
> +#define KVM_PSCI_RET_ALREADY_ON                ((unsigned long)-4)
> +#define KVM_PSCI_RET_ON_PENDING                ((unsigned long)-5)
> +#define KVM_PSCI_RET_INTERNAL_FAILURE  ((unsigned long)-6)
> +#define KVM_PSCI_RET_NOT_PRESENT       ((unsigned long)-7)
> +#define KVM_PSCI_RET_DISABLED          ((unsigned long)-8)
>
>  #endif /* __ARM_KVM_H__ */
> diff --git a/linux-headers/asm-arm64/kvm.h b/linux-headers/asm-arm64/kvm.h
> index 5031f42..cadc318 100644
> --- a/linux-headers/asm-arm64/kvm.h
> +++ b/linux-headers/asm-arm64/kvm.h
> @@ -55,8 +55,9 @@ struct kvm_regs {
>  #define KVM_ARM_TARGET_AEM_V8          0
>  #define KVM_ARM_TARGET_FOUNDATION_V8   1
>  #define KVM_ARM_TARGET_CORTEX_A57      2
> +#define KVM_ARM_TARGET_XGENE_POTENZA   3
>
> -#define KVM_ARM_NUM_TARGETS            3
> +#define KVM_ARM_NUM_TARGETS            4
>
>  /* KVM_ARM_SET_DEVICE_ADDR ioctl id encoding */
>  #define KVM_ARM_DEVICE_TYPE_SHIFT      0
> @@ -76,6 +77,7 @@ struct kvm_regs {
>
>  #define KVM_ARM_VCPU_POWER_OFF         0 /* CPU is started in OFF state */
>  #define KVM_ARM_VCPU_EL1_32BIT         1 /* CPU running a 32bit VM */
> +#define KVM_ARM_VCPU_PSCI_0_2          2 /* CPU uses PSCI v0.2 */
>
>  struct kvm_vcpu_init {
>         __u32 target;
> @@ -129,6 +131,33 @@ struct kvm_arch_memory_slot {
>  #define KVM_REG_ARM64_SYSREG_OP2_MASK  0x0000000000000007
>  #define KVM_REG_ARM64_SYSREG_OP2_SHIFT 0
>
> +#define ARM64_SYS_REG_SHIFT_MASK(x,n) \
> +       (((x) << KVM_REG_ARM64_SYSREG_ ## n ## _SHIFT) & \
> +       KVM_REG_ARM64_SYSREG_ ## n ## _MASK)
> +
> +#define __ARM64_SYS_REG(op0,op1,crn,crm,op2) \
> +       (KVM_REG_ARM64 | KVM_REG_ARM64_SYSREG | \
> +       ARM64_SYS_REG_SHIFT_MASK(op0, OP0) | \
> +       ARM64_SYS_REG_SHIFT_MASK(op1, OP1) | \
> +       ARM64_SYS_REG_SHIFT_MASK(crn, CRN) | \
> +       ARM64_SYS_REG_SHIFT_MASK(crm, CRM) | \
> +       ARM64_SYS_REG_SHIFT_MASK(op2, OP2))
> +
> +#define ARM64_SYS_REG(...) (__ARM64_SYS_REG(__VA_ARGS__) | KVM_REG_SIZE_U64)
> +
> +#define KVM_REG_ARM_TIMER_CTL          ARM64_SYS_REG(3, 3, 14, 3, 1)
> +#define KVM_REG_ARM_TIMER_CNT          ARM64_SYS_REG(3, 3, 14, 3, 2)
> +#define KVM_REG_ARM_TIMER_CVAL         ARM64_SYS_REG(3, 3, 14, 0, 2)
> +
> +/* Device Control API: ARM VGIC */
> +#define KVM_DEV_ARM_VGIC_GRP_ADDR      0
> +#define KVM_DEV_ARM_VGIC_GRP_DIST_REGS 1
> +#define KVM_DEV_ARM_VGIC_GRP_CPU_REGS  2
> +#define   KVM_DEV_ARM_VGIC_CPUID_SHIFT 32
> +#define   KVM_DEV_ARM_VGIC_CPUID_MASK  (0xffULL << KVM_DEV_ARM_VGIC_CPUID_SHIFT)
> +#define   KVM_DEV_ARM_VGIC_OFFSET_SHIFT        0
> +#define   KVM_DEV_ARM_VGIC_OFFSET_MASK (0xffffffffULL << KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
> +
>  /* KVM_IRQ_LINE irq field index values */
>  #define KVM_ARM_IRQ_TYPE_SHIFT         24
>  #define KVM_ARM_IRQ_TYPE_MASK          0xff
> @@ -149,7 +178,7 @@ struct kvm_arch_memory_slot {
>  /* Highest supported SPI, from VGIC_NR_IRQS */
>  #define KVM_ARM_IRQ_GIC_MAX            127
>
> -/* PSCI interface */
> +/* PSCI v0.1 interface */
>  #define KVM_PSCI_FN_BASE               0x95c1ba5e
>  #define KVM_PSCI_FN(n)                 (KVM_PSCI_FN_BASE + (n))
>
> @@ -158,10 +187,42 @@ struct kvm_arch_memory_slot {
>  #define KVM_PSCI_FN_CPU_ON             KVM_PSCI_FN(2)
>  #define KVM_PSCI_FN_MIGRATE            KVM_PSCI_FN(3)
>
> +/* PSCI v0.2 interface */
> +#define KVM_PSCI_0_2_FN_BASE           0x84000000
> +#define KVM_PSCI_0_2_FN(n)             (KVM_PSCI_0_2_FN_BASE + (n))
> +#define KVM_PSCI_0_2_FN64_BASE         0xC4000000
> +#define KVM_PSCI_0_2_FN64(n)           (KVM_PSCI_0_2_FN64_BASE + (n))
> +
> +#define KVM_PSCI_0_2_FN_PSCI_VERSION   KVM_PSCI_0_2_FN(0)
> +#define KVM_PSCI_0_2_FN_CPU_SUSPEND    KVM_PSCI_0_2_FN(1)
> +#define KVM_PSCI_0_2_FN_CPU_OFF                KVM_PSCI_0_2_FN(2)
> +#define KVM_PSCI_0_2_FN_CPU_ON         KVM_PSCI_0_2_FN(3)
> +#define KVM_PSCI_0_2_FN_AFFINITY_INFO  KVM_PSCI_0_2_FN(4)
> +#define KVM_PSCI_0_2_FN_MIGRATE                KVM_PSCI_0_2_FN(5)
> +#define KVM_PSCI_0_2_FN_MIGRATE_INFO_TYPE \
> +                                       KVM_PSCI_0_2_FN(6)
> +#define KVM_PSCI_0_2_FN_MIGRATE_INFO_UP_CPU \
> +                                       KVM_PSCI_0_2_FN(7)
> +#define KVM_PSCI_0_2_FN_SYSTEM_OFF     KVM_PSCI_0_2_FN(8)
> +#define KVM_PSCI_0_2_FN_SYSTEM_RESET   KVM_PSCI_0_2_FN(9)
> +
> +#define KVM_PSCI_0_2_FN64_CPU_SUSPEND  KVM_PSCI_0_2_FN64(1)
> +#define KVM_PSCI_0_2_FN64_CPU_ON       KVM_PSCI_0_2_FN64(3)
> +#define KVM_PSCI_0_2_FN64_AFFINITY_INFO        KVM_PSCI_0_2_FN64(4)
> +#define KVM_PSCI_0_2_FN64_MIGRATE      KVM_PSCI_0_2_FN64(5)
> +#define KVM_PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU \
> +                                       KVM_PSCI_0_2_FN64(7)
> +
> +/* PSCI return values */
>  #define KVM_PSCI_RET_SUCCESS           0
>  #define KVM_PSCI_RET_NI                        ((unsigned long)-1)
>  #define KVM_PSCI_RET_INVAL             ((unsigned long)-2)
>  #define KVM_PSCI_RET_DENIED            ((unsigned long)-3)
> +#define KVM_PSCI_RET_ALREADY_ON                ((unsigned long)-4)
> +#define KVM_PSCI_RET_ON_PENDING                ((unsigned long)-5)
> +#define KVM_PSCI_RET_INTERNAL_FAILURE  ((unsigned long)-6)
> +#define KVM_PSCI_RET_NOT_PRESENT       ((unsigned long)-7)
> +#define KVM_PSCI_RET_DISABLED          ((unsigned long)-8)
>
>  #endif
>
> diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
> index 999fb13..d8dd28b 100644
> --- a/linux-headers/linux/kvm.h
> +++ b/linux-headers/linux/kvm.h
> @@ -171,6 +171,7 @@ struct kvm_pit_config {
>  #define KVM_EXIT_WATCHDOG         21
>  #define KVM_EXIT_S390_TSCH        22
>  #define KVM_EXIT_EPR              23
> +#define KVM_EXIT_SYSTEM_EVENT     24
>
>  /* For KVM_EXIT_INTERNAL_ERROR */
>  /* Emulate instruction failed. */
> @@ -301,6 +302,13 @@ struct kvm_run {
>                 struct {
>                         __u32 epr;
>                 } epr;
> +               /* KVM_EXIT_SYSTEM_EVENT */
> +               struct {
> +#define KVM_SYSTEM_EVENT_SHUTDOWN       1
> +#define KVM_SYSTEM_EVENT_RESET          2
> +                       __u32 type;
> +                       __u64 flags;
> +               } system_event;
>                 /* Fix the size of the union. */
>                 char padding[256];
>         };
> @@ -675,6 +683,7 @@ struct kvm_ppc_smmu_info {
>  #define KVM_CAP_SPAPR_MULTITCE 94
>  #define KVM_CAP_EXT_EMUL_CPUID 95
>  #define KVM_CAP_HYPERV_TIME 96
> +#define KVM_CAP_ARM_PSCI_0_2 97
>
>  #ifdef KVM_CAP_IRQ_ROUTING
>
> @@ -854,6 +863,7 @@ struct kvm_device_attr {
>  #define  KVM_DEV_VFIO_GROUP                    1
>  #define   KVM_DEV_VFIO_GROUP_ADD                       1
>  #define   KVM_DEV_VFIO_GROUP_DEL                       2
> +#define KVM_DEV_TYPE_ARM_VGIC_V2       5
>
>  /*
>   * ioctls for VM fds
> --
> 1.7.9.5
>

Sorry for mentioning wrong qemu devel mail id in my previous mail.
Correcting correct qemu-devel id and re-sending.

Thanks,
Pranav

Re: [Qemu-devel] [RFC PATCH 2/7] target-arm: Try X-Gene Potenza target type for KVM Aarch64

[Pranavkumar Sawargaonkar]

On 27 February 2014 12:21, Pranavkumar Sawargaonkar
<pranavkumar@linaro.org> wrote:
> QEMU Aarch64 tries various target types in kvm_arm_get_host_cpu_features()
> to determine perferred VCPU target type and VCPU features.
>
> This patch adds target type KVM_ARM_TARGET_XGENE_POTENZA to cpus_to_try[]
> of kvm_arm_get_host_cpu_features().
>
> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
> Signed-off-by: Anup Patel <anup.patel@linaro.org>
> ---
>  target-arm/kvm64.c |    1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/target-arm/kvm64.c b/target-arm/kvm64.c
> index 1b7ca90..406529f 100644
> --- a/target-arm/kvm64.c
> +++ b/target-arm/kvm64.c
> @@ -48,6 +48,7 @@ bool kvm_arm_get_host_cpu_features(ARMHostCPUClass *ahcc)
>          KVM_ARM_TARGET_AEM_V8,
>          KVM_ARM_TARGET_FOUNDATION_V8,
>          KVM_ARM_TARGET_CORTEX_A57,
> +        KVM_ARM_TARGET_XGENE_POTENZA,
>          QEMU_KVM_ARM_TARGET_NONE
>      };
>      struct kvm_vcpu_init init;
> --
> 1.7.9.5
>

Sorry for mentioning wrong qemu devel mail id in my previous mail.
Correcting correct qemu-devel  id.

Thanks,
Pranav

Re: [Qemu-devel] [RFC PATCH 3/7] target-arm: Handle exit reason KVM_EXIT_SYSTEM_EVENT

[Pranavkumar Sawargaonkar]

On 27 February 2014 12:21, Pranavkumar Sawargaonkar
<pranavkumar@linaro.org> wrote:
> In-kernel PSCI v0.2 emulation of KVM ARM/ARM64 forwards SYSTEM_OFF
> and SYSTEM_RESET function calls to QEMU using KVM_EXIT_SYSTEM_EVENT
> exit reason.
>
> This patch updates kvm_arch_handle_exit() to handle KVM_EXIT_SYSTEM_EVENT
> from QEMU-side for KVM ARM/ARM64.
>
> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
> Signed-off-by: Anup Patel <anup.patel@linaro.org>
> ---
>  target-arm/kvm.c |   30 +++++++++++++++++++++++++++++-
>  1 file changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/target-arm/kvm.c b/target-arm/kvm.c
> index 1d2688d..7c0aec6 100644
> --- a/target-arm/kvm.c
> +++ b/target-arm/kvm.c
> @@ -325,7 +325,35 @@ void kvm_arch_post_run(CPUState *cs, struct kvm_run *run)
>
>  int kvm_arch_handle_exit(CPUState *cs, struct kvm_run *run)
>  {
> -    return 0;
> +    int ret = 0;
> +
> +    switch (run->exit_reason) {
> +    case KVM_EXIT_SYSTEM_EVENT:
> +        switch (run->system_event.type) {
> +        case KVM_SYSTEM_EVENT_SHUTDOWN:
> +            qemu_system_shutdown_request();
> +            ret = EXCP_INTERRUPT;
> +            break;
> +        case KVM_SYSTEM_EVENT_RESET:
> +            qemu_system_reset_request();
> +            ret = EXCP_INTERRUPT;
> +            break;
> +        default:
> +            fprintf(stderr, "KVM: unknown system event %d\n",
> +                    run->system_event.type);
> +            ret = -1;
> +            break;
> +        }
> +        break;
> +
> +    default:
> +        fprintf(stderr, "KVM: unknown exit reason %d\n",
> +                run->exit_reason);
> +        ret = -1;
> +        break;
> +    }
> +
> +    return ret;
>  }
>
>  bool kvm_arch_stop_on_emulation_error(CPUState *cs)
> --
> 1.7.9.5
>

Sorry for mentioning wrong qemu devel mail id in my previous mail.
Correcting correct qemu-devel  id.

Thanks,
Pranav

Re: [Qemu-devel] [RFC PATCH 3/7] target-arm: Handle exit reason KVM_EXIT_SYSTEM_EVENT

[Peter Maydell]

[mail resent for the benefit of qemu-devel; apologies to those
who see it twice.]

On 14 March 2014 03:43, Christoffer Dall <christoffer.dall@linaro.org> wrote:
> On Thu, Feb 27, 2014 at 12:21:04PM +0530, Pranavkumar Sawargaonkar wrote:
>> In-kernel PSCI v0.2 emulation of KVM ARM/ARM64 forwards SYSTEM_OFF
>> and SYSTEM_RESET function calls to QEMU using KVM_EXIT_SYSTEM_EVENT
>> exit reason.
>>
>> This patch updates kvm_arch_handle_exit() to handle KVM_EXIT_SYSTEM_EVENT
>> from QEMU-side for KVM ARM/ARM64.
>>
>> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
>> Signed-off-by: Anup Patel <anup.patel@linaro.org>
>> ---
>>  target-arm/kvm.c |   30 +++++++++++++++++++++++++++++-
>>  1 file changed, 29 insertions(+), 1 deletion(-)
>>
>> diff --git a/target-arm/kvm.c b/target-arm/kvm.c
>> index 1d2688d..7c0aec6 100644
>> --- a/target-arm/kvm.c
>> +++ b/target-arm/kvm.c
>> @@ -325,7 +325,35 @@ void kvm_arch_post_run(CPUState *cs, struct kvm_run *run)
>>
>>  int kvm_arch_handle_exit(CPUState *cs, struct kvm_run *run)
>>  {
>> -    return 0;
>> +    int ret = 0;
>> +
>> +    switch (run->exit_reason) {
>> +    case KVM_EXIT_SYSTEM_EVENT:
>> +        switch (run->system_event.type) {
>> +        case KVM_SYSTEM_EVENT_SHUTDOWN:
>> +            qemu_system_shutdown_request();
>> +            ret = EXCP_INTERRUPT;
>> +            break;
>> +        case KVM_SYSTEM_EVENT_RESET:
>> +            qemu_system_reset_request();
>> +            ret = EXCP_INTERRUPT;
>> +            break;
>> +        default:
>> +            fprintf(stderr, "KVM: unknown system event %d\n",
>> +                    run->system_event.type);
>> +            ret = -1;
>> +            break;
>> +        }
>> +        break;
>> +
>> +    default:
>> +        fprintf(stderr, "KVM: unknown exit reason %d\n",
>> +                run->exit_reason);
>> +        ret = -1;
>> +        break;
>> +    }
>> +
>> +    return ret;
>>  }
>>
>>  bool kvm_arch_stop_on_emulation_error(CPUState *cs)
>> --
>> 1.7.9.5
>>
>
> The KVM_EXIT_SYSTEM_EVENT is not specific to ARM is it?  Should this not
> be handled in generic code and then call out to arch-specific code for
> handlers?

Well, we should just handle this in kvm-all.c:kvm_cpu_exec(),
if the exit code is not architecture specific. The code
above for handling reset and shutdown should work fine
for every arch that implements it.

thanks
-- PMM

Re: [Qemu-devel] [RFC PATCH 4/7] target-arm: Provide PSCI v0.2 constants to generic QEMU code

[Pranavkumar Sawargaonkar]

On 27 February 2014 12:21, Pranavkumar Sawargaonkar
<pranavkumar@linaro.org> wrote:
> Provide versions of the KVM PSCI v0.2 constants to non-KVM code;
> this will allow us to avoid an ifdef in boards which set up a
> PSCI v0.2 node in the device tree.
>
> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
> Signed-off-by: Anup Patel <anup.patel@linaro.org>
> ---
>  target-arm/kvm-consts.h |   41 +++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 41 insertions(+)
>
> diff --git a/target-arm/kvm-consts.h b/target-arm/kvm-consts.h
> index 0e7f889..0f3f0ff 100644
> --- a/target-arm/kvm-consts.h
> +++ b/target-arm/kvm-consts.h
> @@ -38,6 +38,7 @@ MISMATCH_CHECK(CP_REG_SIZE_U64, KVM_REG_SIZE_U64)
>  MISMATCH_CHECK(CP_REG_ARM, KVM_REG_ARM)
>  MISMATCH_CHECK(CP_REG_ARCH_MASK, KVM_REG_ARCH_MASK)
>
> +/* PSCI v0.1 interface */
>  #define PSCI_FN_BASE 0x95c1ba5e
>  #define PSCI_FN(n) (PSCI_FN_BASE + (n))
>  #define PSCI_FN_CPU_SUSPEND PSCI_FN(0)
> @@ -50,6 +51,46 @@ MISMATCH_CHECK(PSCI_FN_CPU_OFF, KVM_PSCI_FN_CPU_OFF)
>  MISMATCH_CHECK(PSCI_FN_CPU_ON, KVM_PSCI_FN_CPU_ON)
>  MISMATCH_CHECK(PSCI_FN_MIGRATE, KVM_PSCI_FN_MIGRATE)
>
> +/* PSCI v0.2 interface */
> +#define PSCI_0_2_FN_BASE 0x84000000
> +#define PSCI_0_2_FN(n) (PSCI_0_2_FN_BASE + (n))
> +#define PSCI_0_2_FN64_BASE 0xC4000000
> +#define PSCI_0_2_FN64(n) (PSCI_0_2_FN64_BASE + (n))
> +#define PSCI_0_2_FN_PSCI_VERSION PSCI_0_2_FN(0)
> +#define PSCI_0_2_FN_CPU_SUSPEND PSCI_0_2_FN(1)
> +#define PSCI_0_2_FN_CPU_OFF PSCI_0_2_FN(2)
> +#define PSCI_0_2_FN_CPU_ON PSCI_0_2_FN(3)
> +#define PSCI_0_2_FN_AFFINITY_INFO PSCI_0_2_FN(4)
> +#define PSCI_0_2_FN_MIGRATE PSCI_0_2_FN(5)
> +#define PSCI_0_2_FN_MIGRATE_INFO_TYPE PSCI_0_2_FN(6)
> +#define PSCI_0_2_FN_MIGRATE_INFO_UP_CPU PSCI_0_2_FN(7)
> +#define PSCI_0_2_FN_SYSTEM_OFF PSCI_0_2_FN(8)
> +#define PSCI_0_2_FN_SYSTEM_RESET PSCI_0_2_FN(9)
> +#define PSCI_0_2_FN64_CPU_SUSPEND PSCI_0_2_FN64(1)
> +#define PSCI_0_2_FN64_CPU_ON PSCI_0_2_FN64(3)
> +#define PSCI_0_2_FN64_AFFINITY_INFO PSCI_0_2_FN64(4)
> +#define PSCI_0_2_FN64_MIGRATE PSCI_0_2_FN64(5)
> +#define PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU PSCI_0_2_FN64(7)
> +
> +MISMATCH_CHECK(PSCI_0_2_FN_PSCI_VERSION, KVM_PSCI_0_2_FN_PSCI_VERSION)
> +MISMATCH_CHECK(PSCI_0_2_FN_CPU_SUSPEND, KVM_PSCI_0_2_FN_CPU_SUSPEND)
> +MISMATCH_CHECK(PSCI_0_2_FN_CPU_OFF, KVM_PSCI_0_2_FN_CPU_OFF)
> +MISMATCH_CHECK(PSCI_0_2_FN_CPU_ON, KVM_PSCI_0_2_FN_CPU_ON)
> +MISMATCH_CHECK(PSCI_0_2_FN_AFFINITY_INFO, KVM_PSCI_0_2_FN_AFFINITY_INFO)
> +MISMATCH_CHECK(PSCI_0_2_FN_MIGRATE, KVM_PSCI_0_2_FN_MIGRATE)
> +MISMATCH_CHECK(PSCI_0_2_FN_MIGRATE_INFO_TYPE, \
> +               KVM_PSCI_0_2_FN_MIGRATE_INFO_TYPE)
> +MISMATCH_CHECK(PSCI_0_2_FN_MIGRATE_INFO_UP_CPU, \
> +               KVM_PSCI_0_2_FN_MIGRATE_INFO_UP_CPU)
> +MISMATCH_CHECK(PSCI_0_2_FN_SYSTEM_OFF, KVM_PSCI_0_2_FN_SYSTEM_OFF)
> +MISMATCH_CHECK(PSCI_0_2_FN_SYSTEM_RESET, KVM_PSCI_0_2_FN_SYSTEM_RESET)
> +MISMATCH_CHECK(PSCI_0_2_FN64_CPU_SUSPEND, KVM_PSCI_0_2_FN64_CPU_SUSPEND)
> +MISMATCH_CHECK(PSCI_0_2_FN64_CPU_ON, KVM_PSCI_0_2_FN64_CPU_ON)
> +MISMATCH_CHECK(PSCI_0_2_FN64_AFFINITY_INFO, KVM_PSCI_0_2_FN64_AFFINITY_INFO)
> +MISMATCH_CHECK(PSCI_0_2_FN64_MIGRATE, KVM_PSCI_0_2_FN64_MIGRATE)
> +MISMATCH_CHECK(PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU, \
> +               KVM_PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU)
> +
>  #define QEMU_KVM_ARM_TARGET_CORTEX_A15 0
>
>  /* There's no kernel define for this: sentinel value which
> --
> 1.7.9.5
>

Sorry for mentioning wrong qemu devel mail id in my previous mail.
Correcting correct qemu-devel  id.

Thanks,
Pranav

Re: [Qemu-devel] [RFC PATCH 5/7] target-arm: Enable KVM_ARM_VCPU_PSCI_0_2 feature when possible

[Pranavkumar Sawargaonkar]

On 27 February 2014 12:21, Pranavkumar Sawargaonkar
<pranavkumar@linaro.org> wrote:
> Latest linux kernel supports in-kernel emulation of PSCI v0.2 but
> to enable it we need to select KVM_ARM_VCPU_PSCI_0_2 feature using
> KVM_ARM_VCPU_INIT ioctl.
>
> Also, we can use KVM_ARM_VCPU_PSCI_0_2 feature for VCPU only when
> linux kernel has KVM_CAP_ARM_PSCI_0_2 capability.
>
> This patch updates kvm_arch_init_vcpu() to enable KVM_ARM_VCPU_PSCI_0_2
> feature for VCPU when KVM ARM/ARM64 has KVM_CAP_ARM_PSCI_0_2 capability.
>
> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
> Signed-off-by: Anup Patel <anup.patel@linaro.org>
> ---
>  target-arm/kvm32.c |    5 ++++-
>  target-arm/kvm64.c |    5 ++++-
>  2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/target-arm/kvm32.c b/target-arm/kvm32.c
> index a4fde07..afeff01 100644
> --- a/target-arm/kvm32.c
> +++ b/target-arm/kvm32.c
> @@ -181,7 +181,10 @@ int kvm_arch_init_vcpu(CPUState *cs)
>      init.target = cpu->kvm_target;
>      memset(init.features, 0, sizeof(init.features));
>      if (cpu->start_powered_off) {
> -        init.features[0] = 1 << KVM_ARM_VCPU_POWER_OFF;
> +        init.features[0] |= 1 << KVM_ARM_VCPU_POWER_OFF;
> +    }
> +    if (kvm_check_extension(cs->kvm_state, KVM_CAP_ARM_PSCI_0_2)) {
> +        init.features[0] |= 1 << KVM_ARM_VCPU_PSCI_0_2;
>      }
>      ret = kvm_vcpu_ioctl(cs, KVM_ARM_VCPU_INIT, &init);
>      if (ret) {
> diff --git a/target-arm/kvm64.c b/target-arm/kvm64.c
> index 406529f..d303046 100644
> --- a/target-arm/kvm64.c
> +++ b/target-arm/kvm64.c
> @@ -91,7 +91,10 @@ int kvm_arch_init_vcpu(CPUState *cs)
>      init.target = cpu->kvm_target;
>      memset(init.features, 0, sizeof(init.features));
>      if (cpu->start_powered_off) {
> -        init.features[0] = 1 << KVM_ARM_VCPU_POWER_OFF;
> +        init.features[0] |= 1 << KVM_ARM_VCPU_POWER_OFF;
> +    }
> +    if (kvm_check_extension(cs->kvm_state, KVM_CAP_ARM_PSCI_0_2)) {
> +        init.features[0] |= 1 << KVM_ARM_VCPU_PSCI_0_2;
>      }
>      ret = kvm_vcpu_ioctl(cs, KVM_ARM_VCPU_INIT, &init);
>
> --
> 1.7.9.5
>

Sorry for mentioning wrong qemu devel mail id in my previous mail.
Correcting correct qemu-devel  id.

Thanks,
Pranav

Re: [Qemu-devel] [RFC PATCH 5/7] target-arm: Enable KVM_ARM_VCPU_PSCI_0_2 feature when possible

[Peter Maydell]

[another resend for qemu-devel...]

On 27 February 2014 07:16, Pranavkumar Sawargaonkar
<pranavkumar@linaro.org> wrote:
> On 27 February 2014 12:21, Pranavkumar Sawargaonkar
> <pranavkumar@linaro.org> wrote:
>> Latest linux kernel supports in-kernel emulation of PSCI v0.2 but
>> to enable it we need to select KVM_ARM_VCPU_PSCI_0_2 feature using
>> KVM_ARM_VCPU_INIT ioctl.
>>
>> Also, we can use KVM_ARM_VCPU_PSCI_0_2 feature for VCPU only when
>> linux kernel has KVM_CAP_ARM_PSCI_0_2 capability.
>>
>> This patch updates kvm_arch_init_vcpu() to enable KVM_ARM_VCPU_PSCI_0_2
>> feature for VCPU when KVM ARM/ARM64 has KVM_CAP_ARM_PSCI_0_2 capability.

I think this has implications for migration. What happens
if you migrate a VM from a host system where the host
kernel supports this capability to one where it doesn't?
(Presumably the answer is "it won't work" and we need
to ensure we don't allow that.)
Conversely, is it OK to migrate a guest from a host
which didn't support PSCI 0.2 to one which does? Does
that work even if the destination has PSCI 0.2 enabled
for the vCPUs, or do we need to support starting a
VM with 0.2 disabled even on 0.2-capable hosts, for
use as a migration target?

Also we still don't seem to have done anything about
migration of the PSCI CPU powerup/down state.

thanks
-- PMM

Re: [Qemu-devel] [RFC PATCH 5/7] target-arm: Enable KVM_ARM_VCPU_PSCI_0_2 feature when possible

[Christoffer Dall]

On Mon, Mar 17, 2014 at 07:35:43PM +0000, Peter Maydell wrote:
> [another resend for qemu-devel...]
> 
> On 27 February 2014 07:16, Pranavkumar Sawargaonkar
> <pranavkumar@linaro.org> wrote:
> > On 27 February 2014 12:21, Pranavkumar Sawargaonkar
> > <pranavkumar@linaro.org> wrote:
> >> Latest linux kernel supports in-kernel emulation of PSCI v0.2 but
> >> to enable it we need to select KVM_ARM_VCPU_PSCI_0_2 feature using
> >> KVM_ARM_VCPU_INIT ioctl.
> >>
> >> Also, we can use KVM_ARM_VCPU_PSCI_0_2 feature for VCPU only when
> >> linux kernel has KVM_CAP_ARM_PSCI_0_2 capability.
> >>
> >> This patch updates kvm_arch_init_vcpu() to enable KVM_ARM_VCPU_PSCI_0_2
> >> feature for VCPU when KVM ARM/ARM64 has KVM_CAP_ARM_PSCI_0_2 capability.
> 
> I think this has implications for migration. What happens
> if you migrate a VM from a host system where the host
> kernel supports this capability to one where it doesn't?
> (Presumably the answer is "it won't work" and we need
> to ensure we don't allow that.)
> Conversely, is it OK to migrate a guest from a host
> which didn't support PSCI 0.2 to one which does? Does
> that work even if the destination has PSCI 0.2 enabled
> for the vCPUs, or do we need to support starting a
> VM with 0.2 disabled even on 0.2-capable hosts, for
> use as a migration target?

The init feature should be a switch, turn 0.2 on or off, if off, we're
emulating 0.1.  If 0.2 is on, 0.1 call numbers should generate errors.

You're right, we need to fix this for migration.

> 
> Also we still don't seem to have done anything about
> migration of the PSCI CPU powerup/down state.
> 

We need to create a card for this in Linaro.  Thought I would deal with
it when working through migration for ARMv8.

Thanks!
-Christoffer

Re: [Qemu-devel] [RFC PATCH 6/7] hw/arm/virt: Use PSCI v0.2 function IDs when kernel supports its

[Pranavkumar Sawargaonkar]

On 27 February 2014 12:21, Pranavkumar Sawargaonkar
<pranavkumar@linaro.org> wrote:
> If we have in-kernel emulation of PSCI v0.2 for KVM ARM/ARM64 then
> we enable PSCI v0.2 for each VCPU at the time of VCPU init hence we
> need to provide PSCI v0.2 function IDs via generated DTB.
>
> This patch updates generated DTB to have PSCI v0.2 function IDs when
> we have in-kernel emulation PSCI v0.2 for KVM ARM/ARM64.
>
> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
> Signed-off-by: Anup Patel <anup.patel@linaro.org>
> ---
>  hw/arm/virt.c |   25 ++++++++++++++++++++-----
>  1 file changed, 20 insertions(+), 5 deletions(-)
>
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index 517f2fe..a818a80 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -187,11 +187,26 @@ static void create_fdt(VirtBoardInfo *vbi)
>          qemu_fdt_add_subnode(fdt, "/psci");
>          qemu_fdt_setprop_string(fdt, "/psci", "compatible", "arm,psci");
>          qemu_fdt_setprop_string(fdt, "/psci", "method", "hvc");
> -        qemu_fdt_setprop_cell(fdt, "/psci", "cpu_suspend",
> -                                  PSCI_FN_CPU_SUSPEND);
> -        qemu_fdt_setprop_cell(fdt, "/psci", "cpu_off", PSCI_FN_CPU_OFF);
> -        qemu_fdt_setprop_cell(fdt, "/psci", "cpu_on", PSCI_FN_CPU_ON);
> -        qemu_fdt_setprop_cell(fdt, "/psci", "migrate", PSCI_FN_MIGRATE);
> +        if (kvm_check_extension(kvm_state, KVM_CAP_ARM_PSCI_0_2)) {
> +            qemu_fdt_setprop_cell(fdt, "/psci", "cpu_suspend",
> +                                      PSCI_0_2_FN_CPU_SUSPEND);
> +            qemu_fdt_setprop_cell(fdt, "/psci", "cpu_off",
> +                                      PSCI_0_2_FN_CPU_OFF);
> +            qemu_fdt_setprop_cell(fdt, "/psci", "cpu_on",
> +                                      PSCI_0_2_FN_CPU_ON);
> +            qemu_fdt_setprop_cell(fdt, "/psci", "migrate",
> +                                      PSCI_0_2_FN_MIGRATE);
> +            qemu_fdt_setprop_cell(fdt, "/psci", "system_off",
> +                                      PSCI_0_2_FN_SYSTEM_OFF);
> +            qemu_fdt_setprop_cell(fdt, "/psci", "system_reset",
> +                                      PSCI_0_2_FN_SYSTEM_RESET);
> +        } else {
> +            qemu_fdt_setprop_cell(fdt, "/psci", "cpu_suspend",
> +                                      PSCI_FN_CPU_SUSPEND);
> +            qemu_fdt_setprop_cell(fdt, "/psci", "cpu_off", PSCI_FN_CPU_OFF);
> +            qemu_fdt_setprop_cell(fdt, "/psci", "cpu_on", PSCI_FN_CPU_ON);
> +            qemu_fdt_setprop_cell(fdt, "/psci", "migrate", PSCI_FN_MIGRATE);
> +        }
>      }
>  }
>
> --
> 1.7.9.5
>

Sorry for mentioning wrong qemu devel mail id in my previous mail.
Correcting correct qemu-devel  id.

Thanks,
Pranav

Re: [Qemu-devel] [RFC PATCH 6/7] hw/arm/virt: Use PSCI v0.2 function IDs when kernel supports its

[Pranavkumar Sawargaonkar]

Hi Christoffer,

On 14 March 2014 09:19, Christoffer Dall <christoffer.dall@linaro.org> wrote:
> On Thu, Feb 27, 2014 at 12:21:07PM +0530, Pranavkumar Sawargaonkar wrote:
>> If we have in-kernel emulation of PSCI v0.2 for KVM ARM/ARM64 then
>> we enable PSCI v0.2 for each VCPU at the time of VCPU init hence we
>> need to provide PSCI v0.2 function IDs via generated DTB.
>>
>> This patch updates generated DTB to have PSCI v0.2 function IDs when
>> we have in-kernel emulation PSCI v0.2 for KVM ARM/ARM64.
>>
>> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
>> Signed-off-by: Anup Patel <anup.patel@linaro.org>
>> ---
>>  hw/arm/virt.c |   25 ++++++++++++++++++++-----
>>  1 file changed, 20 insertions(+), 5 deletions(-)
>>
>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>> index 517f2fe..a818a80 100644
>> --- a/hw/arm/virt.c
>> +++ b/hw/arm/virt.c
>> @@ -187,11 +187,26 @@ static void create_fdt(VirtBoardInfo *vbi)
>>          qemu_fdt_add_subnode(fdt, "/psci");
>>          qemu_fdt_setprop_string(fdt, "/psci", "compatible", "arm,psci");
>
> was there a decision on the format of the psci 0.2 bindings?
>
> I seem to recall that we should add arm,psci-0.2 or something like that.

Yes there was a discussion related to that by Mark Rutland and Rob Herring :
http://www.spinics.net/lists/arm-kernel/msg298509.html

But there is no dt binding added related to psci 0.2 in kernel (I am
not sure about final conclusion of the dt binding to be added). If the
dt binding gets finalized I will definitely revise this patch.
For now I have added old binding only to test the rfc patch (may now
be the right way to do but do not have any option also).

>
> -Christoffer

Thanks,
Pranav

Re: [Qemu-devel] [RFC PATCH 6/7] hw/arm/virt: Use PSCI v0.2 function IDs when kernel supports its

[Mark Rutland]

On Fri, Mar 14, 2014 at 06:53:53AM +0000, Pranavkumar Sawargaonkar wrote:
> Hi Christoffer,
> 
> On 14 March 2014 09:19, Christoffer Dall <christoffer.dall@linaro.org> wrote:
> > On Thu, Feb 27, 2014 at 12:21:07PM +0530, Pranavkumar Sawargaonkar wrote:
> >> If we have in-kernel emulation of PSCI v0.2 for KVM ARM/ARM64 then
> >> we enable PSCI v0.2 for each VCPU at the time of VCPU init hence we
> >> need to provide PSCI v0.2 function IDs via generated DTB.
> >>
> >> This patch updates generated DTB to have PSCI v0.2 function IDs when
> >> we have in-kernel emulation PSCI v0.2 for KVM ARM/ARM64.
> >>
> >> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
> >> Signed-off-by: Anup Patel <anup.patel@linaro.org>
> >> ---
> >>  hw/arm/virt.c |   25 ++++++++++++++++++++-----
> >>  1 file changed, 20 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> >> index 517f2fe..a818a80 100644
> >> --- a/hw/arm/virt.c
> >> +++ b/hw/arm/virt.c
> >> @@ -187,11 +187,26 @@ static void create_fdt(VirtBoardInfo *vbi)
> >>          qemu_fdt_add_subnode(fdt, "/psci");
> >>          qemu_fdt_setprop_string(fdt, "/psci", "compatible", "arm,psci");
> >
> > was there a decision on the format of the psci 0.2 bindings?
> >
> > I seem to recall that we should add arm,psci-0.2 or something like that.
> 
> Yes there was a discussion related to that by Mark Rutland and Rob Herring :
> http://www.spinics.net/lists/arm-kernel/msg298509.html
> 
> But there is no dt binding added related to psci 0.2 in kernel (I am
> not sure about final conclusion of the dt binding to be added). If the
> dt binding gets finalized I will definitely revise this patch.
> For now I have added old binding only to test the rfc patch (may now
> be the right way to do but do not have any option also).

I believe Rob and I were happy with PSCI 0.2 IDs being implicit, though
for compatibility with existing kernels the IDs in the "arm,psci"
binding might also be listed.

The only issue was Calxeda highbank/midway systems using pre-release
PSCI 0.2 IDs for functions not in the "arm,psci" binding. For those we
could allocate a compatilbe string like "calxeda,highbank-psci-0.2" and
allow them to be implicit, or just leave them in their current
(unsupported) state.

Rob, thoughts?

Thanks,
Mark.

Re: [Qemu-devel] [RFC PATCH 6/7] hw/arm/virt: Use PSCI v0.2 function IDs when kernel supports its

[Rob Herring]

On Fri, Mar 14, 2014 at 5:23 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Fri, Mar 14, 2014 at 06:53:53AM +0000, Pranavkumar Sawargaonkar wrote:
>> Hi Christoffer,
>>
>> On 14 March 2014 09:19, Christoffer Dall <christoffer.dall@linaro.org> wrote:
>> > On Thu, Feb 27, 2014 at 12:21:07PM +0530, Pranavkumar Sawargaonkar wrote:
>> >> If we have in-kernel emulation of PSCI v0.2 for KVM ARM/ARM64 then
>> >> we enable PSCI v0.2 for each VCPU at the time of VCPU init hence we
>> >> need to provide PSCI v0.2 function IDs via generated DTB.
>> >>
>> >> This patch updates generated DTB to have PSCI v0.2 function IDs when
>> >> we have in-kernel emulation PSCI v0.2 for KVM ARM/ARM64.
>> >>
>> >> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
>> >> Signed-off-by: Anup Patel <anup.patel@linaro.org>
>> >> ---
>> >>  hw/arm/virt.c |   25 ++++++++++++++++++++-----
>> >>  1 file changed, 20 insertions(+), 5 deletions(-)
>> >>
>> >> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>> >> index 517f2fe..a818a80 100644
>> >> --- a/hw/arm/virt.c
>> >> +++ b/hw/arm/virt.c
>> >> @@ -187,11 +187,26 @@ static void create_fdt(VirtBoardInfo *vbi)
>> >>          qemu_fdt_add_subnode(fdt, "/psci");
>> >>          qemu_fdt_setprop_string(fdt, "/psci", "compatible", "arm,psci");
>> >
>> > was there a decision on the format of the psci 0.2 bindings?
>> >
>> > I seem to recall that we should add arm,psci-0.2 or something like that.
>>
>> Yes there was a discussion related to that by Mark Rutland and Rob Herring :
>> http://www.spinics.net/lists/arm-kernel/msg298509.html
>>
>> But there is no dt binding added related to psci 0.2 in kernel (I am
>> not sure about final conclusion of the dt binding to be added). If the
>> dt binding gets finalized I will definitely revise this patch.
>> For now I have added old binding only to test the rfc patch (may now
>> be the right way to do but do not have any option also).
>
> I believe Rob and I were happy with PSCI 0.2 IDs being implicit, though
> for compatibility with existing kernels the IDs in the "arm,psci"
> binding might also be listed.
>
> The only issue was Calxeda highbank/midway systems using pre-release
> PSCI 0.2 IDs for functions not in the "arm,psci" binding. For those we
> could allocate a compatilbe string like "calxeda,highbank-psci-0.2" and
> allow them to be implicit, or just leave them in their current
> (unsupported) state.
>
> Rob, thoughts?

We need to add "arm,psci-0.2" compatible since "arm,psci" defines all
the function IDs as required and with 0.2 they are optional.

For highbank, since firmware and DTB is essentially frozen now, a
compatible change is not going to happen. It probably means just
leaving things as is.

For reference, this is what highbank/midway's binding looks like:

        psci {
                compatible      = "arm,psci";
                method          = "smc";
                cpu_suspend     = <0x84000002>;
                cpu_off         = <0x84000004>;
                cpu_on          = <0x84000006>;
                system_off      = <0x84000100>;
                system_reset    = <0x84000101>;
        };

I suppose I could just ignore the binding and make highbank reset/off
functions do custom some PSCI calls. This would mean exposing
invoke_psci_fn or creating some custom call wrapper.

Rob

Re: [Qemu-devel] [RFC PATCH 6/7] hw/arm/virt: Use PSCI v0.2 function IDs when kernel supports its

[Mark Rutland]

On Fri, Mar 14, 2014 at 05:10:34PM +0000, Rob Herring wrote:
> On Fri, Mar 14, 2014 at 5:23 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Fri, Mar 14, 2014 at 06:53:53AM +0000, Pranavkumar Sawargaonkar wrote:
> >> Hi Christoffer,
> >>
> >> On 14 March 2014 09:19, Christoffer Dall <christoffer.dall@linaro.org> wrote:
> >> > On Thu, Feb 27, 2014 at 12:21:07PM +0530, Pranavkumar Sawargaonkar wrote:
> >> >> If we have in-kernel emulation of PSCI v0.2 for KVM ARM/ARM64 then
> >> >> we enable PSCI v0.2 for each VCPU at the time of VCPU init hence we
> >> >> need to provide PSCI v0.2 function IDs via generated DTB.
> >> >>
> >> >> This patch updates generated DTB to have PSCI v0.2 function IDs when
> >> >> we have in-kernel emulation PSCI v0.2 for KVM ARM/ARM64.
> >> >>
> >> >> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
> >> >> Signed-off-by: Anup Patel <anup.patel@linaro.org>
> >> >> ---
> >> >>  hw/arm/virt.c |   25 ++++++++++++++++++++-----
> >> >>  1 file changed, 20 insertions(+), 5 deletions(-)
> >> >>
> >> >> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> >> >> index 517f2fe..a818a80 100644
> >> >> --- a/hw/arm/virt.c
> >> >> +++ b/hw/arm/virt.c
> >> >> @@ -187,11 +187,26 @@ static void create_fdt(VirtBoardInfo *vbi)
> >> >>          qemu_fdt_add_subnode(fdt, "/psci");
> >> >>          qemu_fdt_setprop_string(fdt, "/psci", "compatible", "arm,psci");
> >> >
> >> > was there a decision on the format of the psci 0.2 bindings?
> >> >
> >> > I seem to recall that we should add arm,psci-0.2 or something like that.
> >>
> >> Yes there was a discussion related to that by Mark Rutland and Rob Herring :
> >> http://www.spinics.net/lists/arm-kernel/msg298509.html
> >>
> >> But there is no dt binding added related to psci 0.2 in kernel (I am
> >> not sure about final conclusion of the dt binding to be added). If the
> >> dt binding gets finalized I will definitely revise this patch.
> >> For now I have added old binding only to test the rfc patch (may now
> >> be the right way to do but do not have any option also).
> >
> > I believe Rob and I were happy with PSCI 0.2 IDs being implicit, though
> > for compatibility with existing kernels the IDs in the "arm,psci"
> > binding might also be listed.
> >
> > The only issue was Calxeda highbank/midway systems using pre-release
> > PSCI 0.2 IDs for functions not in the "arm,psci" binding. For those we
> > could allocate a compatilbe string like "calxeda,highbank-psci-0.2" and
> > allow them to be implicit, or just leave them in their current
> > (unsupported) state.
> >
> > Rob, thoughts?
> 
> We need to add "arm,psci-0.2" compatible since "arm,psci" defines all
> the function IDs as required and with 0.2 they are optional.
> 
> For highbank, since firmware and DTB is essentially frozen now, a
> compatible change is not going to happen. It probably means just
> leaving things as is.

Ok.

> 
> For reference, this is what highbank/midway's binding looks like:
> 
>         psci {
>                 compatible      = "arm,psci";
>                 method          = "smc";
>                 cpu_suspend     = <0x84000002>;
>                 cpu_off         = <0x84000004>;
>                 cpu_on          = <0x84000006>;
>                 system_off      = <0x84000100>;
>                 system_reset    = <0x84000101>;
>         };
> 
> I suppose I could just ignore the binding and make highbank reset/off
> functions do custom some PSCI calls. This would mean exposing
> invoke_psci_fn or creating some custom call wrapper.

Is there any good way to tell if a machine is highbank or midway (e.g.
the top-level compatible string)?

We could check for that and if so read the additional values from the
dt. That way highbank and midway get supported but new machines would
still have to follow the IDs from the final release.

This doesn't necessarily have to be documented as an official binding,
it's essentially a workaround for a quirk (though one with a good reason
for existing).

Does that sound reasonable?

Cheers,
Mark.

Re: [Qemu-devel] [RFC PATCH 7/7] target-arm: Hacky implementation of kvm_arch_reset_vcpu() for KVM ARM64

[Pranavkumar Sawargaonkar]

On 27 February 2014 12:21, Pranavkumar Sawargaonkar
<pranavkumar@linaro.org> wrote:
> We need to "Feed the kernel back its initial register state" using KVM
> ioctls for KVM ARM64 (just like KVM ARM). This means we need to save
> the "initial register state" in kvm_arch_init_vcpu() which is not the
> case for KVM ARM64 right now. In simpler work, we are depended upon
> VCPU register init/save/restore for implementing kvm_arch_reset_vcpu().
>
> This patch adds a hacky implementation of kvm_arch_reset_vcpu() which
> only works for "mach-virt". As-per this hacky implemenation, we re-init
> the VCPU using kvm_arch_init_vcpu() so that all registers of VCPU are
> set to their reset values by in-kernel KVM code.
>
> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
> Signed-off-by: Anup Patel <anup.patel@linaro.org>
> ---
>  target-arm/kvm64.c |    8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/target-arm/kvm64.c b/target-arm/kvm64.c
> index d303046..b64909d 100644
> --- a/target-arm/kvm64.c
> +++ b/target-arm/kvm64.c
> @@ -205,4 +205,12 @@ int kvm_arch_get_registers(CPUState *cs)
>
>  void kvm_arch_reset_vcpu(CPUState *cs)
>  {
> +    /* TODO: Feed the kernel back its initial register state */
> +
> +    /* For now just re-init VCPU so that all registers are
> +     * set to their respective reset values. This will work
> +     * for "mach-virt" only because for "mach-virt" we have
> +     * start-pc set to zero.
> +     */
> +    kvm_arch_init_vcpu(cs);
>  }
> --
> 1.7.9.5
>

Sorry for mentioning wrong qemu devel mail id and spamming in my previous mail.
Correcting correct qemu-devel  id.

Thanks,
Pranav

Re: [Qemu-devel] [RFC PATCH 7/7] target-arm: Hacky implementation of kvm_arch_reset_vcpu() for KVM ARM64

[Pranavkumar Sawargaonkar]

Hi Peter,

On 27 February 2014 15:23, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 27 February 2014 06:51, Pranavkumar Sawargaonkar
> <pranavkumar@linaro.org> wrote:
>> We need to "Feed the kernel back its initial register state" using KVM
>> ioctls for KVM ARM64 (just like KVM ARM). This means we need to save
>> the "initial register state" in kvm_arch_init_vcpu() which is not the
>> case for KVM ARM64 right now. In simpler work, we are depended upon
>> VCPU register init/save/restore for implementing kvm_arch_reset_vcpu().
>>
>> This patch adds a hacky implementation of kvm_arch_reset_vcpu() which
>> only works for "mach-virt". As-per this hacky implemenation, we re-init
>> the VCPU using kvm_arch_init_vcpu() so that all registers of VCPU are
>> set to their reset values by in-kernel KVM code.
>
> Re-initing the VCPU is actually the right way to do this -- it is feeding
> all the register state back to KVM that is the hack. (One day I may
> fix 32 bit ARM to re-init the VCPU).
>

Ok, I mentioned this a hack since it is different from arm32 way.
I will update patch comment and description accordingly.

> Why does this only work for mach-virt?

Due to re-init pc becomes zero which is fine for mach-virt but
may not work for some other machine type.

This brings me back to the question that are we going to
allow any other machine type with KVM ARM/ARM64 ?

>
> thanks
> -- PMM

Thanks,
Pranav

Re: [Qemu-devel] [RFC PATCH 7/7] target-arm: Hacky implementation of kvm_arch_reset_vcpu() for KVM ARM64

[Peter Maydell]

On 27 February 2014 10:35, Pranavkumar Sawargaonkar
<pranavkumar@linaro.org> wrote:
> Hi Peter,
>
> On 27 February 2014 15:23, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 27 February 2014 06:51, Pranavkumar Sawargaonkar
>> <pranavkumar@linaro.org> wrote:
>>> We need to "Feed the kernel back its initial register state" using KVM
>>> ioctls for KVM ARM64 (just like KVM ARM). This means we need to save
>>> the "initial register state" in kvm_arch_init_vcpu() which is not the
>>> case for KVM ARM64 right now. In simpler work, we are depended upon
>>> VCPU register init/save/restore for implementing kvm_arch_reset_vcpu().
>>>
>>> This patch adds a hacky implementation of kvm_arch_reset_vcpu() which
>>> only works for "mach-virt". As-per this hacky implemenation, we re-init
>>> the VCPU using kvm_arch_init_vcpu() so that all registers of VCPU are
>>> set to their reset values by in-kernel KVM code.
>>
>> Re-initing the VCPU is actually the right way to do this -- it is feeding
>> all the register state back to KVM that is the hack. (One day I may
>> fix 32 bit ARM to re-init the VCPU).
>>
>
> Ok, I mentioned this a hack since it is different from arm32 way.
> I will update patch comment and description accordingly.
>
>> Why does this only work for mach-virt?
>
> Due to re-init pc becomes zero which is fine for mach-virt but
> may not work for some other machine type.

That is the correct reset value for the CPU (assuming
no hivecs); it should be fine for everything. (Supporting
a CPU with hivecs enabled from reset would probably
require an extra VCPU_INIT feature flag, but it would only
be relevant for AArch32 anyway and we can deal with that
if we ever have a board that actually needs it.)

> This brings me back to the question that are we going to
> allow any other machine type with KVM ARM/ARM64 ?

Of course. For 32 bit KVM/ARM we already support vexpress-a15
and I see no reason why midway or any other implemented A15
board should not work too. For 64-bit we happen not to have
any board models other than virt, but if anybody contributes
one it should also work just fine with KVM.

thanks
-- PMM

Re: [Qemu-devel] [RFC PATCH 7/7] target-arm: Hacky implementation of kvm_arch_reset_vcpu() for KVM ARM64

[Christoffer Dall]

On Thu, Feb 27, 2014 at 04:05:04PM +0530, Pranavkumar Sawargaonkar wrote:
> Hi Peter,
> 
> On 27 February 2014 15:23, Peter Maydell <peter.maydell@linaro.org> wrote:
> > On 27 February 2014 06:51, Pranavkumar Sawargaonkar
> > <pranavkumar@linaro.org> wrote:
> >> We need to "Feed the kernel back its initial register state" using KVM
> >> ioctls for KVM ARM64 (just like KVM ARM). This means we need to save
> >> the "initial register state" in kvm_arch_init_vcpu() which is not the
> >> case for KVM ARM64 right now. In simpler work, we are depended upon
> >> VCPU register init/save/restore for implementing kvm_arch_reset_vcpu().
> >>
> >> This patch adds a hacky implementation of kvm_arch_reset_vcpu() which
> >> only works for "mach-virt". As-per this hacky implemenation, we re-init
> >> the VCPU using kvm_arch_init_vcpu() so that all registers of VCPU are
> >> set to their reset values by in-kernel KVM code.
> >
> > Re-initing the VCPU is actually the right way to do this -- it is feeding
> > all the register state back to KVM that is the hack. (One day I may
> > fix 32 bit ARM to re-init the VCPU).
> >
> 
Didn't I promise a patch to the KVM Documentation some time to clarify
this?  Hmmm.

-Christoffer

Re: [Qemu-devel] [RFC PATCH 7/7] target-arm: Hacky implementation of kvm_arch_reset_vcpu() for KVM ARM64

[Pranavkumar Sawargaonkar]

Hi Christoffer,

On 14 March 2014 09:21, Christoffer Dall <christoffer.dall@linaro.org> wrote:
> On Thu, Feb 27, 2014 at 04:05:04PM +0530, Pranavkumar Sawargaonkar wrote:
>> Hi Peter,
>>
>> On 27 February 2014 15:23, Peter Maydell <peter.maydell@linaro.org> wrote:
>> > On 27 February 2014 06:51, Pranavkumar Sawargaonkar
>> > <pranavkumar@linaro.org> wrote:
>> >> We need to "Feed the kernel back its initial register state" using KVM
>> >> ioctls for KVM ARM64 (just like KVM ARM). This means we need to save
>> >> the "initial register state" in kvm_arch_init_vcpu() which is not the
>> >> case for KVM ARM64 right now. In simpler work, we are depended upon
>> >> VCPU register init/save/restore for implementing kvm_arch_reset_vcpu().
>> >>
>> >> This patch adds a hacky implementation of kvm_arch_reset_vcpu() which
>> >> only works for "mach-virt". As-per this hacky implemenation, we re-init
>> >> the VCPU using kvm_arch_init_vcpu() so that all registers of VCPU are
>> >> set to their reset values by in-kernel KVM code.
>> >
>> > Re-initing the VCPU is actually the right way to do this -- it is feeding
>> > all the register state back to KVM that is the hack. (One day I may
>> > fix 32 bit ARM to re-init the VCPU).
>> >
>>
> Didn't I promise a patch to the KVM Documentation some time to clarify
> this?  Hmmm.

Sorry I was not aware about it about you are going to send a patch to
KVM documentation to clarify this.
Also PMM mentioned that this is not the hack and actually the correct way.
Hence I will revise the patch with removal of Hack word.

>
> -Christoffer

Thanks,
Pranav