2019-06-04 16:11:33 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2011-08-08 23:21:15 +08:00
|
|
|
/*
|
|
|
|
|
* Copyright (C) 2011. Freescale Inc. All rights reserved.
|
|
|
|
|
*
|
|
|
|
|
* Authors:
|
|
|
|
|
* Alexander Graf <agraf@suse.de>
|
|
|
|
|
* Paul Mackerras <paulus@samba.org>
|
|
|
|
|
*
|
|
|
|
|
* Description:
|
|
|
|
|
*
|
|
|
|
|
* Hypercall handling for running PAPR guests in PR KVM on Book 3S
|
|
|
|
|
* processors.
|
|
|
|
|
*/
|
|
|
|
|
|
2012-03-16 05:58:34 +08:00
|
|
|
#include <linux/anon_inodes.h>
|
|
|
|
|
|
2016-12-25 03:46:01 +08:00
|
|
|
#include <linux/uaccess.h>
|
2011-08-08 23:21:15 +08:00
|
|
|
#include <asm/kvm_ppc.h>
|
|
|
|
|
#include <asm/kvm_book3s.h>
|
|
|
|
|
|
2013-09-20 12:52:47 +08:00
|
|
|
#define HPTE_SIZE 16 /* bytes per HPT entry */
|
|
|
|
|
|
2011-08-08 23:21:15 +08:00
|
|
|
static unsigned long get_pteg_addr(struct kvm_vcpu *vcpu, long pte_index)
|
|
|
|
|
{
|
|
|
|
|
struct kvmppc_vcpu_book3s *vcpu_book3s = to_book3s(vcpu);
|
|
|
|
|
unsigned long pteg_addr;
|
|
|
|
|
|
|
|
|
|
pte_index <<= 4;
|
|
|
|
|
pte_index &= ((1 << ((vcpu_book3s->sdr1 & 0x1f) + 11)) - 1) << 7 | 0x70;
|
|
|
|
|
pteg_addr = vcpu_book3s->sdr1 & 0xfffffffffffc0000ULL;
|
|
|
|
|
pteg_addr |= pte_index;
|
|
|
|
|
|
|
|
|
|
return pteg_addr;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int kvmppc_h_pr_enter(struct kvm_vcpu *vcpu)
|
|
|
|
|
{
|
|
|
|
|
long flags = kvmppc_get_gpr(vcpu, 4);
|
|
|
|
|
long pte_index = kvmppc_get_gpr(vcpu, 5);
|
2014-06-16 19:58:11 +08:00
|
|
|
__be64 pteg[2 * 8];
|
|
|
|
|
__be64 *hpte;
|
|
|
|
|
unsigned long pteg_addr, i;
|
2013-09-20 12:52:47 +08:00
|
|
|
long int ret;
|
2011-08-08 23:21:15 +08:00
|
|
|
|
2013-09-20 12:52:47 +08:00
|
|
|
i = pte_index & 7;
|
2011-08-08 23:21:15 +08:00
|
|
|
pte_index &= ~7UL;
|
|
|
|
|
pteg_addr = get_pteg_addr(vcpu, pte_index);
|
|
|
|
|
|
KVM: PPC: Book3S PR: Make HPT accesses and updates SMP-safe
This adds a per-VM mutex to provide mutual exclusion between vcpus
for accesses to and updates of the guest hashed page table (HPT).
This also makes the code use single-byte writes to the HPT entry
when updating of the reference (R) and change (C) bits. The reason
for doing this, rather than writing back the whole HPTE, is that on
non-PAPR virtual machines, the guest OS might be writing to the HPTE
concurrently, and writing back the whole HPTE might conflict with
that. Also, real hardware does single-byte writes to update R and C.
The new mutex is taken in kvmppc_mmu_book3s_64_xlate() when reading
the HPT and updating R and/or C, and in the PAPR HPT update hcalls
(H_ENTER, H_REMOVE, etc.). Having the mutex means that we don't need
to use a hypervisor lock bit in the HPT update hcalls, and we don't
need to be careful about the order in which the bytes of the HPTE are
updated by those hcalls.
The other change here is to make emulated TLB invalidations (tlbie)
effective across all vcpus. To do this we call kvmppc_mmu_pte_vflush
for all vcpus in kvmppc_ppc_book3s_64_tlbie().
For 32-bit, this makes the setting of the accessed and dirty bits use
single-byte writes, and makes tlbie invalidate shadow HPTEs for all
vcpus.
With this, PR KVM can successfully run SMP guests.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2013-09-20 12:52:48 +08:00
|
|
|
mutex_lock(&vcpu->kvm->arch.hpt_mutex);
|
KVM: PPC: Book3S PR: Check copy_to/from_user return values
The PR KVM implementation of the PAPR HPT hypercalls (H_ENTER etc.)
access an image of the HPT in userspace memory using copy_from_user
and copy_to_user. Recently, the declarations of those functions were
annotated to indicate that the return value must be checked. Since
this code doesn't currently check the return value, this causes
compile warnings like the ones shown below, and since on PPC the
default is to compile arch/powerpc with -Werror, this causes the
build to fail.
To fix this, we check the return values, and if non-zero, fail the
hypercall being processed with a H_FUNCTION error return value.
There is really no good error return value to use since PAPR didn't
envisage the possibility that the hypervisor may not be able to access
the guest's HPT, and H_FUNCTION (function not supported) seems as
good as any.
The typical compile warnings look like this:
CC arch/powerpc/kvm/book3s_pr_papr.o
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_pr_papr.c: In function ‘kvmppc_h_pr_enter’:
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_pr_papr.c:53:2: error: ignoring return value of ‘copy_from_user’, declared with attribute warn_unused_result [-Werror=unused-result]
copy_from_user(pteg, (void __user *)pteg_addr, sizeof(pteg));
^
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_pr_papr.c:74:2: error: ignoring return value of ‘copy_to_user’, declared with attribute warn_unused_result [-Werror=unused-result]
copy_to_user((void __user *)pteg_addr, hpte, HPTE_SIZE);
^
... etc.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2017-05-11 09:33:30 +08:00
|
|
|
ret = H_FUNCTION;
|
|
|
|
|
if (copy_from_user(pteg, (void __user *)pteg_addr, sizeof(pteg)))
|
|
|
|
|
goto done;
|
2011-08-08 23:21:15 +08:00
|
|
|
hpte = pteg;
|
|
|
|
|
|
2013-09-20 12:52:47 +08:00
|
|
|
ret = H_PTEG_FULL;
|
2011-08-08 23:21:15 +08:00
|
|
|
if (likely((flags & H_EXACT) == 0)) {
|
|
|
|
|
for (i = 0; ; ++i) {
|
|
|
|
|
if (i == 8)
|
2013-09-20 12:52:47 +08:00
|
|
|
goto done;
|
2014-04-24 19:09:15 +08:00
|
|
|
if ((be64_to_cpu(*hpte) & HPTE_V_VALID) == 0)
|
2011-08-08 23:21:15 +08:00
|
|
|
break;
|
|
|
|
|
hpte += 2;
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
hpte += i * 2;
|
2013-09-20 12:52:47 +08:00
|
|
|
if (*hpte & HPTE_V_VALID)
|
|
|
|
|
goto done;
|
2011-08-08 23:21:15 +08:00
|
|
|
}
|
|
|
|
|
|
2014-04-24 19:09:15 +08:00
|
|
|
hpte[0] = cpu_to_be64(kvmppc_get_gpr(vcpu, 6));
|
|
|
|
|
hpte[1] = cpu_to_be64(kvmppc_get_gpr(vcpu, 7));
|
2013-09-20 12:52:47 +08:00
|
|
|
pteg_addr += i * HPTE_SIZE;
|
KVM: PPC: Book3S PR: Check copy_to/from_user return values
The PR KVM implementation of the PAPR HPT hypercalls (H_ENTER etc.)
access an image of the HPT in userspace memory using copy_from_user
and copy_to_user. Recently, the declarations of those functions were
annotated to indicate that the return value must be checked. Since
this code doesn't currently check the return value, this causes
compile warnings like the ones shown below, and since on PPC the
default is to compile arch/powerpc with -Werror, this causes the
build to fail.
To fix this, we check the return values, and if non-zero, fail the
hypercall being processed with a H_FUNCTION error return value.
There is really no good error return value to use since PAPR didn't
envisage the possibility that the hypervisor may not be able to access
the guest's HPT, and H_FUNCTION (function not supported) seems as
good as any.
The typical compile warnings look like this:
CC arch/powerpc/kvm/book3s_pr_papr.o
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_pr_papr.c: In function ‘kvmppc_h_pr_enter’:
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_pr_papr.c:53:2: error: ignoring return value of ‘copy_from_user’, declared with attribute warn_unused_result [-Werror=unused-result]
copy_from_user(pteg, (void __user *)pteg_addr, sizeof(pteg));
^
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_pr_papr.c:74:2: error: ignoring return value of ‘copy_to_user’, declared with attribute warn_unused_result [-Werror=unused-result]
copy_to_user((void __user *)pteg_addr, hpte, HPTE_SIZE);
^
... etc.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2017-05-11 09:33:30 +08:00
|
|
|
ret = H_FUNCTION;
|
|
|
|
|
if (copy_to_user((void __user *)pteg_addr, hpte, HPTE_SIZE))
|
|
|
|
|
goto done;
|
2011-08-08 23:21:15 +08:00
|
|
|
kvmppc_set_gpr(vcpu, 4, pte_index | i);
|
2013-09-20 12:52:47 +08:00
|
|
|
ret = H_SUCCESS;
|
|
|
|
|
|
|
|
|
|
done:
|
KVM: PPC: Book3S PR: Make HPT accesses and updates SMP-safe
This adds a per-VM mutex to provide mutual exclusion between vcpus
for accesses to and updates of the guest hashed page table (HPT).
This also makes the code use single-byte writes to the HPT entry
when updating of the reference (R) and change (C) bits. The reason
for doing this, rather than writing back the whole HPTE, is that on
non-PAPR virtual machines, the guest OS might be writing to the HPTE
concurrently, and writing back the whole HPTE might conflict with
that. Also, real hardware does single-byte writes to update R and C.
The new mutex is taken in kvmppc_mmu_book3s_64_xlate() when reading
the HPT and updating R and/or C, and in the PAPR HPT update hcalls
(H_ENTER, H_REMOVE, etc.). Having the mutex means that we don't need
to use a hypervisor lock bit in the HPT update hcalls, and we don't
need to be careful about the order in which the bytes of the HPTE are
updated by those hcalls.
The other change here is to make emulated TLB invalidations (tlbie)
effective across all vcpus. To do this we call kvmppc_mmu_pte_vflush
for all vcpus in kvmppc_ppc_book3s_64_tlbie().
For 32-bit, this makes the setting of the accessed and dirty bits use
single-byte writes, and makes tlbie invalidate shadow HPTEs for all
vcpus.
With this, PR KVM can successfully run SMP guests.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2013-09-20 12:52:48 +08:00
|
|
|
mutex_unlock(&vcpu->kvm->arch.hpt_mutex);
|
2013-09-20 12:52:47 +08:00
|
|
|
kvmppc_set_gpr(vcpu, 3, ret);
|
2011-08-08 23:21:15 +08:00
|
|
|
|
|
|
|
|
return EMULATE_DONE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int kvmppc_h_pr_remove(struct kvm_vcpu *vcpu)
|
|
|
|
|
{
|
|
|
|
|
unsigned long flags= kvmppc_get_gpr(vcpu, 4);
|
|
|
|
|
unsigned long pte_index = kvmppc_get_gpr(vcpu, 5);
|
|
|
|
|
unsigned long avpn = kvmppc_get_gpr(vcpu, 6);
|
|
|
|
|
unsigned long v = 0, pteg, rb;
|
|
|
|
|
unsigned long pte[2];
|
KVM: PPC: Book3S PR: Make HPT accesses and updates SMP-safe
This adds a per-VM mutex to provide mutual exclusion between vcpus
for accesses to and updates of the guest hashed page table (HPT).
This also makes the code use single-byte writes to the HPT entry
when updating of the reference (R) and change (C) bits. The reason
for doing this, rather than writing back the whole HPTE, is that on
non-PAPR virtual machines, the guest OS might be writing to the HPTE
concurrently, and writing back the whole HPTE might conflict with
that. Also, real hardware does single-byte writes to update R and C.
The new mutex is taken in kvmppc_mmu_book3s_64_xlate() when reading
the HPT and updating R and/or C, and in the PAPR HPT update hcalls
(H_ENTER, H_REMOVE, etc.). Having the mutex means that we don't need
to use a hypervisor lock bit in the HPT update hcalls, and we don't
need to be careful about the order in which the bytes of the HPTE are
updated by those hcalls.
The other change here is to make emulated TLB invalidations (tlbie)
effective across all vcpus. To do this we call kvmppc_mmu_pte_vflush
for all vcpus in kvmppc_ppc_book3s_64_tlbie().
For 32-bit, this makes the setting of the accessed and dirty bits use
single-byte writes, and makes tlbie invalidate shadow HPTEs for all
vcpus.
With this, PR KVM can successfully run SMP guests.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2013-09-20 12:52:48 +08:00
|
|
|
long int ret;
|
2011-08-08 23:21:15 +08:00
|
|
|
|
|
|
|
|
pteg = get_pteg_addr(vcpu, pte_index);
|
KVM: PPC: Book3S PR: Make HPT accesses and updates SMP-safe
This adds a per-VM mutex to provide mutual exclusion between vcpus
for accesses to and updates of the guest hashed page table (HPT).
This also makes the code use single-byte writes to the HPT entry
when updating of the reference (R) and change (C) bits. The reason
for doing this, rather than writing back the whole HPTE, is that on
non-PAPR virtual machines, the guest OS might be writing to the HPTE
concurrently, and writing back the whole HPTE might conflict with
that. Also, real hardware does single-byte writes to update R and C.
The new mutex is taken in kvmppc_mmu_book3s_64_xlate() when reading
the HPT and updating R and/or C, and in the PAPR HPT update hcalls
(H_ENTER, H_REMOVE, etc.). Having the mutex means that we don't need
to use a hypervisor lock bit in the HPT update hcalls, and we don't
need to be careful about the order in which the bytes of the HPTE are
updated by those hcalls.
The other change here is to make emulated TLB invalidations (tlbie)
effective across all vcpus. To do this we call kvmppc_mmu_pte_vflush
for all vcpus in kvmppc_ppc_book3s_64_tlbie().
For 32-bit, this makes the setting of the accessed and dirty bits use
single-byte writes, and makes tlbie invalidate shadow HPTEs for all
vcpus.
With this, PR KVM can successfully run SMP guests.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2013-09-20 12:52:48 +08:00
|
|
|
mutex_lock(&vcpu->kvm->arch.hpt_mutex);
|
KVM: PPC: Book3S PR: Check copy_to/from_user return values
The PR KVM implementation of the PAPR HPT hypercalls (H_ENTER etc.)
access an image of the HPT in userspace memory using copy_from_user
and copy_to_user. Recently, the declarations of those functions were
annotated to indicate that the return value must be checked. Since
this code doesn't currently check the return value, this causes
compile warnings like the ones shown below, and since on PPC the
default is to compile arch/powerpc with -Werror, this causes the
build to fail.
To fix this, we check the return values, and if non-zero, fail the
hypercall being processed with a H_FUNCTION error return value.
There is really no good error return value to use since PAPR didn't
envisage the possibility that the hypervisor may not be able to access
the guest's HPT, and H_FUNCTION (function not supported) seems as
good as any.
The typical compile warnings look like this:
CC arch/powerpc/kvm/book3s_pr_papr.o
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_pr_papr.c: In function ‘kvmppc_h_pr_enter’:
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_pr_papr.c:53:2: error: ignoring return value of ‘copy_from_user’, declared with attribute warn_unused_result [-Werror=unused-result]
copy_from_user(pteg, (void __user *)pteg_addr, sizeof(pteg));
^
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_pr_papr.c:74:2: error: ignoring return value of ‘copy_to_user’, declared with attribute warn_unused_result [-Werror=unused-result]
copy_to_user((void __user *)pteg_addr, hpte, HPTE_SIZE);
^
... etc.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2017-05-11 09:33:30 +08:00
|
|
|
ret = H_FUNCTION;
|
|
|
|
|
if (copy_from_user(pte, (void __user *)pteg, sizeof(pte)))
|
|
|
|
|
goto done;
|
2014-06-16 19:58:11 +08:00
|
|
|
pte[0] = be64_to_cpu((__force __be64)pte[0]);
|
|
|
|
|
pte[1] = be64_to_cpu((__force __be64)pte[1]);
|
2011-08-08 23:21:15 +08:00
|
|
|
|
KVM: PPC: Book3S PR: Make HPT accesses and updates SMP-safe
This adds a per-VM mutex to provide mutual exclusion between vcpus
for accesses to and updates of the guest hashed page table (HPT).
This also makes the code use single-byte writes to the HPT entry
when updating of the reference (R) and change (C) bits. The reason
for doing this, rather than writing back the whole HPTE, is that on
non-PAPR virtual machines, the guest OS might be writing to the HPTE
concurrently, and writing back the whole HPTE might conflict with
that. Also, real hardware does single-byte writes to update R and C.
The new mutex is taken in kvmppc_mmu_book3s_64_xlate() when reading
the HPT and updating R and/or C, and in the PAPR HPT update hcalls
(H_ENTER, H_REMOVE, etc.). Having the mutex means that we don't need
to use a hypervisor lock bit in the HPT update hcalls, and we don't
need to be careful about the order in which the bytes of the HPTE are
updated by those hcalls.
The other change here is to make emulated TLB invalidations (tlbie)
effective across all vcpus. To do this we call kvmppc_mmu_pte_vflush
for all vcpus in kvmppc_ppc_book3s_64_tlbie().
For 32-bit, this makes the setting of the accessed and dirty bits use
single-byte writes, and makes tlbie invalidate shadow HPTEs for all
vcpus.
With this, PR KVM can successfully run SMP guests.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2013-09-20 12:52:48 +08:00
|
|
|
ret = H_NOT_FOUND;
|
2011-08-08 23:21:15 +08:00
|
|
|
if ((pte[0] & HPTE_V_VALID) == 0 ||
|
|
|
|
|
((flags & H_AVPN) && (pte[0] & ~0x7fUL) != avpn) ||
|
KVM: PPC: Book3S PR: Make HPT accesses and updates SMP-safe
This adds a per-VM mutex to provide mutual exclusion between vcpus
for accesses to and updates of the guest hashed page table (HPT).
This also makes the code use single-byte writes to the HPT entry
when updating of the reference (R) and change (C) bits. The reason
for doing this, rather than writing back the whole HPTE, is that on
non-PAPR virtual machines, the guest OS might be writing to the HPTE
concurrently, and writing back the whole HPTE might conflict with
that. Also, real hardware does single-byte writes to update R and C.
The new mutex is taken in kvmppc_mmu_book3s_64_xlate() when reading
the HPT and updating R and/or C, and in the PAPR HPT update hcalls
(H_ENTER, H_REMOVE, etc.). Having the mutex means that we don't need
to use a hypervisor lock bit in the HPT update hcalls, and we don't
need to be careful about the order in which the bytes of the HPTE are
updated by those hcalls.
The other change here is to make emulated TLB invalidations (tlbie)
effective across all vcpus. To do this we call kvmppc_mmu_pte_vflush
for all vcpus in kvmppc_ppc_book3s_64_tlbie().
For 32-bit, this makes the setting of the accessed and dirty bits use
single-byte writes, and makes tlbie invalidate shadow HPTEs for all
vcpus.
With this, PR KVM can successfully run SMP guests.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2013-09-20 12:52:48 +08:00
|
|
|
((flags & H_ANDCOND) && (pte[0] & avpn) != 0))
|
|
|
|
|
goto done;
|
2011-08-08 23:21:15 +08:00
|
|
|
|
KVM: PPC: Book3S PR: Check copy_to/from_user return values
The PR KVM implementation of the PAPR HPT hypercalls (H_ENTER etc.)
access an image of the HPT in userspace memory using copy_from_user
and copy_to_user. Recently, the declarations of those functions were
annotated to indicate that the return value must be checked. Since
this code doesn't currently check the return value, this causes
compile warnings like the ones shown below, and since on PPC the
default is to compile arch/powerpc with -Werror, this causes the
build to fail.
To fix this, we check the return values, and if non-zero, fail the
hypercall being processed with a H_FUNCTION error return value.
There is really no good error return value to use since PAPR didn't
envisage the possibility that the hypervisor may not be able to access
the guest's HPT, and H_FUNCTION (function not supported) seems as
good as any.
The typical compile warnings look like this:
CC arch/powerpc/kvm/book3s_pr_papr.o
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_pr_papr.c: In function ‘kvmppc_h_pr_enter’:
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_pr_papr.c:53:2: error: ignoring return value of ‘copy_from_user’, declared with attribute warn_unused_result [-Werror=unused-result]
copy_from_user(pteg, (void __user *)pteg_addr, sizeof(pteg));
^
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_pr_papr.c:74:2: error: ignoring return value of ‘copy_to_user’, declared with attribute warn_unused_result [-Werror=unused-result]
copy_to_user((void __user *)pteg_addr, hpte, HPTE_SIZE);
^
... etc.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2017-05-11 09:33:30 +08:00
|
|
|
ret = H_FUNCTION;
|
|
|
|
|
if (copy_to_user((void __user *)pteg, &v, sizeof(v)))
|
|
|
|
|
goto done;
|
2011-08-08 23:21:15 +08:00
|
|
|
|
|
|
|
|
rb = compute_tlbie_rb(pte[0], pte[1], pte_index);
|
|
|
|
|
vcpu->arch.mmu.tlbie(vcpu, rb, rb & 1 ? true : false);
|
|
|
|
|
|
KVM: PPC: Book3S PR: Make HPT accesses and updates SMP-safe
This adds a per-VM mutex to provide mutual exclusion between vcpus
for accesses to and updates of the guest hashed page table (HPT).
This also makes the code use single-byte writes to the HPT entry
when updating of the reference (R) and change (C) bits. The reason
for doing this, rather than writing back the whole HPTE, is that on
non-PAPR virtual machines, the guest OS might be writing to the HPTE
concurrently, and writing back the whole HPTE might conflict with
that. Also, real hardware does single-byte writes to update R and C.
The new mutex is taken in kvmppc_mmu_book3s_64_xlate() when reading
the HPT and updating R and/or C, and in the PAPR HPT update hcalls
(H_ENTER, H_REMOVE, etc.). Having the mutex means that we don't need
to use a hypervisor lock bit in the HPT update hcalls, and we don't
need to be careful about the order in which the bytes of the HPTE are
updated by those hcalls.
The other change here is to make emulated TLB invalidations (tlbie)
effective across all vcpus. To do this we call kvmppc_mmu_pte_vflush
for all vcpus in kvmppc_ppc_book3s_64_tlbie().
For 32-bit, this makes the setting of the accessed and dirty bits use
single-byte writes, and makes tlbie invalidate shadow HPTEs for all
vcpus.
With this, PR KVM can successfully run SMP guests.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2013-09-20 12:52:48 +08:00
|
|
|
ret = H_SUCCESS;
|
2011-08-08 23:21:15 +08:00
|
|
|
kvmppc_set_gpr(vcpu, 4, pte[0]);
|
|
|
|
|
kvmppc_set_gpr(vcpu, 5, pte[1]);
|
|
|
|
|
|
KVM: PPC: Book3S PR: Make HPT accesses and updates SMP-safe
This adds a per-VM mutex to provide mutual exclusion between vcpus
for accesses to and updates of the guest hashed page table (HPT).
This also makes the code use single-byte writes to the HPT entry
when updating of the reference (R) and change (C) bits. The reason
for doing this, rather than writing back the whole HPTE, is that on
non-PAPR virtual machines, the guest OS might be writing to the HPTE
concurrently, and writing back the whole HPTE might conflict with
that. Also, real hardware does single-byte writes to update R and C.
The new mutex is taken in kvmppc_mmu_book3s_64_xlate() when reading
the HPT and updating R and/or C, and in the PAPR HPT update hcalls
(H_ENTER, H_REMOVE, etc.). Having the mutex means that we don't need
to use a hypervisor lock bit in the HPT update hcalls, and we don't
need to be careful about the order in which the bytes of the HPTE are
updated by those hcalls.
The other change here is to make emulated TLB invalidations (tlbie)
effective across all vcpus. To do this we call kvmppc_mmu_pte_vflush
for all vcpus in kvmppc_ppc_book3s_64_tlbie().
For 32-bit, this makes the setting of the accessed and dirty bits use
single-byte writes, and makes tlbie invalidate shadow HPTEs for all
vcpus.
With this, PR KVM can successfully run SMP guests.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2013-09-20 12:52:48 +08:00
|
|
|
done:
|
|
|
|
|
mutex_unlock(&vcpu->kvm->arch.hpt_mutex);
|
|
|
|
|
kvmppc_set_gpr(vcpu, 3, ret);
|
|
|
|
|
|
2011-08-08 23:21:15 +08:00
|
|
|
return EMULATE_DONE;
|
|
|
|
|
}
|
|
|
|
|
|
2012-01-31 04:25:31 +08:00
|
|
|
/* Request defs for kvmppc_h_pr_bulk_remove() */
|
|
|
|
|
#define H_BULK_REMOVE_TYPE 0xc000000000000000ULL
|
|
|
|
|
#define H_BULK_REMOVE_REQUEST 0x4000000000000000ULL
|
|
|
|
|
#define H_BULK_REMOVE_RESPONSE 0x8000000000000000ULL
|
|
|
|
|
#define H_BULK_REMOVE_END 0xc000000000000000ULL
|
|
|
|
|
#define H_BULK_REMOVE_CODE 0x3000000000000000ULL
|
|
|
|
|
#define H_BULK_REMOVE_SUCCESS 0x0000000000000000ULL
|
|
|
|
|
#define H_BULK_REMOVE_NOT_FOUND 0x1000000000000000ULL
|
|
|
|
|
#define H_BULK_REMOVE_PARM 0x2000000000000000ULL
|
|
|
|
|
#define H_BULK_REMOVE_HW 0x3000000000000000ULL
|
|
|
|
|
#define H_BULK_REMOVE_RC 0x0c00000000000000ULL
|
|
|
|
|
#define H_BULK_REMOVE_FLAGS 0x0300000000000000ULL
|
|
|
|
|
#define H_BULK_REMOVE_ABSOLUTE 0x0000000000000000ULL
|
|
|
|
|
#define H_BULK_REMOVE_ANDCOND 0x0100000000000000ULL
|
|
|
|
|
#define H_BULK_REMOVE_AVPN 0x0200000000000000ULL
|
|
|
|
|
#define H_BULK_REMOVE_PTEX 0x00ffffffffffffffULL
|
|
|
|
|
#define H_BULK_REMOVE_MAX_BATCH 4
|
|
|
|
|
|
|
|
|
|
static int kvmppc_h_pr_bulk_remove(struct kvm_vcpu *vcpu)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
int paramnr = 4;
|
|
|
|
|
int ret = H_SUCCESS;
|
|
|
|
|
|
KVM: PPC: Book3S PR: Make HPT accesses and updates SMP-safe
This adds a per-VM mutex to provide mutual exclusion between vcpus
for accesses to and updates of the guest hashed page table (HPT).
This also makes the code use single-byte writes to the HPT entry
when updating of the reference (R) and change (C) bits. The reason
for doing this, rather than writing back the whole HPTE, is that on
non-PAPR virtual machines, the guest OS might be writing to the HPTE
concurrently, and writing back the whole HPTE might conflict with
that. Also, real hardware does single-byte writes to update R and C.
The new mutex is taken in kvmppc_mmu_book3s_64_xlate() when reading
the HPT and updating R and/or C, and in the PAPR HPT update hcalls
(H_ENTER, H_REMOVE, etc.). Having the mutex means that we don't need
to use a hypervisor lock bit in the HPT update hcalls, and we don't
need to be careful about the order in which the bytes of the HPTE are
updated by those hcalls.
The other change here is to make emulated TLB invalidations (tlbie)
effective across all vcpus. To do this we call kvmppc_mmu_pte_vflush
for all vcpus in kvmppc_ppc_book3s_64_tlbie().
For 32-bit, this makes the setting of the accessed and dirty bits use
single-byte writes, and makes tlbie invalidate shadow HPTEs for all
vcpus.
With this, PR KVM can successfully run SMP guests.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2013-09-20 12:52:48 +08:00
|
|
|
mutex_lock(&vcpu->kvm->arch.hpt_mutex);
|
2012-01-31 04:25:31 +08:00
|
|
|
for (i = 0; i < H_BULK_REMOVE_MAX_BATCH; i++) {
|
|
|
|
|
unsigned long tsh = kvmppc_get_gpr(vcpu, paramnr+(2*i));
|
|
|
|
|
unsigned long tsl = kvmppc_get_gpr(vcpu, paramnr+(2*i)+1);
|
|
|
|
|
unsigned long pteg, rb, flags;
|
|
|
|
|
unsigned long pte[2];
|
|
|
|
|
unsigned long v = 0;
|
|
|
|
|
|
|
|
|
|
if ((tsh & H_BULK_REMOVE_TYPE) == H_BULK_REMOVE_END) {
|
|
|
|
|
break; /* Exit success */
|
|
|
|
|
} else if ((tsh & H_BULK_REMOVE_TYPE) !=
|
|
|
|
|
H_BULK_REMOVE_REQUEST) {
|
|
|
|
|
ret = H_PARAMETER;
|
|
|
|
|
break; /* Exit fail */
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
tsh &= H_BULK_REMOVE_PTEX | H_BULK_REMOVE_FLAGS;
|
|
|
|
|
tsh |= H_BULK_REMOVE_RESPONSE;
|
|
|
|
|
|
|
|
|
|
if ((tsh & H_BULK_REMOVE_ANDCOND) &&
|
|
|
|
|
(tsh & H_BULK_REMOVE_AVPN)) {
|
|
|
|
|
tsh |= H_BULK_REMOVE_PARM;
|
|
|
|
|
kvmppc_set_gpr(vcpu, paramnr+(2*i), tsh);
|
|
|
|
|
ret = H_PARAMETER;
|
|
|
|
|
break; /* Exit fail */
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pteg = get_pteg_addr(vcpu, tsh & H_BULK_REMOVE_PTEX);
|
KVM: PPC: Book3S PR: Check copy_to/from_user return values
The PR KVM implementation of the PAPR HPT hypercalls (H_ENTER etc.)
access an image of the HPT in userspace memory using copy_from_user
and copy_to_user. Recently, the declarations of those functions were
annotated to indicate that the return value must be checked. Since
this code doesn't currently check the return value, this causes
compile warnings like the ones shown below, and since on PPC the
default is to compile arch/powerpc with -Werror, this causes the
build to fail.
To fix this, we check the return values, and if non-zero, fail the
hypercall being processed with a H_FUNCTION error return value.
There is really no good error return value to use since PAPR didn't
envisage the possibility that the hypervisor may not be able to access
the guest's HPT, and H_FUNCTION (function not supported) seems as
good as any.
The typical compile warnings look like this:
CC arch/powerpc/kvm/book3s_pr_papr.o
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_pr_papr.c: In function ‘kvmppc_h_pr_enter’:
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_pr_papr.c:53:2: error: ignoring return value of ‘copy_from_user’, declared with attribute warn_unused_result [-Werror=unused-result]
copy_from_user(pteg, (void __user *)pteg_addr, sizeof(pteg));
^
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_pr_papr.c:74:2: error: ignoring return value of ‘copy_to_user’, declared with attribute warn_unused_result [-Werror=unused-result]
copy_to_user((void __user *)pteg_addr, hpte, HPTE_SIZE);
^
... etc.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2017-05-11 09:33:30 +08:00
|
|
|
if (copy_from_user(pte, (void __user *)pteg, sizeof(pte))) {
|
|
|
|
|
ret = H_FUNCTION;
|
|
|
|
|
break;
|
|
|
|
|
}
|
2014-06-16 19:58:11 +08:00
|
|
|
pte[0] = be64_to_cpu((__force __be64)pte[0]);
|
|
|
|
|
pte[1] = be64_to_cpu((__force __be64)pte[1]);
|
2012-01-31 04:25:31 +08:00
|
|
|
|
|
|
|
|
/* tsl = AVPN */
|
|
|
|
|
flags = (tsh & H_BULK_REMOVE_FLAGS) >> 26;
|
|
|
|
|
|
|
|
|
|
if ((pte[0] & HPTE_V_VALID) == 0 ||
|
|
|
|
|
((flags & H_AVPN) && (pte[0] & ~0x7fUL) != tsl) ||
|
|
|
|
|
((flags & H_ANDCOND) && (pte[0] & tsl) != 0)) {
|
|
|
|
|
tsh |= H_BULK_REMOVE_NOT_FOUND;
|
|
|
|
|
} else {
|
|
|
|
|
/* Splat the pteg in (userland) hpt */
|
KVM: PPC: Book3S PR: Check copy_to/from_user return values
The PR KVM implementation of the PAPR HPT hypercalls (H_ENTER etc.)
access an image of the HPT in userspace memory using copy_from_user
and copy_to_user. Recently, the declarations of those functions were
annotated to indicate that the return value must be checked. Since
this code doesn't currently check the return value, this causes
compile warnings like the ones shown below, and since on PPC the
default is to compile arch/powerpc with -Werror, this causes the
build to fail.
To fix this, we check the return values, and if non-zero, fail the
hypercall being processed with a H_FUNCTION error return value.
There is really no good error return value to use since PAPR didn't
envisage the possibility that the hypervisor may not be able to access
the guest's HPT, and H_FUNCTION (function not supported) seems as
good as any.
The typical compile warnings look like this:
CC arch/powerpc/kvm/book3s_pr_papr.o
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_pr_papr.c: In function ‘kvmppc_h_pr_enter’:
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_pr_papr.c:53:2: error: ignoring return value of ‘copy_from_user’, declared with attribute warn_unused_result [-Werror=unused-result]
copy_from_user(pteg, (void __user *)pteg_addr, sizeof(pteg));
^
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_pr_papr.c:74:2: error: ignoring return value of ‘copy_to_user’, declared with attribute warn_unused_result [-Werror=unused-result]
copy_to_user((void __user *)pteg_addr, hpte, HPTE_SIZE);
^
... etc.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2017-05-11 09:33:30 +08:00
|
|
|
if (copy_to_user((void __user *)pteg, &v, sizeof(v))) {
|
|
|
|
|
ret = H_FUNCTION;
|
|
|
|
|
break;
|
|
|
|
|
}
|
2012-01-31 04:25:31 +08:00
|
|
|
|
|
|
|
|
rb = compute_tlbie_rb(pte[0], pte[1],
|
|
|
|
|
tsh & H_BULK_REMOVE_PTEX);
|
|
|
|
|
vcpu->arch.mmu.tlbie(vcpu, rb, rb & 1 ? true : false);
|
|
|
|
|
tsh |= H_BULK_REMOVE_SUCCESS;
|
|
|
|
|
tsh |= (pte[1] & (HPTE_R_C | HPTE_R_R)) << 43;
|
|
|
|
|
}
|
|
|
|
|
kvmppc_set_gpr(vcpu, paramnr+(2*i), tsh);
|
|
|
|
|
}
|
KVM: PPC: Book3S PR: Make HPT accesses and updates SMP-safe
This adds a per-VM mutex to provide mutual exclusion between vcpus
for accesses to and updates of the guest hashed page table (HPT).
This also makes the code use single-byte writes to the HPT entry
when updating of the reference (R) and change (C) bits. The reason
for doing this, rather than writing back the whole HPTE, is that on
non-PAPR virtual machines, the guest OS might be writing to the HPTE
concurrently, and writing back the whole HPTE might conflict with
that. Also, real hardware does single-byte writes to update R and C.
The new mutex is taken in kvmppc_mmu_book3s_64_xlate() when reading
the HPT and updating R and/or C, and in the PAPR HPT update hcalls
(H_ENTER, H_REMOVE, etc.). Having the mutex means that we don't need
to use a hypervisor lock bit in the HPT update hcalls, and we don't
need to be careful about the order in which the bytes of the HPTE are
updated by those hcalls.
The other change here is to make emulated TLB invalidations (tlbie)
effective across all vcpus. To do this we call kvmppc_mmu_pte_vflush
for all vcpus in kvmppc_ppc_book3s_64_tlbie().
For 32-bit, this makes the setting of the accessed and dirty bits use
single-byte writes, and makes tlbie invalidate shadow HPTEs for all
vcpus.
With this, PR KVM can successfully run SMP guests.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2013-09-20 12:52:48 +08:00
|
|
|
mutex_unlock(&vcpu->kvm->arch.hpt_mutex);
|
2012-01-31 04:25:31 +08:00
|
|
|
kvmppc_set_gpr(vcpu, 3, ret);
|
|
|
|
|
|
|
|
|
|
return EMULATE_DONE;
|
|
|
|
|
}
|
|
|
|
|
|
2011-08-08 23:21:15 +08:00
|
|
|
static int kvmppc_h_pr_protect(struct kvm_vcpu *vcpu)
|
|
|
|
|
{
|
|
|
|
|
unsigned long flags = kvmppc_get_gpr(vcpu, 4);
|
|
|
|
|
unsigned long pte_index = kvmppc_get_gpr(vcpu, 5);
|
|
|
|
|
unsigned long avpn = kvmppc_get_gpr(vcpu, 6);
|
|
|
|
|
unsigned long rb, pteg, r, v;
|
|
|
|
|
unsigned long pte[2];
|
KVM: PPC: Book3S PR: Make HPT accesses and updates SMP-safe
This adds a per-VM mutex to provide mutual exclusion between vcpus
for accesses to and updates of the guest hashed page table (HPT).
This also makes the code use single-byte writes to the HPT entry
when updating of the reference (R) and change (C) bits. The reason
for doing this, rather than writing back the whole HPTE, is that on
non-PAPR virtual machines, the guest OS might be writing to the HPTE
concurrently, and writing back the whole HPTE might conflict with
that. Also, real hardware does single-byte writes to update R and C.
The new mutex is taken in kvmppc_mmu_book3s_64_xlate() when reading
the HPT and updating R and/or C, and in the PAPR HPT update hcalls
(H_ENTER, H_REMOVE, etc.). Having the mutex means that we don't need
to use a hypervisor lock bit in the HPT update hcalls, and we don't
need to be careful about the order in which the bytes of the HPTE are
updated by those hcalls.
The other change here is to make emulated TLB invalidations (tlbie)
effective across all vcpus. To do this we call kvmppc_mmu_pte_vflush
for all vcpus in kvmppc_ppc_book3s_64_tlbie().
For 32-bit, this makes the setting of the accessed and dirty bits use
single-byte writes, and makes tlbie invalidate shadow HPTEs for all
vcpus.
With this, PR KVM can successfully run SMP guests.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2013-09-20 12:52:48 +08:00
|
|
|
long int ret;
|
2011-08-08 23:21:15 +08:00
|
|
|
|
|
|
|
|
pteg = get_pteg_addr(vcpu, pte_index);
|
KVM: PPC: Book3S PR: Make HPT accesses and updates SMP-safe
This adds a per-VM mutex to provide mutual exclusion between vcpus
for accesses to and updates of the guest hashed page table (HPT).
This also makes the code use single-byte writes to the HPT entry
when updating of the reference (R) and change (C) bits. The reason
for doing this, rather than writing back the whole HPTE, is that on
non-PAPR virtual machines, the guest OS might be writing to the HPTE
concurrently, and writing back the whole HPTE might conflict with
that. Also, real hardware does single-byte writes to update R and C.
The new mutex is taken in kvmppc_mmu_book3s_64_xlate() when reading
the HPT and updating R and/or C, and in the PAPR HPT update hcalls
(H_ENTER, H_REMOVE, etc.). Having the mutex means that we don't need
to use a hypervisor lock bit in the HPT update hcalls, and we don't
need to be careful about the order in which the bytes of the HPTE are
updated by those hcalls.
The other change here is to make emulated TLB invalidations (tlbie)
effective across all vcpus. To do this we call kvmppc_mmu_pte_vflush
for all vcpus in kvmppc_ppc_book3s_64_tlbie().
For 32-bit, this makes the setting of the accessed and dirty bits use
single-byte writes, and makes tlbie invalidate shadow HPTEs for all
vcpus.
With this, PR KVM can successfully run SMP guests.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2013-09-20 12:52:48 +08:00
|
|
|
mutex_lock(&vcpu->kvm->arch.hpt_mutex);
|
KVM: PPC: Book3S PR: Check copy_to/from_user return values
The PR KVM implementation of the PAPR HPT hypercalls (H_ENTER etc.)
access an image of the HPT in userspace memory using copy_from_user
and copy_to_user. Recently, the declarations of those functions were
annotated to indicate that the return value must be checked. Since
this code doesn't currently check the return value, this causes
compile warnings like the ones shown below, and since on PPC the
default is to compile arch/powerpc with -Werror, this causes the
build to fail.
To fix this, we check the return values, and if non-zero, fail the
hypercall being processed with a H_FUNCTION error return value.
There is really no good error return value to use since PAPR didn't
envisage the possibility that the hypervisor may not be able to access
the guest's HPT, and H_FUNCTION (function not supported) seems as
good as any.
The typical compile warnings look like this:
CC arch/powerpc/kvm/book3s_pr_papr.o
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_pr_papr.c: In function ‘kvmppc_h_pr_enter’:
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_pr_papr.c:53:2: error: ignoring return value of ‘copy_from_user’, declared with attribute warn_unused_result [-Werror=unused-result]
copy_from_user(pteg, (void __user *)pteg_addr, sizeof(pteg));
^
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_pr_papr.c:74:2: error: ignoring return value of ‘copy_to_user’, declared with attribute warn_unused_result [-Werror=unused-result]
copy_to_user((void __user *)pteg_addr, hpte, HPTE_SIZE);
^
... etc.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2017-05-11 09:33:30 +08:00
|
|
|
ret = H_FUNCTION;
|
|
|
|
|
if (copy_from_user(pte, (void __user *)pteg, sizeof(pte)))
|
|
|
|
|
goto done;
|
2014-06-16 19:58:11 +08:00
|
|
|
pte[0] = be64_to_cpu((__force __be64)pte[0]);
|
|
|
|
|
pte[1] = be64_to_cpu((__force __be64)pte[1]);
|
2011-08-08 23:21:15 +08:00
|
|
|
|
KVM: PPC: Book3S PR: Make HPT accesses and updates SMP-safe
This adds a per-VM mutex to provide mutual exclusion between vcpus
for accesses to and updates of the guest hashed page table (HPT).
This also makes the code use single-byte writes to the HPT entry
when updating of the reference (R) and change (C) bits. The reason
for doing this, rather than writing back the whole HPTE, is that on
non-PAPR virtual machines, the guest OS might be writing to the HPTE
concurrently, and writing back the whole HPTE might conflict with
that. Also, real hardware does single-byte writes to update R and C.
The new mutex is taken in kvmppc_mmu_book3s_64_xlate() when reading
the HPT and updating R and/or C, and in the PAPR HPT update hcalls
(H_ENTER, H_REMOVE, etc.). Having the mutex means that we don't need
to use a hypervisor lock bit in the HPT update hcalls, and we don't
need to be careful about the order in which the bytes of the HPTE are
updated by those hcalls.
The other change here is to make emulated TLB invalidations (tlbie)
effective across all vcpus. To do this we call kvmppc_mmu_pte_vflush
for all vcpus in kvmppc_ppc_book3s_64_tlbie().
For 32-bit, this makes the setting of the accessed and dirty bits use
single-byte writes, and makes tlbie invalidate shadow HPTEs for all
vcpus.
With this, PR KVM can successfully run SMP guests.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2013-09-20 12:52:48 +08:00
|
|
|
ret = H_NOT_FOUND;
|
2011-08-08 23:21:15 +08:00
|
|
|
if ((pte[0] & HPTE_V_VALID) == 0 ||
|
KVM: PPC: Book3S PR: Make HPT accesses and updates SMP-safe
This adds a per-VM mutex to provide mutual exclusion between vcpus
for accesses to and updates of the guest hashed page table (HPT).
This also makes the code use single-byte writes to the HPT entry
when updating of the reference (R) and change (C) bits. The reason
for doing this, rather than writing back the whole HPTE, is that on
non-PAPR virtual machines, the guest OS might be writing to the HPTE
concurrently, and writing back the whole HPTE might conflict with
that. Also, real hardware does single-byte writes to update R and C.
The new mutex is taken in kvmppc_mmu_book3s_64_xlate() when reading
the HPT and updating R and/or C, and in the PAPR HPT update hcalls
(H_ENTER, H_REMOVE, etc.). Having the mutex means that we don't need
to use a hypervisor lock bit in the HPT update hcalls, and we don't
need to be careful about the order in which the bytes of the HPTE are
updated by those hcalls.
The other change here is to make emulated TLB invalidations (tlbie)
effective across all vcpus. To do this we call kvmppc_mmu_pte_vflush
for all vcpus in kvmppc_ppc_book3s_64_tlbie().
For 32-bit, this makes the setting of the accessed and dirty bits use
single-byte writes, and makes tlbie invalidate shadow HPTEs for all
vcpus.
With this, PR KVM can successfully run SMP guests.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2013-09-20 12:52:48 +08:00
|
|
|
((flags & H_AVPN) && (pte[0] & ~0x7fUL) != avpn))
|
|
|
|
|
goto done;
|
2011-08-08 23:21:15 +08:00
|
|
|
|
|
|
|
|
v = pte[0];
|
|
|
|
|
r = pte[1];
|
|
|
|
|
r &= ~(HPTE_R_PP0 | HPTE_R_PP | HPTE_R_N | HPTE_R_KEY_HI |
|
|
|
|
|
HPTE_R_KEY_LO);
|
|
|
|
|
r |= (flags << 55) & HPTE_R_PP0;
|
|
|
|
|
r |= (flags << 48) & HPTE_R_KEY_HI;
|
|
|
|
|
r |= flags & (HPTE_R_PP | HPTE_R_N | HPTE_R_KEY_LO);
|
|
|
|
|
|
|
|
|
|
pte[1] = r;
|
|
|
|
|
|
|
|
|
|
rb = compute_tlbie_rb(v, r, pte_index);
|
|
|
|
|
vcpu->arch.mmu.tlbie(vcpu, rb, rb & 1 ? true : false);
|
2014-06-16 19:58:11 +08:00
|
|
|
pte[0] = (__force u64)cpu_to_be64(pte[0]);
|
|
|
|
|
pte[1] = (__force u64)cpu_to_be64(pte[1]);
|
KVM: PPC: Book3S PR: Check copy_to/from_user return values
The PR KVM implementation of the PAPR HPT hypercalls (H_ENTER etc.)
access an image of the HPT in userspace memory using copy_from_user
and copy_to_user. Recently, the declarations of those functions were
annotated to indicate that the return value must be checked. Since
this code doesn't currently check the return value, this causes
compile warnings like the ones shown below, and since on PPC the
default is to compile arch/powerpc with -Werror, this causes the
build to fail.
To fix this, we check the return values, and if non-zero, fail the
hypercall being processed with a H_FUNCTION error return value.
There is really no good error return value to use since PAPR didn't
envisage the possibility that the hypervisor may not be able to access
the guest's HPT, and H_FUNCTION (function not supported) seems as
good as any.
The typical compile warnings look like this:
CC arch/powerpc/kvm/book3s_pr_papr.o
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_pr_papr.c: In function ‘kvmppc_h_pr_enter’:
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_pr_papr.c:53:2: error: ignoring return value of ‘copy_from_user’, declared with attribute warn_unused_result [-Werror=unused-result]
copy_from_user(pteg, (void __user *)pteg_addr, sizeof(pteg));
^
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_pr_papr.c:74:2: error: ignoring return value of ‘copy_to_user’, declared with attribute warn_unused_result [-Werror=unused-result]
copy_to_user((void __user *)pteg_addr, hpte, HPTE_SIZE);
^
... etc.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2017-05-11 09:33:30 +08:00
|
|
|
ret = H_FUNCTION;
|
|
|
|
|
if (copy_to_user((void __user *)pteg, pte, sizeof(pte)))
|
|
|
|
|
goto done;
|
KVM: PPC: Book3S PR: Make HPT accesses and updates SMP-safe
This adds a per-VM mutex to provide mutual exclusion between vcpus
for accesses to and updates of the guest hashed page table (HPT).
This also makes the code use single-byte writes to the HPT entry
when updating of the reference (R) and change (C) bits. The reason
for doing this, rather than writing back the whole HPTE, is that on
non-PAPR virtual machines, the guest OS might be writing to the HPTE
concurrently, and writing back the whole HPTE might conflict with
that. Also, real hardware does single-byte writes to update R and C.
The new mutex is taken in kvmppc_mmu_book3s_64_xlate() when reading
the HPT and updating R and/or C, and in the PAPR HPT update hcalls
(H_ENTER, H_REMOVE, etc.). Having the mutex means that we don't need
to use a hypervisor lock bit in the HPT update hcalls, and we don't
need to be careful about the order in which the bytes of the HPTE are
updated by those hcalls.
The other change here is to make emulated TLB invalidations (tlbie)
effective across all vcpus. To do this we call kvmppc_mmu_pte_vflush
for all vcpus in kvmppc_ppc_book3s_64_tlbie().
For 32-bit, this makes the setting of the accessed and dirty bits use
single-byte writes, and makes tlbie invalidate shadow HPTEs for all
vcpus.
With this, PR KVM can successfully run SMP guests.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2013-09-20 12:52:48 +08:00
|
|
|
ret = H_SUCCESS;
|
2011-08-08 23:21:15 +08:00
|
|
|
|
KVM: PPC: Book3S PR: Make HPT accesses and updates SMP-safe
This adds a per-VM mutex to provide mutual exclusion between vcpus
for accesses to and updates of the guest hashed page table (HPT).
This also makes the code use single-byte writes to the HPT entry
when updating of the reference (R) and change (C) bits. The reason
for doing this, rather than writing back the whole HPTE, is that on
non-PAPR virtual machines, the guest OS might be writing to the HPTE
concurrently, and writing back the whole HPTE might conflict with
that. Also, real hardware does single-byte writes to update R and C.
The new mutex is taken in kvmppc_mmu_book3s_64_xlate() when reading
the HPT and updating R and/or C, and in the PAPR HPT update hcalls
(H_ENTER, H_REMOVE, etc.). Having the mutex means that we don't need
to use a hypervisor lock bit in the HPT update hcalls, and we don't
need to be careful about the order in which the bytes of the HPTE are
updated by those hcalls.
The other change here is to make emulated TLB invalidations (tlbie)
effective across all vcpus. To do this we call kvmppc_mmu_pte_vflush
for all vcpus in kvmppc_ppc_book3s_64_tlbie().
For 32-bit, this makes the setting of the accessed and dirty bits use
single-byte writes, and makes tlbie invalidate shadow HPTEs for all
vcpus.
With this, PR KVM can successfully run SMP guests.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2013-09-20 12:52:48 +08:00
|
|
|
done:
|
|
|
|
|
mutex_unlock(&vcpu->kvm->arch.hpt_mutex);
|
|
|
|
|
kvmppc_set_gpr(vcpu, 3, ret);
|
2011-08-08 23:21:15 +08:00
|
|
|
|
|
|
|
|
return EMULATE_DONE;
|
|
|
|
|
}
|
|
|
|
|
|
KVM: PPC: Book3S PR: Don't include SPAPR TCE code on non-pseries platforms
Commit e91aa8e6ecd5 ("KVM: PPC: Enable IOMMU_API for KVM_BOOK3S_64
permanently", 2017-03-22) enabled the SPAPR TCE code for all 64-bit
Book 3S kernel configurations in order to simplify the code and
reduce #ifdefs. However, 64-bit Book 3S PPC platforms other than
pseries and powernv don't implement the necessary IOMMU callbacks,
leading to build failures like the following (for a pasemi config):
scripts/kconfig/conf --silentoldconfig Kconfig
warning: (KVM_BOOK3S_64) selects SPAPR_TCE_IOMMU which has unmet direct dependencies (IOMMU_SUPPORT && (PPC_POWERNV || PPC_PSERIES))
...
CC [M] arch/powerpc/kvm/book3s_64_vio.o
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_64_vio.c: In function ‘kvmppc_clear_tce’:
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_64_vio.c:363:2: error: implicit declaration of function ‘iommu_tce_xchg’ [-Werror=implicit-function-declaration]
iommu_tce_xchg(tbl, entry, &hpa, &dir);
^
To fix this, we make the inclusion of the SPAPR TCE support, and the
code that uses it in book3s_vio.c and book3s_vio_hv.c, depend on
the inclusion of support for the pseries and/or powernv platforms.
This means that when running a 'pseries' guest on those platforms,
the guest won't have in-kernel acceleration of the PAPR TCE hypercalls,
but at least now they compile.
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2017-05-11 12:31:59 +08:00
|
|
|
static int kvmppc_h_pr_logical_ci_load(struct kvm_vcpu *vcpu)
|
2012-03-16 05:58:34 +08:00
|
|
|
{
|
|
|
|
|
long rc;
|
|
|
|
|
|
KVM: PPC: Book3S PR: Don't include SPAPR TCE code on non-pseries platforms
Commit e91aa8e6ecd5 ("KVM: PPC: Enable IOMMU_API for KVM_BOOK3S_64
permanently", 2017-03-22) enabled the SPAPR TCE code for all 64-bit
Book 3S kernel configurations in order to simplify the code and
reduce #ifdefs. However, 64-bit Book 3S PPC platforms other than
pseries and powernv don't implement the necessary IOMMU callbacks,
leading to build failures like the following (for a pasemi config):
scripts/kconfig/conf --silentoldconfig Kconfig
warning: (KVM_BOOK3S_64) selects SPAPR_TCE_IOMMU which has unmet direct dependencies (IOMMU_SUPPORT && (PPC_POWERNV || PPC_PSERIES))
...
CC [M] arch/powerpc/kvm/book3s_64_vio.o
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_64_vio.c: In function ‘kvmppc_clear_tce’:
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_64_vio.c:363:2: error: implicit declaration of function ‘iommu_tce_xchg’ [-Werror=implicit-function-declaration]
iommu_tce_xchg(tbl, entry, &hpa, &dir);
^
To fix this, we make the inclusion of the SPAPR TCE support, and the
code that uses it in book3s_vio.c and book3s_vio_hv.c, depend on
the inclusion of support for the pseries and/or powernv platforms.
This means that when running a 'pseries' guest on those platforms,
the guest won't have in-kernel acceleration of the PAPR TCE hypercalls,
but at least now they compile.
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2017-05-11 12:31:59 +08:00
|
|
|
rc = kvmppc_h_logical_ci_load(vcpu);
|
2012-03-16 05:58:34 +08:00
|
|
|
if (rc == H_TOO_HARD)
|
|
|
|
|
return EMULATE_FAIL;
|
|
|
|
|
kvmppc_set_gpr(vcpu, 3, rc);
|
|
|
|
|
return EMULATE_DONE;
|
|
|
|
|
}
|
|
|
|
|
|
KVM: PPC: Book3S PR: Don't include SPAPR TCE code on non-pseries platforms
Commit e91aa8e6ecd5 ("KVM: PPC: Enable IOMMU_API for KVM_BOOK3S_64
permanently", 2017-03-22) enabled the SPAPR TCE code for all 64-bit
Book 3S kernel configurations in order to simplify the code and
reduce #ifdefs. However, 64-bit Book 3S PPC platforms other than
pseries and powernv don't implement the necessary IOMMU callbacks,
leading to build failures like the following (for a pasemi config):
scripts/kconfig/conf --silentoldconfig Kconfig
warning: (KVM_BOOK3S_64) selects SPAPR_TCE_IOMMU which has unmet direct dependencies (IOMMU_SUPPORT && (PPC_POWERNV || PPC_PSERIES))
...
CC [M] arch/powerpc/kvm/book3s_64_vio.o
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_64_vio.c: In function ‘kvmppc_clear_tce’:
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_64_vio.c:363:2: error: implicit declaration of function ‘iommu_tce_xchg’ [-Werror=implicit-function-declaration]
iommu_tce_xchg(tbl, entry, &hpa, &dir);
^
To fix this, we make the inclusion of the SPAPR TCE support, and the
code that uses it in book3s_vio.c and book3s_vio_hv.c, depend on
the inclusion of support for the pseries and/or powernv platforms.
This means that when running a 'pseries' guest on those platforms,
the guest won't have in-kernel acceleration of the PAPR TCE hypercalls,
but at least now they compile.
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2017-05-11 12:31:59 +08:00
|
|
|
static int kvmppc_h_pr_logical_ci_store(struct kvm_vcpu *vcpu)
|
kvmppc: Implement H_LOGICAL_CI_{LOAD,STORE} in KVM
On POWER, storage caching is usually configured via the MMU - attributes
such as cache-inhibited are stored in the TLB and the hashed page table.
This makes correctly performing cache inhibited IO accesses awkward when
the MMU is turned off (real mode). Some CPU models provide special
registers to control the cache attributes of real mode load and stores but
this is not at all consistent. This is a problem in particular for SLOF,
the firmware used on KVM guests, which runs entirely in real mode, but
which needs to do IO to load the kernel.
To simplify this qemu implements two special hypercalls, H_LOGICAL_CI_LOAD
and H_LOGICAL_CI_STORE which simulate a cache-inhibited load or store to
a logical address (aka guest physical address). SLOF uses these for IO.
However, because these are implemented within qemu, not the host kernel,
these bypass any IO devices emulated within KVM itself. The simplest way
to see this problem is to attempt to boot a KVM guest from a virtio-blk
device with iothread / dataplane enabled. The iothread code relies on an
in kernel implementation of the virtio queue notification, which is not
triggered by the IO hcalls, and so the guest will stall in SLOF unable to
load the guest OS.
This patch addresses this by providing in-kernel implementations of the
2 hypercalls, which correctly scan the KVM IO bus. Any access to an
address not handled by the KVM IO bus will cause a VM exit, hitting the
qemu implementation as before.
Note that a userspace change is also required, in order to enable these
new hcall implementations with KVM_CAP_PPC_ENABLE_HCALL.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
[agraf: fix compilation]
Signed-off-by: Alexander Graf <agraf@suse.de>
2015-02-05 08:53:25 +08:00
|
|
|
{
|
|
|
|
|
long rc;
|
|
|
|
|
|
KVM: PPC: Book3S PR: Don't include SPAPR TCE code on non-pseries platforms
Commit e91aa8e6ecd5 ("KVM: PPC: Enable IOMMU_API for KVM_BOOK3S_64
permanently", 2017-03-22) enabled the SPAPR TCE code for all 64-bit
Book 3S kernel configurations in order to simplify the code and
reduce #ifdefs. However, 64-bit Book 3S PPC platforms other than
pseries and powernv don't implement the necessary IOMMU callbacks,
leading to build failures like the following (for a pasemi config):
scripts/kconfig/conf --silentoldconfig Kconfig
warning: (KVM_BOOK3S_64) selects SPAPR_TCE_IOMMU which has unmet direct dependencies (IOMMU_SUPPORT && (PPC_POWERNV || PPC_PSERIES))
...
CC [M] arch/powerpc/kvm/book3s_64_vio.o
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_64_vio.c: In function ‘kvmppc_clear_tce’:
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_64_vio.c:363:2: error: implicit declaration of function ‘iommu_tce_xchg’ [-Werror=implicit-function-declaration]
iommu_tce_xchg(tbl, entry, &hpa, &dir);
^
To fix this, we make the inclusion of the SPAPR TCE support, and the
code that uses it in book3s_vio.c and book3s_vio_hv.c, depend on
the inclusion of support for the pseries and/or powernv platforms.
This means that when running a 'pseries' guest on those platforms,
the guest won't have in-kernel acceleration of the PAPR TCE hypercalls,
but at least now they compile.
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2017-05-11 12:31:59 +08:00
|
|
|
rc = kvmppc_h_logical_ci_store(vcpu);
|
kvmppc: Implement H_LOGICAL_CI_{LOAD,STORE} in KVM
On POWER, storage caching is usually configured via the MMU - attributes
such as cache-inhibited are stored in the TLB and the hashed page table.
This makes correctly performing cache inhibited IO accesses awkward when
the MMU is turned off (real mode). Some CPU models provide special
registers to control the cache attributes of real mode load and stores but
this is not at all consistent. This is a problem in particular for SLOF,
the firmware used on KVM guests, which runs entirely in real mode, but
which needs to do IO to load the kernel.
To simplify this qemu implements two special hypercalls, H_LOGICAL_CI_LOAD
and H_LOGICAL_CI_STORE which simulate a cache-inhibited load or store to
a logical address (aka guest physical address). SLOF uses these for IO.
However, because these are implemented within qemu, not the host kernel,
these bypass any IO devices emulated within KVM itself. The simplest way
to see this problem is to attempt to boot a KVM guest from a virtio-blk
device with iothread / dataplane enabled. The iothread code relies on an
in kernel implementation of the virtio queue notification, which is not
triggered by the IO hcalls, and so the guest will stall in SLOF unable to
load the guest OS.
This patch addresses this by providing in-kernel implementations of the
2 hypercalls, which correctly scan the KVM IO bus. Any access to an
address not handled by the KVM IO bus will cause a VM exit, hitting the
qemu implementation as before.
Note that a userspace change is also required, in order to enable these
new hcall implementations with KVM_CAP_PPC_ENABLE_HCALL.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
[agraf: fix compilation]
Signed-off-by: Alexander Graf <agraf@suse.de>
2015-02-05 08:53:25 +08:00
|
|
|
if (rc == H_TOO_HARD)
|
|
|
|
|
return EMULATE_FAIL;
|
|
|
|
|
kvmppc_set_gpr(vcpu, 3, rc);
|
|
|
|
|
return EMULATE_DONE;
|
|
|
|
|
}
|
|
|
|
|
|
KVM: PPC: Book3S PR: Don't include SPAPR TCE code on non-pseries platforms
Commit e91aa8e6ecd5 ("KVM: PPC: Enable IOMMU_API for KVM_BOOK3S_64
permanently", 2017-03-22) enabled the SPAPR TCE code for all 64-bit
Book 3S kernel configurations in order to simplify the code and
reduce #ifdefs. However, 64-bit Book 3S PPC platforms other than
pseries and powernv don't implement the necessary IOMMU callbacks,
leading to build failures like the following (for a pasemi config):
scripts/kconfig/conf --silentoldconfig Kconfig
warning: (KVM_BOOK3S_64) selects SPAPR_TCE_IOMMU which has unmet direct dependencies (IOMMU_SUPPORT && (PPC_POWERNV || PPC_PSERIES))
...
CC [M] arch/powerpc/kvm/book3s_64_vio.o
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_64_vio.c: In function ‘kvmppc_clear_tce’:
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_64_vio.c:363:2: error: implicit declaration of function ‘iommu_tce_xchg’ [-Werror=implicit-function-declaration]
iommu_tce_xchg(tbl, entry, &hpa, &dir);
^
To fix this, we make the inclusion of the SPAPR TCE support, and the
code that uses it in book3s_vio.c and book3s_vio_hv.c, depend on
the inclusion of support for the pseries and/or powernv platforms.
This means that when running a 'pseries' guest on those platforms,
the guest won't have in-kernel acceleration of the PAPR TCE hypercalls,
but at least now they compile.
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2017-05-11 12:31:59 +08:00
|
|
|
#ifdef CONFIG_SPAPR_TCE_IOMMU
|
|
|
|
|
static int kvmppc_h_pr_put_tce(struct kvm_vcpu *vcpu)
|
kvmppc: Implement H_LOGICAL_CI_{LOAD,STORE} in KVM
On POWER, storage caching is usually configured via the MMU - attributes
such as cache-inhibited are stored in the TLB and the hashed page table.
This makes correctly performing cache inhibited IO accesses awkward when
the MMU is turned off (real mode). Some CPU models provide special
registers to control the cache attributes of real mode load and stores but
this is not at all consistent. This is a problem in particular for SLOF,
the firmware used on KVM guests, which runs entirely in real mode, but
which needs to do IO to load the kernel.
To simplify this qemu implements two special hypercalls, H_LOGICAL_CI_LOAD
and H_LOGICAL_CI_STORE which simulate a cache-inhibited load or store to
a logical address (aka guest physical address). SLOF uses these for IO.
However, because these are implemented within qemu, not the host kernel,
these bypass any IO devices emulated within KVM itself. The simplest way
to see this problem is to attempt to boot a KVM guest from a virtio-blk
device with iothread / dataplane enabled. The iothread code relies on an
in kernel implementation of the virtio queue notification, which is not
triggered by the IO hcalls, and so the guest will stall in SLOF unable to
load the guest OS.
This patch addresses this by providing in-kernel implementations of the
2 hypercalls, which correctly scan the KVM IO bus. Any access to an
address not handled by the KVM IO bus will cause a VM exit, hitting the
qemu implementation as before.
Note that a userspace change is also required, in order to enable these
new hcall implementations with KVM_CAP_PPC_ENABLE_HCALL.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
[agraf: fix compilation]
Signed-off-by: Alexander Graf <agraf@suse.de>
2015-02-05 08:53:25 +08:00
|
|
|
{
|
KVM: PPC: Book3S PR: Don't include SPAPR TCE code on non-pseries platforms
Commit e91aa8e6ecd5 ("KVM: PPC: Enable IOMMU_API for KVM_BOOK3S_64
permanently", 2017-03-22) enabled the SPAPR TCE code for all 64-bit
Book 3S kernel configurations in order to simplify the code and
reduce #ifdefs. However, 64-bit Book 3S PPC platforms other than
pseries and powernv don't implement the necessary IOMMU callbacks,
leading to build failures like the following (for a pasemi config):
scripts/kconfig/conf --silentoldconfig Kconfig
warning: (KVM_BOOK3S_64) selects SPAPR_TCE_IOMMU which has unmet direct dependencies (IOMMU_SUPPORT && (PPC_POWERNV || PPC_PSERIES))
...
CC [M] arch/powerpc/kvm/book3s_64_vio.o
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_64_vio.c: In function ‘kvmppc_clear_tce’:
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_64_vio.c:363:2: error: implicit declaration of function ‘iommu_tce_xchg’ [-Werror=implicit-function-declaration]
iommu_tce_xchg(tbl, entry, &hpa, &dir);
^
To fix this, we make the inclusion of the SPAPR TCE support, and the
code that uses it in book3s_vio.c and book3s_vio_hv.c, depend on
the inclusion of support for the pseries and/or powernv platforms.
This means that when running a 'pseries' guest on those platforms,
the guest won't have in-kernel acceleration of the PAPR TCE hypercalls,
but at least now they compile.
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2017-05-11 12:31:59 +08:00
|
|
|
unsigned long liobn = kvmppc_get_gpr(vcpu, 4);
|
|
|
|
|
unsigned long ioba = kvmppc_get_gpr(vcpu, 5);
|
|
|
|
|
unsigned long tce = kvmppc_get_gpr(vcpu, 6);
|
kvmppc: Implement H_LOGICAL_CI_{LOAD,STORE} in KVM
On POWER, storage caching is usually configured via the MMU - attributes
such as cache-inhibited are stored in the TLB and the hashed page table.
This makes correctly performing cache inhibited IO accesses awkward when
the MMU is turned off (real mode). Some CPU models provide special
registers to control the cache attributes of real mode load and stores but
this is not at all consistent. This is a problem in particular for SLOF,
the firmware used on KVM guests, which runs entirely in real mode, but
which needs to do IO to load the kernel.
To simplify this qemu implements two special hypercalls, H_LOGICAL_CI_LOAD
and H_LOGICAL_CI_STORE which simulate a cache-inhibited load or store to
a logical address (aka guest physical address). SLOF uses these for IO.
However, because these are implemented within qemu, not the host kernel,
these bypass any IO devices emulated within KVM itself. The simplest way
to see this problem is to attempt to boot a KVM guest from a virtio-blk
device with iothread / dataplane enabled. The iothread code relies on an
in kernel implementation of the virtio queue notification, which is not
triggered by the IO hcalls, and so the guest will stall in SLOF unable to
load the guest OS.
This patch addresses this by providing in-kernel implementations of the
2 hypercalls, which correctly scan the KVM IO bus. Any access to an
address not handled by the KVM IO bus will cause a VM exit, hitting the
qemu implementation as before.
Note that a userspace change is also required, in order to enable these
new hcall implementations with KVM_CAP_PPC_ENABLE_HCALL.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
[agraf: fix compilation]
Signed-off-by: Alexander Graf <agraf@suse.de>
2015-02-05 08:53:25 +08:00
|
|
|
long rc;
|
|
|
|
|
|
KVM: PPC: Book3S PR: Don't include SPAPR TCE code on non-pseries platforms
Commit e91aa8e6ecd5 ("KVM: PPC: Enable IOMMU_API for KVM_BOOK3S_64
permanently", 2017-03-22) enabled the SPAPR TCE code for all 64-bit
Book 3S kernel configurations in order to simplify the code and
reduce #ifdefs. However, 64-bit Book 3S PPC platforms other than
pseries and powernv don't implement the necessary IOMMU callbacks,
leading to build failures like the following (for a pasemi config):
scripts/kconfig/conf --silentoldconfig Kconfig
warning: (KVM_BOOK3S_64) selects SPAPR_TCE_IOMMU which has unmet direct dependencies (IOMMU_SUPPORT && (PPC_POWERNV || PPC_PSERIES))
...
CC [M] arch/powerpc/kvm/book3s_64_vio.o
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_64_vio.c: In function ‘kvmppc_clear_tce’:
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_64_vio.c:363:2: error: implicit declaration of function ‘iommu_tce_xchg’ [-Werror=implicit-function-declaration]
iommu_tce_xchg(tbl, entry, &hpa, &dir);
^
To fix this, we make the inclusion of the SPAPR TCE support, and the
code that uses it in book3s_vio.c and book3s_vio_hv.c, depend on
the inclusion of support for the pseries and/or powernv platforms.
This means that when running a 'pseries' guest on those platforms,
the guest won't have in-kernel acceleration of the PAPR TCE hypercalls,
but at least now they compile.
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2017-05-11 12:31:59 +08:00
|
|
|
rc = kvmppc_h_put_tce(vcpu, liobn, ioba, tce);
|
kvmppc: Implement H_LOGICAL_CI_{LOAD,STORE} in KVM
On POWER, storage caching is usually configured via the MMU - attributes
such as cache-inhibited are stored in the TLB and the hashed page table.
This makes correctly performing cache inhibited IO accesses awkward when
the MMU is turned off (real mode). Some CPU models provide special
registers to control the cache attributes of real mode load and stores but
this is not at all consistent. This is a problem in particular for SLOF,
the firmware used on KVM guests, which runs entirely in real mode, but
which needs to do IO to load the kernel.
To simplify this qemu implements two special hypercalls, H_LOGICAL_CI_LOAD
and H_LOGICAL_CI_STORE which simulate a cache-inhibited load or store to
a logical address (aka guest physical address). SLOF uses these for IO.
However, because these are implemented within qemu, not the host kernel,
these bypass any IO devices emulated within KVM itself. The simplest way
to see this problem is to attempt to boot a KVM guest from a virtio-blk
device with iothread / dataplane enabled. The iothread code relies on an
in kernel implementation of the virtio queue notification, which is not
triggered by the IO hcalls, and so the guest will stall in SLOF unable to
load the guest OS.
This patch addresses this by providing in-kernel implementations of the
2 hypercalls, which correctly scan the KVM IO bus. Any access to an
address not handled by the KVM IO bus will cause a VM exit, hitting the
qemu implementation as before.
Note that a userspace change is also required, in order to enable these
new hcall implementations with KVM_CAP_PPC_ENABLE_HCALL.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
[agraf: fix compilation]
Signed-off-by: Alexander Graf <agraf@suse.de>
2015-02-05 08:53:25 +08:00
|
|
|
if (rc == H_TOO_HARD)
|
|
|
|
|
return EMULATE_FAIL;
|
|
|
|
|
kvmppc_set_gpr(vcpu, 3, rc);
|
|
|
|
|
return EMULATE_DONE;
|
|
|
|
|
}
|
|
|
|
|
|
2016-02-15 09:55:09 +08:00
|
|
|
static int kvmppc_h_pr_put_tce_indirect(struct kvm_vcpu *vcpu)
|
|
|
|
|
{
|
|
|
|
|
unsigned long liobn = kvmppc_get_gpr(vcpu, 4);
|
|
|
|
|
unsigned long ioba = kvmppc_get_gpr(vcpu, 5);
|
|
|
|
|
unsigned long tce = kvmppc_get_gpr(vcpu, 6);
|
|
|
|
|
unsigned long npages = kvmppc_get_gpr(vcpu, 7);
|
|
|
|
|
long rc;
|
|
|
|
|
|
|
|
|
|
rc = kvmppc_h_put_tce_indirect(vcpu, liobn, ioba,
|
|
|
|
|
tce, npages);
|
|
|
|
|
if (rc == H_TOO_HARD)
|
|
|
|
|
return EMULATE_FAIL;
|
|
|
|
|
kvmppc_set_gpr(vcpu, 3, rc);
|
|
|
|
|
return EMULATE_DONE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int kvmppc_h_pr_stuff_tce(struct kvm_vcpu *vcpu)
|
|
|
|
|
{
|
|
|
|
|
unsigned long liobn = kvmppc_get_gpr(vcpu, 4);
|
|
|
|
|
unsigned long ioba = kvmppc_get_gpr(vcpu, 5);
|
|
|
|
|
unsigned long tce_value = kvmppc_get_gpr(vcpu, 6);
|
|
|
|
|
unsigned long npages = kvmppc_get_gpr(vcpu, 7);
|
|
|
|
|
long rc;
|
|
|
|
|
|
|
|
|
|
rc = kvmppc_h_stuff_tce(vcpu, liobn, ioba, tce_value, npages);
|
|
|
|
|
if (rc == H_TOO_HARD)
|
|
|
|
|
return EMULATE_FAIL;
|
|
|
|
|
kvmppc_set_gpr(vcpu, 3, rc);
|
|
|
|
|
return EMULATE_DONE;
|
|
|
|
|
}
|
|
|
|
|
|
KVM: PPC: Book3S PR: Don't include SPAPR TCE code on non-pseries platforms
Commit e91aa8e6ecd5 ("KVM: PPC: Enable IOMMU_API for KVM_BOOK3S_64
permanently", 2017-03-22) enabled the SPAPR TCE code for all 64-bit
Book 3S kernel configurations in order to simplify the code and
reduce #ifdefs. However, 64-bit Book 3S PPC platforms other than
pseries and powernv don't implement the necessary IOMMU callbacks,
leading to build failures like the following (for a pasemi config):
scripts/kconfig/conf --silentoldconfig Kconfig
warning: (KVM_BOOK3S_64) selects SPAPR_TCE_IOMMU which has unmet direct dependencies (IOMMU_SUPPORT && (PPC_POWERNV || PPC_PSERIES))
...
CC [M] arch/powerpc/kvm/book3s_64_vio.o
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_64_vio.c: In function ‘kvmppc_clear_tce’:
/home/paulus/kernel/kvm/arch/powerpc/kvm/book3s_64_vio.c:363:2: error: implicit declaration of function ‘iommu_tce_xchg’ [-Werror=implicit-function-declaration]
iommu_tce_xchg(tbl, entry, &hpa, &dir);
^
To fix this, we make the inclusion of the SPAPR TCE support, and the
code that uses it in book3s_vio.c and book3s_vio_hv.c, depend on
the inclusion of support for the pseries and/or powernv platforms.
This means that when running a 'pseries' guest on those platforms,
the guest won't have in-kernel acceleration of the PAPR TCE hypercalls,
but at least now they compile.
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2017-05-11 12:31:59 +08:00
|
|
|
#else /* CONFIG_SPAPR_TCE_IOMMU */
|
|
|
|
|
static int kvmppc_h_pr_put_tce(struct kvm_vcpu *vcpu)
|
|
|
|
|
{
|
|
|
|
|
return EMULATE_FAIL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int kvmppc_h_pr_put_tce_indirect(struct kvm_vcpu *vcpu)
|
|
|
|
|
{
|
|
|
|
|
return EMULATE_FAIL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int kvmppc_h_pr_stuff_tce(struct kvm_vcpu *vcpu)
|
|
|
|
|
{
|
|
|
|
|
return EMULATE_FAIL;
|
|
|
|
|
}
|
|
|
|
|
#endif /* CONFIG_SPAPR_TCE_IOMMU */
|
|
|
|
|
|
2013-04-18 04:30:26 +08:00
|
|
|
static int kvmppc_h_pr_xics_hcall(struct kvm_vcpu *vcpu, u32 cmd)
|
|
|
|
|
{
|
|
|
|
|
long rc = kvmppc_xics_hcall(vcpu, cmd);
|
|
|
|
|
kvmppc_set_gpr(vcpu, 3, rc);
|
|
|
|
|
return EMULATE_DONE;
|
|
|
|
|
}
|
|
|
|
|
|
2011-08-08 23:21:15 +08:00
|
|
|
int kvmppc_h_pr(struct kvm_vcpu *vcpu, unsigned long cmd)
|
|
|
|
|
{
|
2014-07-19 15:59:35 +08:00
|
|
|
int rc, idx;
|
|
|
|
|
|
2014-06-02 09:02:59 +08:00
|
|
|
if (cmd <= MAX_HCALL_OPCODE &&
|
|
|
|
|
!test_bit(cmd/4, vcpu->kvm->arch.enabled_hcalls))
|
|
|
|
|
return EMULATE_FAIL;
|
|
|
|
|
|
2011-08-08 23:21:15 +08:00
|
|
|
switch (cmd) {
|
|
|
|
|
case H_ENTER:
|
|
|
|
|
return kvmppc_h_pr_enter(vcpu);
|
|
|
|
|
case H_REMOVE:
|
|
|
|
|
return kvmppc_h_pr_remove(vcpu);
|
|
|
|
|
case H_PROTECT:
|
|
|
|
|
return kvmppc_h_pr_protect(vcpu);
|
|
|
|
|
case H_BULK_REMOVE:
|
2012-01-31 04:25:31 +08:00
|
|
|
return kvmppc_h_pr_bulk_remove(vcpu);
|
2012-03-16 05:58:34 +08:00
|
|
|
case H_PUT_TCE:
|
|
|
|
|
return kvmppc_h_pr_put_tce(vcpu);
|
2016-02-15 09:55:09 +08:00
|
|
|
case H_PUT_TCE_INDIRECT:
|
|
|
|
|
return kvmppc_h_pr_put_tce_indirect(vcpu);
|
|
|
|
|
case H_STUFF_TCE:
|
|
|
|
|
return kvmppc_h_pr_stuff_tce(vcpu);
|
2011-08-08 23:21:15 +08:00
|
|
|
case H_CEDE:
|
2014-04-24 19:46:24 +08:00
|
|
|
kvmppc_set_msr_fast(vcpu, kvmppc_get_msr(vcpu) | MSR_EE);
|
2011-08-08 23:21:15 +08:00
|
|
|
kvm_vcpu_block(vcpu);
|
2017-04-27 04:32:19 +08:00
|
|
|
kvm_clear_request(KVM_REQ_UNHALT, vcpu);
|
2011-08-08 23:21:15 +08:00
|
|
|
vcpu->stat.halt_wakeup++;
|
|
|
|
|
return EMULATE_DONE;
|
kvmppc: Implement H_LOGICAL_CI_{LOAD,STORE} in KVM
On POWER, storage caching is usually configured via the MMU - attributes
such as cache-inhibited are stored in the TLB and the hashed page table.
This makes correctly performing cache inhibited IO accesses awkward when
the MMU is turned off (real mode). Some CPU models provide special
registers to control the cache attributes of real mode load and stores but
this is not at all consistent. This is a problem in particular for SLOF,
the firmware used on KVM guests, which runs entirely in real mode, but
which needs to do IO to load the kernel.
To simplify this qemu implements two special hypercalls, H_LOGICAL_CI_LOAD
and H_LOGICAL_CI_STORE which simulate a cache-inhibited load or store to
a logical address (aka guest physical address). SLOF uses these for IO.
However, because these are implemented within qemu, not the host kernel,
these bypass any IO devices emulated within KVM itself. The simplest way
to see this problem is to attempt to boot a KVM guest from a virtio-blk
device with iothread / dataplane enabled. The iothread code relies on an
in kernel implementation of the virtio queue notification, which is not
triggered by the IO hcalls, and so the guest will stall in SLOF unable to
load the guest OS.
This patch addresses this by providing in-kernel implementations of the
2 hypercalls, which correctly scan the KVM IO bus. Any access to an
address not handled by the KVM IO bus will cause a VM exit, hitting the
qemu implementation as before.
Note that a userspace change is also required, in order to enable these
new hcall implementations with KVM_CAP_PPC_ENABLE_HCALL.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
[agraf: fix compilation]
Signed-off-by: Alexander Graf <agraf@suse.de>
2015-02-05 08:53:25 +08:00
|
|
|
case H_LOGICAL_CI_LOAD:
|
|
|
|
|
return kvmppc_h_pr_logical_ci_load(vcpu);
|
|
|
|
|
case H_LOGICAL_CI_STORE:
|
|
|
|
|
return kvmppc_h_pr_logical_ci_store(vcpu);
|
2013-04-18 04:30:26 +08:00
|
|
|
case H_XIRR:
|
|
|
|
|
case H_CPPR:
|
|
|
|
|
case H_EOI:
|
|
|
|
|
case H_IPI:
|
2013-05-23 23:42:21 +08:00
|
|
|
case H_IPOLL:
|
|
|
|
|
case H_XIRR_X:
|
2013-04-18 04:30:26 +08:00
|
|
|
if (kvmppc_xics_enabled(vcpu))
|
|
|
|
|
return kvmppc_h_pr_xics_hcall(vcpu, cmd);
|
|
|
|
|
break;
|
2013-04-18 04:30:00 +08:00
|
|
|
case H_RTAS:
|
|
|
|
|
if (list_empty(&vcpu->kvm->arch.rtas_tokens))
|
2014-07-19 15:59:35 +08:00
|
|
|
break;
|
|
|
|
|
idx = srcu_read_lock(&vcpu->kvm->srcu);
|
|
|
|
|
rc = kvmppc_rtas_hcall(vcpu);
|
|
|
|
|
srcu_read_unlock(&vcpu->kvm->srcu, idx);
|
|
|
|
|
if (rc)
|
2013-04-18 04:30:00 +08:00
|
|
|
break;
|
|
|
|
|
kvmppc_set_gpr(vcpu, 3, 0);
|
|
|
|
|
return EMULATE_DONE;
|
2011-08-08 23:21:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return EMULATE_FAIL;
|
|
|
|
|
}
|
2014-06-02 09:02:59 +08:00
|
|
|
|
2014-06-02 09:03:00 +08:00
|
|
|
int kvmppc_hcall_impl_pr(unsigned long cmd)
|
|
|
|
|
{
|
|
|
|
|
switch (cmd) {
|
|
|
|
|
case H_ENTER:
|
|
|
|
|
case H_REMOVE:
|
|
|
|
|
case H_PROTECT:
|
|
|
|
|
case H_BULK_REMOVE:
|
|
|
|
|
case H_PUT_TCE:
|
2017-10-11 13:01:08 +08:00
|
|
|
case H_PUT_TCE_INDIRECT:
|
|
|
|
|
case H_STUFF_TCE:
|
2014-06-02 09:03:00 +08:00
|
|
|
case H_CEDE:
|
kvmppc: Implement H_LOGICAL_CI_{LOAD,STORE} in KVM
On POWER, storage caching is usually configured via the MMU - attributes
such as cache-inhibited are stored in the TLB and the hashed page table.
This makes correctly performing cache inhibited IO accesses awkward when
the MMU is turned off (real mode). Some CPU models provide special
registers to control the cache attributes of real mode load and stores but
this is not at all consistent. This is a problem in particular for SLOF,
the firmware used on KVM guests, which runs entirely in real mode, but
which needs to do IO to load the kernel.
To simplify this qemu implements two special hypercalls, H_LOGICAL_CI_LOAD
and H_LOGICAL_CI_STORE which simulate a cache-inhibited load or store to
a logical address (aka guest physical address). SLOF uses these for IO.
However, because these are implemented within qemu, not the host kernel,
these bypass any IO devices emulated within KVM itself. The simplest way
to see this problem is to attempt to boot a KVM guest from a virtio-blk
device with iothread / dataplane enabled. The iothread code relies on an
in kernel implementation of the virtio queue notification, which is not
triggered by the IO hcalls, and so the guest will stall in SLOF unable to
load the guest OS.
This patch addresses this by providing in-kernel implementations of the
2 hypercalls, which correctly scan the KVM IO bus. Any access to an
address not handled by the KVM IO bus will cause a VM exit, hitting the
qemu implementation as before.
Note that a userspace change is also required, in order to enable these
new hcall implementations with KVM_CAP_PPC_ENABLE_HCALL.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
[agraf: fix compilation]
Signed-off-by: Alexander Graf <agraf@suse.de>
2015-02-05 08:53:25 +08:00
|
|
|
case H_LOGICAL_CI_LOAD:
|
|
|
|
|
case H_LOGICAL_CI_STORE:
|
2014-06-02 09:03:00 +08:00
|
|
|
#ifdef CONFIG_KVM_XICS
|
|
|
|
|
case H_XIRR:
|
|
|
|
|
case H_CPPR:
|
|
|
|
|
case H_EOI:
|
|
|
|
|
case H_IPI:
|
|
|
|
|
case H_IPOLL:
|
|
|
|
|
case H_XIRR_X:
|
|
|
|
|
#endif
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2014-06-02 09:02:59 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* List of hcall numbers to enable by default.
|
|
|
|
|
* For compatibility with old userspace, we enable by default
|
|
|
|
|
* all hcalls that were implemented before the hcall-enabling
|
|
|
|
|
* facility was added. Note this list should not include H_RTAS.
|
|
|
|
|
*/
|
|
|
|
|
static unsigned int default_hcall_list[] = {
|
|
|
|
|
H_ENTER,
|
|
|
|
|
H_REMOVE,
|
|
|
|
|
H_PROTECT,
|
|
|
|
|
H_BULK_REMOVE,
|
|
|
|
|
H_PUT_TCE,
|
|
|
|
|
H_CEDE,
|
|
|
|
|
#ifdef CONFIG_KVM_XICS
|
|
|
|
|
H_XIRR,
|
|
|
|
|
H_CPPR,
|
|
|
|
|
H_EOI,
|
|
|
|
|
H_IPI,
|
|
|
|
|
H_IPOLL,
|
|
|
|
|
H_XIRR_X,
|
|
|
|
|
#endif
|
|
|
|
|
0
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
void kvmppc_pr_init_default_hcalls(struct kvm *kvm)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
2014-06-02 09:03:00 +08:00
|
|
|
unsigned int hcall;
|
2014-06-02 09:02:59 +08:00
|
|
|
|
2014-06-02 09:03:00 +08:00
|
|
|
for (i = 0; default_hcall_list[i]; ++i) {
|
|
|
|
|
hcall = default_hcall_list[i];
|
|
|
|
|
WARN_ON(!kvmppc_hcall_impl_pr(hcall));
|
|
|
|
|
__set_bit(hcall / 4, kvm->arch.enabled_hcalls);
|
|
|
|
|
}
|
2014-06-02 09:02:59 +08:00
|
|
|
}
|