Messages in this thread | | | From | Paolo Bonzini <> | Subject | Re: [PATCH 5/6] KVM: x86/mmu: Protect kvm->memslots with a mutex | Date | Wed, 28 Apr 2021 23:41:47 +0200 |
| |
On 28/04/21 22:40, Ben Gardon wrote: > ... However with the locking you propose below, we might still run > into issues on a move or delete, which would mean we'd still need the > separate memory allocation for the rmaps array. Or we do some > shenanigans where we try to copy the rmap pointers from the other set > of memslots.
If that's (almost) as easy as passing old to kvm_arch_prepare_memory_region, that would be totally okay.
> My only worry is the latency this could add to a nested VM launch, but > it seems pretty unlikely that that would be frequently coinciding with > a memslot change in practice.
Right, memslot changes in practice occur only at boot and on hotplug. If that was a problem we could always make the allocation state off/in-progress/on, allowing to check the allocation state out of the lock. This would only potentially slow down the first nested VM launch.
Paolo
| |