KVM: PPC: Allocate RMAs (Real Mode Areas) at boot for use by guests
This adds infrastructure which will be needed to allow book3s_hv KVM to
run on older POWER processors, including PPC970, which don't support
the Virtual Real Mode Area (VRMA) facility, but only the Real Mode
Offset (RMO) facility. These processors require a physically
contiguous, aligned area of memory for each guest. When the guest does
an access in real mode (MMU off), the address is compared against a
limit value, and if it is lower, the address is ORed with an offset
value (from the Real Mode Offset Register (RMOR)) and the result becomes
the real address for the access. The size of the RMA has to be one of
a set of supported values, which usually includes 64MB, 128MB, 256MB
and some larger powers of 2.
Since we are unlikely to be able to allocate 64MB or more of physically
contiguous memory after the kernel has been running for a while, we
allocate a pool of RMAs at boot time using the bootmem allocator. The
size and number of the RMAs can be set using the kvm_rma_size=xx and
kvm_rma_count=xx kernel command line options.
KVM exports a new capability, KVM_CAP_PPC_RMA, to signal the availability
of the pool of preallocated RMAs. The capability value is 1 if the
processor can use an RMA but doesn't require one (because it supports
the VRMA facility), or 2 if the processor requires an RMA for each guest.
This adds a new ioctl, KVM_ALLOCATE_RMA, which allocates an RMA from the
pool and returns a file descriptor which can be used to map the RMA. It
also returns the size of the RMA in the argument structure.
Having an RMA means we will get multiple KMV_SET_USER_MEMORY_REGION
ioctl calls from userspace. To cope with this, we now preallocate the
kvm->arch.ram_pginfo array when the VM is created with a size sufficient
for up to 64GB of guest memory. Subsequently we will get rid of this
array and use memory associated with each memslot instead.
This moves most of the code that translates the user addresses into
host pfns (page frame numbers) out of kvmppc_prepare_vrma up one level
to kvmppc_core_prepare_memory_region. Also, instead of having to look
up the VMA for each page in order to check the page size, we now check
that the pages we get are compound pages of 16MB. However, if we are
adding memory that is mapped to an RMA, we don't bother with calling
get_user_pages_fast and instead just offset from the base pfn for the
RMA.
Typically the RMA gets added after vcpus are created, which makes it
inconvenient to have the LPCR (logical partition control register) value
in the vcpu->arch struct, since the LPCR controls whether the processor
uses RMA or VRMA for the guest. This moves the LPCR value into the
kvm->arch struct and arranges for the MER (mediated external request)
bit, which is the only bit that varies between vcpus, to be set in
assembly code when going into the guest if there is a pending external
interrupt request.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-06-29 08:25:44 +08:00
|
|
|
/*
|
|
|
|
|
* Copyright 2011 Paul Mackerras, IBM Corp. <paulus@au1.ibm.com>
|
|
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
|
* it under the terms of the GNU General Public License, version 2, as
|
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
|
*/
|
|
|
|
|
|
2014-05-23 16:15:25 +08:00
|
|
|
#include <linux/cpu.h>
|
KVM: PPC: Allocate RMAs (Real Mode Areas) at boot for use by guests
This adds infrastructure which will be needed to allow book3s_hv KVM to
run on older POWER processors, including PPC970, which don't support
the Virtual Real Mode Area (VRMA) facility, but only the Real Mode
Offset (RMO) facility. These processors require a physically
contiguous, aligned area of memory for each guest. When the guest does
an access in real mode (MMU off), the address is compared against a
limit value, and if it is lower, the address is ORed with an offset
value (from the Real Mode Offset Register (RMOR)) and the result becomes
the real address for the access. The size of the RMA has to be one of
a set of supported values, which usually includes 64MB, 128MB, 256MB
and some larger powers of 2.
Since we are unlikely to be able to allocate 64MB or more of physically
contiguous memory after the kernel has been running for a while, we
allocate a pool of RMAs at boot time using the bootmem allocator. The
size and number of the RMAs can be set using the kvm_rma_size=xx and
kvm_rma_count=xx kernel command line options.
KVM exports a new capability, KVM_CAP_PPC_RMA, to signal the availability
of the pool of preallocated RMAs. The capability value is 1 if the
processor can use an RMA but doesn't require one (because it supports
the VRMA facility), or 2 if the processor requires an RMA for each guest.
This adds a new ioctl, KVM_ALLOCATE_RMA, which allocates an RMA from the
pool and returns a file descriptor which can be used to map the RMA. It
also returns the size of the RMA in the argument structure.
Having an RMA means we will get multiple KMV_SET_USER_MEMORY_REGION
ioctl calls from userspace. To cope with this, we now preallocate the
kvm->arch.ram_pginfo array when the VM is created with a size sufficient
for up to 64GB of guest memory. Subsequently we will get rid of this
array and use memory associated with each memslot instead.
This moves most of the code that translates the user addresses into
host pfns (page frame numbers) out of kvmppc_prepare_vrma up one level
to kvmppc_core_prepare_memory_region. Also, instead of having to look
up the VMA for each page in order to check the page size, we now check
that the pages we get are compound pages of 16MB. However, if we are
adding memory that is mapped to an RMA, we don't bother with calling
get_user_pages_fast and instead just offset from the base pfn for the
RMA.
Typically the RMA gets added after vcpus are created, which makes it
inconvenient to have the LPCR (logical partition control register) value
in the vcpu->arch struct, since the LPCR controls whether the processor
uses RMA or VRMA for the guest. This moves the LPCR value into the
kvm->arch struct and arranges for the MER (mediated external request)
bit, which is the only bit that varies between vcpus, to be set in
assembly code when going into the guest if there is a pending external
interrupt request.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-06-29 08:25:44 +08:00
|
|
|
#include <linux/kvm_host.h>
|
|
|
|
|
#include <linux/preempt.h>
|
2011-05-27 22:46:24 +08:00
|
|
|
#include <linux/export.h>
|
KVM: PPC: Allocate RMAs (Real Mode Areas) at boot for use by guests
This adds infrastructure which will be needed to allow book3s_hv KVM to
run on older POWER processors, including PPC970, which don't support
the Virtual Real Mode Area (VRMA) facility, but only the Real Mode
Offset (RMO) facility. These processors require a physically
contiguous, aligned area of memory for each guest. When the guest does
an access in real mode (MMU off), the address is compared against a
limit value, and if it is lower, the address is ORed with an offset
value (from the Real Mode Offset Register (RMOR)) and the result becomes
the real address for the access. The size of the RMA has to be one of
a set of supported values, which usually includes 64MB, 128MB, 256MB
and some larger powers of 2.
Since we are unlikely to be able to allocate 64MB or more of physically
contiguous memory after the kernel has been running for a while, we
allocate a pool of RMAs at boot time using the bootmem allocator. The
size and number of the RMAs can be set using the kvm_rma_size=xx and
kvm_rma_count=xx kernel command line options.
KVM exports a new capability, KVM_CAP_PPC_RMA, to signal the availability
of the pool of preallocated RMAs. The capability value is 1 if the
processor can use an RMA but doesn't require one (because it supports
the VRMA facility), or 2 if the processor requires an RMA for each guest.
This adds a new ioctl, KVM_ALLOCATE_RMA, which allocates an RMA from the
pool and returns a file descriptor which can be used to map the RMA. It
also returns the size of the RMA in the argument structure.
Having an RMA means we will get multiple KMV_SET_USER_MEMORY_REGION
ioctl calls from userspace. To cope with this, we now preallocate the
kvm->arch.ram_pginfo array when the VM is created with a size sufficient
for up to 64GB of guest memory. Subsequently we will get rid of this
array and use memory associated with each memslot instead.
This moves most of the code that translates the user addresses into
host pfns (page frame numbers) out of kvmppc_prepare_vrma up one level
to kvmppc_core_prepare_memory_region. Also, instead of having to look
up the VMA for each page in order to check the page size, we now check
that the pages we get are compound pages of 16MB. However, if we are
adding memory that is mapped to an RMA, we don't bother with calling
get_user_pages_fast and instead just offset from the base pfn for the
RMA.
Typically the RMA gets added after vcpus are created, which makes it
inconvenient to have the LPCR (logical partition control register) value
in the vcpu->arch struct, since the LPCR controls whether the processor
uses RMA or VRMA for the guest. This moves the LPCR value into the
kvm->arch struct and arranges for the MER (mediated external request)
bit, which is the only bit that varies between vcpus, to be set in
assembly code when going into the guest if there is a pending external
interrupt request.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-06-29 08:25:44 +08:00
|
|
|
#include <linux/sched.h>
|
|
|
|
|
#include <linux/spinlock.h>
|
|
|
|
|
#include <linux/init.h>
|
2013-07-02 13:45:16 +08:00
|
|
|
#include <linux/memblock.h>
|
|
|
|
|
#include <linux/sizes.h>
|
2014-08-07 07:05:28 +08:00
|
|
|
#include <linux/cma.h>
|
2014-12-03 10:30:40 +08:00
|
|
|
#include <linux/bitops.h>
|
KVM: PPC: Allocate RMAs (Real Mode Areas) at boot for use by guests
This adds infrastructure which will be needed to allow book3s_hv KVM to
run on older POWER processors, including PPC970, which don't support
the Virtual Real Mode Area (VRMA) facility, but only the Real Mode
Offset (RMO) facility. These processors require a physically
contiguous, aligned area of memory for each guest. When the guest does
an access in real mode (MMU off), the address is compared against a
limit value, and if it is lower, the address is ORed with an offset
value (from the Real Mode Offset Register (RMOR)) and the result becomes
the real address for the access. The size of the RMA has to be one of
a set of supported values, which usually includes 64MB, 128MB, 256MB
and some larger powers of 2.
Since we are unlikely to be able to allocate 64MB or more of physically
contiguous memory after the kernel has been running for a while, we
allocate a pool of RMAs at boot time using the bootmem allocator. The
size and number of the RMAs can be set using the kvm_rma_size=xx and
kvm_rma_count=xx kernel command line options.
KVM exports a new capability, KVM_CAP_PPC_RMA, to signal the availability
of the pool of preallocated RMAs. The capability value is 1 if the
processor can use an RMA but doesn't require one (because it supports
the VRMA facility), or 2 if the processor requires an RMA for each guest.
This adds a new ioctl, KVM_ALLOCATE_RMA, which allocates an RMA from the
pool and returns a file descriptor which can be used to map the RMA. It
also returns the size of the RMA in the argument structure.
Having an RMA means we will get multiple KMV_SET_USER_MEMORY_REGION
ioctl calls from userspace. To cope with this, we now preallocate the
kvm->arch.ram_pginfo array when the VM is created with a size sufficient
for up to 64GB of guest memory. Subsequently we will get rid of this
array and use memory associated with each memslot instead.
This moves most of the code that translates the user addresses into
host pfns (page frame numbers) out of kvmppc_prepare_vrma up one level
to kvmppc_core_prepare_memory_region. Also, instead of having to look
up the VMA for each page in order to check the page size, we now check
that the pages we get are compound pages of 16MB. However, if we are
adding memory that is mapped to an RMA, we don't bother with calling
get_user_pages_fast and instead just offset from the base pfn for the
RMA.
Typically the RMA gets added after vcpus are created, which makes it
inconvenient to have the LPCR (logical partition control register) value
in the vcpu->arch struct, since the LPCR controls whether the processor
uses RMA or VRMA for the guest. This moves the LPCR value into the
kvm->arch struct and arranges for the MER (mediated external request)
bit, which is the only bit that varies between vcpus, to be set in
assembly code when going into the guest if there is a pending external
interrupt request.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-06-29 08:25:44 +08:00
|
|
|
|
|
|
|
|
#include <asm/cputable.h>
|
|
|
|
|
#include <asm/kvm_ppc.h>
|
|
|
|
|
#include <asm/kvm_book3s.h>
|
2015-03-20 17:39:41 +08:00
|
|
|
#include <asm/archrandom.h>
|
2015-03-28 11:21:11 +08:00
|
|
|
#include <asm/xics.h>
|
KVM: PPC: Book3S HV: Use msgsnd for signalling threads on POWER8
This uses msgsnd where possible for signalling other threads within
the same core on POWER8 systems, rather than IPIs through the XICS
interrupt controller. This includes waking secondary threads to run
the guest, the interrupts generated by the virtual XICS, and the
interrupts to bring the other threads out of the guest when exiting.
Aggregated statistics from debugfs across vcpus for a guest with 32
vcpus, 8 threads/vcore, running on a POWER8, show this before the
change:
rm_entry: 3387.6ns (228 - 86600, 1008969 samples)
rm_exit: 4561.5ns (12 - 3477452, 1009402 samples)
rm_intr: 1660.0ns (12 - 553050, 3600051 samples)
and this after the change:
rm_entry: 3060.1ns (212 - 65138, 953873 samples)
rm_exit: 4244.1ns (12 - 9693408, 954331 samples)
rm_intr: 1342.3ns (12 - 1104718, 3405326 samples)
for a test of booting Fedora 20 big-endian to the login prompt.
The time taken for a H_PROD hcall (which is handled in the host
kernel) went down from about 35 microseconds to about 16 microseconds
with this change.
The noinline added to kvmppc_run_core turned out to be necessary for
good performance, at least with gcc 4.9.2 as packaged with Fedora 21
and a little-endian POWER8 host.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2015-03-28 11:21:12 +08:00
|
|
|
#include <asm/dbell.h>
|
|
|
|
|
#include <asm/cputhreads.h>
|
KVM: PPC: Allocate RMAs (Real Mode Areas) at boot for use by guests
This adds infrastructure which will be needed to allow book3s_hv KVM to
run on older POWER processors, including PPC970, which don't support
the Virtual Real Mode Area (VRMA) facility, but only the Real Mode
Offset (RMO) facility. These processors require a physically
contiguous, aligned area of memory for each guest. When the guest does
an access in real mode (MMU off), the address is compared against a
limit value, and if it is lower, the address is ORed with an offset
value (from the Real Mode Offset Register (RMOR)) and the result becomes
the real address for the access. The size of the RMA has to be one of
a set of supported values, which usually includes 64MB, 128MB, 256MB
and some larger powers of 2.
Since we are unlikely to be able to allocate 64MB or more of physically
contiguous memory after the kernel has been running for a while, we
allocate a pool of RMAs at boot time using the bootmem allocator. The
size and number of the RMAs can be set using the kvm_rma_size=xx and
kvm_rma_count=xx kernel command line options.
KVM exports a new capability, KVM_CAP_PPC_RMA, to signal the availability
of the pool of preallocated RMAs. The capability value is 1 if the
processor can use an RMA but doesn't require one (because it supports
the VRMA facility), or 2 if the processor requires an RMA for each guest.
This adds a new ioctl, KVM_ALLOCATE_RMA, which allocates an RMA from the
pool and returns a file descriptor which can be used to map the RMA. It
also returns the size of the RMA in the argument structure.
Having an RMA means we will get multiple KMV_SET_USER_MEMORY_REGION
ioctl calls from userspace. To cope with this, we now preallocate the
kvm->arch.ram_pginfo array when the VM is created with a size sufficient
for up to 64GB of guest memory. Subsequently we will get rid of this
array and use memory associated with each memslot instead.
This moves most of the code that translates the user addresses into
host pfns (page frame numbers) out of kvmppc_prepare_vrma up one level
to kvmppc_core_prepare_memory_region. Also, instead of having to look
up the VMA for each page in order to check the page size, we now check
that the pages we get are compound pages of 16MB. However, if we are
adding memory that is mapped to an RMA, we don't bother with calling
get_user_pages_fast and instead just offset from the base pfn for the
RMA.
Typically the RMA gets added after vcpus are created, which makes it
inconvenient to have the LPCR (logical partition control register) value
in the vcpu->arch struct, since the LPCR controls whether the processor
uses RMA or VRMA for the guest. This moves the LPCR value into the
kvm->arch struct and arranges for the MER (mediated external request)
bit, which is the only bit that varies between vcpus, to be set in
assembly code when going into the guest if there is a pending external
interrupt request.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-06-29 08:25:44 +08:00
|
|
|
|
2014-08-07 07:05:28 +08:00
|
|
|
#define KVM_CMA_CHUNK_ORDER 18
|
|
|
|
|
|
2013-07-02 13:45:16 +08:00
|
|
|
/*
|
|
|
|
|
* Hash page table alignment on newer cpus(CPU_FTR_ARCH_206)
|
|
|
|
|
* should be power of 2.
|
|
|
|
|
*/
|
|
|
|
|
#define HPT_ALIGN_PAGES ((1 << 18) >> PAGE_SHIFT) /* 256k */
|
|
|
|
|
/*
|
|
|
|
|
* By default we reserve 5% of memory for hash pagetable allocation.
|
|
|
|
|
*/
|
|
|
|
|
static unsigned long kvm_cma_resv_ratio = 5;
|
KVM: PPC: Allocate RMAs (Real Mode Areas) at boot for use by guests
This adds infrastructure which will be needed to allow book3s_hv KVM to
run on older POWER processors, including PPC970, which don't support
the Virtual Real Mode Area (VRMA) facility, but only the Real Mode
Offset (RMO) facility. These processors require a physically
contiguous, aligned area of memory for each guest. When the guest does
an access in real mode (MMU off), the address is compared against a
limit value, and if it is lower, the address is ORed with an offset
value (from the Real Mode Offset Register (RMOR)) and the result becomes
the real address for the access. The size of the RMA has to be one of
a set of supported values, which usually includes 64MB, 128MB, 256MB
and some larger powers of 2.
Since we are unlikely to be able to allocate 64MB or more of physically
contiguous memory after the kernel has been running for a while, we
allocate a pool of RMAs at boot time using the bootmem allocator. The
size and number of the RMAs can be set using the kvm_rma_size=xx and
kvm_rma_count=xx kernel command line options.
KVM exports a new capability, KVM_CAP_PPC_RMA, to signal the availability
of the pool of preallocated RMAs. The capability value is 1 if the
processor can use an RMA but doesn't require one (because it supports
the VRMA facility), or 2 if the processor requires an RMA for each guest.
This adds a new ioctl, KVM_ALLOCATE_RMA, which allocates an RMA from the
pool and returns a file descriptor which can be used to map the RMA. It
also returns the size of the RMA in the argument structure.
Having an RMA means we will get multiple KMV_SET_USER_MEMORY_REGION
ioctl calls from userspace. To cope with this, we now preallocate the
kvm->arch.ram_pginfo array when the VM is created with a size sufficient
for up to 64GB of guest memory. Subsequently we will get rid of this
array and use memory associated with each memslot instead.
This moves most of the code that translates the user addresses into
host pfns (page frame numbers) out of kvmppc_prepare_vrma up one level
to kvmppc_core_prepare_memory_region. Also, instead of having to look
up the VMA for each page in order to check the page size, we now check
that the pages we get are compound pages of 16MB. However, if we are
adding memory that is mapped to an RMA, we don't bother with calling
get_user_pages_fast and instead just offset from the base pfn for the
RMA.
Typically the RMA gets added after vcpus are created, which makes it
inconvenient to have the LPCR (logical partition control register) value
in the vcpu->arch struct, since the LPCR controls whether the processor
uses RMA or VRMA for the guest. This moves the LPCR value into the
kvm->arch struct and arranges for the MER (mediated external request)
bit, which is the only bit that varies between vcpus, to be set in
assembly code when going into the guest if there is a pending external
interrupt request.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2011-06-29 08:25:44 +08:00
|
|
|
|
2014-08-07 07:05:28 +08:00
|
|
|
static struct cma *kvm_cma;
|
|
|
|
|
|
2013-07-02 13:45:16 +08:00
|
|
|
static int __init early_parse_kvm_cma_resv(char *p)
|
2012-01-17 02:12:11 +08:00
|
|
|
{
|
2013-07-02 13:45:16 +08:00
|
|
|
pr_debug("%s(%s)\n", __func__, p);
|
2012-01-17 02:12:11 +08:00
|
|
|
if (!p)
|
2013-07-02 13:45:16 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
return kstrtoul(p, 0, &kvm_cma_resv_ratio);
|
2012-01-17 02:12:11 +08:00
|
|
|
}
|
2013-07-02 13:45:16 +08:00
|
|
|
early_param("kvm_cma_resv_ratio", early_parse_kvm_cma_resv);
|
2012-01-17 02:12:11 +08:00
|
|
|
|
2013-07-02 13:45:16 +08:00
|
|
|
struct page *kvm_alloc_hpt(unsigned long nr_pages)
|
2012-01-17 02:12:11 +08:00
|
|
|
{
|
2014-08-14 13:03:07 +08:00
|
|
|
VM_BUG_ON(order_base_2(nr_pages) < KVM_CMA_CHUNK_ORDER - PAGE_SHIFT);
|
2014-08-07 07:05:28 +08:00
|
|
|
|
2014-12-03 10:30:38 +08:00
|
|
|
return cma_alloc(kvm_cma, nr_pages, order_base_2(HPT_ALIGN_PAGES));
|
2012-01-17 02:12:11 +08:00
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(kvm_alloc_hpt);
|
|
|
|
|
|
2013-07-02 13:45:16 +08:00
|
|
|
void kvm_release_hpt(struct page *page, unsigned long nr_pages)
|
2012-01-17 02:12:11 +08:00
|
|
|
{
|
2014-08-07 07:05:28 +08:00
|
|
|
cma_release(kvm_cma, page, nr_pages);
|
2012-01-17 02:12:11 +08:00
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(kvm_release_hpt);
|
|
|
|
|
|
2013-07-02 13:45:16 +08:00
|
|
|
/**
|
|
|
|
|
* kvm_cma_reserve() - reserve area for kvm hash pagetable
|
|
|
|
|
*
|
|
|
|
|
* This function reserves memory from early allocator. It should be
|
2014-09-17 20:15:34 +08:00
|
|
|
* called by arch specific code once the memblock allocator
|
2013-07-02 13:45:16 +08:00
|
|
|
* has been activated and all other subsystems have already allocated/reserved
|
|
|
|
|
* memory.
|
|
|
|
|
*/
|
|
|
|
|
void __init kvm_cma_reserve(void)
|
|
|
|
|
{
|
|
|
|
|
unsigned long align_size;
|
|
|
|
|
struct memblock_region *reg;
|
|
|
|
|
phys_addr_t selected_size = 0;
|
2014-09-29 16:02:38 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We need CMA reservation only when we are in HV mode
|
|
|
|
|
*/
|
|
|
|
|
if (!cpu_has_feature(CPU_FTR_HVMODE))
|
|
|
|
|
return;
|
2013-07-02 13:45:16 +08:00
|
|
|
/*
|
|
|
|
|
* We cannot use memblock_phys_mem_size() here, because
|
|
|
|
|
* memblock_analyze() has not been called yet.
|
|
|
|
|
*/
|
|
|
|
|
for_each_memblock(memory, reg)
|
|
|
|
|
selected_size += memblock_region_memory_end_pfn(reg) -
|
|
|
|
|
memblock_region_memory_base_pfn(reg);
|
|
|
|
|
|
|
|
|
|
selected_size = (selected_size * kvm_cma_resv_ratio / 100) << PAGE_SHIFT;
|
|
|
|
|
if (selected_size) {
|
|
|
|
|
pr_debug("%s: reserving %ld MiB for global area\n", __func__,
|
|
|
|
|
(unsigned long)selected_size / SZ_1M);
|
2014-12-03 10:30:38 +08:00
|
|
|
align_size = HPT_ALIGN_PAGES << PAGE_SHIFT;
|
2014-08-07 07:05:32 +08:00
|
|
|
cma_declare_contiguous(0, selected_size, 0, align_size,
|
|
|
|
|
KVM_CMA_CHUNK_ORDER - PAGE_SHIFT, false, &kvm_cma);
|
2013-07-02 13:45:16 +08:00
|
|
|
}
|
|
|
|
|
}
|
2014-05-23 16:15:25 +08:00
|
|
|
|
2014-12-03 10:30:40 +08:00
|
|
|
/*
|
|
|
|
|
* Real-mode H_CONFER implementation.
|
|
|
|
|
* We check if we are the only vcpu out of this virtual core
|
|
|
|
|
* still running in the guest and not ceded. If so, we pop up
|
|
|
|
|
* to the virtual-mode implementation; if not, just return to
|
|
|
|
|
* the guest.
|
|
|
|
|
*/
|
|
|
|
|
long int kvmppc_rm_h_confer(struct kvm_vcpu *vcpu, int target,
|
|
|
|
|
unsigned int yield_count)
|
|
|
|
|
{
|
KVM: PPC: Book3S HV: Make use of unused threads when running guests
When running a virtual core of a guest that is configured with fewer
threads per core than the physical cores have, the extra physical
threads are currently unused. This makes it possible to use them to
run one or more other virtual cores from the same guest when certain
conditions are met. This applies on POWER7, and on POWER8 to guests
with one thread per virtual core. (It doesn't apply to POWER8 guests
with multiple threads per vcore because they require a 1-1 virtual to
physical thread mapping in order to be able to use msgsndp and the
TIR.)
The idea is that we maintain a list of preempted vcores for each
physical cpu (i.e. each core, since the host runs single-threaded).
Then, when a vcore is about to run, it checks to see if there are
any vcores on the list for its physical cpu that could be
piggybacked onto this vcore's execution. If so, those additional
vcores are put into state VCORE_PIGGYBACK and their runnable VCPU
threads are started as well as the original vcore, which is called
the master vcore.
After the vcores have exited the guest, the extra ones are put back
onto the preempted list if any of their VCPUs are still runnable and
not idle.
This means that vcpu->arch.ptid is no longer necessarily the same as
the physical thread that the vcpu runs on. In order to make it easier
for code that wants to send an IPI to know which CPU to target, we
now store that in a new field in struct vcpu_arch, called thread_cpu.
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2015-06-24 19:18:03 +08:00
|
|
|
struct kvmppc_vcore *vc = local_paca->kvm_hstate.kvm_vcore;
|
|
|
|
|
int ptid = local_paca->kvm_hstate.ptid;
|
2014-12-03 10:30:40 +08:00
|
|
|
int threads_running;
|
|
|
|
|
int threads_ceded;
|
|
|
|
|
int threads_conferring;
|
|
|
|
|
u64 stop = get_tb() + 10 * tb_ticks_per_usec;
|
|
|
|
|
int rv = H_SUCCESS; /* => don't yield */
|
|
|
|
|
|
KVM: PPC: Book3S HV: Make use of unused threads when running guests
When running a virtual core of a guest that is configured with fewer
threads per core than the physical cores have, the extra physical
threads are currently unused. This makes it possible to use them to
run one or more other virtual cores from the same guest when certain
conditions are met. This applies on POWER7, and on POWER8 to guests
with one thread per virtual core. (It doesn't apply to POWER8 guests
with multiple threads per vcore because they require a 1-1 virtual to
physical thread mapping in order to be able to use msgsndp and the
TIR.)
The idea is that we maintain a list of preempted vcores for each
physical cpu (i.e. each core, since the host runs single-threaded).
Then, when a vcore is about to run, it checks to see if there are
any vcores on the list for its physical cpu that could be
piggybacked onto this vcore's execution. If so, those additional
vcores are put into state VCORE_PIGGYBACK and their runnable VCPU
threads are started as well as the original vcore, which is called
the master vcore.
After the vcores have exited the guest, the extra ones are put back
onto the preempted list if any of their VCPUs are still runnable and
not idle.
This means that vcpu->arch.ptid is no longer necessarily the same as
the physical thread that the vcpu runs on. In order to make it easier
for code that wants to send an IPI to know which CPU to target, we
now store that in a new field in struct vcpu_arch, called thread_cpu.
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2015-06-24 19:18:03 +08:00
|
|
|
set_bit(ptid, &vc->conferring_threads);
|
2015-03-28 11:21:09 +08:00
|
|
|
while ((get_tb() < stop) && !VCORE_IS_EXITING(vc)) {
|
|
|
|
|
threads_running = VCORE_ENTRY_MAP(vc);
|
|
|
|
|
threads_ceded = vc->napping_threads;
|
|
|
|
|
threads_conferring = vc->conferring_threads;
|
|
|
|
|
if ((threads_ceded | threads_conferring) == threads_running) {
|
2014-12-03 10:30:40 +08:00
|
|
|
rv = H_TOO_HARD; /* => do yield */
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
KVM: PPC: Book3S HV: Make use of unused threads when running guests
When running a virtual core of a guest that is configured with fewer
threads per core than the physical cores have, the extra physical
threads are currently unused. This makes it possible to use them to
run one or more other virtual cores from the same guest when certain
conditions are met. This applies on POWER7, and on POWER8 to guests
with one thread per virtual core. (It doesn't apply to POWER8 guests
with multiple threads per vcore because they require a 1-1 virtual to
physical thread mapping in order to be able to use msgsndp and the
TIR.)
The idea is that we maintain a list of preempted vcores for each
physical cpu (i.e. each core, since the host runs single-threaded).
Then, when a vcore is about to run, it checks to see if there are
any vcores on the list for its physical cpu that could be
piggybacked onto this vcore's execution. If so, those additional
vcores are put into state VCORE_PIGGYBACK and their runnable VCPU
threads are started as well as the original vcore, which is called
the master vcore.
After the vcores have exited the guest, the extra ones are put back
onto the preempted list if any of their VCPUs are still runnable and
not idle.
This means that vcpu->arch.ptid is no longer necessarily the same as
the physical thread that the vcpu runs on. In order to make it easier
for code that wants to send an IPI to know which CPU to target, we
now store that in a new field in struct vcpu_arch, called thread_cpu.
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2015-06-24 19:18:03 +08:00
|
|
|
clear_bit(ptid, &vc->conferring_threads);
|
2014-12-03 10:30:40 +08:00
|
|
|
return rv;
|
|
|
|
|
}
|
|
|
|
|
|
2014-05-23 16:15:25 +08:00
|
|
|
/*
|
|
|
|
|
* When running HV mode KVM we need to block certain operations while KVM VMs
|
|
|
|
|
* exist in the system. We use a counter of VMs to track this.
|
|
|
|
|
*
|
|
|
|
|
* One of the operations we need to block is onlining of secondaries, so we
|
|
|
|
|
* protect hv_vm_count with get/put_online_cpus().
|
|
|
|
|
*/
|
|
|
|
|
static atomic_t hv_vm_count;
|
|
|
|
|
|
|
|
|
|
void kvm_hv_vm_activated(void)
|
|
|
|
|
{
|
|
|
|
|
get_online_cpus();
|
|
|
|
|
atomic_inc(&hv_vm_count);
|
|
|
|
|
put_online_cpus();
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(kvm_hv_vm_activated);
|
|
|
|
|
|
|
|
|
|
void kvm_hv_vm_deactivated(void)
|
|
|
|
|
{
|
|
|
|
|
get_online_cpus();
|
|
|
|
|
atomic_dec(&hv_vm_count);
|
|
|
|
|
put_online_cpus();
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(kvm_hv_vm_deactivated);
|
|
|
|
|
|
|
|
|
|
bool kvm_hv_mode_active(void)
|
|
|
|
|
{
|
|
|
|
|
return atomic_read(&hv_vm_count) != 0;
|
|
|
|
|
}
|
2014-06-02 09:03:00 +08:00
|
|
|
|
|
|
|
|
extern int hcall_real_table[], hcall_real_table_end[];
|
|
|
|
|
|
|
|
|
|
int kvmppc_hcall_impl_hv_realmode(unsigned long cmd)
|
|
|
|
|
{
|
|
|
|
|
cmd /= 4;
|
|
|
|
|
if (cmd < hcall_real_table_end - hcall_real_table &&
|
|
|
|
|
hcall_real_table[cmd])
|
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(kvmppc_hcall_impl_hv_realmode);
|
2015-03-20 17:39:41 +08:00
|
|
|
|
|
|
|
|
int kvmppc_hwrng_present(void)
|
|
|
|
|
{
|
|
|
|
|
return powernv_hwrng_present();
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(kvmppc_hwrng_present);
|
|
|
|
|
|
|
|
|
|
long kvmppc_h_random(struct kvm_vcpu *vcpu)
|
|
|
|
|
{
|
|
|
|
|
if (powernv_get_random_real_mode(&vcpu->arch.gpr[4]))
|
|
|
|
|
return H_SUCCESS;
|
|
|
|
|
|
|
|
|
|
return H_HARDWARE;
|
|
|
|
|
}
|
2015-03-28 11:21:11 +08:00
|
|
|
|
|
|
|
|
static inline void rm_writeb(unsigned long paddr, u8 val)
|
|
|
|
|
{
|
|
|
|
|
__asm__ __volatile__("stbcix %0,0,%1"
|
|
|
|
|
: : "r" (val), "r" (paddr) : "memory");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
KVM: PPC: Book3S HV: Use msgsnd for signalling threads on POWER8
This uses msgsnd where possible for signalling other threads within
the same core on POWER8 systems, rather than IPIs through the XICS
interrupt controller. This includes waking secondary threads to run
the guest, the interrupts generated by the virtual XICS, and the
interrupts to bring the other threads out of the guest when exiting.
Aggregated statistics from debugfs across vcpus for a guest with 32
vcpus, 8 threads/vcore, running on a POWER8, show this before the
change:
rm_entry: 3387.6ns (228 - 86600, 1008969 samples)
rm_exit: 4561.5ns (12 - 3477452, 1009402 samples)
rm_intr: 1660.0ns (12 - 553050, 3600051 samples)
and this after the change:
rm_entry: 3060.1ns (212 - 65138, 953873 samples)
rm_exit: 4244.1ns (12 - 9693408, 954331 samples)
rm_intr: 1342.3ns (12 - 1104718, 3405326 samples)
for a test of booting Fedora 20 big-endian to the login prompt.
The time taken for a H_PROD hcall (which is handled in the host
kernel) went down from about 35 microseconds to about 16 microseconds
with this change.
The noinline added to kvmppc_run_core turned out to be necessary for
good performance, at least with gcc 4.9.2 as packaged with Fedora 21
and a little-endian POWER8 host.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2015-03-28 11:21:12 +08:00
|
|
|
* Send an interrupt or message to another CPU.
|
2015-03-28 11:21:11 +08:00
|
|
|
* This can only be called in real mode.
|
|
|
|
|
* The caller needs to include any barrier needed to order writes
|
|
|
|
|
* to memory vs. the IPI/message.
|
|
|
|
|
*/
|
|
|
|
|
void kvmhv_rm_send_ipi(int cpu)
|
|
|
|
|
{
|
|
|
|
|
unsigned long xics_phys;
|
|
|
|
|
|
KVM: PPC: Book3S HV: Use msgsnd for signalling threads on POWER8
This uses msgsnd where possible for signalling other threads within
the same core on POWER8 systems, rather than IPIs through the XICS
interrupt controller. This includes waking secondary threads to run
the guest, the interrupts generated by the virtual XICS, and the
interrupts to bring the other threads out of the guest when exiting.
Aggregated statistics from debugfs across vcpus for a guest with 32
vcpus, 8 threads/vcore, running on a POWER8, show this before the
change:
rm_entry: 3387.6ns (228 - 86600, 1008969 samples)
rm_exit: 4561.5ns (12 - 3477452, 1009402 samples)
rm_intr: 1660.0ns (12 - 553050, 3600051 samples)
and this after the change:
rm_entry: 3060.1ns (212 - 65138, 953873 samples)
rm_exit: 4244.1ns (12 - 9693408, 954331 samples)
rm_intr: 1342.3ns (12 - 1104718, 3405326 samples)
for a test of booting Fedora 20 big-endian to the login prompt.
The time taken for a H_PROD hcall (which is handled in the host
kernel) went down from about 35 microseconds to about 16 microseconds
with this change.
The noinline added to kvmppc_run_core turned out to be necessary for
good performance, at least with gcc 4.9.2 as packaged with Fedora 21
and a little-endian POWER8 host.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2015-03-28 11:21:12 +08:00
|
|
|
/* On POWER8 for IPIs to threads in the same core, use msgsnd */
|
|
|
|
|
if (cpu_has_feature(CPU_FTR_ARCH_207S) &&
|
|
|
|
|
cpu_first_thread_sibling(cpu) ==
|
|
|
|
|
cpu_first_thread_sibling(raw_smp_processor_id())) {
|
|
|
|
|
unsigned long msg = PPC_DBELL_TYPE(PPC_DBELL_SERVER);
|
|
|
|
|
msg |= cpu_thread_in_core(cpu);
|
|
|
|
|
__asm__ __volatile__ (PPC_MSGSND(%0) : : "r" (msg));
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Else poke the target with an IPI */
|
2015-03-28 11:21:11 +08:00
|
|
|
xics_phys = paca[cpu].kvm_hstate.xics_phys;
|
|
|
|
|
rm_writeb(xics_phys + XICS_MFRR, IPI_PRIORITY);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* The following functions are called from the assembly code
|
|
|
|
|
* in book3s_hv_rmhandlers.S.
|
|
|
|
|
*/
|
|
|
|
|
static void kvmhv_interrupt_vcore(struct kvmppc_vcore *vc, int active)
|
|
|
|
|
{
|
|
|
|
|
int cpu = vc->pcpu;
|
|
|
|
|
|
|
|
|
|
/* Order setting of exit map vs. msgsnd/IPI */
|
|
|
|
|
smp_mb();
|
|
|
|
|
for (; active; active >>= 1, ++cpu)
|
|
|
|
|
if (active & 1)
|
|
|
|
|
kvmhv_rm_send_ipi(cpu);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void kvmhv_commence_exit(int trap)
|
|
|
|
|
{
|
|
|
|
|
struct kvmppc_vcore *vc = local_paca->kvm_hstate.kvm_vcore;
|
|
|
|
|
int ptid = local_paca->kvm_hstate.ptid;
|
KVM: PPC: Book3S HV: Implement dynamic micro-threading on POWER8
This builds on the ability to run more than one vcore on a physical
core by using the micro-threading (split-core) modes of the POWER8
chip. Previously, only vcores from the same VM could be run together,
and (on POWER8) only if they had just one thread per core. With the
ability to split the core on guest entry and unsplit it on guest exit,
we can run up to 8 vcpu threads from up to 4 different VMs, and we can
run multiple vcores with 2 or 4 vcpus per vcore.
Dynamic micro-threading is only available if the static configuration
of the cores is whole-core mode (unsplit), and only on POWER8.
To manage this, we introduce a new kvm_split_mode struct which is
shared across all of the subcores in the core, with a pointer in the
paca on each thread. In addition we extend the core_info struct to
have information on each subcore. When deciding whether to add a
vcore to the set already on the core, we now have two possibilities:
(a) piggyback the vcore onto an existing subcore, or (b) start a new
subcore.
Currently, when any vcpu needs to exit the guest and switch to host
virtual mode, we interrupt all the threads in all subcores and switch
the core back to whole-core mode. It may be possible in future to
allow some of the subcores to keep executing in the guest while
subcore 0 switches to the host, but that is not implemented in this
patch.
This adds a module parameter called dynamic_mt_modes which controls
which micro-threading (split-core) modes the code will consider, as a
bitmap. In other words, if it is 0, no micro-threading mode is
considered; if it is 2, only 2-way micro-threading is considered; if
it is 4, only 4-way, and if it is 6, both 2-way and 4-way
micro-threading mode will be considered. The default is 6.
With this, we now have secondary threads which are the primary thread
for their subcore and therefore need to do the MMU switch. These
threads will need to be started even if they have no vcpu to run, so
we use the vcore pointer in the PACA rather than the vcpu pointer to
trigger them.
It is now possible for thread 0 to find that an exit has been
requested before it gets to switch the subcore state to the guest. In
that case we haven't added the guest's timebase offset to the
timebase, so we need to be careful not to subtract the offset in the
guest exit path. In fact we just skip the whole path that switches
back to host context, since we haven't switched to the guest context.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2015-07-02 18:38:16 +08:00
|
|
|
struct kvm_split_mode *sip = local_paca->kvm_hstate.kvm_split_mode;
|
|
|
|
|
int me, ee, i;
|
2015-03-28 11:21:11 +08:00
|
|
|
|
|
|
|
|
/* Set our bit in the threads-exiting-guest map in the 0xff00
|
|
|
|
|
bits of vcore->entry_exit_map */
|
|
|
|
|
me = 0x100 << ptid;
|
|
|
|
|
do {
|
|
|
|
|
ee = vc->entry_exit_map;
|
|
|
|
|
} while (cmpxchg(&vc->entry_exit_map, ee, ee | me) != ee);
|
|
|
|
|
|
|
|
|
|
/* Are we the first here? */
|
|
|
|
|
if ((ee >> 8) != 0)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Trigger the other threads in this vcore to exit the guest.
|
|
|
|
|
* If this is a hypervisor decrementer interrupt then they
|
|
|
|
|
* will be already on their way out of the guest.
|
|
|
|
|
*/
|
|
|
|
|
if (trap != BOOK3S_INTERRUPT_HV_DECREMENTER)
|
|
|
|
|
kvmhv_interrupt_vcore(vc, ee & ~(1 << ptid));
|
KVM: PPC: Book3S HV: Implement dynamic micro-threading on POWER8
This builds on the ability to run more than one vcore on a physical
core by using the micro-threading (split-core) modes of the POWER8
chip. Previously, only vcores from the same VM could be run together,
and (on POWER8) only if they had just one thread per core. With the
ability to split the core on guest entry and unsplit it on guest exit,
we can run up to 8 vcpu threads from up to 4 different VMs, and we can
run multiple vcores with 2 or 4 vcpus per vcore.
Dynamic micro-threading is only available if the static configuration
of the cores is whole-core mode (unsplit), and only on POWER8.
To manage this, we introduce a new kvm_split_mode struct which is
shared across all of the subcores in the core, with a pointer in the
paca on each thread. In addition we extend the core_info struct to
have information on each subcore. When deciding whether to add a
vcore to the set already on the core, we now have two possibilities:
(a) piggyback the vcore onto an existing subcore, or (b) start a new
subcore.
Currently, when any vcpu needs to exit the guest and switch to host
virtual mode, we interrupt all the threads in all subcores and switch
the core back to whole-core mode. It may be possible in future to
allow some of the subcores to keep executing in the guest while
subcore 0 switches to the host, but that is not implemented in this
patch.
This adds a module parameter called dynamic_mt_modes which controls
which micro-threading (split-core) modes the code will consider, as a
bitmap. In other words, if it is 0, no micro-threading mode is
considered; if it is 2, only 2-way micro-threading is considered; if
it is 4, only 4-way, and if it is 6, both 2-way and 4-way
micro-threading mode will be considered. The default is 6.
With this, we now have secondary threads which are the primary thread
for their subcore and therefore need to do the MMU switch. These
threads will need to be started even if they have no vcpu to run, so
we use the vcore pointer in the PACA rather than the vcpu pointer to
trigger them.
It is now possible for thread 0 to find that an exit has been
requested before it gets to switch the subcore state to the guest. In
that case we haven't added the guest's timebase offset to the
timebase, so we need to be careful not to subtract the offset in the
guest exit path. In fact we just skip the whole path that switches
back to host context, since we haven't switched to the guest context.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2015-07-02 18:38:16 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If we are doing dynamic micro-threading, interrupt the other
|
|
|
|
|
* subcores to pull them out of their guests too.
|
|
|
|
|
*/
|
|
|
|
|
if (!sip)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < MAX_SUBCORES; ++i) {
|
|
|
|
|
vc = sip->master_vcs[i];
|
|
|
|
|
if (!vc)
|
|
|
|
|
break;
|
|
|
|
|
do {
|
|
|
|
|
ee = vc->entry_exit_map;
|
|
|
|
|
/* Already asked to exit? */
|
|
|
|
|
if ((ee >> 8) != 0)
|
|
|
|
|
break;
|
|
|
|
|
} while (cmpxchg(&vc->entry_exit_map, ee,
|
|
|
|
|
ee | VCORE_EXIT_REQ) != ee);
|
|
|
|
|
if ((ee >> 8) == 0)
|
|
|
|
|
kvmhv_interrupt_vcore(vc, ee);
|
|
|
|
|
}
|
2015-03-28 11:21:11 +08:00
|
|
|
}
|