On Tue, 2 Mar 2021 at 11:59, Claudio Fontana <[email protected]> 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
