2019-06-04 08:11:36 +00:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-only */
|
2007-12-03 21:30:23 +00:00
|
|
|
|
|
|
|
#ifndef __KVM_TYPES_H__
|
|
|
|
#define __KVM_TYPES_H__
|
|
|
|
|
2014-08-29 12:01:17 +00:00
|
|
|
struct kvm;
|
|
|
|
struct kvm_async_pf;
|
|
|
|
struct kvm_device_ops;
|
|
|
|
struct kvm_interrupt;
|
|
|
|
struct kvm_irq_routing_table;
|
|
|
|
struct kvm_memory_slot;
|
|
|
|
struct kvm_one_reg;
|
|
|
|
struct kvm_run;
|
|
|
|
struct kvm_userspace_memory_region;
|
|
|
|
struct kvm_vcpu;
|
|
|
|
struct kvm_vcpu_init;
|
2015-05-17 19:26:08 +00:00
|
|
|
struct kvm_memslots;
|
2014-08-29 12:01:17 +00:00
|
|
|
|
|
|
|
enum kvm_mr_change;
|
|
|
|
|
2019-12-05 01:30:51 +00:00
|
|
|
#include <linux/types.h>
|
KVM: Reinstate gfn_to_pfn_cache with invalidation support
This can be used in two modes. There is an atomic mode where the cached
mapping is accessed while holding the rwlock, and a mode where the
physical address is used by a vCPU in guest mode.
For the latter case, an invalidation will wake the vCPU with the new
KVM_REQ_GPC_INVALIDATE, and the architecture will need to refresh any
caches it still needs to access before entering guest mode again.
Only one vCPU can be targeted by the wake requests; it's simple enough
to make it wake all vCPUs or even a mask but I don't see a use case for
that additional complexity right now.
Invalidation happens from the invalidate_range_start MMU notifier, which
needs to be able to sleep in order to wake the vCPU and wait for it.
This means that revalidation potentially needs to "wait" for the MMU
operation to complete and the invalidate_range_end notifier to be
invoked. Like the vCPU when it takes a page fault in that period, we
just spin — fixing that in a future patch by implementing an actual
*wait* may be another part of shaving this particularly hirsute yak.
As noted in the comments in the function itself, the only case where
the invalidate_range_start notifier is expected to be called *without*
being able to sleep is when the OOM reaper is killing the process. In
that case, we expect the vCPU threads already to have exited, and thus
there will be nothing to wake, and no reason to wait. So we clear the
KVM_REQUEST_WAIT bit and send the request anyway, then complain loudly
if there actually *was* anything to wake up.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Message-Id: <20211210163625.2886-3-dwmw2@infradead.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-12-10 16:36:21 +00:00
|
|
|
#include <linux/spinlock_types.h>
|
2007-12-03 21:30:23 +00:00
|
|
|
|
2020-07-03 02:35:38 +00:00
|
|
|
#include <asm/kvm_types.h>
|
|
|
|
|
2007-12-03 21:30:23 +00:00
|
|
|
/*
|
|
|
|
* Address types:
|
|
|
|
*
|
|
|
|
* gva - guest virtual address
|
|
|
|
* gpa - guest physical address
|
|
|
|
* gfn - guest frame number
|
|
|
|
* hva - host virtual address
|
|
|
|
* hpa - host physical address
|
|
|
|
* hfn - host frame number
|
|
|
|
*/
|
|
|
|
|
|
|
|
typedef unsigned long gva_t;
|
|
|
|
typedef u64 gpa_t;
|
2010-07-01 14:00:12 +00:00
|
|
|
typedef u64 gfn_t;
|
2007-12-03 21:30:23 +00:00
|
|
|
|
2019-10-21 15:28:18 +00:00
|
|
|
#define GPA_INVALID (~(gpa_t)0)
|
|
|
|
|
2007-12-03 21:30:23 +00:00
|
|
|
typedef unsigned long hva_t;
|
|
|
|
typedef u64 hpa_t;
|
2010-07-01 14:00:12 +00:00
|
|
|
typedef u64 hfn_t;
|
2007-12-03 21:30:23 +00:00
|
|
|
|
kvm: rename pfn_t to kvm_pfn_t
To date, we have implemented two I/O usage models for persistent memory,
PMEM (a persistent "ram disk") and DAX (mmap persistent memory into
userspace). This series adds a third, DAX-GUP, that allows DAX mappings
to be the target of direct-i/o. It allows userspace to coordinate
DMA/RDMA from/to persistent memory.
The implementation leverages the ZONE_DEVICE mm-zone that went into
4.3-rc1 (also discussed at kernel summit) to flag pages that are owned
and dynamically mapped by a device driver. The pmem driver, after
mapping a persistent memory range into the system memmap via
devm_memremap_pages(), arranges for DAX to distinguish pfn-only versus
page-backed pmem-pfns via flags in the new pfn_t type.
The DAX code, upon seeing a PFN_DEV+PFN_MAP flagged pfn, flags the
resulting pte(s) inserted into the process page tables with a new
_PAGE_DEVMAP flag. Later, when get_user_pages() is walking ptes it keys
off _PAGE_DEVMAP to pin the device hosting the page range active.
Finally, get_page() and put_page() are modified to take references
against the device driver established page mapping.
Finally, this need for "struct page" for persistent memory requires
memory capacity to store the memmap array. Given the memmap array for a
large pool of persistent may exhaust available DRAM introduce a
mechanism to allocate the memmap from persistent memory. The new
"struct vmem_altmap *" parameter to devm_memremap_pages() enables
arch_add_memory() to use reserved pmem capacity rather than the page
allocator.
This patch (of 18):
The core has developed a need for a "pfn_t" type [1]. Move the existing
pfn_t in KVM to kvm_pfn_t [2].
[1]: https://lists.01.org/pipermail/linux-nvdimm/2015-September/002199.html
[2]: https://lists.01.org/pipermail/linux-nvdimm/2015-September/002218.html
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-01-16 00:56:11 +00:00
|
|
|
typedef hfn_t kvm_pfn_t;
|
2008-04-02 19:46:56 +00:00
|
|
|
|
2010-10-18 13:22:23 +00:00
|
|
|
struct gfn_to_hva_cache {
|
|
|
|
u64 generation;
|
|
|
|
gpa_t gpa;
|
|
|
|
unsigned long hva;
|
2013-03-29 16:35:21 +00:00
|
|
|
unsigned long len;
|
2010-10-18 13:22:23 +00:00
|
|
|
struct kvm_memory_slot *memslot;
|
|
|
|
};
|
|
|
|
|
KVM: Reinstate gfn_to_pfn_cache with invalidation support
This can be used in two modes. There is an atomic mode where the cached
mapping is accessed while holding the rwlock, and a mode where the
physical address is used by a vCPU in guest mode.
For the latter case, an invalidation will wake the vCPU with the new
KVM_REQ_GPC_INVALIDATE, and the architecture will need to refresh any
caches it still needs to access before entering guest mode again.
Only one vCPU can be targeted by the wake requests; it's simple enough
to make it wake all vCPUs or even a mask but I don't see a use case for
that additional complexity right now.
Invalidation happens from the invalidate_range_start MMU notifier, which
needs to be able to sleep in order to wake the vCPU and wait for it.
This means that revalidation potentially needs to "wait" for the MMU
operation to complete and the invalidate_range_end notifier to be
invoked. Like the vCPU when it takes a page fault in that period, we
just spin — fixing that in a future patch by implementing an actual
*wait* may be another part of shaving this particularly hirsute yak.
As noted in the comments in the function itself, the only case where
the invalidate_range_start notifier is expected to be called *without*
being able to sleep is when the OOM reaper is killing the process. In
that case, we expect the vCPU threads already to have exited, and thus
there will be nothing to wake, and no reason to wait. So we clear the
KVM_REQUEST_WAIT bit and send the request anyway, then complain loudly
if there actually *was* anything to wake up.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Message-Id: <20211210163625.2886-3-dwmw2@infradead.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-12-10 16:36:21 +00:00
|
|
|
struct gfn_to_pfn_cache {
|
|
|
|
u64 generation;
|
|
|
|
gpa_t gpa;
|
|
|
|
unsigned long uhva;
|
|
|
|
struct kvm_memory_slot *memslot;
|
|
|
|
struct kvm_vcpu *vcpu;
|
|
|
|
struct list_head list;
|
|
|
|
rwlock_t lock;
|
|
|
|
void *khva;
|
|
|
|
kvm_pfn_t pfn;
|
|
|
|
bool active;
|
|
|
|
bool valid;
|
|
|
|
bool dirty;
|
|
|
|
bool kernel_map;
|
|
|
|
bool guest_uses_pa;
|
|
|
|
};
|
|
|
|
|
2020-07-03 02:35:38 +00:00
|
|
|
#ifdef KVM_ARCH_NR_OBJS_PER_MEMORY_CACHE
|
|
|
|
/*
|
|
|
|
* Memory caches are used to preallocate memory ahead of various MMU flows,
|
|
|
|
* e.g. page fault handlers. Gracefully handling allocation failures deep in
|
|
|
|
* MMU flows is problematic, as is triggering reclaim, I/O, etc... while
|
|
|
|
* holding MMU locks. Note, these caches act more like prefetch buffers than
|
|
|
|
* classical caches, i.e. objects are not returned to the cache on being freed.
|
|
|
|
*/
|
|
|
|
struct kvm_mmu_memory_cache {
|
|
|
|
int nobjs;
|
|
|
|
gfp_t gfp_zero;
|
|
|
|
struct kmem_cache *kmem_cache;
|
|
|
|
void *objects[KVM_ARCH_NR_OBJS_PER_MEMORY_CACHE];
|
|
|
|
};
|
|
|
|
#endif
|
|
|
|
|
2021-08-02 16:56:33 +00:00
|
|
|
#define HALT_POLL_HIST_COUNT 32
|
|
|
|
|
2021-06-18 22:27:03 +00:00
|
|
|
struct kvm_vm_stat_generic {
|
|
|
|
u64 remote_tlb_flush;
|
2021-08-17 00:26:39 +00:00
|
|
|
u64 remote_tlb_flush_requests;
|
2021-06-18 22:27:03 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct kvm_vcpu_stat_generic {
|
|
|
|
u64 halt_successful_poll;
|
|
|
|
u64 halt_attempted_poll;
|
|
|
|
u64 halt_poll_invalid;
|
|
|
|
u64 halt_wakeup;
|
|
|
|
u64 halt_poll_success_ns;
|
|
|
|
u64 halt_poll_fail_ns;
|
2021-08-02 16:56:32 +00:00
|
|
|
u64 halt_wait_ns;
|
2021-08-02 16:56:33 +00:00
|
|
|
u64 halt_poll_success_hist[HALT_POLL_HIST_COUNT];
|
|
|
|
u64 halt_poll_fail_hist[HALT_POLL_HIST_COUNT];
|
|
|
|
u64 halt_wait_hist[HALT_POLL_HIST_COUNT];
|
2021-10-09 02:12:08 +00:00
|
|
|
u64 blocking;
|
2021-06-18 22:27:03 +00:00
|
|
|
};
|
2020-07-03 02:35:38 +00:00
|
|
|
|
2021-06-18 22:27:04 +00:00
|
|
|
#define KVM_STATS_NAME_SIZE 48
|
|
|
|
|
2007-12-03 21:30:23 +00:00
|
|
|
#endif /* __KVM_TYPES_H__ */
|