2019-06-04 16:11:33 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
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>
|
|
|
|
|
*/
|
|
|
|
|
|
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
|
|
|
|
KVM: PPC: Book3S HV: Send kvmppc_bad_interrupt NMIs to Linux handlers
It's possible to take a SRESET or MCE in these paths due to a bug
in the host code or a NMI IPI, etc. A recent bug attempting to load
a virtual address from real mode gave th complete but cryptic error,
abridged:
Oops: Bad interrupt in KVM entry/exit code, sig: 6 [#1]
LE SMP NR_CPUS=2048 NUMA PowerNV
CPU: 53 PID: 6582 Comm: qemu-system-ppc Not tainted
NIP: c0000000000155ac LR: c0000000000c2430 CTR: c000000000015580
REGS: c000000fff76dd80 TRAP: 0200 Not tainted
MSR: 9000000000201003 <SF,HV,ME,RI,LE> CR: 48082222 XER: 00000000
CFAR: 0000000102900ef0 DAR: d00017fffd941a28 DSISR: 00000040 SOFTE: 3
NIP [c0000000000155ac] perf_trace_tlbie+0x2c/0x1a0
LR [c0000000000c2430] do_tlbies+0x230/0x2f0
Sending the NMIs through the Linux handlers gives a nicer output:
Severe Machine check interrupt [Not recovered]
NIP [c0000000000155ac]: perf_trace_tlbie+0x2c/0x1a0
Initiator: CPU
Error type: Real address [Load (bad)]
Effective address: d00017fffcc01a28
opal: Machine check interrupt unrecoverable: MSR(RI=0)
opal: Hardware platform error: Unrecoverable Machine Check exception
CPU: 0 PID: 6700 Comm: qemu-system-ppc Tainted: G M
NIP: c0000000000155ac LR: c0000000000c23c0 CTR: c000000000015580
REGS: c000000fff9e9d80 TRAP: 0200 Tainted: G M
MSR: 9000000000201001 <SF,HV,ME,LE> CR: 48082222 XER: 00000000
CFAR: 000000010cbc1a30 DAR: d00017fffcc01a28 DSISR: 00000040 SOFTE: 3
NIP [c0000000000155ac] perf_trace_tlbie+0x2c/0x1a0
LR [c0000000000c23c0] do_tlbies+0x1c0/0x280
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2018-05-18 01:49:44 +08:00
|
|
|
#include <asm/asm-prototypes.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>
|
2021-01-30 21:08:38 +08:00
|
|
|
#include <asm/interrupt.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/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>
|
2017-04-05 15:54:50 +08:00
|
|
|
#include <asm/xive.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>
|
2016-08-19 13:35:46 +08:00
|
|
|
#include <asm/io.h>
|
KVM: PPC: Book3S HV: Use OPAL XICS emulation on POWER9
POWER9 includes a new interrupt controller, called XIVE, which is
quite different from the XICS interrupt controller on POWER7 and
POWER8 machines. KVM-HV accesses the XICS directly in several places
in order to send and clear IPIs and handle interrupts from PCI
devices being passed through to the guest.
In order to make the transition to XIVE easier, OPAL firmware will
include an emulation of XICS on top of XIVE. Access to the emulated
XICS is via OPAL calls. The one complication is that the EOI
(end-of-interrupt) function can now return a value indicating that
another interrupt is pending; in this case, the XIVE will not signal
an interrupt in hardware to the CPU, and software is supposed to
acknowledge the new interrupt without waiting for another interrupt
to be delivered in hardware.
This adapts KVM-HV to use the OPAL calls on machines where there is
no XICS hardware. When there is no XICS, we look for a device-tree
node with "ibm,opal-intc" in its compatible property, which is how
OPAL indicates that it provides XICS emulation.
In order to handle the EOI return value, kvmppc_read_intr() has
become kvmppc_read_one_intr(), with a boolean variable passed by
reference which can be set by the EOI functions to indicate that
another interrupt is pending. The new kvmppc_read_intr() keeps
calling kvmppc_read_one_intr() until there are no more interrupts
to process. The return value from kvmppc_read_intr() is the
largest non-zero value of the returns from kvmppc_read_one_intr().
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-18 06:02:08 +08:00
|
|
|
#include <asm/opal.h>
|
2016-11-24 11:10:43 +08:00
|
|
|
#include <asm/smp.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
|
|
|
|
|
|
2017-04-05 15:54:56 +08:00
|
|
|
#include "book3s_xics.h"
|
|
|
|
|
#include "book3s_xive.h"
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* The XIVE module will populate these when it loads
|
|
|
|
|
*/
|
|
|
|
|
unsigned long (*__xive_vm_h_xirr)(struct kvm_vcpu *vcpu);
|
|
|
|
|
unsigned long (*__xive_vm_h_ipoll)(struct kvm_vcpu *vcpu, unsigned long server);
|
|
|
|
|
int (*__xive_vm_h_ipi)(struct kvm_vcpu *vcpu, unsigned long server,
|
|
|
|
|
unsigned long mfrr);
|
|
|
|
|
int (*__xive_vm_h_cppr)(struct kvm_vcpu *vcpu, unsigned long cppr);
|
|
|
|
|
int (*__xive_vm_h_eoi)(struct kvm_vcpu *vcpu, unsigned long xirr);
|
|
|
|
|
EXPORT_SYMBOL_GPL(__xive_vm_h_xirr);
|
|
|
|
|
EXPORT_SYMBOL_GPL(__xive_vm_h_ipoll);
|
|
|
|
|
EXPORT_SYMBOL_GPL(__xive_vm_h_ipi);
|
|
|
|
|
EXPORT_SYMBOL_GPL(__xive_vm_h_cppr);
|
|
|
|
|
EXPORT_SYMBOL_GPL(__xive_vm_h_eoi);
|
|
|
|
|
|
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
|
|
|
|
2016-12-20 13:48:59 +08:00
|
|
|
struct page *kvm_alloc_hpt_cma(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
|
|
|
|
2017-02-25 06:58:41 +08:00
|
|
|
return cma_alloc(kvm_cma, nr_pages, order_base_2(HPT_ALIGN_PAGES),
|
2018-08-18 06:48:57 +08:00
|
|
|
false);
|
2012-01-17 02:12:11 +08:00
|
|
|
}
|
2016-12-20 13:48:59 +08:00
|
|
|
EXPORT_SYMBOL_GPL(kvm_alloc_hpt_cma);
|
2012-01-17 02:12:11 +08:00
|
|
|
|
2016-12-20 13:48:59 +08:00
|
|
|
void kvm_free_hpt_cma(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
|
|
|
}
|
2016-12-20 13:48:59 +08:00
|
|
|
EXPORT_SYMBOL_GPL(kvm_free_hpt_cma);
|
2012-01-17 02:12:11 +08:00
|
|
|
|
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;
|
2020-10-14 07:57:17 +08:00
|
|
|
phys_addr_t selected_size;
|
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
|
|
|
|
2020-10-14 07:57:17 +08:00
|
|
|
selected_size = PAGE_ALIGN(memblock_phys_mem_size() * kvm_cma_resv_ratio / 100);
|
2013-07-02 13:45:16 +08:00
|
|
|
if (selected_size) {
|
2020-07-13 23:07:49 +08:00
|
|
|
pr_info("%s: reserving %ld MiB for global area\n", __func__,
|
2013-07-02 13:45:16 +08:00
|
|
|
(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,
|
2017-04-19 02:27:03 +08:00
|
|
|
KVM_CMA_CHUNK_ORDER - PAGE_SHIFT, false, "kvm_cma",
|
|
|
|
|
&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)
|
|
|
|
|
{
|
KVM: PPC: Book3S HV: Add radix checks in real-mode hypercall handlers
POWER9 running a radix guest will take some hypervisor interrupts
without going to real mode (turning off the MMU). This means that
early hypercall handlers may now be called in virtual mode. Most of
the handlers work just fine in both modes, but there are some that
can crash the host if called in virtual mode, notably the TCE (IOMMU)
hypercalls H_PUT_TCE, H_STUFF_TCE and H_PUT_TCE_INDIRECT. These
already have both a real-mode and a virtual-mode version, so we
arrange for the real-mode version to return H_TOO_HARD for radix
guests, which will result in the virtual-mode version being called.
The other hypercall which is sensitive to the MMU mode is H_RANDOM.
It doesn't have a virtual-mode version, so this adds code to enable
it to be called in either mode.
An alternative solution was considered which would refuse to call any
of the early hypercall handlers when doing a virtual-mode exit from a
radix guest. However, the XICS-on-XIVE code depends on the XICS
hypercalls being handled early even for virtual-mode exits, because
the handlers need to be called before the XIVE vCPU state has been
pulled off the hardware. Therefore that solution would have become
quite invasive and complicated, and was rejected in favour of the
simpler, though less elegant, solution presented here.
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2017-05-10 14:39:41 +08:00
|
|
|
int r;
|
|
|
|
|
|
|
|
|
|
/* Only need to do the expensive mfmsr() on radix */
|
|
|
|
|
if (kvm_is_radix(vcpu->kvm) && (mfmsr() & MSR_IR))
|
2018-05-07 14:20:07 +08:00
|
|
|
r = powernv_get_random_long(&vcpu->arch.regs.gpr[4]);
|
KVM: PPC: Book3S HV: Add radix checks in real-mode hypercall handlers
POWER9 running a radix guest will take some hypervisor interrupts
without going to real mode (turning off the MMU). This means that
early hypercall handlers may now be called in virtual mode. Most of
the handlers work just fine in both modes, but there are some that
can crash the host if called in virtual mode, notably the TCE (IOMMU)
hypercalls H_PUT_TCE, H_STUFF_TCE and H_PUT_TCE_INDIRECT. These
already have both a real-mode and a virtual-mode version, so we
arrange for the real-mode version to return H_TOO_HARD for radix
guests, which will result in the virtual-mode version being called.
The other hypercall which is sensitive to the MMU mode is H_RANDOM.
It doesn't have a virtual-mode version, so this adds code to enable
it to be called in either mode.
An alternative solution was considered which would refuse to call any
of the early hypercall handlers when doing a virtual-mode exit from a
radix guest. However, the XICS-on-XIVE code depends on the XICS
hypercalls being handled early even for virtual-mode exits, because
the handlers need to be called before the XIVE vCPU state has been
pulled off the hardware. Therefore that solution would have become
quite invasive and complicated, and was rejected in favour of the
simpler, though less elegant, solution presented here.
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2017-05-10 14:39:41 +08:00
|
|
|
else
|
2018-05-07 14:20:07 +08:00
|
|
|
r = powernv_get_random_real_mode(&vcpu->arch.regs.gpr[4]);
|
KVM: PPC: Book3S HV: Add radix checks in real-mode hypercall handlers
POWER9 running a radix guest will take some hypervisor interrupts
without going to real mode (turning off the MMU). This means that
early hypercall handlers may now be called in virtual mode. Most of
the handlers work just fine in both modes, but there are some that
can crash the host if called in virtual mode, notably the TCE (IOMMU)
hypercalls H_PUT_TCE, H_STUFF_TCE and H_PUT_TCE_INDIRECT. These
already have both a real-mode and a virtual-mode version, so we
arrange for the real-mode version to return H_TOO_HARD for radix
guests, which will result in the virtual-mode version being called.
The other hypercall which is sensitive to the MMU mode is H_RANDOM.
It doesn't have a virtual-mode version, so this adds code to enable
it to be called in either mode.
An alternative solution was considered which would refuse to call any
of the early hypercall handlers when doing a virtual-mode exit from a
radix guest. However, the XICS-on-XIVE code depends on the XICS
hypercalls being handled early even for virtual-mode exits, because
the handlers need to be called before the XIVE vCPU state has been
pulled off the hardware. Therefore that solution would have become
quite invasive and complicated, and was rejected in favour of the
simpler, though less elegant, solution presented here.
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Tested-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2017-05-10 14:39:41 +08:00
|
|
|
if (r)
|
2015-03-20 17:39:41 +08:00
|
|
|
return H_SUCCESS;
|
|
|
|
|
|
|
|
|
|
return H_HARDWARE;
|
|
|
|
|
}
|
2015-03-28 11:21:11 +08:00
|
|
|
|
|
|
|
|
/*
|
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
|
|
|
* The caller needs to include any barrier needed to order writes
|
|
|
|
|
* to memory vs. the IPI/message.
|
|
|
|
|
*/
|
|
|
|
|
void kvmhv_rm_send_ipi(int cpu)
|
|
|
|
|
{
|
2017-04-05 15:54:54 +08:00
|
|
|
void __iomem *xics_phys;
|
2016-11-18 05:47:08 +08:00
|
|
|
unsigned long msg = PPC_DBELL_TYPE(PPC_DBELL_SERVER);
|
2015-03-28 11:21:11 +08:00
|
|
|
|
2018-10-08 13:31:05 +08:00
|
|
|
/* For a nested hypervisor, use the XICS via hcall */
|
|
|
|
|
if (kvmhv_on_pseries()) {
|
|
|
|
|
unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
|
|
|
|
|
|
|
|
|
|
plpar_hcall_raw(H_IPI, retbuf, get_hard_smp_processor_id(cpu),
|
|
|
|
|
IPI_PRIORITY);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2016-11-18 05:47:08 +08:00
|
|
|
/* On POWER9 we can use msgsnd for any destination cpu. */
|
|
|
|
|
if (cpu_has_feature(CPU_FTR_ARCH_300)) {
|
|
|
|
|
msg |= get_hard_smp_processor_id(cpu);
|
|
|
|
|
__asm__ __volatile__ (PPC_MSGSND(%0) : : "r" (msg));
|
|
|
|
|
return;
|
|
|
|
|
}
|
2017-04-05 15:54:56 +08:00
|
|
|
|
2016-11-18 05:47:08 +08:00
|
|
|
/* On POWER8 for IPIs to threads in the same core, use msgsnd. */
|
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
|
|
|
if (cpu_has_feature(CPU_FTR_ARCH_207S) &&
|
|
|
|
|
cpu_first_thread_sibling(cpu) ==
|
|
|
|
|
cpu_first_thread_sibling(raw_smp_processor_id())) {
|
|
|
|
|
msg |= cpu_thread_in_core(cpu);
|
|
|
|
|
__asm__ __volatile__ (PPC_MSGSND(%0) : : "r" (msg));
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2017-04-05 15:54:50 +08:00
|
|
|
/* We should never reach this */
|
KVM: PPC: Book3S: Allow XICS emulation to work in nested hosts using XIVE
Currently, the KVM code assumes that if the host kernel is using the
XIVE interrupt controller (the new interrupt controller that first
appeared in POWER9 systems), then the in-kernel XICS emulation will
use the XIVE hardware to deliver interrupts to the guest. However,
this only works when the host is running in hypervisor mode and has
full access to all of the XIVE functionality. It doesn't work in any
nested virtualization scenario, either with PR KVM or nested-HV KVM,
because the XICS-on-XIVE code calls directly into the native-XIVE
routines, which are not initialized and cannot function correctly
because they use OPAL calls, and OPAL is not available in a guest.
This means that using the in-kernel XICS emulation in a nested
hypervisor that is using XIVE as its interrupt controller will cause a
(nested) host kernel crash. To fix this, we change most of the places
where the current code calls xive_enabled() to select between the
XICS-on-XIVE emulation and the plain XICS emulation to call a new
function, xics_on_xive(), which returns false in a guest.
However, there is a further twist. The plain XICS emulation has some
functions which are used in real mode and access the underlying XICS
controller (the interrupt controller of the host) directly. In the
case of a nested hypervisor, this means doing XICS hypercalls
directly. When the nested host is using XIVE as its interrupt
controller, these hypercalls will fail. Therefore this also adds
checks in the places where the XICS emulation wants to access the
underlying interrupt controller directly, and if that is XIVE, makes
the code use the virtual mode fallback paths, which call generic
kernel infrastructure rather than doing direct XICS access.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2019-02-04 19:07:20 +08:00
|
|
|
if (WARN_ON_ONCE(xics_on_xive()))
|
2017-04-05 15:54:50 +08:00
|
|
|
return;
|
|
|
|
|
|
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
|
|
|
/* Else poke the target with an IPI */
|
2018-02-13 23:08:12 +08:00
|
|
|
xics_phys = paca_ptrs[cpu]->kvm_hstate.xics_phys;
|
2017-02-07 13:03:17 +08:00
|
|
|
if (xics_phys)
|
2017-04-05 15:54:54 +08:00
|
|
|
__raw_rm_writeb(IPI_PRIORITY, xics_phys + XICS_MFRR);
|
KVM: PPC: Book3S HV: Use OPAL XICS emulation on POWER9
POWER9 includes a new interrupt controller, called XIVE, which is
quite different from the XICS interrupt controller on POWER7 and
POWER8 machines. KVM-HV accesses the XICS directly in several places
in order to send and clear IPIs and handle interrupts from PCI
devices being passed through to the guest.
In order to make the transition to XIVE easier, OPAL firmware will
include an emulation of XICS on top of XIVE. Access to the emulated
XICS is via OPAL calls. The one complication is that the EOI
(end-of-interrupt) function can now return a value indicating that
another interrupt is pending; in this case, the XIVE will not signal
an interrupt in hardware to the CPU, and software is supposed to
acknowledge the new interrupt without waiting for another interrupt
to be delivered in hardware.
This adapts KVM-HV to use the OPAL calls on machines where there is
no XICS hardware. When there is no XICS, we look for a device-tree
node with "ibm,opal-intc" in its compatible property, which is how
OPAL indicates that it provides XICS emulation.
In order to handle the EOI return value, kvmppc_read_intr() has
become kvmppc_read_one_intr(), with a boolean variable passed by
reference which can be set by the EOI functions to indicate that
another interrupt is pending. The new kvmppc_read_intr() keeps
calling kvmppc_read_one_intr() until there are no more interrupts
to process. The return value from kvmppc_read_intr() is the
largest non-zero value of the returns from kvmppc_read_one_intr().
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-18 06:02:08 +08:00
|
|
|
else
|
2017-02-07 13:03:17 +08:00
|
|
|
opal_int_set_mfrr(get_hard_smp_processor_id(cpu), IPI_PRIORITY);
|
2015-03-28 11:21:11 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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;
|
2021-01-18 14:28:06 +08:00
|
|
|
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) {
|
2017-06-22 13:08:42 +08:00
|
|
|
vc = sip->vc[i];
|
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 (!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
|
|
|
}
|
2015-12-18 04:59:06 +08:00
|
|
|
|
|
|
|
|
struct kvmppc_host_rm_ops *kvmppc_host_rm_ops_hv;
|
|
|
|
|
EXPORT_SYMBOL_GPL(kvmppc_host_rm_ops_hv);
|
2016-08-19 13:35:46 +08:00
|
|
|
|
KVM: PPC: Book3S HV: Handle passthrough interrupts in guest
Currently, KVM switches back to the host to handle any external
interrupt (when the interrupt is received while running in the
guest). This patch updates real-mode KVM to check if an interrupt
is generated by a passthrough adapter that is owned by this guest.
If so, the real mode KVM will directly inject the corresponding
virtual interrupt to the guest VCPU's ICS and also EOI the interrupt
in hardware. In short, the interrupt is handled entirely in real
mode in the guest context without switching back to the host.
In some rare cases, the interrupt cannot be completely handled in
real mode, for instance, a VCPU that is sleeping needs to be woken
up. In this case, KVM simply switches back to the host with trap
reason set to 0x500. This works, but it is clearly not very efficient.
A following patch will distinguish this case and handle it
correctly in the host. Note that we can use the existing
check_too_hard() routine even though we are not in a hypercall to
determine if there is unfinished business that needs to be
completed in host virtual mode.
The patch assumes that the mapping between hardware interrupt IRQ
and virtual IRQ to be injected to the guest already exists for the
PCI passthrough interrupts that need to be handled in real mode.
If the mapping does not exist, KVM falls back to the default
existing behavior.
The KVM real mode code reads mappings from the mapped array in the
passthrough IRQ map without taking any lock. We carefully order the
loads and stores of the fields in the kvmppc_irq_map data structure
using memory barriers to avoid an inconsistent mapping being seen by
the reader. Thus, although it is possible to miss a map entry, it is
not possible to read a stale value.
[paulus@ozlabs.org - get irq_chip from irq_map rather than pimap,
pulled out powernv eoi change into a separate patch, made
kvmppc_read_intr get the vcpu from the paca rather than being
passed in, rewrote the logic at the end of kvmppc_read_intr to
avoid deep indentation, simplified logic in book3s_hv_rmhandlers.S
since we were always restoring SRR0/1 anyway, get rid of the cached
array (just use the mapped array), removed the kick_all_cpus_sync()
call, clear saved_xirr PACA field when we handle the interrupt in
real mode, fix compilation with CONFIG_KVM_XICS=n.]
Signed-off-by: Suresh Warrier <warrier@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-08-19 13:35:51 +08:00
|
|
|
#ifdef CONFIG_KVM_XICS
|
|
|
|
|
static struct kvmppc_irq_map *get_irqmap(struct kvmppc_passthru_irqmap *pimap,
|
|
|
|
|
u32 xisr)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We access the mapped array here without a lock. That
|
|
|
|
|
* is safe because we never reduce the number of entries
|
|
|
|
|
* in the array and we never change the v_hwirq field of
|
|
|
|
|
* an entry once it is set.
|
|
|
|
|
*
|
|
|
|
|
* We have also carefully ordered the stores in the writer
|
|
|
|
|
* and the loads here in the reader, so that if we find a matching
|
|
|
|
|
* hwirq here, the associated GSI and irq_desc fields are valid.
|
|
|
|
|
*/
|
|
|
|
|
for (i = 0; i < pimap->n_mapped; i++) {
|
|
|
|
|
if (xisr == pimap->mapped[i].r_hwirq) {
|
|
|
|
|
/*
|
|
|
|
|
* Order subsequent reads in the caller to serialize
|
|
|
|
|
* with the writer.
|
|
|
|
|
*/
|
|
|
|
|
smp_rmb();
|
|
|
|
|
return &pimap->mapped[i];
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If we have an interrupt that's not an IPI, check if we have a
|
|
|
|
|
* passthrough adapter and if so, check if this external interrupt
|
|
|
|
|
* is for the adapter.
|
|
|
|
|
* We will attempt to deliver the IRQ directly to the target VCPU's
|
|
|
|
|
* ICP, the virtual ICP (based on affinity - the xive value in ICS).
|
|
|
|
|
*
|
|
|
|
|
* If the delivery fails or if this is not for a passthrough adapter,
|
|
|
|
|
* return to the host to handle this interrupt. We earlier
|
|
|
|
|
* saved a copy of the XIRR in the PACA, it will be picked up by
|
|
|
|
|
* the host ICP driver.
|
|
|
|
|
*/
|
KVM: PPC: Book3S HV: Use OPAL XICS emulation on POWER9
POWER9 includes a new interrupt controller, called XIVE, which is
quite different from the XICS interrupt controller on POWER7 and
POWER8 machines. KVM-HV accesses the XICS directly in several places
in order to send and clear IPIs and handle interrupts from PCI
devices being passed through to the guest.
In order to make the transition to XIVE easier, OPAL firmware will
include an emulation of XICS on top of XIVE. Access to the emulated
XICS is via OPAL calls. The one complication is that the EOI
(end-of-interrupt) function can now return a value indicating that
another interrupt is pending; in this case, the XIVE will not signal
an interrupt in hardware to the CPU, and software is supposed to
acknowledge the new interrupt without waiting for another interrupt
to be delivered in hardware.
This adapts KVM-HV to use the OPAL calls on machines where there is
no XICS hardware. When there is no XICS, we look for a device-tree
node with "ibm,opal-intc" in its compatible property, which is how
OPAL indicates that it provides XICS emulation.
In order to handle the EOI return value, kvmppc_read_intr() has
become kvmppc_read_one_intr(), with a boolean variable passed by
reference which can be set by the EOI functions to indicate that
another interrupt is pending. The new kvmppc_read_intr() keeps
calling kvmppc_read_one_intr() until there are no more interrupts
to process. The return value from kvmppc_read_intr() is the
largest non-zero value of the returns from kvmppc_read_one_intr().
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-18 06:02:08 +08:00
|
|
|
static int kvmppc_check_passthru(u32 xisr, __be32 xirr, bool *again)
|
KVM: PPC: Book3S HV: Handle passthrough interrupts in guest
Currently, KVM switches back to the host to handle any external
interrupt (when the interrupt is received while running in the
guest). This patch updates real-mode KVM to check if an interrupt
is generated by a passthrough adapter that is owned by this guest.
If so, the real mode KVM will directly inject the corresponding
virtual interrupt to the guest VCPU's ICS and also EOI the interrupt
in hardware. In short, the interrupt is handled entirely in real
mode in the guest context without switching back to the host.
In some rare cases, the interrupt cannot be completely handled in
real mode, for instance, a VCPU that is sleeping needs to be woken
up. In this case, KVM simply switches back to the host with trap
reason set to 0x500. This works, but it is clearly not very efficient.
A following patch will distinguish this case and handle it
correctly in the host. Note that we can use the existing
check_too_hard() routine even though we are not in a hypercall to
determine if there is unfinished business that needs to be
completed in host virtual mode.
The patch assumes that the mapping between hardware interrupt IRQ
and virtual IRQ to be injected to the guest already exists for the
PCI passthrough interrupts that need to be handled in real mode.
If the mapping does not exist, KVM falls back to the default
existing behavior.
The KVM real mode code reads mappings from the mapped array in the
passthrough IRQ map without taking any lock. We carefully order the
loads and stores of the fields in the kvmppc_irq_map data structure
using memory barriers to avoid an inconsistent mapping being seen by
the reader. Thus, although it is possible to miss a map entry, it is
not possible to read a stale value.
[paulus@ozlabs.org - get irq_chip from irq_map rather than pimap,
pulled out powernv eoi change into a separate patch, made
kvmppc_read_intr get the vcpu from the paca rather than being
passed in, rewrote the logic at the end of kvmppc_read_intr to
avoid deep indentation, simplified logic in book3s_hv_rmhandlers.S
since we were always restoring SRR0/1 anyway, get rid of the cached
array (just use the mapped array), removed the kick_all_cpus_sync()
call, clear saved_xirr PACA field when we handle the interrupt in
real mode, fix compilation with CONFIG_KVM_XICS=n.]
Signed-off-by: Suresh Warrier <warrier@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-08-19 13:35:51 +08:00
|
|
|
{
|
|
|
|
|
struct kvmppc_passthru_irqmap *pimap;
|
|
|
|
|
struct kvmppc_irq_map *irq_map;
|
|
|
|
|
struct kvm_vcpu *vcpu;
|
|
|
|
|
|
|
|
|
|
vcpu = local_paca->kvm_hstate.kvm_vcpu;
|
|
|
|
|
if (!vcpu)
|
|
|
|
|
return 1;
|
|
|
|
|
pimap = kvmppc_get_passthru_irqmap(vcpu->kvm);
|
|
|
|
|
if (!pimap)
|
|
|
|
|
return 1;
|
|
|
|
|
irq_map = get_irqmap(pimap, xisr);
|
|
|
|
|
if (!irq_map)
|
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
|
|
/* We're handling this interrupt, generic code doesn't need to */
|
|
|
|
|
local_paca->kvm_hstate.saved_xirr = 0;
|
|
|
|
|
|
KVM: PPC: Book3S HV: Use OPAL XICS emulation on POWER9
POWER9 includes a new interrupt controller, called XIVE, which is
quite different from the XICS interrupt controller on POWER7 and
POWER8 machines. KVM-HV accesses the XICS directly in several places
in order to send and clear IPIs and handle interrupts from PCI
devices being passed through to the guest.
In order to make the transition to XIVE easier, OPAL firmware will
include an emulation of XICS on top of XIVE. Access to the emulated
XICS is via OPAL calls. The one complication is that the EOI
(end-of-interrupt) function can now return a value indicating that
another interrupt is pending; in this case, the XIVE will not signal
an interrupt in hardware to the CPU, and software is supposed to
acknowledge the new interrupt without waiting for another interrupt
to be delivered in hardware.
This adapts KVM-HV to use the OPAL calls on machines where there is
no XICS hardware. When there is no XICS, we look for a device-tree
node with "ibm,opal-intc" in its compatible property, which is how
OPAL indicates that it provides XICS emulation.
In order to handle the EOI return value, kvmppc_read_intr() has
become kvmppc_read_one_intr(), with a boolean variable passed by
reference which can be set by the EOI functions to indicate that
another interrupt is pending. The new kvmppc_read_intr() keeps
calling kvmppc_read_one_intr() until there are no more interrupts
to process. The return value from kvmppc_read_intr() is the
largest non-zero value of the returns from kvmppc_read_one_intr().
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-18 06:02:08 +08:00
|
|
|
return kvmppc_deliver_irq_passthru(vcpu, xirr, irq_map, pimap, again);
|
KVM: PPC: Book3S HV: Handle passthrough interrupts in guest
Currently, KVM switches back to the host to handle any external
interrupt (when the interrupt is received while running in the
guest). This patch updates real-mode KVM to check if an interrupt
is generated by a passthrough adapter that is owned by this guest.
If so, the real mode KVM will directly inject the corresponding
virtual interrupt to the guest VCPU's ICS and also EOI the interrupt
in hardware. In short, the interrupt is handled entirely in real
mode in the guest context without switching back to the host.
In some rare cases, the interrupt cannot be completely handled in
real mode, for instance, a VCPU that is sleeping needs to be woken
up. In this case, KVM simply switches back to the host with trap
reason set to 0x500. This works, but it is clearly not very efficient.
A following patch will distinguish this case and handle it
correctly in the host. Note that we can use the existing
check_too_hard() routine even though we are not in a hypercall to
determine if there is unfinished business that needs to be
completed in host virtual mode.
The patch assumes that the mapping between hardware interrupt IRQ
and virtual IRQ to be injected to the guest already exists for the
PCI passthrough interrupts that need to be handled in real mode.
If the mapping does not exist, KVM falls back to the default
existing behavior.
The KVM real mode code reads mappings from the mapped array in the
passthrough IRQ map without taking any lock. We carefully order the
loads and stores of the fields in the kvmppc_irq_map data structure
using memory barriers to avoid an inconsistent mapping being seen by
the reader. Thus, although it is possible to miss a map entry, it is
not possible to read a stale value.
[paulus@ozlabs.org - get irq_chip from irq_map rather than pimap,
pulled out powernv eoi change into a separate patch, made
kvmppc_read_intr get the vcpu from the paca rather than being
passed in, rewrote the logic at the end of kvmppc_read_intr to
avoid deep indentation, simplified logic in book3s_hv_rmhandlers.S
since we were always restoring SRR0/1 anyway, get rid of the cached
array (just use the mapped array), removed the kick_all_cpus_sync()
call, clear saved_xirr PACA field when we handle the interrupt in
real mode, fix compilation with CONFIG_KVM_XICS=n.]
Signed-off-by: Suresh Warrier <warrier@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-08-19 13:35:51 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#else
|
2016-11-24 11:10:43 +08:00
|
|
|
static inline int kvmppc_check_passthru(u32 xisr, __be32 xirr, bool *again)
|
KVM: PPC: Book3S HV: Handle passthrough interrupts in guest
Currently, KVM switches back to the host to handle any external
interrupt (when the interrupt is received while running in the
guest). This patch updates real-mode KVM to check if an interrupt
is generated by a passthrough adapter that is owned by this guest.
If so, the real mode KVM will directly inject the corresponding
virtual interrupt to the guest VCPU's ICS and also EOI the interrupt
in hardware. In short, the interrupt is handled entirely in real
mode in the guest context without switching back to the host.
In some rare cases, the interrupt cannot be completely handled in
real mode, for instance, a VCPU that is sleeping needs to be woken
up. In this case, KVM simply switches back to the host with trap
reason set to 0x500. This works, but it is clearly not very efficient.
A following patch will distinguish this case and handle it
correctly in the host. Note that we can use the existing
check_too_hard() routine even though we are not in a hypercall to
determine if there is unfinished business that needs to be
completed in host virtual mode.
The patch assumes that the mapping between hardware interrupt IRQ
and virtual IRQ to be injected to the guest already exists for the
PCI passthrough interrupts that need to be handled in real mode.
If the mapping does not exist, KVM falls back to the default
existing behavior.
The KVM real mode code reads mappings from the mapped array in the
passthrough IRQ map without taking any lock. We carefully order the
loads and stores of the fields in the kvmppc_irq_map data structure
using memory barriers to avoid an inconsistent mapping being seen by
the reader. Thus, although it is possible to miss a map entry, it is
not possible to read a stale value.
[paulus@ozlabs.org - get irq_chip from irq_map rather than pimap,
pulled out powernv eoi change into a separate patch, made
kvmppc_read_intr get the vcpu from the paca rather than being
passed in, rewrote the logic at the end of kvmppc_read_intr to
avoid deep indentation, simplified logic in book3s_hv_rmhandlers.S
since we were always restoring SRR0/1 anyway, get rid of the cached
array (just use the mapped array), removed the kick_all_cpus_sync()
call, clear saved_xirr PACA field when we handle the interrupt in
real mode, fix compilation with CONFIG_KVM_XICS=n.]
Signed-off-by: Suresh Warrier <warrier@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-08-19 13:35:51 +08:00
|
|
|
{
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2016-08-19 13:35:46 +08:00
|
|
|
/*
|
|
|
|
|
* Determine what sort of external interrupt is pending (if any).
|
|
|
|
|
* Returns:
|
|
|
|
|
* 0 if no interrupt is pending
|
|
|
|
|
* 1 if an interrupt is pending that needs to be handled by the host
|
2016-08-19 13:35:52 +08:00
|
|
|
* 2 Passthrough that needs completion in the host
|
2016-08-19 13:35:46 +08:00
|
|
|
* -1 if there was a guest wakeup IPI (which has now been cleared)
|
KVM: PPC: Book3S HV: Handle passthrough interrupts in guest
Currently, KVM switches back to the host to handle any external
interrupt (when the interrupt is received while running in the
guest). This patch updates real-mode KVM to check if an interrupt
is generated by a passthrough adapter that is owned by this guest.
If so, the real mode KVM will directly inject the corresponding
virtual interrupt to the guest VCPU's ICS and also EOI the interrupt
in hardware. In short, the interrupt is handled entirely in real
mode in the guest context without switching back to the host.
In some rare cases, the interrupt cannot be completely handled in
real mode, for instance, a VCPU that is sleeping needs to be woken
up. In this case, KVM simply switches back to the host with trap
reason set to 0x500. This works, but it is clearly not very efficient.
A following patch will distinguish this case and handle it
correctly in the host. Note that we can use the existing
check_too_hard() routine even though we are not in a hypercall to
determine if there is unfinished business that needs to be
completed in host virtual mode.
The patch assumes that the mapping between hardware interrupt IRQ
and virtual IRQ to be injected to the guest already exists for the
PCI passthrough interrupts that need to be handled in real mode.
If the mapping does not exist, KVM falls back to the default
existing behavior.
The KVM real mode code reads mappings from the mapped array in the
passthrough IRQ map without taking any lock. We carefully order the
loads and stores of the fields in the kvmppc_irq_map data structure
using memory barriers to avoid an inconsistent mapping being seen by
the reader. Thus, although it is possible to miss a map entry, it is
not possible to read a stale value.
[paulus@ozlabs.org - get irq_chip from irq_map rather than pimap,
pulled out powernv eoi change into a separate patch, made
kvmppc_read_intr get the vcpu from the paca rather than being
passed in, rewrote the logic at the end of kvmppc_read_intr to
avoid deep indentation, simplified logic in book3s_hv_rmhandlers.S
since we were always restoring SRR0/1 anyway, get rid of the cached
array (just use the mapped array), removed the kick_all_cpus_sync()
call, clear saved_xirr PACA field when we handle the interrupt in
real mode, fix compilation with CONFIG_KVM_XICS=n.]
Signed-off-by: Suresh Warrier <warrier@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-08-19 13:35:51 +08:00
|
|
|
* -2 if there is PCI passthrough external interrupt that was handled
|
2016-08-19 13:35:46 +08:00
|
|
|
*/
|
KVM: PPC: Book3S HV: Use OPAL XICS emulation on POWER9
POWER9 includes a new interrupt controller, called XIVE, which is
quite different from the XICS interrupt controller on POWER7 and
POWER8 machines. KVM-HV accesses the XICS directly in several places
in order to send and clear IPIs and handle interrupts from PCI
devices being passed through to the guest.
In order to make the transition to XIVE easier, OPAL firmware will
include an emulation of XICS on top of XIVE. Access to the emulated
XICS is via OPAL calls. The one complication is that the EOI
(end-of-interrupt) function can now return a value indicating that
another interrupt is pending; in this case, the XIVE will not signal
an interrupt in hardware to the CPU, and software is supposed to
acknowledge the new interrupt without waiting for another interrupt
to be delivered in hardware.
This adapts KVM-HV to use the OPAL calls on machines where there is
no XICS hardware. When there is no XICS, we look for a device-tree
node with "ibm,opal-intc" in its compatible property, which is how
OPAL indicates that it provides XICS emulation.
In order to handle the EOI return value, kvmppc_read_intr() has
become kvmppc_read_one_intr(), with a boolean variable passed by
reference which can be set by the EOI functions to indicate that
another interrupt is pending. The new kvmppc_read_intr() keeps
calling kvmppc_read_one_intr() until there are no more interrupts
to process. The return value from kvmppc_read_intr() is the
largest non-zero value of the returns from kvmppc_read_one_intr().
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-18 06:02:08 +08:00
|
|
|
static long kvmppc_read_one_intr(bool *again);
|
2016-08-19 13:35:46 +08:00
|
|
|
|
|
|
|
|
long kvmppc_read_intr(void)
|
KVM: PPC: Book3S HV: Use OPAL XICS emulation on POWER9
POWER9 includes a new interrupt controller, called XIVE, which is
quite different from the XICS interrupt controller on POWER7 and
POWER8 machines. KVM-HV accesses the XICS directly in several places
in order to send and clear IPIs and handle interrupts from PCI
devices being passed through to the guest.
In order to make the transition to XIVE easier, OPAL firmware will
include an emulation of XICS on top of XIVE. Access to the emulated
XICS is via OPAL calls. The one complication is that the EOI
(end-of-interrupt) function can now return a value indicating that
another interrupt is pending; in this case, the XIVE will not signal
an interrupt in hardware to the CPU, and software is supposed to
acknowledge the new interrupt without waiting for another interrupt
to be delivered in hardware.
This adapts KVM-HV to use the OPAL calls on machines where there is
no XICS hardware. When there is no XICS, we look for a device-tree
node with "ibm,opal-intc" in its compatible property, which is how
OPAL indicates that it provides XICS emulation.
In order to handle the EOI return value, kvmppc_read_intr() has
become kvmppc_read_one_intr(), with a boolean variable passed by
reference which can be set by the EOI functions to indicate that
another interrupt is pending. The new kvmppc_read_intr() keeps
calling kvmppc_read_one_intr() until there are no more interrupts
to process. The return value from kvmppc_read_intr() is the
largest non-zero value of the returns from kvmppc_read_one_intr().
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-18 06:02:08 +08:00
|
|
|
{
|
|
|
|
|
long ret = 0;
|
|
|
|
|
long rc;
|
|
|
|
|
bool again;
|
|
|
|
|
|
2017-04-05 15:54:50 +08:00
|
|
|
if (xive_enabled())
|
|
|
|
|
return 1;
|
|
|
|
|
|
KVM: PPC: Book3S HV: Use OPAL XICS emulation on POWER9
POWER9 includes a new interrupt controller, called XIVE, which is
quite different from the XICS interrupt controller on POWER7 and
POWER8 machines. KVM-HV accesses the XICS directly in several places
in order to send and clear IPIs and handle interrupts from PCI
devices being passed through to the guest.
In order to make the transition to XIVE easier, OPAL firmware will
include an emulation of XICS on top of XIVE. Access to the emulated
XICS is via OPAL calls. The one complication is that the EOI
(end-of-interrupt) function can now return a value indicating that
another interrupt is pending; in this case, the XIVE will not signal
an interrupt in hardware to the CPU, and software is supposed to
acknowledge the new interrupt without waiting for another interrupt
to be delivered in hardware.
This adapts KVM-HV to use the OPAL calls on machines where there is
no XICS hardware. When there is no XICS, we look for a device-tree
node with "ibm,opal-intc" in its compatible property, which is how
OPAL indicates that it provides XICS emulation.
In order to handle the EOI return value, kvmppc_read_intr() has
become kvmppc_read_one_intr(), with a boolean variable passed by
reference which can be set by the EOI functions to indicate that
another interrupt is pending. The new kvmppc_read_intr() keeps
calling kvmppc_read_one_intr() until there are no more interrupts
to process. The return value from kvmppc_read_intr() is the
largest non-zero value of the returns from kvmppc_read_one_intr().
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-18 06:02:08 +08:00
|
|
|
do {
|
|
|
|
|
again = false;
|
|
|
|
|
rc = kvmppc_read_one_intr(&again);
|
|
|
|
|
if (rc && (ret == 0 || rc > ret))
|
|
|
|
|
ret = rc;
|
|
|
|
|
} while (again);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static long kvmppc_read_one_intr(bool *again)
|
2016-08-19 13:35:46 +08:00
|
|
|
{
|
2017-04-05 15:54:54 +08:00
|
|
|
void __iomem *xics_phys;
|
2016-08-19 13:35:46 +08:00
|
|
|
u32 h_xirr;
|
|
|
|
|
__be32 xirr;
|
|
|
|
|
u32 xisr;
|
|
|
|
|
u8 host_ipi;
|
KVM: PPC: Book3S HV: Use OPAL XICS emulation on POWER9
POWER9 includes a new interrupt controller, called XIVE, which is
quite different from the XICS interrupt controller on POWER7 and
POWER8 machines. KVM-HV accesses the XICS directly in several places
in order to send and clear IPIs and handle interrupts from PCI
devices being passed through to the guest.
In order to make the transition to XIVE easier, OPAL firmware will
include an emulation of XICS on top of XIVE. Access to the emulated
XICS is via OPAL calls. The one complication is that the EOI
(end-of-interrupt) function can now return a value indicating that
another interrupt is pending; in this case, the XIVE will not signal
an interrupt in hardware to the CPU, and software is supposed to
acknowledge the new interrupt without waiting for another interrupt
to be delivered in hardware.
This adapts KVM-HV to use the OPAL calls on machines where there is
no XICS hardware. When there is no XICS, we look for a device-tree
node with "ibm,opal-intc" in its compatible property, which is how
OPAL indicates that it provides XICS emulation.
In order to handle the EOI return value, kvmppc_read_intr() has
become kvmppc_read_one_intr(), with a boolean variable passed by
reference which can be set by the EOI functions to indicate that
another interrupt is pending. The new kvmppc_read_intr() keeps
calling kvmppc_read_one_intr() until there are no more interrupts
to process. The return value from kvmppc_read_intr() is the
largest non-zero value of the returns from kvmppc_read_one_intr().
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-18 06:02:08 +08:00
|
|
|
int64_t rc;
|
2016-08-19 13:35:46 +08:00
|
|
|
|
2017-04-05 15:54:56 +08:00
|
|
|
if (xive_enabled())
|
|
|
|
|
return 1;
|
|
|
|
|
|
2016-08-19 13:35:46 +08:00
|
|
|
/* see if a host IPI is pending */
|
|
|
|
|
host_ipi = local_paca->kvm_hstate.host_ipi;
|
|
|
|
|
if (host_ipi)
|
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
|
|
/* Now read the interrupt from the ICP */
|
2018-10-08 13:31:05 +08:00
|
|
|
if (kvmhv_on_pseries()) {
|
|
|
|
|
unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
|
|
|
|
|
|
|
|
|
|
rc = plpar_hcall_raw(H_XIRR, retbuf, 0xFF);
|
|
|
|
|
xirr = cpu_to_be32(retbuf[0]);
|
|
|
|
|
} else {
|
|
|
|
|
xics_phys = local_paca->kvm_hstate.xics_phys;
|
|
|
|
|
rc = 0;
|
|
|
|
|
if (!xics_phys)
|
|
|
|
|
rc = opal_int_get_xirr(&xirr, false);
|
|
|
|
|
else
|
|
|
|
|
xirr = __raw_rm_readl(xics_phys + XICS_XIRR);
|
|
|
|
|
}
|
2017-01-30 18:21:51 +08:00
|
|
|
if (rc < 0)
|
|
|
|
|
return 1;
|
2016-08-19 13:35:46 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Save XIRR for later. Since we get control in reverse endian
|
|
|
|
|
* on LE systems, save it byte reversed and fetch it back in
|
|
|
|
|
* host endian. Note that xirr is the value read from the
|
|
|
|
|
* XIRR register, while h_xirr is the host endian version.
|
|
|
|
|
*/
|
|
|
|
|
h_xirr = be32_to_cpu(xirr);
|
|
|
|
|
local_paca->kvm_hstate.saved_xirr = h_xirr;
|
|
|
|
|
xisr = h_xirr & 0xffffff;
|
|
|
|
|
/*
|
|
|
|
|
* Ensure that the store/load complete to guarantee all side
|
|
|
|
|
* effects of loading from XIRR has completed
|
|
|
|
|
*/
|
|
|
|
|
smp_mb();
|
|
|
|
|
|
|
|
|
|
/* if nothing pending in the ICP */
|
|
|
|
|
if (!xisr)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
/* We found something in the ICP...
|
|
|
|
|
*
|
|
|
|
|
* If it is an IPI, clear the MFRR and EOI it.
|
|
|
|
|
*/
|
|
|
|
|
if (xisr == XICS_IPI) {
|
2017-01-30 18:21:51 +08:00
|
|
|
rc = 0;
|
2018-10-08 13:31:05 +08:00
|
|
|
if (kvmhv_on_pseries()) {
|
|
|
|
|
unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
|
|
|
|
|
|
|
|
|
|
plpar_hcall_raw(H_IPI, retbuf,
|
|
|
|
|
hard_smp_processor_id(), 0xff);
|
|
|
|
|
plpar_hcall_raw(H_EOI, retbuf, h_xirr);
|
|
|
|
|
} else if (xics_phys) {
|
2017-04-05 15:54:54 +08:00
|
|
|
__raw_rm_writeb(0xff, xics_phys + XICS_MFRR);
|
|
|
|
|
__raw_rm_writel(xirr, xics_phys + XICS_XIRR);
|
KVM: PPC: Book3S HV: Use OPAL XICS emulation on POWER9
POWER9 includes a new interrupt controller, called XIVE, which is
quite different from the XICS interrupt controller on POWER7 and
POWER8 machines. KVM-HV accesses the XICS directly in several places
in order to send and clear IPIs and handle interrupts from PCI
devices being passed through to the guest.
In order to make the transition to XIVE easier, OPAL firmware will
include an emulation of XICS on top of XIVE. Access to the emulated
XICS is via OPAL calls. The one complication is that the EOI
(end-of-interrupt) function can now return a value indicating that
another interrupt is pending; in this case, the XIVE will not signal
an interrupt in hardware to the CPU, and software is supposed to
acknowledge the new interrupt without waiting for another interrupt
to be delivered in hardware.
This adapts KVM-HV to use the OPAL calls on machines where there is
no XICS hardware. When there is no XICS, we look for a device-tree
node with "ibm,opal-intc" in its compatible property, which is how
OPAL indicates that it provides XICS emulation.
In order to handle the EOI return value, kvmppc_read_intr() has
become kvmppc_read_one_intr(), with a boolean variable passed by
reference which can be set by the EOI functions to indicate that
another interrupt is pending. The new kvmppc_read_intr() keeps
calling kvmppc_read_one_intr() until there are no more interrupts
to process. The return value from kvmppc_read_intr() is the
largest non-zero value of the returns from kvmppc_read_one_intr().
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-18 06:02:08 +08:00
|
|
|
} else {
|
2017-02-07 13:03:17 +08:00
|
|
|
opal_int_set_mfrr(hard_smp_processor_id(), 0xff);
|
|
|
|
|
rc = opal_int_eoi(h_xirr);
|
KVM: PPC: Book3S HV: Use OPAL XICS emulation on POWER9
POWER9 includes a new interrupt controller, called XIVE, which is
quite different from the XICS interrupt controller on POWER7 and
POWER8 machines. KVM-HV accesses the XICS directly in several places
in order to send and clear IPIs and handle interrupts from PCI
devices being passed through to the guest.
In order to make the transition to XIVE easier, OPAL firmware will
include an emulation of XICS on top of XIVE. Access to the emulated
XICS is via OPAL calls. The one complication is that the EOI
(end-of-interrupt) function can now return a value indicating that
another interrupt is pending; in this case, the XIVE will not signal
an interrupt in hardware to the CPU, and software is supposed to
acknowledge the new interrupt without waiting for another interrupt
to be delivered in hardware.
This adapts KVM-HV to use the OPAL calls on machines where there is
no XICS hardware. When there is no XICS, we look for a device-tree
node with "ibm,opal-intc" in its compatible property, which is how
OPAL indicates that it provides XICS emulation.
In order to handle the EOI return value, kvmppc_read_intr() has
become kvmppc_read_one_intr(), with a boolean variable passed by
reference which can be set by the EOI functions to indicate that
another interrupt is pending. The new kvmppc_read_intr() keeps
calling kvmppc_read_one_intr() until there are no more interrupts
to process. The return value from kvmppc_read_intr() is the
largest non-zero value of the returns from kvmppc_read_one_intr().
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-18 06:02:08 +08:00
|
|
|
}
|
2017-01-30 18:21:51 +08:00
|
|
|
/* If rc > 0, there is another interrupt pending */
|
|
|
|
|
*again = rc > 0;
|
KVM: PPC: Book3S HV: Use OPAL XICS emulation on POWER9
POWER9 includes a new interrupt controller, called XIVE, which is
quite different from the XICS interrupt controller on POWER7 and
POWER8 machines. KVM-HV accesses the XICS directly in several places
in order to send and clear IPIs and handle interrupts from PCI
devices being passed through to the guest.
In order to make the transition to XIVE easier, OPAL firmware will
include an emulation of XICS on top of XIVE. Access to the emulated
XICS is via OPAL calls. The one complication is that the EOI
(end-of-interrupt) function can now return a value indicating that
another interrupt is pending; in this case, the XIVE will not signal
an interrupt in hardware to the CPU, and software is supposed to
acknowledge the new interrupt without waiting for another interrupt
to be delivered in hardware.
This adapts KVM-HV to use the OPAL calls on machines where there is
no XICS hardware. When there is no XICS, we look for a device-tree
node with "ibm,opal-intc" in its compatible property, which is how
OPAL indicates that it provides XICS emulation.
In order to handle the EOI return value, kvmppc_read_intr() has
become kvmppc_read_one_intr(), with a boolean variable passed by
reference which can be set by the EOI functions to indicate that
another interrupt is pending. The new kvmppc_read_intr() keeps
calling kvmppc_read_one_intr() until there are no more interrupts
to process. The return value from kvmppc_read_intr() is the
largest non-zero value of the returns from kvmppc_read_one_intr().
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-18 06:02:08 +08:00
|
|
|
|
2016-08-19 13:35:46 +08:00
|
|
|
/*
|
|
|
|
|
* Need to ensure side effects of above stores
|
|
|
|
|
* complete before proceeding.
|
|
|
|
|
*/
|
|
|
|
|
smp_mb();
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We need to re-check host IPI now in case it got set in the
|
|
|
|
|
* meantime. If it's clear, we bounce the interrupt to the
|
|
|
|
|
* guest
|
|
|
|
|
*/
|
|
|
|
|
host_ipi = local_paca->kvm_hstate.host_ipi;
|
|
|
|
|
if (unlikely(host_ipi != 0)) {
|
|
|
|
|
/* We raced with the host,
|
|
|
|
|
* we need to resend that IPI, bummer
|
|
|
|
|
*/
|
2018-10-08 13:31:05 +08:00
|
|
|
if (kvmhv_on_pseries()) {
|
|
|
|
|
unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
|
|
|
|
|
|
|
|
|
|
plpar_hcall_raw(H_IPI, retbuf,
|
|
|
|
|
hard_smp_processor_id(),
|
|
|
|
|
IPI_PRIORITY);
|
|
|
|
|
} else if (xics_phys)
|
2017-04-05 15:54:54 +08:00
|
|
|
__raw_rm_writeb(IPI_PRIORITY,
|
|
|
|
|
xics_phys + XICS_MFRR);
|
KVM: PPC: Book3S HV: Use OPAL XICS emulation on POWER9
POWER9 includes a new interrupt controller, called XIVE, which is
quite different from the XICS interrupt controller on POWER7 and
POWER8 machines. KVM-HV accesses the XICS directly in several places
in order to send and clear IPIs and handle interrupts from PCI
devices being passed through to the guest.
In order to make the transition to XIVE easier, OPAL firmware will
include an emulation of XICS on top of XIVE. Access to the emulated
XICS is via OPAL calls. The one complication is that the EOI
(end-of-interrupt) function can now return a value indicating that
another interrupt is pending; in this case, the XIVE will not signal
an interrupt in hardware to the CPU, and software is supposed to
acknowledge the new interrupt without waiting for another interrupt
to be delivered in hardware.
This adapts KVM-HV to use the OPAL calls on machines where there is
no XICS hardware. When there is no XICS, we look for a device-tree
node with "ibm,opal-intc" in its compatible property, which is how
OPAL indicates that it provides XICS emulation.
In order to handle the EOI return value, kvmppc_read_intr() has
become kvmppc_read_one_intr(), with a boolean variable passed by
reference which can be set by the EOI functions to indicate that
another interrupt is pending. The new kvmppc_read_intr() keeps
calling kvmppc_read_one_intr() until there are no more interrupts
to process. The return value from kvmppc_read_intr() is the
largest non-zero value of the returns from kvmppc_read_one_intr().
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-18 06:02:08 +08:00
|
|
|
else
|
2017-02-07 13:03:17 +08:00
|
|
|
opal_int_set_mfrr(hard_smp_processor_id(),
|
|
|
|
|
IPI_PRIORITY);
|
2016-08-19 13:35:46 +08:00
|
|
|
/* Let side effects complete */
|
|
|
|
|
smp_mb();
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* OK, it's an IPI for us */
|
|
|
|
|
local_paca->kvm_hstate.saved_xirr = 0;
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
KVM: PPC: Book3S HV: Use OPAL XICS emulation on POWER9
POWER9 includes a new interrupt controller, called XIVE, which is
quite different from the XICS interrupt controller on POWER7 and
POWER8 machines. KVM-HV accesses the XICS directly in several places
in order to send and clear IPIs and handle interrupts from PCI
devices being passed through to the guest.
In order to make the transition to XIVE easier, OPAL firmware will
include an emulation of XICS on top of XIVE. Access to the emulated
XICS is via OPAL calls. The one complication is that the EOI
(end-of-interrupt) function can now return a value indicating that
another interrupt is pending; in this case, the XIVE will not signal
an interrupt in hardware to the CPU, and software is supposed to
acknowledge the new interrupt without waiting for another interrupt
to be delivered in hardware.
This adapts KVM-HV to use the OPAL calls on machines where there is
no XICS hardware. When there is no XICS, we look for a device-tree
node with "ibm,opal-intc" in its compatible property, which is how
OPAL indicates that it provides XICS emulation.
In order to handle the EOI return value, kvmppc_read_intr() has
become kvmppc_read_one_intr(), with a boolean variable passed by
reference which can be set by the EOI functions to indicate that
another interrupt is pending. The new kvmppc_read_intr() keeps
calling kvmppc_read_one_intr() until there are no more interrupts
to process. The return value from kvmppc_read_intr() is the
largest non-zero value of the returns from kvmppc_read_one_intr().
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2016-11-18 06:02:08 +08:00
|
|
|
return kvmppc_check_passthru(xisr, xirr, again);
|
2016-08-19 13:35:46 +08:00
|
|
|
}
|
2017-04-05 15:54:56 +08:00
|
|
|
|
|
|
|
|
#ifdef CONFIG_KVM_XICS
|
|
|
|
|
static inline bool is_rm(void)
|
|
|
|
|
{
|
|
|
|
|
return !(mfmsr() & MSR_DR);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
unsigned long kvmppc_rm_h_xirr(struct kvm_vcpu *vcpu)
|
|
|
|
|
{
|
2017-10-26 14:00:22 +08:00
|
|
|
if (!kvmppc_xics_enabled(vcpu))
|
|
|
|
|
return H_TOO_HARD;
|
KVM: PPC: Book3S: Allow XICS emulation to work in nested hosts using XIVE
Currently, the KVM code assumes that if the host kernel is using the
XIVE interrupt controller (the new interrupt controller that first
appeared in POWER9 systems), then the in-kernel XICS emulation will
use the XIVE hardware to deliver interrupts to the guest. However,
this only works when the host is running in hypervisor mode and has
full access to all of the XIVE functionality. It doesn't work in any
nested virtualization scenario, either with PR KVM or nested-HV KVM,
because the XICS-on-XIVE code calls directly into the native-XIVE
routines, which are not initialized and cannot function correctly
because they use OPAL calls, and OPAL is not available in a guest.
This means that using the in-kernel XICS emulation in a nested
hypervisor that is using XIVE as its interrupt controller will cause a
(nested) host kernel crash. To fix this, we change most of the places
where the current code calls xive_enabled() to select between the
XICS-on-XIVE emulation and the plain XICS emulation to call a new
function, xics_on_xive(), which returns false in a guest.
However, there is a further twist. The plain XICS emulation has some
functions which are used in real mode and access the underlying XICS
controller (the interrupt controller of the host) directly. In the
case of a nested hypervisor, this means doing XICS hypercalls
directly. When the nested host is using XIVE as its interrupt
controller, these hypercalls will fail. Therefore this also adds
checks in the places where the XICS emulation wants to access the
underlying interrupt controller directly, and if that is XIVE, makes
the code use the virtual mode fallback paths, which call generic
kernel infrastructure rather than doing direct XICS access.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2019-02-04 19:07:20 +08:00
|
|
|
if (xics_on_xive()) {
|
2017-04-05 15:54:56 +08:00
|
|
|
if (is_rm())
|
|
|
|
|
return xive_rm_h_xirr(vcpu);
|
|
|
|
|
if (unlikely(!__xive_vm_h_xirr))
|
|
|
|
|
return H_NOT_AVAILABLE;
|
|
|
|
|
return __xive_vm_h_xirr(vcpu);
|
|
|
|
|
} else
|
|
|
|
|
return xics_rm_h_xirr(vcpu);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
unsigned long kvmppc_rm_h_xirr_x(struct kvm_vcpu *vcpu)
|
|
|
|
|
{
|
2017-10-26 14:00:22 +08:00
|
|
|
if (!kvmppc_xics_enabled(vcpu))
|
|
|
|
|
return H_TOO_HARD;
|
2018-05-07 14:20:07 +08:00
|
|
|
vcpu->arch.regs.gpr[5] = get_tb();
|
KVM: PPC: Book3S: Allow XICS emulation to work in nested hosts using XIVE
Currently, the KVM code assumes that if the host kernel is using the
XIVE interrupt controller (the new interrupt controller that first
appeared in POWER9 systems), then the in-kernel XICS emulation will
use the XIVE hardware to deliver interrupts to the guest. However,
this only works when the host is running in hypervisor mode and has
full access to all of the XIVE functionality. It doesn't work in any
nested virtualization scenario, either with PR KVM or nested-HV KVM,
because the XICS-on-XIVE code calls directly into the native-XIVE
routines, which are not initialized and cannot function correctly
because they use OPAL calls, and OPAL is not available in a guest.
This means that using the in-kernel XICS emulation in a nested
hypervisor that is using XIVE as its interrupt controller will cause a
(nested) host kernel crash. To fix this, we change most of the places
where the current code calls xive_enabled() to select between the
XICS-on-XIVE emulation and the plain XICS emulation to call a new
function, xics_on_xive(), which returns false in a guest.
However, there is a further twist. The plain XICS emulation has some
functions which are used in real mode and access the underlying XICS
controller (the interrupt controller of the host) directly. In the
case of a nested hypervisor, this means doing XICS hypercalls
directly. When the nested host is using XIVE as its interrupt
controller, these hypercalls will fail. Therefore this also adds
checks in the places where the XICS emulation wants to access the
underlying interrupt controller directly, and if that is XIVE, makes
the code use the virtual mode fallback paths, which call generic
kernel infrastructure rather than doing direct XICS access.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2019-02-04 19:07:20 +08:00
|
|
|
if (xics_on_xive()) {
|
2017-04-05 15:54:56 +08:00
|
|
|
if (is_rm())
|
|
|
|
|
return xive_rm_h_xirr(vcpu);
|
|
|
|
|
if (unlikely(!__xive_vm_h_xirr))
|
|
|
|
|
return H_NOT_AVAILABLE;
|
|
|
|
|
return __xive_vm_h_xirr(vcpu);
|
|
|
|
|
} else
|
|
|
|
|
return xics_rm_h_xirr(vcpu);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
unsigned long kvmppc_rm_h_ipoll(struct kvm_vcpu *vcpu, unsigned long server)
|
|
|
|
|
{
|
2017-10-26 14:00:22 +08:00
|
|
|
if (!kvmppc_xics_enabled(vcpu))
|
|
|
|
|
return H_TOO_HARD;
|
KVM: PPC: Book3S: Allow XICS emulation to work in nested hosts using XIVE
Currently, the KVM code assumes that if the host kernel is using the
XIVE interrupt controller (the new interrupt controller that first
appeared in POWER9 systems), then the in-kernel XICS emulation will
use the XIVE hardware to deliver interrupts to the guest. However,
this only works when the host is running in hypervisor mode and has
full access to all of the XIVE functionality. It doesn't work in any
nested virtualization scenario, either with PR KVM or nested-HV KVM,
because the XICS-on-XIVE code calls directly into the native-XIVE
routines, which are not initialized and cannot function correctly
because they use OPAL calls, and OPAL is not available in a guest.
This means that using the in-kernel XICS emulation in a nested
hypervisor that is using XIVE as its interrupt controller will cause a
(nested) host kernel crash. To fix this, we change most of the places
where the current code calls xive_enabled() to select between the
XICS-on-XIVE emulation and the plain XICS emulation to call a new
function, xics_on_xive(), which returns false in a guest.
However, there is a further twist. The plain XICS emulation has some
functions which are used in real mode and access the underlying XICS
controller (the interrupt controller of the host) directly. In the
case of a nested hypervisor, this means doing XICS hypercalls
directly. When the nested host is using XIVE as its interrupt
controller, these hypercalls will fail. Therefore this also adds
checks in the places where the XICS emulation wants to access the
underlying interrupt controller directly, and if that is XIVE, makes
the code use the virtual mode fallback paths, which call generic
kernel infrastructure rather than doing direct XICS access.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2019-02-04 19:07:20 +08:00
|
|
|
if (xics_on_xive()) {
|
2017-04-05 15:54:56 +08:00
|
|
|
if (is_rm())
|
|
|
|
|
return xive_rm_h_ipoll(vcpu, server);
|
|
|
|
|
if (unlikely(!__xive_vm_h_ipoll))
|
|
|
|
|
return H_NOT_AVAILABLE;
|
|
|
|
|
return __xive_vm_h_ipoll(vcpu, server);
|
|
|
|
|
} else
|
|
|
|
|
return H_TOO_HARD;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int kvmppc_rm_h_ipi(struct kvm_vcpu *vcpu, unsigned long server,
|
|
|
|
|
unsigned long mfrr)
|
|
|
|
|
{
|
2017-10-26 14:00:22 +08:00
|
|
|
if (!kvmppc_xics_enabled(vcpu))
|
|
|
|
|
return H_TOO_HARD;
|
KVM: PPC: Book3S: Allow XICS emulation to work in nested hosts using XIVE
Currently, the KVM code assumes that if the host kernel is using the
XIVE interrupt controller (the new interrupt controller that first
appeared in POWER9 systems), then the in-kernel XICS emulation will
use the XIVE hardware to deliver interrupts to the guest. However,
this only works when the host is running in hypervisor mode and has
full access to all of the XIVE functionality. It doesn't work in any
nested virtualization scenario, either with PR KVM or nested-HV KVM,
because the XICS-on-XIVE code calls directly into the native-XIVE
routines, which are not initialized and cannot function correctly
because they use OPAL calls, and OPAL is not available in a guest.
This means that using the in-kernel XICS emulation in a nested
hypervisor that is using XIVE as its interrupt controller will cause a
(nested) host kernel crash. To fix this, we change most of the places
where the current code calls xive_enabled() to select between the
XICS-on-XIVE emulation and the plain XICS emulation to call a new
function, xics_on_xive(), which returns false in a guest.
However, there is a further twist. The plain XICS emulation has some
functions which are used in real mode and access the underlying XICS
controller (the interrupt controller of the host) directly. In the
case of a nested hypervisor, this means doing XICS hypercalls
directly. When the nested host is using XIVE as its interrupt
controller, these hypercalls will fail. Therefore this also adds
checks in the places where the XICS emulation wants to access the
underlying interrupt controller directly, and if that is XIVE, makes
the code use the virtual mode fallback paths, which call generic
kernel infrastructure rather than doing direct XICS access.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2019-02-04 19:07:20 +08:00
|
|
|
if (xics_on_xive()) {
|
2017-04-05 15:54:56 +08:00
|
|
|
if (is_rm())
|
|
|
|
|
return xive_rm_h_ipi(vcpu, server, mfrr);
|
|
|
|
|
if (unlikely(!__xive_vm_h_ipi))
|
|
|
|
|
return H_NOT_AVAILABLE;
|
|
|
|
|
return __xive_vm_h_ipi(vcpu, server, mfrr);
|
|
|
|
|
} else
|
|
|
|
|
return xics_rm_h_ipi(vcpu, server, mfrr);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int kvmppc_rm_h_cppr(struct kvm_vcpu *vcpu, unsigned long cppr)
|
|
|
|
|
{
|
2017-10-26 14:00:22 +08:00
|
|
|
if (!kvmppc_xics_enabled(vcpu))
|
|
|
|
|
return H_TOO_HARD;
|
KVM: PPC: Book3S: Allow XICS emulation to work in nested hosts using XIVE
Currently, the KVM code assumes that if the host kernel is using the
XIVE interrupt controller (the new interrupt controller that first
appeared in POWER9 systems), then the in-kernel XICS emulation will
use the XIVE hardware to deliver interrupts to the guest. However,
this only works when the host is running in hypervisor mode and has
full access to all of the XIVE functionality. It doesn't work in any
nested virtualization scenario, either with PR KVM or nested-HV KVM,
because the XICS-on-XIVE code calls directly into the native-XIVE
routines, which are not initialized and cannot function correctly
because they use OPAL calls, and OPAL is not available in a guest.
This means that using the in-kernel XICS emulation in a nested
hypervisor that is using XIVE as its interrupt controller will cause a
(nested) host kernel crash. To fix this, we change most of the places
where the current code calls xive_enabled() to select between the
XICS-on-XIVE emulation and the plain XICS emulation to call a new
function, xics_on_xive(), which returns false in a guest.
However, there is a further twist. The plain XICS emulation has some
functions which are used in real mode and access the underlying XICS
controller (the interrupt controller of the host) directly. In the
case of a nested hypervisor, this means doing XICS hypercalls
directly. When the nested host is using XIVE as its interrupt
controller, these hypercalls will fail. Therefore this also adds
checks in the places where the XICS emulation wants to access the
underlying interrupt controller directly, and if that is XIVE, makes
the code use the virtual mode fallback paths, which call generic
kernel infrastructure rather than doing direct XICS access.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2019-02-04 19:07:20 +08:00
|
|
|
if (xics_on_xive()) {
|
2017-04-05 15:54:56 +08:00
|
|
|
if (is_rm())
|
|
|
|
|
return xive_rm_h_cppr(vcpu, cppr);
|
|
|
|
|
if (unlikely(!__xive_vm_h_cppr))
|
|
|
|
|
return H_NOT_AVAILABLE;
|
|
|
|
|
return __xive_vm_h_cppr(vcpu, cppr);
|
|
|
|
|
} else
|
|
|
|
|
return xics_rm_h_cppr(vcpu, cppr);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int kvmppc_rm_h_eoi(struct kvm_vcpu *vcpu, unsigned long xirr)
|
|
|
|
|
{
|
2017-10-26 14:00:22 +08:00
|
|
|
if (!kvmppc_xics_enabled(vcpu))
|
|
|
|
|
return H_TOO_HARD;
|
KVM: PPC: Book3S: Allow XICS emulation to work in nested hosts using XIVE
Currently, the KVM code assumes that if the host kernel is using the
XIVE interrupt controller (the new interrupt controller that first
appeared in POWER9 systems), then the in-kernel XICS emulation will
use the XIVE hardware to deliver interrupts to the guest. However,
this only works when the host is running in hypervisor mode and has
full access to all of the XIVE functionality. It doesn't work in any
nested virtualization scenario, either with PR KVM or nested-HV KVM,
because the XICS-on-XIVE code calls directly into the native-XIVE
routines, which are not initialized and cannot function correctly
because they use OPAL calls, and OPAL is not available in a guest.
This means that using the in-kernel XICS emulation in a nested
hypervisor that is using XIVE as its interrupt controller will cause a
(nested) host kernel crash. To fix this, we change most of the places
where the current code calls xive_enabled() to select between the
XICS-on-XIVE emulation and the plain XICS emulation to call a new
function, xics_on_xive(), which returns false in a guest.
However, there is a further twist. The plain XICS emulation has some
functions which are used in real mode and access the underlying XICS
controller (the interrupt controller of the host) directly. In the
case of a nested hypervisor, this means doing XICS hypercalls
directly. When the nested host is using XIVE as its interrupt
controller, these hypercalls will fail. Therefore this also adds
checks in the places where the XICS emulation wants to access the
underlying interrupt controller directly, and if that is XIVE, makes
the code use the virtual mode fallback paths, which call generic
kernel infrastructure rather than doing direct XICS access.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2019-02-04 19:07:20 +08:00
|
|
|
if (xics_on_xive()) {
|
2017-04-05 15:54:56 +08:00
|
|
|
if (is_rm())
|
|
|
|
|
return xive_rm_h_eoi(vcpu, xirr);
|
|
|
|
|
if (unlikely(!__xive_vm_h_eoi))
|
|
|
|
|
return H_NOT_AVAILABLE;
|
|
|
|
|
return __xive_vm_h_eoi(vcpu, xirr);
|
|
|
|
|
} else
|
|
|
|
|
return xics_rm_h_eoi(vcpu, xirr);
|
|
|
|
|
}
|
|
|
|
|
#endif /* CONFIG_KVM_XICS */
|
KVM: PPC: Book3S HV: Handle unexpected interrupts better
At present, if an interrupt (i.e. an exception or trap) occurs in the
code where KVM is switching the MMU to or from guest context, we jump
to kvmppc_bad_host_intr, where we simply spin with interrupts disabled.
In this situation, it is hard to debug what happened because we get no
indication as to which interrupt occurred or where. Typically we get
a cascade of stall and soft lockup warnings from other CPUs.
In order to get more information for debugging, this adds code to
create a stack frame on the emergency stack and save register values
to it. We start half-way down the emergency stack in order to give
ourselves some chance of being able to do a stack trace on secondary
threads that are already on the emergency stack.
On POWER7 or POWER8, we then just spin, as before, because we don't
know what state the MMU context is in or what other threads are doing,
and we can't switch back to host context without coordinating with
other threads. On POWER9 we can do better; there we load up the host
MMU context and jump to C code, which prints an oops message to the
console and panics.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2017-09-01 14:17:27 +08:00
|
|
|
|
|
|
|
|
void kvmppc_bad_interrupt(struct pt_regs *regs)
|
|
|
|
|
{
|
KVM: PPC: Book3S HV: Send kvmppc_bad_interrupt NMIs to Linux handlers
It's possible to take a SRESET or MCE in these paths due to a bug
in the host code or a NMI IPI, etc. A recent bug attempting to load
a virtual address from real mode gave th complete but cryptic error,
abridged:
Oops: Bad interrupt in KVM entry/exit code, sig: 6 [#1]
LE SMP NR_CPUS=2048 NUMA PowerNV
CPU: 53 PID: 6582 Comm: qemu-system-ppc Not tainted
NIP: c0000000000155ac LR: c0000000000c2430 CTR: c000000000015580
REGS: c000000fff76dd80 TRAP: 0200 Not tainted
MSR: 9000000000201003 <SF,HV,ME,RI,LE> CR: 48082222 XER: 00000000
CFAR: 0000000102900ef0 DAR: d00017fffd941a28 DSISR: 00000040 SOFTE: 3
NIP [c0000000000155ac] perf_trace_tlbie+0x2c/0x1a0
LR [c0000000000c2430] do_tlbies+0x230/0x2f0
Sending the NMIs through the Linux handlers gives a nicer output:
Severe Machine check interrupt [Not recovered]
NIP [c0000000000155ac]: perf_trace_tlbie+0x2c/0x1a0
Initiator: CPU
Error type: Real address [Load (bad)]
Effective address: d00017fffcc01a28
opal: Machine check interrupt unrecoverable: MSR(RI=0)
opal: Hardware platform error: Unrecoverable Machine Check exception
CPU: 0 PID: 6700 Comm: qemu-system-ppc Tainted: G M
NIP: c0000000000155ac LR: c0000000000c23c0 CTR: c000000000015580
REGS: c000000fff9e9d80 TRAP: 0200 Tainted: G M
MSR: 9000000000201001 <SF,HV,ME,LE> CR: 48082222 XER: 00000000
CFAR: 000000010cbc1a30 DAR: d00017fffcc01a28 DSISR: 00000040 SOFTE: 3
NIP [c0000000000155ac] perf_trace_tlbie+0x2c/0x1a0
LR [c0000000000c23c0] do_tlbies+0x1c0/0x280
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2018-05-18 01:49:44 +08:00
|
|
|
/*
|
|
|
|
|
* 100 could happen at any time, 200 can happen due to invalid real
|
|
|
|
|
* address access for example (or any time due to a hardware problem).
|
|
|
|
|
*/
|
|
|
|
|
if (TRAP(regs) == 0x100) {
|
|
|
|
|
get_paca()->in_nmi++;
|
|
|
|
|
system_reset_exception(regs);
|
|
|
|
|
get_paca()->in_nmi--;
|
|
|
|
|
} else if (TRAP(regs) == 0x200) {
|
|
|
|
|
machine_check_exception(regs);
|
|
|
|
|
} else {
|
|
|
|
|
die("Bad interrupt in KVM entry/exit code", regs, SIGABRT);
|
|
|
|
|
}
|
KVM: PPC: Book3S HV: Handle unexpected interrupts better
At present, if an interrupt (i.e. an exception or trap) occurs in the
code where KVM is switching the MMU to or from guest context, we jump
to kvmppc_bad_host_intr, where we simply spin with interrupts disabled.
In this situation, it is hard to debug what happened because we get no
indication as to which interrupt occurred or where. Typically we get
a cascade of stall and soft lockup warnings from other CPUs.
In order to get more information for debugging, this adds code to
create a stack frame on the emergency stack and save register values
to it. We start half-way down the emergency stack in order to give
ourselves some chance of being able to do a stack trace on secondary
threads that are already on the emergency stack.
On POWER7 or POWER8, we then just spin, as before, because we don't
know what state the MMU context is in or what other threads are doing,
and we can't switch back to host context without coordinating with
other threads. On POWER9 we can do better; there we load up the host
MMU context and jump to C code, which prints an oops message to the
console and panics.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2017-09-01 14:17:27 +08:00
|
|
|
panic("Bad KVM trap");
|
|
|
|
|
}
|
KVM: PPC: Book3S HV: Run HPT guests on POWER9 radix hosts
This patch removes the restriction that a radix host can only run
radix guests, allowing us to run HPT (hashed page table) guests as
well. This is useful because it provides a way to run old guest
kernels that know about POWER8 but not POWER9.
Unfortunately, POWER9 currently has a restriction that all threads
in a given code must either all be in HPT mode, or all in radix mode.
This means that when entering a HPT guest, we have to obtain control
of all 4 threads in the core and get them to switch their LPIDR and
LPCR registers, even if they are not going to run a guest. On guest
exit we also have to get all threads to switch LPIDR and LPCR back
to host values.
To make this feasible, we require that KVM not be in the "independent
threads" mode, and that the CPU cores be in single-threaded mode from
the host kernel's perspective (only thread 0 online; threads 1, 2 and
3 offline). That allows us to use the same code as on POWER8 for
obtaining control of the secondary threads.
To manage the LPCR/LPIDR changes required, we extend the kvm_split_info
struct to contain the information needed by the secondary threads.
All threads perform a barrier synchronization (where all threads wait
for every other thread to reach the synchronization point) on guest
entry, both before and after loading LPCR and LPIDR. On guest exit,
they all once again perform a barrier synchronization both before
and after loading host values into LPCR and LPIDR.
Finally, it is also currently necessary to flush the entire TLB every
time we enter a HPT guest on a radix host. We do this on thread 0
with a loop of tlbiel instructions.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2017-10-19 11:11:23 +08:00
|
|
|
|
2019-10-02 14:00:23 +08:00
|
|
|
static void kvmppc_end_cede(struct kvm_vcpu *vcpu)
|
|
|
|
|
{
|
|
|
|
|
vcpu->arch.ceded = 0;
|
|
|
|
|
if (vcpu->arch.timer_running) {
|
|
|
|
|
hrtimer_try_to_cancel(&vcpu->arch.dec_timer);
|
|
|
|
|
vcpu->arch.timer_running = 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void kvmppc_set_msr_hv(struct kvm_vcpu *vcpu, u64 msr)
|
|
|
|
|
{
|
2021-04-12 09:48:44 +08:00
|
|
|
/* Guest must always run with ME enabled. */
|
|
|
|
|
msr = msr | MSR_ME;
|
|
|
|
|
|
2019-10-02 14:00:23 +08:00
|
|
|
/*
|
|
|
|
|
* Check for illegal transactional state bit combination
|
|
|
|
|
* and if we find it, force the TS field to a safe state.
|
|
|
|
|
*/
|
|
|
|
|
if ((msr & MSR_TS_MASK) == MSR_TS_MASK)
|
|
|
|
|
msr &= ~MSR_TS_MASK;
|
|
|
|
|
vcpu->arch.shregs.msr = msr;
|
|
|
|
|
kvmppc_end_cede(vcpu);
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(kvmppc_set_msr_hv);
|
|
|
|
|
|
|
|
|
|
static void inject_interrupt(struct kvm_vcpu *vcpu, int vec, u64 srr1_flags)
|
|
|
|
|
{
|
|
|
|
|
unsigned long msr, pc, new_msr, new_pc;
|
|
|
|
|
|
|
|
|
|
msr = kvmppc_get_msr(vcpu);
|
|
|
|
|
pc = kvmppc_get_pc(vcpu);
|
|
|
|
|
new_msr = vcpu->arch.intr_msr;
|
|
|
|
|
new_pc = vec;
|
|
|
|
|
|
|
|
|
|
/* If transactional, change to suspend mode on IRQ delivery */
|
|
|
|
|
if (MSR_TM_TRANSACTIONAL(msr))
|
|
|
|
|
new_msr |= MSR_TS_S;
|
|
|
|
|
else
|
|
|
|
|
new_msr |= msr & MSR_TS_MASK;
|
|
|
|
|
|
2019-10-02 14:00:24 +08:00
|
|
|
/*
|
|
|
|
|
* Perform MSR and PC adjustment for LPCR[AIL]=3 if it is set and
|
|
|
|
|
* applicable. AIL=2 is not supported.
|
|
|
|
|
*
|
|
|
|
|
* AIL does not apply to SRESET, MCE, or HMI (which is never
|
|
|
|
|
* delivered to the guest), and does not apply if IR=0 or DR=0.
|
|
|
|
|
*/
|
|
|
|
|
if (vec != BOOK3S_INTERRUPT_SYSTEM_RESET &&
|
|
|
|
|
vec != BOOK3S_INTERRUPT_MACHINE_CHECK &&
|
|
|
|
|
(vcpu->arch.vcore->lpcr & LPCR_AIL) == LPCR_AIL_3 &&
|
|
|
|
|
(msr & (MSR_IR|MSR_DR)) == (MSR_IR|MSR_DR) ) {
|
|
|
|
|
new_msr |= MSR_IR | MSR_DR;
|
|
|
|
|
new_pc += 0xC000000000004000ULL;
|
|
|
|
|
}
|
|
|
|
|
|
2019-10-02 14:00:23 +08:00
|
|
|
kvmppc_set_srr0(vcpu, pc);
|
|
|
|
|
kvmppc_set_srr1(vcpu, (msr & SRR1_MSR_BITS) | srr1_flags);
|
|
|
|
|
kvmppc_set_pc(vcpu, new_pc);
|
|
|
|
|
vcpu->arch.shregs.msr = new_msr;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void kvmppc_inject_interrupt_hv(struct kvm_vcpu *vcpu, int vec, u64 srr1_flags)
|
|
|
|
|
{
|
|
|
|
|
inject_interrupt(vcpu, vec, srr1_flags);
|
|
|
|
|
kvmppc_end_cede(vcpu);
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(kvmppc_inject_interrupt_hv);
|
|
|
|
|
|
2018-10-08 13:30:50 +08:00
|
|
|
/*
|
|
|
|
|
* Is there a PRIV_DOORBELL pending for the guest (on POWER9)?
|
|
|
|
|
* Can we inject a Decrementer or a External interrupt?
|
|
|
|
|
*/
|
|
|
|
|
void kvmppc_guest_entry_inject_int(struct kvm_vcpu *vcpu)
|
|
|
|
|
{
|
|
|
|
|
int ext;
|
|
|
|
|
unsigned long lpcr;
|
|
|
|
|
|
|
|
|
|
/* Insert EXTERNAL bit into LPCR at the MER bit position */
|
|
|
|
|
ext = (vcpu->arch.pending_exceptions >> BOOK3S_IRQPRIO_EXTERNAL) & 1;
|
|
|
|
|
lpcr = mfspr(SPRN_LPCR);
|
|
|
|
|
lpcr |= ext << LPCR_MER_SH;
|
|
|
|
|
mtspr(SPRN_LPCR, lpcr);
|
|
|
|
|
isync();
|
|
|
|
|
|
|
|
|
|
if (vcpu->arch.shregs.msr & MSR_EE) {
|
|
|
|
|
if (ext) {
|
2019-10-02 14:00:23 +08:00
|
|
|
inject_interrupt(vcpu, BOOK3S_INTERRUPT_EXTERNAL, 0);
|
2018-10-08 13:30:50 +08:00
|
|
|
} else {
|
|
|
|
|
long int dec = mfspr(SPRN_DEC);
|
|
|
|
|
if (!(lpcr & LPCR_LD))
|
|
|
|
|
dec = (int) dec;
|
|
|
|
|
if (dec < 0)
|
2019-10-02 14:00:23 +08:00
|
|
|
inject_interrupt(vcpu,
|
|
|
|
|
BOOK3S_INTERRUPT_DECREMENTER, 0);
|
2018-10-08 13:30:50 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (vcpu->arch.doorbell_request) {
|
|
|
|
|
mtspr(SPRN_DPDES, 1);
|
|
|
|
|
vcpu->arch.vcore->dpdes = 1;
|
|
|
|
|
smp_wmb();
|
|
|
|
|
vcpu->arch.doorbell_request = 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-04-29 17:00:40 +08:00
|
|
|
|
KVM: PPC: Book3S HV: Flush TLB on secondary radix threads
When running on POWER9 with kvm_hv.indep_threads_mode = N and the host
in SMT1 mode, KVM will run guest VCPUs on offline secondary threads.
If those guests are in radix mode, we fail to load the LPID and flush
the TLB if necessary, leading to the guest crashing with an
unsupported MMU fault. This arises from commit 9a4506e11b97 ("KVM:
PPC: Book3S HV: Make radix handle process scoped LPID flush in C,
with relocation on", 2018-05-17), which didn't consider the case
where indep_threads_mode = N.
For simplicity, this makes the real-mode guest entry path flush the
TLB in the same place for both radix and hash guests, as we did before
9a4506e11b97, though the code is now C code rather than assembly code.
We also have the radix TLB flush open-coded rather than calling
radix__local_flush_tlb_lpid_guest(), because the TLB flush can be
called in real mode, and in real mode we don't want to invoke the
tracepoint code.
Fixes: 9a4506e11b97 ("KVM: PPC: Book3S HV: Make radix handle process scoped LPID flush in C, with relocation on")
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2019-04-29 17:02:58 +08:00
|
|
|
static void flush_guest_tlb(struct kvm *kvm)
|
2019-04-29 17:00:40 +08:00
|
|
|
{
|
|
|
|
|
unsigned long rb, set;
|
|
|
|
|
|
KVM: PPC: Book3S HV: Flush TLB on secondary radix threads
When running on POWER9 with kvm_hv.indep_threads_mode = N and the host
in SMT1 mode, KVM will run guest VCPUs on offline secondary threads.
If those guests are in radix mode, we fail to load the LPID and flush
the TLB if necessary, leading to the guest crashing with an
unsupported MMU fault. This arises from commit 9a4506e11b97 ("KVM:
PPC: Book3S HV: Make radix handle process scoped LPID flush in C,
with relocation on", 2018-05-17), which didn't consider the case
where indep_threads_mode = N.
For simplicity, this makes the real-mode guest entry path flush the
TLB in the same place for both radix and hash guests, as we did before
9a4506e11b97, though the code is now C code rather than assembly code.
We also have the radix TLB flush open-coded rather than calling
radix__local_flush_tlb_lpid_guest(), because the TLB flush can be
called in real mode, and in real mode we don't want to invoke the
tracepoint code.
Fixes: 9a4506e11b97 ("KVM: PPC: Book3S HV: Make radix handle process scoped LPID flush in C, with relocation on")
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2019-04-29 17:02:58 +08:00
|
|
|
rb = PPC_BIT(52); /* IS = 2 */
|
|
|
|
|
if (kvm_is_radix(kvm)) {
|
|
|
|
|
/* R=1 PRS=1 RIC=2 */
|
|
|
|
|
asm volatile(PPC_TLBIEL(%0, %4, %3, %2, %1)
|
|
|
|
|
: : "r" (rb), "i" (1), "i" (1), "i" (2),
|
|
|
|
|
"r" (0) : "memory");
|
|
|
|
|
for (set = 1; set < kvm->arch.tlb_sets; ++set) {
|
|
|
|
|
rb += PPC_BIT(51); /* increment set number */
|
|
|
|
|
/* R=1 PRS=1 RIC=0 */
|
|
|
|
|
asm volatile(PPC_TLBIEL(%0, %4, %3, %2, %1)
|
|
|
|
|
: : "r" (rb), "i" (1), "i" (1), "i" (0),
|
|
|
|
|
"r" (0) : "memory");
|
|
|
|
|
}
|
2019-06-23 18:41:52 +08:00
|
|
|
asm volatile("ptesync": : :"memory");
|
|
|
|
|
asm volatile(PPC_RADIX_INVALIDATE_ERAT_GUEST : : :"memory");
|
KVM: PPC: Book3S HV: Flush TLB on secondary radix threads
When running on POWER9 with kvm_hv.indep_threads_mode = N and the host
in SMT1 mode, KVM will run guest VCPUs on offline secondary threads.
If those guests are in radix mode, we fail to load the LPID and flush
the TLB if necessary, leading to the guest crashing with an
unsupported MMU fault. This arises from commit 9a4506e11b97 ("KVM:
PPC: Book3S HV: Make radix handle process scoped LPID flush in C,
with relocation on", 2018-05-17), which didn't consider the case
where indep_threads_mode = N.
For simplicity, this makes the real-mode guest entry path flush the
TLB in the same place for both radix and hash guests, as we did before
9a4506e11b97, though the code is now C code rather than assembly code.
We also have the radix TLB flush open-coded rather than calling
radix__local_flush_tlb_lpid_guest(), because the TLB flush can be
called in real mode, and in real mode we don't want to invoke the
tracepoint code.
Fixes: 9a4506e11b97 ("KVM: PPC: Book3S HV: Make radix handle process scoped LPID flush in C, with relocation on")
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2019-04-29 17:02:58 +08:00
|
|
|
} else {
|
|
|
|
|
for (set = 0; set < kvm->arch.tlb_sets; ++set) {
|
|
|
|
|
/* R=0 PRS=0 RIC=0 */
|
|
|
|
|
asm volatile(PPC_TLBIEL(%0, %4, %3, %2, %1)
|
|
|
|
|
: : "r" (rb), "i" (0), "i" (0), "i" (0),
|
|
|
|
|
"r" (0) : "memory");
|
|
|
|
|
rb += PPC_BIT(51); /* increment set number */
|
|
|
|
|
}
|
2019-06-23 18:41:52 +08:00
|
|
|
asm volatile("ptesync": : :"memory");
|
|
|
|
|
asm volatile(PPC_ISA_3_0_INVALIDATE_ERAT : : :"memory");
|
KVM: PPC: Book3S HV: Flush TLB on secondary radix threads
When running on POWER9 with kvm_hv.indep_threads_mode = N and the host
in SMT1 mode, KVM will run guest VCPUs on offline secondary threads.
If those guests are in radix mode, we fail to load the LPID and flush
the TLB if necessary, leading to the guest crashing with an
unsupported MMU fault. This arises from commit 9a4506e11b97 ("KVM:
PPC: Book3S HV: Make radix handle process scoped LPID flush in C,
with relocation on", 2018-05-17), which didn't consider the case
where indep_threads_mode = N.
For simplicity, this makes the real-mode guest entry path flush the
TLB in the same place for both radix and hash guests, as we did before
9a4506e11b97, though the code is now C code rather than assembly code.
We also have the radix TLB flush open-coded rather than calling
radix__local_flush_tlb_lpid_guest(), because the TLB flush can be
called in real mode, and in real mode we don't want to invoke the
tracepoint code.
Fixes: 9a4506e11b97 ("KVM: PPC: Book3S HV: Make radix handle process scoped LPID flush in C, with relocation on")
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2019-04-29 17:02:58 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void kvmppc_check_need_tlb_flush(struct kvm *kvm, int pcpu,
|
|
|
|
|
struct kvm_nested_guest *nested)
|
|
|
|
|
{
|
|
|
|
|
cpumask_t *need_tlb_flush;
|
|
|
|
|
|
2019-04-29 17:00:40 +08:00
|
|
|
/*
|
|
|
|
|
* On POWER9, individual threads can come in here, but the
|
|
|
|
|
* TLB is shared between the 4 threads in a core, hence
|
|
|
|
|
* invalidating on one thread invalidates for all.
|
|
|
|
|
* Thus we make all 4 threads use the same bit.
|
|
|
|
|
*/
|
|
|
|
|
if (cpu_has_feature(CPU_FTR_ARCH_300))
|
|
|
|
|
pcpu = cpu_first_thread_sibling(pcpu);
|
|
|
|
|
|
KVM: PPC: Book3S HV: Flush TLB on secondary radix threads
When running on POWER9 with kvm_hv.indep_threads_mode = N and the host
in SMT1 mode, KVM will run guest VCPUs on offline secondary threads.
If those guests are in radix mode, we fail to load the LPID and flush
the TLB if necessary, leading to the guest crashing with an
unsupported MMU fault. This arises from commit 9a4506e11b97 ("KVM:
PPC: Book3S HV: Make radix handle process scoped LPID flush in C,
with relocation on", 2018-05-17), which didn't consider the case
where indep_threads_mode = N.
For simplicity, this makes the real-mode guest entry path flush the
TLB in the same place for both radix and hash guests, as we did before
9a4506e11b97, though the code is now C code rather than assembly code.
We also have the radix TLB flush open-coded rather than calling
radix__local_flush_tlb_lpid_guest(), because the TLB flush can be
called in real mode, and in real mode we don't want to invoke the
tracepoint code.
Fixes: 9a4506e11b97 ("KVM: PPC: Book3S HV: Make radix handle process scoped LPID flush in C, with relocation on")
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2019-04-29 17:02:58 +08:00
|
|
|
if (nested)
|
|
|
|
|
need_tlb_flush = &nested->need_tlb_flush;
|
|
|
|
|
else
|
|
|
|
|
need_tlb_flush = &kvm->arch.need_tlb_flush;
|
|
|
|
|
|
|
|
|
|
if (cpumask_test_cpu(pcpu, need_tlb_flush)) {
|
|
|
|
|
flush_guest_tlb(kvm);
|
2019-04-29 17:00:40 +08:00
|
|
|
|
|
|
|
|
/* Clear the bit after the TLB flush */
|
KVM: PPC: Book3S HV: Flush TLB on secondary radix threads
When running on POWER9 with kvm_hv.indep_threads_mode = N and the host
in SMT1 mode, KVM will run guest VCPUs on offline secondary threads.
If those guests are in radix mode, we fail to load the LPID and flush
the TLB if necessary, leading to the guest crashing with an
unsupported MMU fault. This arises from commit 9a4506e11b97 ("KVM:
PPC: Book3S HV: Make radix handle process scoped LPID flush in C,
with relocation on", 2018-05-17), which didn't consider the case
where indep_threads_mode = N.
For simplicity, this makes the real-mode guest entry path flush the
TLB in the same place for both radix and hash guests, as we did before
9a4506e11b97, though the code is now C code rather than assembly code.
We also have the radix TLB flush open-coded rather than calling
radix__local_flush_tlb_lpid_guest(), because the TLB flush can be
called in real mode, and in real mode we don't want to invoke the
tracepoint code.
Fixes: 9a4506e11b97 ("KVM: PPC: Book3S HV: Make radix handle process scoped LPID flush in C, with relocation on")
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2019-04-29 17:02:58 +08:00
|
|
|
cpumask_clear_cpu(pcpu, need_tlb_flush);
|
2019-04-29 17:00:40 +08:00
|
|
|
}
|
|
|
|
|
}
|
KVM: PPC: Book3S HV: Flush TLB on secondary radix threads
When running on POWER9 with kvm_hv.indep_threads_mode = N and the host
in SMT1 mode, KVM will run guest VCPUs on offline secondary threads.
If those guests are in radix mode, we fail to load the LPID and flush
the TLB if necessary, leading to the guest crashing with an
unsupported MMU fault. This arises from commit 9a4506e11b97 ("KVM:
PPC: Book3S HV: Make radix handle process scoped LPID flush in C,
with relocation on", 2018-05-17), which didn't consider the case
where indep_threads_mode = N.
For simplicity, this makes the real-mode guest entry path flush the
TLB in the same place for both radix and hash guests, as we did before
9a4506e11b97, though the code is now C code rather than assembly code.
We also have the radix TLB flush open-coded rather than calling
radix__local_flush_tlb_lpid_guest(), because the TLB flush can be
called in real mode, and in real mode we don't want to invoke the
tracepoint code.
Fixes: 9a4506e11b97 ("KVM: PPC: Book3S HV: Make radix handle process scoped LPID flush in C, with relocation on")
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2019-04-29 17:02:58 +08:00
|
|
|
EXPORT_SYMBOL_GPL(kvmppc_check_need_tlb_flush);
|