qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [PATCH v3 RFC 2/2] target: arm: Add support for VCPU even


From: Peter Maydell
Subject: Re: [Qemu-arm] [PATCH v3 RFC 2/2] target: arm: Add support for VCPU event states
Date: Wed, 20 Jun 2018 17:56:16 +0100

On 7 June 2018 at 21:31, Dongjiu Geng <address@hidden> wrote:
> This patch extends the qemu-kvm state sync logic with support for
> KVM_GET/SET_VCPU_EVENTS, giving access to yet missing SError exception.
> And also it can support the exception state migration.
>
> Signed-off-by: Dongjiu Geng <address@hidden>
> ---
>  target/arm/cpu.h     |  5 ++++
>  target/arm/kvm64.c   | 64 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  target/arm/machine.c |  3 +++
>  3 files changed, 72 insertions(+)
>
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index 8488273..b3d6682 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -645,6 +645,11 @@ typedef struct CPUARMState {
>      const struct arm_boot_info *boot_info;
>      /* Store GICv3CPUState to access from this struct */
>      void *gicv3state;
> +    struct {
> +        uint32_t pending;
> +        uint32_t has_esr;
> +        uint64_t esr;
> +    } serror;

What is this state? That is, what guest CPU architectural state
is it supposed to correspond to?

> diff --git a/target/arm/machine.c b/target/arm/machine.c
> index 2e28d08..5a359f4 100644
> --- a/target/arm/machine.c
> +++ b/target/arm/machine.c
> @@ -695,6 +695,9 @@ const VMStateDescription vmstate_arm_cpu = {
>          VMSTATE_UINT32(env.exception.syndrome, ARMCPU),
>          VMSTATE_UINT32(env.exception.fsr, ARMCPU),
>          VMSTATE_UINT64(env.exception.vaddress, ARMCPU),
> +        VMSTATE_UINT32(env.serror.pending, ARMCPU),
> +        VMSTATE_UINT32(env.serror.has_esr, ARMCPU),
> +        VMSTATE_UINT64(env.serror.esr, ARMCPU),
>          VMSTATE_TIMER_PTR(gt_timer[GTIMER_PHYS], ARMCPU),
>          VMSTATE_TIMER_PTR(gt_timer[GTIMER_VIRT], ARMCPU),
>          {

You can't just add fields like this, as it breaks migration
compatibility. If these need to be migrated then you need a
new subsection with a suitable 'needed' function controlling
whether it is present. But we should determine first
whether this really is new guest CPU state...

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]