On 2/10/22 01:47, Sean Christopherson wrote:
The nested mess is likely easily solved, I don't see any obvious issue with swapping the order. But I still don't love the subtlety. I do like shaving cycles, just not the subtlety...
Not so easily, but it's doable and it's essentially what I did in the other series (the one that reworks the root cache).
Quick spoiler: there's a complicated dependency between the _old_ values in kvm_mmu and the root cache, so that the root cache code currently needs both the old MMU state (especially shadow_root_level/root_level) and the new role.
kvm_mmu_reset_context does the expensive kvm_mmu_unload to cop out of having to know in advance the new role; the crux of the other series is to remove that need, so that kvm_mmu_reset_context does not have to cop out anymore.
If we do rework things to have kvm_mmu_new_pgd() pull the role from the mmu, then we should first add a long overdue audit/warn that KVM never runs with a mmu_role that isn't consistent with respect to its root SP's role.
There's a much cheaper check that can be done to enforce the invariant that kvm_mmu_new_pgd must follow kvm_init_mmu: kvm_init_mmu sets a not_ready flag, kvm_mmu_new_pgd clears it, and kvm_mmu_reload screams if it sees not_ready == 1.
Paolo
