qemu-devel
[Top][All Lists]
Advanced

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

Re: [RFC v2 19/24] target/arm: move aarch64_sync_32_to_64 (and vv) to cp


From: Peter Maydell
Subject: Re: [RFC v2 19/24] target/arm: move aarch64_sync_32_to_64 (and vv) to cpu code
Date: Tue, 2 Mar 2021 12:11:09 +0000

On Tue, 2 Mar 2021 at 11:59, Claudio Fontana <cfontana@suse.de> wrote:
> Then, in kvm64.c:
> kvm_arch_get_registers()
> {
>     ...
>     if (!is_a64(env)) {
>         aarch64_sync_64_to_32(env);
>     }
>     ...
>     write_kvmstate_to_list(cpu);
>     ...
>     write_list_to_cpustate(cpu);
>     ...
> }

The way to think about this is that there are three places where
system register state can be stored:
 * in the kernel (assuming we're using KVM)
 * in the 'list', which is the cpreg_indexes[]/cpreg_values[] arrays
 * in fields in QEMU's CPUARMState structure

The "list" data structure is a transitional one only: we use it:
 (1) for migration: outgoing migration is of the cpreg_indexes/values
      arrays, and incoming migration goes into these arrays
 (2) as the intermediate point when moving state between the kernel
      and the CPUARMState structure fields: we have functions for
      going between KVM state and the lists, and for going between
      the lists and CPU state fields

Nothing else except the migration and the conversion functions should
need to know about or touch the 'list' representation. All QEMU code
which needs to examine or update guest CPU state will arrange that
the in-kernel state is synced into the CPU state struct fields (going via the
list in the process) and then update CPU state fields. Before the guest
is run again we sync in the opposite direction (again via the list structures).

thanks
-- PMM



reply via email to

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