diff options
author | Fuad Tabba <tabba@google.com> | 2025-09-09 08:24:34 +0100 |
---|---|---|
committer | Marc Zyngier <maz@kernel.org> | 2025-09-15 10:46:55 +0100 |
commit | 814fd6beacf3c105ab8c8796be07d740952899fe (patch) | |
tree | 32824bd97483d1c3c6b619e1086ee1b2ce22dccf /rust/kernel/alloc/allocator_test.rs | |
parent | 1abc1ad52989fcc45a0de68bc49656d9fd0c2d74 (diff) |
KVM: arm64: Consolidate pKVM hypervisor VM initialization logic
The insert_vm_table_entry() function was performing tasks beyond its
primary responsibility. In addition to inserting a VM pointer into the
vm_table, it was also initializing several fields within 'struct
pkvm_hyp_vm', such as the VMID and stage-2 MMU pointers. This mixing of
concerns made the code harder to follow.
As another preparatory step towards allowing a VM table entry to be
reserved before the VM is fully created, this logic must be cleaned up.
By separating table insertion from state initialization, we can control
the timing of the initialization step more precisely in subsequent
patches.
Refactor the code to consolidate all initialization logic into
init_pkvm_hyp_vm():
- Move the initialization of the handle, VMID, and MMU fields from
insert_vm_table_entry() to init_pkvm_hyp_vm().
- Simplify insert_vm_table_entry() to perform only one action: placing
the provided pkvm_hyp_vm pointer into the vm_table.
- Update the calling sequence in __pkvm_init_vm() to first allocate an
entry in the VM table, initialize the VM, and then insert the VM into
the VM table. This is all protected by the vm_table_lock for now.
Subsequent patches will adjust the sequence and not hold the
vm_table_lock while initializing the VM at the hypervisor
(init_pkvm_hyp_vm()).
Signed-off-by: Fuad Tabba <tabba@google.com>
Tested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Diffstat (limited to 'rust/kernel/alloc/allocator_test.rs')
0 files changed, 0 insertions, 0 deletions