* Re: [PATCH 2/4] KVM: PPC: BOOK3S: PR: Doorbell support
From: Aneesh Kumar K.V @ 2014-06-05 15:55 UTC (permalink / raw)
To: Alexander Graf, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <53906156.4090403@suse.de>
Alexander Graf <agraf@suse.de> writes:
> On 05.06.14 14:21, Alexander Graf wrote:
>>
>> On 05.06.14 14:08, Aneesh Kumar K.V wrote:
>>> We don't have SMT support yet, hence we should not find a doorbell
>>> message generated
>>>
>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>>> ---
>>> arch/powerpc/kvm/book3s_emulate.c | 18 ++++++++++++++++++
>>> 1 file changed, 18 insertions(+)
>>>
>>> diff --git a/arch/powerpc/kvm/book3s_emulate.c
>>> b/arch/powerpc/kvm/book3s_emulate.c
>>> index 1bb16a59dcbc..d6c87d085182 100644
>>> --- a/arch/powerpc/kvm/book3s_emulate.c
>>> +++ b/arch/powerpc/kvm/book3s_emulate.c
>>> @@ -28,7 +28,9 @@
>>> #define OP_19_XOP_RFI 50
>>> #define OP_31_XOP_MFMSR 83
>>> +#define OP_31_XOP_MSGSNDP 142
>>> #define OP_31_XOP_MTMSR 146
>>> +#define OP_31_XOP_MSGCLRP 174
>>> #define OP_31_XOP_MTMSRD 178
>>> #define OP_31_XOP_MTSR 210
>>> #define OP_31_XOP_MTSRIN 242
>>> @@ -303,6 +305,22 @@ int kvmppc_core_emulate_op_pr(struct kvm_run
>>> *run, struct kvm_vcpu *vcpu,
>>> break;
>>> }
>>> + case OP_31_XOP_MSGSNDP:
>>> + {
>>> + /*
>>> + * PR KVM still don't support SMT mode. So we should
>>
>> still?
>>
>>> + * not see a MSGSNDP/MSGCLRP used with PR KVM
>>> + */
>>> + pr_info("KVM: MSGSNDP used in non SMT case\n");
>>> + emulated = EMULATE_FAIL;
>>
>> What would happen on an HV guest with only 1 thread that MSGSNDs to
>> thread 0? Would the guest get an illegal instruction trap, a
>> self-interrupt or would this be a simple nop?
>
> What I'm trying to say here is that it's ok to treat it as illegal
> instructions, but then we don't need this patch :).
>
Agreed. I will verify whether it is treated as a nop. If so will send an
updated patch.
-aneesh
^ permalink raw reply
* Re: [PATCH 1/4] KVM: PPC: BOOK3S: PR: Emulate virtual timebase register
From: Aneesh Kumar K.V @ 2014-06-05 15:50 UTC (permalink / raw)
To: Alexander Graf, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <5390604C.4050704@suse.de>
Alexander Graf <agraf@suse.de> writes:
> On 05.06.14 14:08, Aneesh Kumar K.V wrote:
>> virtual time base register is a per VM, per cpu register that needs
>> to be saved and restored on vm exit and entry. Writing to VTB is not
>> allowed in the privileged mode.
>>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/include/asm/kvm_host.h | 1 +
>> arch/powerpc/include/asm/reg.h | 15 +++++++++++++++
>> arch/powerpc/include/asm/time.h | 9 +++++++++
>> arch/powerpc/kvm/book3s.c | 6 ++++++
>> arch/powerpc/kvm/book3s_emulate.c | 3 +++
>> arch/powerpc/kvm/book3s_hv.c | 6 ------
>> arch/powerpc/kvm/book3s_pr.c | 3 ++-
>> 7 files changed, 36 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
>> index 4a58731a0a72..bd3caeaeebe1 100644
>> --- a/arch/powerpc/include/asm/kvm_host.h
>> +++ b/arch/powerpc/include/asm/kvm_host.h
>> @@ -505,6 +505,7 @@ struct kvm_vcpu_arch {
>> #endif
>> /* Time base value when we entered the guest */
>> u64 entry_tb;
>> + u64 entry_vtb;
>> u32 tcr;
>> ulong tsr; /* we need to perform set/clr_bits() which requires ulong */
>> u32 ivor[64];
>> diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
>> index 4852bcf270f3..3e7085d8af90 100644
>> --- a/arch/powerpc/include/asm/reg.h
>> +++ b/arch/powerpc/include/asm/reg.h
>> @@ -25,6 +25,7 @@
>> #ifdef CONFIG_8xx
>> #include <asm/reg_8xx.h>
>> #endif /* CONFIG_8xx */
>> +#include <asm/bug.h>
>>
>> #define MSR_SF_LG 63 /* Enable 64 bit mode */
>> #define MSR_ISF_LG 61 /* Interrupt 64b mode valid on 630 */
>> @@ -1193,6 +1194,20 @@
>> : "r" ((unsigned long)(v)) \
>> : "memory")
>>
>> +static inline unsigned long mfvtb (void)
>> +{
>> +#ifdef CONFIG_PPC_BOOK3S_64
>> + if (cpu_has_feature(CPU_FTR_ARCH_207S))
>> + return mfspr(SPRN_VTB);
>> +#endif
>> + /*
>> + * The above mfspr will be a no-op on anything before Power8
>> + * That can result in random values returned. We need to
>> + * capture that.
>> + */
>> + BUG();
>> +}
>> +
>> #ifdef __powerpc64__
>> #if defined(CONFIG_PPC_CELL) || defined(CONFIG_PPC_FSL_BOOK3E)
>> #define mftb() ({unsigned long rval; \
>> diff --git a/arch/powerpc/include/asm/time.h b/arch/powerpc/include/asm/time.h
>> index 1d428e6007ca..03cbada59d3a 100644
>> --- a/arch/powerpc/include/asm/time.h
>> +++ b/arch/powerpc/include/asm/time.h
>> @@ -102,6 +102,15 @@ static inline u64 get_rtc(void)
>> return (u64)hi * 1000000000 + lo;
>> }
>>
>> +static inline u64 get_vtb(void)
>> +{
>> +#ifdef CONFIG_PPC_BOOK3S_64
>> + if (cpu_has_feature(CPU_FTR_ARCH_207S))
>> + return mfvtb();
>> +#endif
>> + return 0;
>> +}
>> +
>> #ifdef CONFIG_PPC64
>> static inline u64 get_tb(void)
>> {
>> diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
>> index 52c654dbd41a..ae43e4178ecd 100644
>> --- a/arch/powerpc/kvm/book3s.c
>> +++ b/arch/powerpc/kvm/book3s.c
>> @@ -646,6 +646,9 @@ int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg)
>> case KVM_REG_PPC_BESCR:
>> val = get_reg_val(reg->id, vcpu->arch.bescr);
>> break;
>> + case KVM_REG_PPC_VTB:
>> + val = get_reg_val(reg->id, vcpu->arch.vtb);
>> + break;
>> default:
>> r = -EINVAL;
>> break;
>> @@ -750,6 +753,9 @@ int kvm_vcpu_ioctl_set_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg)
>> case KVM_REG_PPC_BESCR:
>> vcpu->arch.bescr = set_reg_val(reg->id, val);
>> break;
>> + case KVM_REG_PPC_VTB:
>> + vcpu->arch.vtb = set_reg_val(reg->id, val);
>> + break;
>> default:
>> r = -EINVAL;
>> break;
>> diff --git a/arch/powerpc/kvm/book3s_emulate.c b/arch/powerpc/kvm/book3s_emulate.c
>> index 3565e775b61b..1bb16a59dcbc 100644
>> --- a/arch/powerpc/kvm/book3s_emulate.c
>> +++ b/arch/powerpc/kvm/book3s_emulate.c
>> @@ -577,6 +577,9 @@ int kvmppc_core_emulate_mfspr_pr(struct kvm_vcpu *vcpu, int sprn, ulong *spr_val
>> */
>> *spr_val = vcpu->arch.spurr;
>> break;
>> + case SPRN_VTB:
>> + *spr_val = vcpu->arch.vtb;
>
> Doesn't this mean that vtb can be the same 2 when the guest reads it 2
> times in a row without getting preempted?
But a mfspr will result in VM exit and that would make sure we
update vcpu->arch.vtb with the correct value.
-aneesh
^ permalink raw reply
* [PATCH 2/2] powerpc/powernv : Disable subcore for UP configs
From: Shreyas B. Prabhu @ 2014-06-05 15:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: Shreyas B. Prabhu, linuxppc-dev, linux-kernel
In-Reply-To: <1401981695-3682-1-git-send-email-shreyas@linux.vnet.ibm.com>
Build throws following errors when CONFIG_SMP=n
arch/powerpc/platforms/powernv/subcore.c: In function ‘cpu_update_split_mode’:
arch/powerpc/platforms/powernv/subcore.c:274:15: error: ‘setup_max_cpus’ undeclared (first use in this function)
arch/powerpc/platforms/powernv/subcore.c:285:5: error: lvalue required as left operand of assignment
'setup_max_cpus' variable is relevant only on SMP, so there is no point
working around it for UP. Furthermore, subcore.c itself is relevant only
on SMP and hence the better solution is to exclude subcore.c for UP builds.
Signed-off-by: Shreyas B. Prabhu <shreyas@linux.vnet.ibm.com>
---
This patch applies on top of ben/powerpc.git/next branch
arch/powerpc/platforms/powernv/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/Makefile b/arch/powerpc/platforms/powernv/Makefile
index 4ad0d34..636d206 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -1,9 +1,9 @@
obj-y += setup.o opal-takeover.o opal-wrappers.o opal.o opal-async.o
obj-y += opal-rtc.o opal-nvram.o opal-lpc.o opal-flash.o
obj-y += rng.o opal-elog.o opal-dump.o opal-sysparam.o opal-sensor.o
-obj-y += opal-msglog.o subcore.o subcore-asm.o
+obj-y += opal-msglog.o subcore-asm.o
-obj-$(CONFIG_SMP) += smp.o
+obj-$(CONFIG_SMP) += smp.o subcore.o
obj-$(CONFIG_PCI) += pci.o pci-p5ioc2.o pci-ioda.o
obj-$(CONFIG_EEH) += eeh-ioda.o eeh-powernv.o
obj-$(CONFIG_PPC_SCOM) += opal-xscom.o
--
1.9.0
^ permalink raw reply related
* [PATCH 1/2] powerpc/powernv: include asm/smp.h to handle UP config
From: Shreyas B. Prabhu @ 2014-06-05 15:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras
Cc: Geert Uytterhoeven, linuxppc-dev, linux-kernel, Shreyas B. Prabhu
Build throws following errors when CONFIG_SMP=n
arch/powerpc/platforms/powernv/setup.c: In function ‘pnv_kexec_wait_secondaries_down’:
arch/powerpc/platforms/powernv/setup.c:179:4: error: implicit declaration of function ‘get_hard_smp_processor_id’
rc = opal_query_cpu_status(get_hard_smp_processor_id(i),
The usage of get_hard_smp_processor_id() needs the declaration from
<asm/smp.h>. The file setup.c includes <linux/sched.h>, which in-turn
includes <linux/smp.h>. However, <linux/smp.h> includes <asm/smp.h>
only on SMP configs and hence UP builds fail.
Fix this by directly including <asm/smp.h> in setup.c unconditionally.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Shreyas B. Prabhu <shreyas@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/setup.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/platforms/powernv/setup.c b/arch/powerpc/platforms/powernv/setup.c
index 8c16a5f..678573c 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -35,6 +35,7 @@
#include <asm/rtas.h>
#include <asm/opal.h>
#include <asm/kexec.h>
+#include <asm/smp.h>
#include "powernv.h"
--
1.9.0
^ permalink raw reply related
* Re: [PATCH 3/3] PPC: KVM: Add support for 64bit TCE windows
From: Alexey Kardashevskiy @ 2014-06-05 13:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Alexander Graf
Cc: kvm, Gleb Natapov, linux-kernel, kvm-ppc, Paul Mackerras,
Paolo Bonzini, linuxppc-dev
In-Reply-To: <1401971411.3247.132.camel@pasglop>
On 06/05/2014 10:30 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2014-06-05 at 13:56 +0200, Alexander Graf wrote:
>> What if we ask user space to give us a pointer to user space allocated
>> memory along with the TCE registration? We would still ask user space to
>> only use the returned fd for TCE modifications, but would have some
>> nicely swappable memory we can store the TCE entries in.
>
> That isn't going to work terribly well for VFIO :-) But yes, for
> emulated devices, we could improve things a bit, including for
> the 32-bit TCE tables.
>
> For emulated, the real mode path could walk the page tables and fallback
> to virtual mode & get_user if the page isn't present, thus operating
> directly on qemu memory TCE tables instead of the current pinned stuff.
>
> However that has a cost in performance, but since that's really only
> used for emulated devices and PAPR VIOs, it might not be a huge issue.
>
> But for VFIO we don't have much choice, we need to create something the
> HW can access.
You are confusing things here.
There are 2 tables:
1. guest-visible TCE table, this is what is allocated for VIO or emulated PCI;
2. real HW DMA window, one exists already for DMA32 and one I will
allocated for a huge window.
I have just #2 for VFIO now but we will need both in order to implement
H_GET_TCE correctly, and this is the table I will allocate by this new ioctl.
>> In fact, the code as is today can allocate an arbitrary amount of pinned
>> kernel memory from within user space without any checks.
>
> Right. We should at least account it in the locked limit.
Yup. And (probably) this thing will keep a counter of how many windows were
created per KVM instance to avoid having multiple copies of the same table.
--
Alexey
^ permalink raw reply
* Re: [PATCH v8 0/3] EEH Support for VFIO PCI Device
From: Alexander Graf @ 2014-06-05 12:54 UTC (permalink / raw)
To: Gavin Shan, kvm-ppc, linuxppc-dev; +Cc: aik, alex.williamson, qiudayu
In-Reply-To: <1401950169-30206-1-git-send-email-gwshan@linux.vnet.ibm.com>
On 05.06.14 08:36, Gavin Shan wrote:
> The series of patches adds support EEH for PCI devices, which are passed
> through to PowerKVM based guest via VFIO. The implementation is straightforward
> based on the issues or problems we have to resolve to support EEH for PowerKVM
> based guest.
>
> - Emulation for EEH RTAS requests. All EEH RTAS requests goes to QEMU firstly.
> If QEMU can't handle it, the request will be sent to host via newly introduced
> VFIO container IOCTL command (VFIO_EEH_OP) and gets handled in host kernel.
>
> The series of patches requires corresponding QEMU changes.
Acked-by: Alexander Graf <agraf@suse.de>
Alex
^ permalink raw reply
* Re: [PATCH 3/3] PPC: KVM: Add support for 64bit TCE windows
From: Alexander Graf @ 2014-06-05 12:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: kvm, Alexey Kardashevskiy, linux-kernel, kvm-ppc, Gleb Natapov,
Paul Mackerras, Paolo Bonzini, linuxppc-dev
In-Reply-To: <1401971411.3247.132.camel@pasglop>
On 05.06.14 14:30, Benjamin Herrenschmidt wrote:
> On Thu, 2014-06-05 at 13:56 +0200, Alexander Graf wrote:
>> What if we ask user space to give us a pointer to user space allocated
>> memory along with the TCE registration? We would still ask user space to
>> only use the returned fd for TCE modifications, but would have some
>> nicely swappable memory we can store the TCE entries in.
> That isn't going to work terribly well for VFIO :-) But yes, for
> emulated devices, we could improve things a bit, including for
> the 32-bit TCE tables.
>
> For emulated, the real mode path could walk the page tables and fallback
> to virtual mode & get_user if the page isn't present, thus operating
> directly on qemu memory TCE tables instead of the current pinned stuff.
>
> However that has a cost in performance, but since that's really only
> used for emulated devices and PAPR VIOs, it might not be a huge issue.
>
> But for VFIO we don't have much choice, we need to create something the
> HW can access.
But we need to create separate tables for VFIO anyways, because these
TCE tables contain virtual addresses, no?
Alex
>
>> In fact, the code as is today can allocate an arbitrary amount of pinned
>> kernel memory from within user space without any checks.
> Right. We should at least account it in the locked limit.
>
> Cheers,
> Ben.
>
>
^ permalink raw reply
* Re: [PATCH 3/3] PPC: KVM: Add support for 64bit TCE windows
From: Benjamin Herrenschmidt @ 2014-06-05 12:30 UTC (permalink / raw)
To: Alexander Graf
Cc: kvm, Alexey Kardashevskiy, linux-kernel, kvm-ppc, Gleb Natapov,
Paul Mackerras, Paolo Bonzini, linuxppc-dev
In-Reply-To: <53905ADB.8000100@suse.de>
On Thu, 2014-06-05 at 13:56 +0200, Alexander Graf wrote:
> What if we ask user space to give us a pointer to user space allocated
> memory along with the TCE registration? We would still ask user space to
> only use the returned fd for TCE modifications, but would have some
> nicely swappable memory we can store the TCE entries in.
That isn't going to work terribly well for VFIO :-) But yes, for
emulated devices, we could improve things a bit, including for
the 32-bit TCE tables.
For emulated, the real mode path could walk the page tables and fallback
to virtual mode & get_user if the page isn't present, thus operating
directly on qemu memory TCE tables instead of the current pinned stuff.
However that has a cost in performance, but since that's really only
used for emulated devices and PAPR VIOs, it might not be a huge issue.
But for VFIO we don't have much choice, we need to create something the
HW can access.
> In fact, the code as is today can allocate an arbitrary amount of pinned
> kernel memory from within user space without any checks.
Right. We should at least account it in the locked limit.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 2/4] KVM: PPC: BOOK3S: PR: Doorbell support
From: Alexander Graf @ 2014-06-05 12:23 UTC (permalink / raw)
To: Aneesh Kumar K.V, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <539060B5.9040808@suse.de>
On 05.06.14 14:21, Alexander Graf wrote:
>
> On 05.06.14 14:08, Aneesh Kumar K.V wrote:
>> We don't have SMT support yet, hence we should not find a doorbell
>> message generated
>>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/kvm/book3s_emulate.c | 18 ++++++++++++++++++
>> 1 file changed, 18 insertions(+)
>>
>> diff --git a/arch/powerpc/kvm/book3s_emulate.c
>> b/arch/powerpc/kvm/book3s_emulate.c
>> index 1bb16a59dcbc..d6c87d085182 100644
>> --- a/arch/powerpc/kvm/book3s_emulate.c
>> +++ b/arch/powerpc/kvm/book3s_emulate.c
>> @@ -28,7 +28,9 @@
>> #define OP_19_XOP_RFI 50
>> #define OP_31_XOP_MFMSR 83
>> +#define OP_31_XOP_MSGSNDP 142
>> #define OP_31_XOP_MTMSR 146
>> +#define OP_31_XOP_MSGCLRP 174
>> #define OP_31_XOP_MTMSRD 178
>> #define OP_31_XOP_MTSR 210
>> #define OP_31_XOP_MTSRIN 242
>> @@ -303,6 +305,22 @@ int kvmppc_core_emulate_op_pr(struct kvm_run
>> *run, struct kvm_vcpu *vcpu,
>> break;
>> }
>> + case OP_31_XOP_MSGSNDP:
>> + {
>> + /*
>> + * PR KVM still don't support SMT mode. So we should
>
> still?
>
>> + * not see a MSGSNDP/MSGCLRP used with PR KVM
>> + */
>> + pr_info("KVM: MSGSNDP used in non SMT case\n");
>> + emulated = EMULATE_FAIL;
>
> What would happen on an HV guest with only 1 thread that MSGSNDs to
> thread 0? Would the guest get an illegal instruction trap, a
> self-interrupt or would this be a simple nop?
What I'm trying to say here is that it's ok to treat it as illegal
instructions, but then we don't need this patch :).
Alex
^ permalink raw reply
* Re: [PATCH 2/4] KVM: PPC: BOOK3S: PR: Doorbell support
From: Alexander Graf @ 2014-06-05 12:21 UTC (permalink / raw)
To: Aneesh Kumar K.V, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1401970085-14493-3-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On 05.06.14 14:08, Aneesh Kumar K.V wrote:
> We don't have SMT support yet, hence we should not find a doorbell
> message generated
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> ---
> arch/powerpc/kvm/book3s_emulate.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/powerpc/kvm/book3s_emulate.c b/arch/powerpc/kvm/book3s_emulate.c
> index 1bb16a59dcbc..d6c87d085182 100644
> --- a/arch/powerpc/kvm/book3s_emulate.c
> +++ b/arch/powerpc/kvm/book3s_emulate.c
> @@ -28,7 +28,9 @@
> #define OP_19_XOP_RFI 50
>
> #define OP_31_XOP_MFMSR 83
> +#define OP_31_XOP_MSGSNDP 142
> #define OP_31_XOP_MTMSR 146
> +#define OP_31_XOP_MSGCLRP 174
> #define OP_31_XOP_MTMSRD 178
> #define OP_31_XOP_MTSR 210
> #define OP_31_XOP_MTSRIN 242
> @@ -303,6 +305,22 @@ int kvmppc_core_emulate_op_pr(struct kvm_run *run, struct kvm_vcpu *vcpu,
>
> break;
> }
> + case OP_31_XOP_MSGSNDP:
> + {
> + /*
> + * PR KVM still don't support SMT mode. So we should
still?
> + * not see a MSGSNDP/MSGCLRP used with PR KVM
> + */
> + pr_info("KVM: MSGSNDP used in non SMT case\n");
> + emulated = EMULATE_FAIL;
What would happen on an HV guest with only 1 thread that MSGSNDs to
thread 0? Would the guest get an illegal instruction trap, a
self-interrupt or would this be a simple nop?
Alex
> + break;
> + }
> + case OP_31_XOP_MSGCLRP:
> + {
> + pr_info("KVM: MSGCLRP used in non SMT case\n");
> + emulated = EMULATE_FAIL;
> + break;
> + }
> default:
> emulated = EMULATE_FAIL;
> }
^ permalink raw reply
* Re: [PATCH 1/4] KVM: PPC: BOOK3S: PR: Emulate virtual timebase register
From: Alexander Graf @ 2014-06-05 12:19 UTC (permalink / raw)
To: Aneesh Kumar K.V, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1401970085-14493-2-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On 05.06.14 14:08, Aneesh Kumar K.V wrote:
> virtual time base register is a per VM, per cpu register that needs
> to be saved and restored on vm exit and entry. Writing to VTB is not
> allowed in the privileged mode.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/kvm_host.h | 1 +
> arch/powerpc/include/asm/reg.h | 15 +++++++++++++++
> arch/powerpc/include/asm/time.h | 9 +++++++++
> arch/powerpc/kvm/book3s.c | 6 ++++++
> arch/powerpc/kvm/book3s_emulate.c | 3 +++
> arch/powerpc/kvm/book3s_hv.c | 6 ------
> arch/powerpc/kvm/book3s_pr.c | 3 ++-
> 7 files changed, 36 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
> index 4a58731a0a72..bd3caeaeebe1 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -505,6 +505,7 @@ struct kvm_vcpu_arch {
> #endif
> /* Time base value when we entered the guest */
> u64 entry_tb;
> + u64 entry_vtb;
> u32 tcr;
> ulong tsr; /* we need to perform set/clr_bits() which requires ulong */
> u32 ivor[64];
> diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
> index 4852bcf270f3..3e7085d8af90 100644
> --- a/arch/powerpc/include/asm/reg.h
> +++ b/arch/powerpc/include/asm/reg.h
> @@ -25,6 +25,7 @@
> #ifdef CONFIG_8xx
> #include <asm/reg_8xx.h>
> #endif /* CONFIG_8xx */
> +#include <asm/bug.h>
>
> #define MSR_SF_LG 63 /* Enable 64 bit mode */
> #define MSR_ISF_LG 61 /* Interrupt 64b mode valid on 630 */
> @@ -1193,6 +1194,20 @@
> : "r" ((unsigned long)(v)) \
> : "memory")
>
> +static inline unsigned long mfvtb (void)
> +{
> +#ifdef CONFIG_PPC_BOOK3S_64
> + if (cpu_has_feature(CPU_FTR_ARCH_207S))
> + return mfspr(SPRN_VTB);
> +#endif
> + /*
> + * The above mfspr will be a no-op on anything before Power8
> + * That can result in random values returned. We need to
> + * capture that.
> + */
> + BUG();
> +}
> +
> #ifdef __powerpc64__
> #if defined(CONFIG_PPC_CELL) || defined(CONFIG_PPC_FSL_BOOK3E)
> #define mftb() ({unsigned long rval; \
> diff --git a/arch/powerpc/include/asm/time.h b/arch/powerpc/include/asm/time.h
> index 1d428e6007ca..03cbada59d3a 100644
> --- a/arch/powerpc/include/asm/time.h
> +++ b/arch/powerpc/include/asm/time.h
> @@ -102,6 +102,15 @@ static inline u64 get_rtc(void)
> return (u64)hi * 1000000000 + lo;
> }
>
> +static inline u64 get_vtb(void)
> +{
> +#ifdef CONFIG_PPC_BOOK3S_64
> + if (cpu_has_feature(CPU_FTR_ARCH_207S))
> + return mfvtb();
> +#endif
> + return 0;
> +}
> +
> #ifdef CONFIG_PPC64
> static inline u64 get_tb(void)
> {
> diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
> index 52c654dbd41a..ae43e4178ecd 100644
> --- a/arch/powerpc/kvm/book3s.c
> +++ b/arch/powerpc/kvm/book3s.c
> @@ -646,6 +646,9 @@ int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg)
> case KVM_REG_PPC_BESCR:
> val = get_reg_val(reg->id, vcpu->arch.bescr);
> break;
> + case KVM_REG_PPC_VTB:
> + val = get_reg_val(reg->id, vcpu->arch.vtb);
> + break;
> default:
> r = -EINVAL;
> break;
> @@ -750,6 +753,9 @@ int kvm_vcpu_ioctl_set_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg)
> case KVM_REG_PPC_BESCR:
> vcpu->arch.bescr = set_reg_val(reg->id, val);
> break;
> + case KVM_REG_PPC_VTB:
> + vcpu->arch.vtb = set_reg_val(reg->id, val);
> + break;
> default:
> r = -EINVAL;
> break;
> diff --git a/arch/powerpc/kvm/book3s_emulate.c b/arch/powerpc/kvm/book3s_emulate.c
> index 3565e775b61b..1bb16a59dcbc 100644
> --- a/arch/powerpc/kvm/book3s_emulate.c
> +++ b/arch/powerpc/kvm/book3s_emulate.c
> @@ -577,6 +577,9 @@ int kvmppc_core_emulate_mfspr_pr(struct kvm_vcpu *vcpu, int sprn, ulong *spr_val
> */
> *spr_val = vcpu->arch.spurr;
> break;
> + case SPRN_VTB:
> + *spr_val = vcpu->arch.vtb;
Doesn't this mean that vtb can be the same 2 when the guest reads it 2
times in a row without getting preempted?
Alex
> + break;
> case SPRN_GQR0:
> case SPRN_GQR1:
> case SPRN_GQR2:
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index aba05bbb3e74..f6ac58336b3f 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -897,9 +897,6 @@ static int kvmppc_get_one_reg_hv(struct kvm_vcpu *vcpu, u64 id,
> case KVM_REG_PPC_IC:
> *val = get_reg_val(id, vcpu->arch.ic);
> break;
> - case KVM_REG_PPC_VTB:
> - *val = get_reg_val(id, vcpu->arch.vtb);
> - break;
> case KVM_REG_PPC_CSIGR:
> *val = get_reg_val(id, vcpu->arch.csigr);
> break;
> @@ -1097,9 +1094,6 @@ static int kvmppc_set_one_reg_hv(struct kvm_vcpu *vcpu, u64 id,
> case KVM_REG_PPC_IC:
> vcpu->arch.ic = set_reg_val(id, *val);
> break;
> - case KVM_REG_PPC_VTB:
> - vcpu->arch.vtb = set_reg_val(id, *val);
> - break;
> case KVM_REG_PPC_CSIGR:
> vcpu->arch.csigr = set_reg_val(id, *val);
> break;
> diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
> index ff15f8e31a27..96cdf89a8c86 100644
> --- a/arch/powerpc/kvm/book3s_pr.c
> +++ b/arch/powerpc/kvm/book3s_pr.c
> @@ -125,6 +125,7 @@ void kvmppc_copy_to_svcpu(struct kvmppc_book3s_shadow_vcpu *svcpu,
> * to find the guest purr and spurr value.
> */
> vcpu->arch.entry_tb = get_tb();
> + vcpu->arch.entry_vtb = get_vtb();
> svcpu->in_use = true;
> }
>
> @@ -176,7 +177,7 @@ void kvmppc_copy_from_svcpu(struct kvm_vcpu *vcpu,
> */
> vcpu->arch.purr += get_tb() - vcpu->arch.entry_tb;
> vcpu->arch.spurr += get_tb() - vcpu->arch.entry_tb;
> -
> + vcpu->arch.vtb += get_vtb() - vcpu->arch.entry_vtb;
> svcpu->in_use = false;
>
> out:
^ permalink raw reply
* [PATCH 4/4] KVM: PPC: BOOK3S: PR: Emulate instruction counter
From: Aneesh Kumar K.V @ 2014-06-05 12:08 UTC (permalink / raw)
To: agraf, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc, Aneesh Kumar K.V
In-Reply-To: <1401970085-14493-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
Writing to IC is not allowed in the privileged mode.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/kvm_host.h | 1 +
arch/powerpc/kvm/book3s.c | 6 ++++++
arch/powerpc/kvm/book3s_emulate.c | 3 +++
arch/powerpc/kvm/book3s_hv.c | 6 ------
arch/powerpc/kvm/book3s_pr.c | 4 ++++
5 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index bd3caeaeebe1..f9ae69682ce1 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -506,6 +506,7 @@ struct kvm_vcpu_arch {
/* Time base value when we entered the guest */
u64 entry_tb;
u64 entry_vtb;
+ u64 entry_ic;
u32 tcr;
ulong tsr; /* we need to perform set/clr_bits() which requires ulong */
u32 ivor[64];
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index ae43e4178ecd..52c4c43900cb 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -649,6 +649,9 @@ int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg)
case KVM_REG_PPC_VTB:
val = get_reg_val(reg->id, vcpu->arch.vtb);
break;
+ case KVM_REG_PPC_IC:
+ val = get_reg_val(reg->id, vcpu->arch.ic);
+ break;
default:
r = -EINVAL;
break;
@@ -756,6 +759,9 @@ int kvm_vcpu_ioctl_set_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg)
case KVM_REG_PPC_VTB:
vcpu->arch.vtb = set_reg_val(reg->id, val);
break;
+ case KVM_REG_PPC_IC:
+ vcpu->arch.ic = set_reg_val(reg->id, val);
+ break;
default:
r = -EINVAL;
break;
diff --git a/arch/powerpc/kvm/book3s_emulate.c b/arch/powerpc/kvm/book3s_emulate.c
index 062b5da7786e..e6912c618160 100644
--- a/arch/powerpc/kvm/book3s_emulate.c
+++ b/arch/powerpc/kvm/book3s_emulate.c
@@ -598,6 +598,9 @@ int kvmppc_core_emulate_mfspr_pr(struct kvm_vcpu *vcpu, int sprn, ulong *spr_val
case SPRN_VTB:
*spr_val = vcpu->arch.vtb;
break;
+ case SPRN_IC:
+ *spr_val = vcpu->arch.ic;
+ break;
case SPRN_GQR0:
case SPRN_GQR1:
case SPRN_GQR2:
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index f6ac58336b3f..c38cf9f836c0 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -894,9 +894,6 @@ static int kvmppc_get_one_reg_hv(struct kvm_vcpu *vcpu, u64 id,
case KVM_REG_PPC_CIABR:
*val = get_reg_val(id, vcpu->arch.ciabr);
break;
- case KVM_REG_PPC_IC:
- *val = get_reg_val(id, vcpu->arch.ic);
- break;
case KVM_REG_PPC_CSIGR:
*val = get_reg_val(id, vcpu->arch.csigr);
break;
@@ -1091,9 +1088,6 @@ static int kvmppc_set_one_reg_hv(struct kvm_vcpu *vcpu, u64 id,
if ((vcpu->arch.ciabr & CIABR_PRIV) == CIABR_PRIV_HYPER)
vcpu->arch.ciabr &= ~CIABR_PRIV; /* disable */
break;
- case KVM_REG_PPC_IC:
- vcpu->arch.ic = set_reg_val(id, *val);
- break;
case KVM_REG_PPC_CSIGR:
vcpu->arch.csigr = set_reg_val(id, *val);
break;
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index 96cdf89a8c86..03fc8847cd67 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -126,6 +126,8 @@ void kvmppc_copy_to_svcpu(struct kvmppc_book3s_shadow_vcpu *svcpu,
*/
vcpu->arch.entry_tb = get_tb();
vcpu->arch.entry_vtb = get_vtb();
+ if (cpu_has_feature(CPU_FTR_ARCH_207S))
+ vcpu->arch.entry_ic = mfspr(SPRN_IC);
svcpu->in_use = true;
}
@@ -178,6 +180,8 @@ void kvmppc_copy_from_svcpu(struct kvm_vcpu *vcpu,
vcpu->arch.purr += get_tb() - vcpu->arch.entry_tb;
vcpu->arch.spurr += get_tb() - vcpu->arch.entry_tb;
vcpu->arch.vtb += get_vtb() - vcpu->arch.entry_vtb;
+ if (cpu_has_feature(CPU_FTR_ARCH_207S))
+ vcpu->arch.ic += mfspr(SPRN_IC) - vcpu->arch.entry_ic;
svcpu->in_use = false;
out:
--
1.9.1
^ permalink raw reply related
* [PATCH 3/4] KVM: PPC: BOOK3S: PR: Emulate DPDES register
From: Aneesh Kumar K.V @ 2014-06-05 12:08 UTC (permalink / raw)
To: agraf, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc, Aneesh Kumar K.V
In-Reply-To: <1401970085-14493-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
Since we don't support SMT yet, we should always find zero in
Directed privileged doorbell exception state register.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
arch/powerpc/kvm/book3s_emulate.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kvm/book3s_emulate.c b/arch/powerpc/kvm/book3s_emulate.c
index d6c87d085182..062b5da7786e 100644
--- a/arch/powerpc/kvm/book3s_emulate.c
+++ b/arch/powerpc/kvm/book3s_emulate.c
@@ -655,6 +655,7 @@ int kvmppc_core_emulate_mfspr_pr(struct kvm_vcpu *vcpu, int sprn, ulong *spr_val
case SPRN_MMCR1:
case SPRN_MMCR2:
case SPRN_TIR:
+ case SPRN_DPDES:
#endif
*spr_val = 0;
break;
--
1.9.1
^ permalink raw reply related
* [PATCH 1/4] KVM: PPC: BOOK3S: PR: Emulate virtual timebase register
From: Aneesh Kumar K.V @ 2014-06-05 12:08 UTC (permalink / raw)
To: agraf, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc, Aneesh Kumar K.V
In-Reply-To: <1401970085-14493-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
virtual time base register is a per VM, per cpu register that needs
to be saved and restored on vm exit and entry. Writing to VTB is not
allowed in the privileged mode.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/kvm_host.h | 1 +
arch/powerpc/include/asm/reg.h | 15 +++++++++++++++
arch/powerpc/include/asm/time.h | 9 +++++++++
arch/powerpc/kvm/book3s.c | 6 ++++++
arch/powerpc/kvm/book3s_emulate.c | 3 +++
arch/powerpc/kvm/book3s_hv.c | 6 ------
arch/powerpc/kvm/book3s_pr.c | 3 ++-
7 files changed, 36 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index 4a58731a0a72..bd3caeaeebe1 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -505,6 +505,7 @@ struct kvm_vcpu_arch {
#endif
/* Time base value when we entered the guest */
u64 entry_tb;
+ u64 entry_vtb;
u32 tcr;
ulong tsr; /* we need to perform set/clr_bits() which requires ulong */
u32 ivor[64];
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index 4852bcf270f3..3e7085d8af90 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -25,6 +25,7 @@
#ifdef CONFIG_8xx
#include <asm/reg_8xx.h>
#endif /* CONFIG_8xx */
+#include <asm/bug.h>
#define MSR_SF_LG 63 /* Enable 64 bit mode */
#define MSR_ISF_LG 61 /* Interrupt 64b mode valid on 630 */
@@ -1193,6 +1194,20 @@
: "r" ((unsigned long)(v)) \
: "memory")
+static inline unsigned long mfvtb (void)
+{
+#ifdef CONFIG_PPC_BOOK3S_64
+ if (cpu_has_feature(CPU_FTR_ARCH_207S))
+ return mfspr(SPRN_VTB);
+#endif
+ /*
+ * The above mfspr will be a no-op on anything before Power8
+ * That can result in random values returned. We need to
+ * capture that.
+ */
+ BUG();
+}
+
#ifdef __powerpc64__
#if defined(CONFIG_PPC_CELL) || defined(CONFIG_PPC_FSL_BOOK3E)
#define mftb() ({unsigned long rval; \
diff --git a/arch/powerpc/include/asm/time.h b/arch/powerpc/include/asm/time.h
index 1d428e6007ca..03cbada59d3a 100644
--- a/arch/powerpc/include/asm/time.h
+++ b/arch/powerpc/include/asm/time.h
@@ -102,6 +102,15 @@ static inline u64 get_rtc(void)
return (u64)hi * 1000000000 + lo;
}
+static inline u64 get_vtb(void)
+{
+#ifdef CONFIG_PPC_BOOK3S_64
+ if (cpu_has_feature(CPU_FTR_ARCH_207S))
+ return mfvtb();
+#endif
+ return 0;
+}
+
#ifdef CONFIG_PPC64
static inline u64 get_tb(void)
{
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 52c654dbd41a..ae43e4178ecd 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -646,6 +646,9 @@ int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg)
case KVM_REG_PPC_BESCR:
val = get_reg_val(reg->id, vcpu->arch.bescr);
break;
+ case KVM_REG_PPC_VTB:
+ val = get_reg_val(reg->id, vcpu->arch.vtb);
+ break;
default:
r = -EINVAL;
break;
@@ -750,6 +753,9 @@ int kvm_vcpu_ioctl_set_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg)
case KVM_REG_PPC_BESCR:
vcpu->arch.bescr = set_reg_val(reg->id, val);
break;
+ case KVM_REG_PPC_VTB:
+ vcpu->arch.vtb = set_reg_val(reg->id, val);
+ break;
default:
r = -EINVAL;
break;
diff --git a/arch/powerpc/kvm/book3s_emulate.c b/arch/powerpc/kvm/book3s_emulate.c
index 3565e775b61b..1bb16a59dcbc 100644
--- a/arch/powerpc/kvm/book3s_emulate.c
+++ b/arch/powerpc/kvm/book3s_emulate.c
@@ -577,6 +577,9 @@ int kvmppc_core_emulate_mfspr_pr(struct kvm_vcpu *vcpu, int sprn, ulong *spr_val
*/
*spr_val = vcpu->arch.spurr;
break;
+ case SPRN_VTB:
+ *spr_val = vcpu->arch.vtb;
+ break;
case SPRN_GQR0:
case SPRN_GQR1:
case SPRN_GQR2:
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index aba05bbb3e74..f6ac58336b3f 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -897,9 +897,6 @@ static int kvmppc_get_one_reg_hv(struct kvm_vcpu *vcpu, u64 id,
case KVM_REG_PPC_IC:
*val = get_reg_val(id, vcpu->arch.ic);
break;
- case KVM_REG_PPC_VTB:
- *val = get_reg_val(id, vcpu->arch.vtb);
- break;
case KVM_REG_PPC_CSIGR:
*val = get_reg_val(id, vcpu->arch.csigr);
break;
@@ -1097,9 +1094,6 @@ static int kvmppc_set_one_reg_hv(struct kvm_vcpu *vcpu, u64 id,
case KVM_REG_PPC_IC:
vcpu->arch.ic = set_reg_val(id, *val);
break;
- case KVM_REG_PPC_VTB:
- vcpu->arch.vtb = set_reg_val(id, *val);
- break;
case KVM_REG_PPC_CSIGR:
vcpu->arch.csigr = set_reg_val(id, *val);
break;
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index ff15f8e31a27..96cdf89a8c86 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -125,6 +125,7 @@ void kvmppc_copy_to_svcpu(struct kvmppc_book3s_shadow_vcpu *svcpu,
* to find the guest purr and spurr value.
*/
vcpu->arch.entry_tb = get_tb();
+ vcpu->arch.entry_vtb = get_vtb();
svcpu->in_use = true;
}
@@ -176,7 +177,7 @@ void kvmppc_copy_from_svcpu(struct kvm_vcpu *vcpu,
*/
vcpu->arch.purr += get_tb() - vcpu->arch.entry_tb;
vcpu->arch.spurr += get_tb() - vcpu->arch.entry_tb;
-
+ vcpu->arch.vtb += get_vtb() - vcpu->arch.entry_vtb;
svcpu->in_use = false;
out:
--
1.9.1
^ permalink raw reply related
* [PATCH 2/4] KVM: PPC: BOOK3S: PR: Doorbell support
From: Aneesh Kumar K.V @ 2014-06-05 12:08 UTC (permalink / raw)
To: agraf, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc, Aneesh Kumar K.V
In-Reply-To: <1401970085-14493-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
We don't have SMT support yet, hence we should not find a doorbell
message generated
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
arch/powerpc/kvm/book3s_emulate.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/powerpc/kvm/book3s_emulate.c b/arch/powerpc/kvm/book3s_emulate.c
index 1bb16a59dcbc..d6c87d085182 100644
--- a/arch/powerpc/kvm/book3s_emulate.c
+++ b/arch/powerpc/kvm/book3s_emulate.c
@@ -28,7 +28,9 @@
#define OP_19_XOP_RFI 50
#define OP_31_XOP_MFMSR 83
+#define OP_31_XOP_MSGSNDP 142
#define OP_31_XOP_MTMSR 146
+#define OP_31_XOP_MSGCLRP 174
#define OP_31_XOP_MTMSRD 178
#define OP_31_XOP_MTSR 210
#define OP_31_XOP_MTSRIN 242
@@ -303,6 +305,22 @@ int kvmppc_core_emulate_op_pr(struct kvm_run *run, struct kvm_vcpu *vcpu,
break;
}
+ case OP_31_XOP_MSGSNDP:
+ {
+ /*
+ * PR KVM still don't support SMT mode. So we should
+ * not see a MSGSNDP/MSGCLRP used with PR KVM
+ */
+ pr_info("KVM: MSGSNDP used in non SMT case\n");
+ emulated = EMULATE_FAIL;
+ break;
+ }
+ case OP_31_XOP_MSGCLRP:
+ {
+ pr_info("KVM: MSGCLRP used in non SMT case\n");
+ emulated = EMULATE_FAIL;
+ break;
+ }
default:
emulated = EMULATE_FAIL;
}
--
1.9.1
^ permalink raw reply related
* KVM: PPC: BOOK3S: PR: P8 Support
From: Aneesh Kumar K.V @ 2014-06-05 12:08 UTC (permalink / raw)
To: agraf, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc
This patchset adds support for emulating VTB, IC and Doorbell features in P8.
Doorbell support is dummy since we don't support SMT cores with PR-KVM.
-aneesh
^ permalink raw reply
* Re: [PATCH 0/3] Prepare for in-kernel VFIO DMA operations acceleration
From: Alexander Graf @ 2014-06-05 11:57 UTC (permalink / raw)
To: Alexey Kardashevskiy, linuxppc-dev
Cc: kvm, Gleb Natapov, linux-kernel, kvm-ppc, Paul Mackerras,
Paolo Bonzini
In-Reply-To: <1401953144-19186-1-git-send-email-aik@ozlabs.ru>
On 05.06.14 09:25, Alexey Kardashevskiy wrote:
> This reserves 2 capability numbers.
>
> This implements an extended version of KVM_CREATE_SPAPR_TCE_64 ioctl.
>
> Please advise how to proceed with these patches as I suspect that
> first two should go via Paolo's tree while the last one via Alex Graf's tree
> (correct?).
They would just go via my tree, but only be actually allocated (read:
mergable to qemu) when they hit Paolo's tree.
In fact, I don't think it makes sense to split them off at all.
Alex
^ permalink raw reply
* Re: [PATCH 3/3] PPC: KVM: Add support for 64bit TCE windows
From: Alexander Graf @ 2014-06-05 11:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Alexey Kardashevskiy
Cc: kvm, Gleb Natapov, linux-kernel, kvm-ppc, Paul Mackerras,
Paolo Bonzini, linuxppc-dev
In-Reply-To: <1401964037.3247.129.camel@pasglop>
On 05.06.14 12:27, Benjamin Herrenschmidt wrote:
> On Thu, 2014-06-05 at 19:26 +1000, Alexey Kardashevskiy wrote:
>> No trees yet. For 64GB window we need (64<<30)/(16<<20)*8 = 32K TCE table.
>> Do we really need trees?
> The above is assuming hugetlbfs backed guests. These are the least of my worry
> indeed. But we need to deal with 4k and 64k guests.
What if we ask user space to give us a pointer to user space allocated
memory along with the TCE registration? We would still ask user space to
only use the returned fd for TCE modifications, but would have some
nicely swappable memory we can store the TCE entries in.
In fact, the code as is today can allocate an arbitrary amount of pinned
kernel memory from within user space without any checks.
Alex
^ permalink raw reply
* Re: [PATCH 3/3] PPC: KVM: Add support for 64bit TCE windows
From: Benjamin Herrenschmidt @ 2014-06-05 10:27 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: kvm, Gleb Natapov, Alexander Graf, kvm-ppc, linux-kernel,
Paul Mackerras, Paolo Bonzini, linuxppc-dev
In-Reply-To: <539037DB.5080706@ozlabs.ru>
On Thu, 2014-06-05 at 19:26 +1000, Alexey Kardashevskiy wrote:
>
> No trees yet. For 64GB window we need (64<<30)/(16<<20)*8 = 32K TCE table.
> Do we really need trees?
The above is assuming hugetlbfs backed guests. These are the least of my worry
indeed. But we need to deal with 4k and 64k guests.
Cheers,
Ben
^ permalink raw reply
* Re: [PATCH 3/3] PPC: KVM: Add support for 64bit TCE windows
From: Alexey Kardashevskiy @ 2014-06-05 9:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: kvm, Gleb Natapov, Alexander Graf, kvm-ppc, linux-kernel,
Paul Mackerras, Paolo Bonzini, linuxppc-dev
In-Reply-To: <1401953908.3247.121.camel@pasglop>
On 06/05/2014 05:38 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2014-06-05 at 17:25 +1000, Alexey Kardashevskiy wrote:
>> +This creates a virtual TCE (translation control entry) table, which
>> +is an IOMMU for PAPR-style virtual I/O. It is used to translate
>> +logical addresses used in virtual I/O into guest physical addresses,
>> +and provides a scatter/gather capability for PAPR virtual I/O.
>> +
>> +/* for KVM_CAP_SPAPR_TCE_64 */
>> +struct kvm_create_spapr_tce_64 {
>> + __u64 liobn;
>> + __u64 window_size;
>> + __u64 bus_offset;
>> + __u32 page_shift;
>> + __u32 flags;
>> +};
>> +
>> +The liobn field gives the logical IO bus number for which to create a
>> +TCE table. The window_size field specifies the size of the DMA window
>> +which this TCE table will translate - the table will contain one 64
>> +bit TCE entry for every IOMMU page. The bus_offset field tells where
>> +this window is mapped on the IO bus.
>
> Hrm, the bus_offset cannot be set arbitrarily, it has some pretty strong
> HW limits depending on the type of bridge & architecture version...
>
> Do you plan to have that knowledge in qemu ? Or do you have some other
> mechanism to query it ? (I might be missing a piece of the puzzle here).
Yes. QEMU will have this knowledge as it has to implement
ibm,create-pe-dma-window and return this address to the guest. There will
be a container API to receive it from powernv code via funky ppc_md callback.
There are 2 steps:
1. query + create window
2. enable in-kernel KVM acceleration for it.
Everything will work without step2 and, frankly speaking, we do not need it
too much for DDW but it does not cost much.
By having bus_offset in ioctl which is only used for step2, I reduce
dependance from powernv.
> Also one thing I've been pondering ...
>
> We'll end up wasting a ton of memory with those TCE tables. If you have
> 3 PEs mapped into a guest, it will try to create 3 DDW's mapping the
> entire guest memory and so 3 TCE tables large enough for that ... and
> which will contain exactly the same entries !
This is in the plan too, do not rush :)
> We really want to look into extending PAPR to allow the creation of
> table "aliases" so that the guest can essentially create one table and
> associate it with multiple PEs. We might still decide to do multiple
> copies for NUMA reasons but no more than one per node for example... at
> least we can have the policy in qemu/kvm.
>
> Also, do you currently require allocating a single physically contiguous
> table or do you support TCE trees in your implementation ?
No trees yet. For 64GB window we need (64<<30)/(16<<20)*8 = 32K TCE table.
Do we really need trees?
--
Alexey
^ permalink raw reply
* Re: [PATCH 3/3] PPC: KVM: Add support for 64bit TCE windows
From: Benjamin Herrenschmidt @ 2014-06-05 7:38 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: kvm, Gleb Natapov, Alexander Graf, kvm-ppc, linux-kernel,
Paul Mackerras, Paolo Bonzini, linuxppc-dev
In-Reply-To: <1401953144-19186-4-git-send-email-aik@ozlabs.ru>
On Thu, 2014-06-05 at 17:25 +1000, Alexey Kardashevskiy wrote:
> +This creates a virtual TCE (translation control entry) table, which
> +is an IOMMU for PAPR-style virtual I/O. It is used to translate
> +logical addresses used in virtual I/O into guest physical addresses,
> +and provides a scatter/gather capability for PAPR virtual I/O.
> +
> +/* for KVM_CAP_SPAPR_TCE_64 */
> +struct kvm_create_spapr_tce_64 {
> + __u64 liobn;
> + __u64 window_size;
> + __u64 bus_offset;
> + __u32 page_shift;
> + __u32 flags;
> +};
> +
> +The liobn field gives the logical IO bus number for which to create a
> +TCE table. The window_size field specifies the size of the DMA window
> +which this TCE table will translate - the table will contain one 64
> +bit TCE entry for every IOMMU page. The bus_offset field tells where
> +this window is mapped on the IO bus.
Hrm, the bus_offset cannot be set arbitrarily, it has some pretty strong
HW limits depending on the type of bridge & architecture version...
Do you plan to have that knowledge in qemu ? Or do you have some other
mechanism to query it ? (I might be missing a piece of the puzzle here).
Also one thing I've been pondering ...
We'll end up wasting a ton of memory with those TCE tables. If you have
3 PEs mapped into a guest, it will try to create 3 DDW's mapping the
entire guest memory and so 3 TCE tables large enough for that ... and
which will contain exactly the same entries !
We really want to look into extending PAPR to allow the creation of
table "aliases" so that the guest can essentially create one table and
associate it with multiple PEs. We might still decide to do multiple
copies for NUMA reasons but no more than one per node for example... at
least we can have the policy in qemu/kvm.
Also, do you currently require allocating a single physically contiguous
table or do you support TCE trees in your implementation ?
Cheers,
Ben.
^ permalink raw reply
* [PATCH 0/3] Prepare for in-kernel VFIO DMA operations acceleration
From: Alexey Kardashevskiy @ 2014-06-05 7:25 UTC (permalink / raw)
To: linuxppc-dev
Cc: kvm, Alexey Kardashevskiy, Alexander Graf, kvm-ppc, linux-kernel,
Gleb Natapov, Paul Mackerras, Paolo Bonzini
This reserves 2 capability numbers.
This implements an extended version of KVM_CREATE_SPAPR_TCE_64 ioctl.
Please advise how to proceed with these patches as I suspect that
first two should go via Paolo's tree while the last one via Alex Graf's tree
(correct?).
Thanks!
Alexey Kardashevskiy (3):
PPC: KVM: Reserve KVM_CAP_SPAPR_TCE_VFIO capability number
PPC: KVM: Reserve KVM_CAP_SPAPR_TCE_64 capability number
PPC: KVM: Add support for 64bit TCE windows
Documentation/virtual/kvm/api.txt | 46 +++++++++++++++++++++++++++++++++++++
arch/powerpc/include/asm/kvm_host.h | 4 +++-
arch/powerpc/include/asm/kvm_ppc.h | 2 +-
arch/powerpc/include/uapi/asm/kvm.h | 9 ++++++++
arch/powerpc/kvm/book3s_64_vio.c | 4 +++-
arch/powerpc/kvm/powerpc.c | 24 ++++++++++++++++++-
include/uapi/linux/kvm.h | 4 ++++
7 files changed, 89 insertions(+), 4 deletions(-)
--
2.0.0
^ permalink raw reply
* [PATCH 3/3] PPC: KVM: Add support for 64bit TCE windows
From: Alexey Kardashevskiy @ 2014-06-05 7:25 UTC (permalink / raw)
To: linuxppc-dev
Cc: kvm, Alexey Kardashevskiy, Alexander Graf, kvm-ppc, linux-kernel,
Gleb Natapov, Paul Mackerras, Paolo Bonzini
In-Reply-To: <1401953144-19186-1-git-send-email-aik@ozlabs.ru>
The existing KVM_CREATE_SPAPR_TCE only supports 32bit windows which is not
enough for directly mapped windows as the guest can get more than 4GB.
This adds KVM_CREATE_SPAPR_TCE_64 ioctl and advertises it
via KVM_CAP_SPAPR_TCE_64 capability.
Since 64bit windows are to support Dynamic DMA windows (DDW), let's add
@bus_offset and @page_shift which are also required by DDW.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Documentation/virtual/kvm/api.txt | 46 +++++++++++++++++++++++++++++++++++++
arch/powerpc/include/asm/kvm_host.h | 4 +++-
arch/powerpc/include/asm/kvm_ppc.h | 2 +-
arch/powerpc/include/uapi/asm/kvm.h | 9 ++++++++
arch/powerpc/kvm/book3s_64_vio.c | 4 +++-
arch/powerpc/kvm/powerpc.c | 24 ++++++++++++++++++-
include/uapi/linux/kvm.h | 2 ++
7 files changed, 87 insertions(+), 4 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index b4f5365..8a2a2da 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2484,6 +2484,52 @@ calls by the guest for that service will be passed to userspace to be
handled.
+4.87 KVM_CREATE_SPAPR_TCE_64
+
+Capability: KVM_CAP_SPAPR_TCE_64
+Architectures: powerpc
+Type: vm ioctl
+Parameters: struct kvm_create_spapr_tce_64 (in)
+Returns: file descriptor for manipulating the created TCE table
+
+This is an extension for KVM_CAP_SPAPR_TCE which only supports 32bit
+windows.
+
+This creates a virtual TCE (translation control entry) table, which
+is an IOMMU for PAPR-style virtual I/O. It is used to translate
+logical addresses used in virtual I/O into guest physical addresses,
+and provides a scatter/gather capability for PAPR virtual I/O.
+
+/* for KVM_CAP_SPAPR_TCE_64 */
+struct kvm_create_spapr_tce_64 {
+ __u64 liobn;
+ __u64 window_size;
+ __u64 bus_offset;
+ __u32 page_shift;
+ __u32 flags;
+};
+
+The liobn field gives the logical IO bus number for which to create a
+TCE table. The window_size field specifies the size of the DMA window
+which this TCE table will translate - the table will contain one 64
+bit TCE entry for every IOMMU page. The bus_offset field tells where
+this window is mapped on the IO bus. The page_size field tells a size
+of the pages in this window, can be 4K, 64K, 16MB, etc. The flags field
+is not used at the moment but provides the room for extensions.
+
+When the guest issues an H_PUT_TCE/H_PUT_TCE_INDIRECT/H_STUFF_TCE hcall
+on a liobn for which a TCE table has been created using this ioctl(),
+the kernel will handle it in real or virtual mode, updating the TCE table.
+If liobn has not been registered with this ioctl, H_PUT_TCE/etc calls
+will cause a vm exit and must be handled by userspace.
+
+The return value is a file descriptor which can be passed to mmap(2)
+to map the created TCE table into userspace. This lets userspace read
+the entries written by kernel-handled H_PUT_TCE calls, and also lets
+userspace update the TCE table directly which is useful in some
+circumstances.
+
+
5. The kvm_run structure
------------------------
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index 1eaea2d..260a810 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -179,7 +179,9 @@ struct kvmppc_spapr_tce_table {
struct list_head list;
struct kvm *kvm;
u64 liobn;
- u32 window_size;
+ u64 window_size;
+ u64 bus_offset;
+ u32 page_shift;
struct page *pages[0];
};
diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
index 4096f16..b472fd3 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -126,7 +126,7 @@ extern void kvmppc_map_vrma(struct kvm_vcpu *vcpu,
extern int kvmppc_pseries_do_hcall(struct kvm_vcpu *vcpu);
extern long kvm_vm_ioctl_create_spapr_tce(struct kvm *kvm,
- struct kvm_create_spapr_tce *args);
+ struct kvm_create_spapr_tce_64 *args);
extern long kvmppc_h_put_tce(struct kvm_vcpu *vcpu, unsigned long liobn,
unsigned long ioba, unsigned long tce);
extern long kvmppc_h_get_tce(struct kvm_vcpu *vcpu, unsigned long liobn,
diff --git a/arch/powerpc/include/uapi/asm/kvm.h b/arch/powerpc/include/uapi/asm/kvm.h
index a6665be..0ada7b4 100644
--- a/arch/powerpc/include/uapi/asm/kvm.h
+++ b/arch/powerpc/include/uapi/asm/kvm.h
@@ -333,6 +333,15 @@ struct kvm_create_spapr_tce {
__u32 window_size;
};
+/* for KVM_CAP_SPAPR_TCE_64 */
+struct kvm_create_spapr_tce_64 {
+ __u64 liobn;
+ __u64 window_size;
+ __u64 bus_offset;
+ __u32 page_shift;
+ __u32 flags;
+};
+
/* for KVM_ALLOCATE_RMA */
struct kvm_allocate_rma {
__u64 rma_size;
diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index 54cf9bc..230fa5f 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/arch/powerpc/kvm/book3s_64_vio.c
@@ -98,7 +98,7 @@ static const struct file_operations kvm_spapr_tce_fops = {
};
long kvm_vm_ioctl_create_spapr_tce(struct kvm *kvm,
- struct kvm_create_spapr_tce *args)
+ struct kvm_create_spapr_tce_64 *args)
{
struct kvmppc_spapr_tce_table *stt = NULL;
long npages;
@@ -120,6 +120,8 @@ long kvm_vm_ioctl_create_spapr_tce(struct kvm *kvm,
stt->liobn = args->liobn;
stt->window_size = args->window_size;
+ stt->bus_offset = args->bus_offset;
+ stt->page_shift = args->page_shift;
stt->kvm = kvm;
for (i = 0; i < npages; i++) {
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 3cf541a..3b78b8d 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -33,6 +33,7 @@
#include <asm/tlbflush.h>
#include <asm/cputhreads.h>
#include <asm/irqflags.h>
+#include <asm/iommu.h>
#include "timing.h"
#include "irq.h"
#include "../mm/mmu_decl.h"
@@ -373,6 +374,7 @@ int kvm_dev_ioctl_check_extension(long ext)
#ifdef CONFIG_PPC_BOOK3S_64
case KVM_CAP_SPAPR_TCE:
+ case KVM_CAP_SPAPR_TCE_64:
case KVM_CAP_PPC_ALLOC_HTAB:
case KVM_CAP_PPC_RTAS:
#ifdef CONFIG_KVM_XICS
@@ -1077,13 +1079,33 @@ long kvm_arch_vm_ioctl(struct file *filp,
break;
}
#ifdef CONFIG_PPC_BOOK3S_64
+ case KVM_CREATE_SPAPR_TCE_64: {
+ struct kvm_create_spapr_tce_64 create_tce_64;
+
+ r = -EFAULT;
+ if (copy_from_user(&create_tce_64, argp, sizeof(create_tce_64)))
+ goto out;
+ if (create_tce_64.flags) {
+ r = -EINVAL;
+ goto out;
+ }
+ r = kvm_vm_ioctl_create_spapr_tce(kvm, &create_tce_64);
+ goto out;
+ }
case KVM_CREATE_SPAPR_TCE: {
struct kvm_create_spapr_tce create_tce;
+ struct kvm_create_spapr_tce_64 create_tce_64;
r = -EFAULT;
if (copy_from_user(&create_tce, argp, sizeof(create_tce)))
goto out;
- r = kvm_vm_ioctl_create_spapr_tce(kvm, &create_tce);
+
+ create_tce_64.liobn = create_tce.liobn;
+ create_tce_64.window_size = create_tce.window_size;
+ create_tce_64.bus_offset = 0;
+ create_tce_64.page_shift = IOMMU_PAGE_SHIFT_4K;
+ create_tce_64.flags = 0;
+ r = kvm_vm_ioctl_create_spapr_tce(kvm, &create_tce_64);
goto out;
}
case KVM_PPC_GET_SMMU_INFO: {
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index e6972bf..c435cbb 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1018,6 +1018,8 @@ struct kvm_s390_ucas_mapping {
/* Available with KVM_CAP_PPC_ALLOC_HTAB */
#define KVM_PPC_ALLOCATE_HTAB _IOWR(KVMIO, 0xa7, __u32)
#define KVM_CREATE_SPAPR_TCE _IOW(KVMIO, 0xa8, struct kvm_create_spapr_tce)
+#define KVM_CREATE_SPAPR_TCE_64 _IOW(KVMIO, 0xa8, \
+ struct kvm_create_spapr_tce_64)
/* Available with KVM_CAP_RMA */
#define KVM_ALLOCATE_RMA _IOR(KVMIO, 0xa9, struct kvm_allocate_rma)
/* Available with KVM_CAP_PPC_HTAB_FD */
--
2.0.0
^ permalink raw reply related
* [PATCH 1/3] PPC: KVM: Reserve KVM_CAP_SPAPR_TCE_VFIO capability number
From: Alexey Kardashevskiy @ 2014-06-05 7:25 UTC (permalink / raw)
To: linuxppc-dev
Cc: kvm, Alexey Kardashevskiy, Alexander Graf, kvm-ppc, linux-kernel,
Gleb Natapov, Paul Mackerras, Paolo Bonzini
In-Reply-To: <1401953144-19186-1-git-send-email-aik@ozlabs.ru>
This adds a capability number for in-kernel support for VFIO on
SPAPR platform.
The capability will tell the user space whether in-kernel handlers of
H_PUT_TCE can handle VFIO-targeted requests or not. If not, the user space
must not attempt allocating a TCE table in the host kernel via
the KVM_CREATE_SPAPR_TCE KVM ioctl because in that case TCE requests
will not be passed to the user space which is desired action in
the situation like that.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
include/uapi/linux/kvm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index a8f4ee5..944cd21 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -743,6 +743,7 @@ struct kvm_ppc_smmu_info {
#define KVM_CAP_IOAPIC_POLARITY_IGNORED 97
#define KVM_CAP_ENABLE_CAP_VM 98
#define KVM_CAP_S390_IRQCHIP 99
+#define KVM_CAP_SPAPR_TCE_VFIO 100
#ifdef KVM_CAP_IRQ_ROUTING
--
2.0.0
^ permalink raw reply related
* [PATCH 2/3] PPC: KVM: Reserve KVM_CAP_SPAPR_TCE_64 capability number
From: Alexey Kardashevskiy @ 2014-06-05 7:25 UTC (permalink / raw)
To: linuxppc-dev
Cc: kvm, Alexey Kardashevskiy, Alexander Graf, kvm-ppc, linux-kernel,
Gleb Natapov, Paul Mackerras, Paolo Bonzini
In-Reply-To: <1401953144-19186-1-git-send-email-aik@ozlabs.ru>
This adds a capability number for 64-bit TCE tables support.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
include/uapi/linux/kvm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 944cd21..e6972bf 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -744,6 +744,7 @@ struct kvm_ppc_smmu_info {
#define KVM_CAP_ENABLE_CAP_VM 98
#define KVM_CAP_S390_IRQCHIP 99
#define KVM_CAP_SPAPR_TCE_VFIO 100
+#define KVM_CAP_SPAPR_TCE_64 101
#ifdef KVM_CAP_IRQ_ROUTING
--
2.0.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox