diff options
| author | Sean Christopherson <seanjc@google.com> | 2022-04-29 21:00:23 +0000 |
|---|---|---|
| committer | Paolo Bonzini <pbonzini@redhat.com> | 2022-05-25 05:23:43 -0400 |
| commit | 93984f19e7bce4c18084a6ef3dacafb155b806ed (patch) | |
| tree | d40a8874510885dafedb97b20f7226ce76ba154f /virt/kvm/kvm_main.c | |
| parent | 3ba2c95ea180740b16281fa43a3ee5f47279c0ed (diff) | |
| download | linux-93984f19e7bce4c18084a6ef3dacafb155b806ed.tar.gz linux-93984f19e7bce4c18084a6ef3dacafb155b806ed.tar.bz2 linux-93984f19e7bce4c18084a6ef3dacafb155b806ed.zip | |
KVM: Fully serialize gfn=>pfn cache refresh via mutex
Protect gfn=>pfn cache refresh with a mutex to fully serialize refreshes.
The refresh logic doesn't protect against
- concurrent unmaps, or refreshes with different GPAs (which may or may not
happen in practice, for example if a cache is only used under vcpu->mutex;
but it's allowed in the code)
- a false negative on the memslot generation. If the first refresh sees
a stale memslot generation, it will refresh the hva and generation before
moving on to the hva=>pfn translation. If it then drops gpc->lock, a
different user of the cache can come along, acquire gpc->lock, see that
the memslot generation is fresh, and skip the hva=>pfn update due to the
userspace address also matching (because it too was updated).
The refresh path can already sleep during hva=>pfn resolution, so wrap
the refresh with a mutex to ensure that any given refresh runs to
completion before other callers can start their refresh.
Cc: stable@vger.kernel.org
Cc: Lai Jiangshan <jiangshanlai@gmail.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20220429210025.3293691-7-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'virt/kvm/kvm_main.c')
0 files changed, 0 insertions, 0 deletions
