]> www.infradead.org Git - users/dwmw2/linux.git/commit
KVM: Remove dirty handling from gfn_to_pfn_cache completely
authorDavid Woodhouse <dwmw@amazon.co.uk>
Sun, 27 Feb 2022 14:48:37 +0000 (14:48 +0000)
committerDavid Woodhouse <dwmw@amazon.co.uk>
Thu, 3 Mar 2022 15:17:26 +0000 (15:17 +0000)
commitb654a04ad5574e6eb01c0a19c157a30edd37d42c
tree2d27fe2818252d07548e63e1a03d212ae7e2414d
parent45622ff1b75d4d58c640cd1d3a32a0ab376649b3
KVM: Remove dirty handling from gfn_to_pfn_cache completely

It isn't OK to cache the dirty status of a page in internal structures
for an indefinite period of time.

Any time a vCPU exits the run loop to userspace might be its last; the
VMM might do its final check of the dirty log, flush the last remaining
dirty pages to the destination and complete a live migration. If we
have internal 'dirty' state which doesn't get flushed until the vCPU
is finally destroyed on the source after migration is complete, then
we have lost data because that will escape the final copy.

This problem already exists with the use of kvm_vcpu_unmap() to mark
pages dirty in e.g. VMX nesting.

Note that the actual Linux MM already considers the page to be dirty
since we have a writeable mapping of it. This is just about the KVM
dirty logging.

For the nesting-style use cases (KVM_GUEST_USES_PFN) we will need to
track which gfn_to_pfn_caches have been used and explicitly mark the
corresponding pages dirty before returning to userspace. But we would
have needed external tracking of that anyway, rather than walking the
full list of GPCs to find those belonging to this vCPU which are dirty.

So let's rely *solely* on that external tracking, and keep it simple
rather than laying a tempting trap for callers to fall into.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Documentation/virt/kvm/api.rst
arch/x86/kvm/xen.c
include/linux/kvm_host.h
include/linux/kvm_types.h
virt/kvm/pfncache.c