* [PATCH 05/10] KVM: PPC: Read out syscall instruction on trap
From: Alexander Graf @ 2011-08-09 16:31 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, paulus, kvm
In-Reply-To: <1312907508-14599-1-git-send-email-agraf@suse.de>
We have a few traps where we cache the instruction that cause the trap
for analysis later on. Since we now need to be able to distinguish
between SC 0 and SC 1 system calls and the only way to find out which
is which is by looking at the instruction, we also read out the instruction
causing the system call.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/book3s_segment.S | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_segment.S b/arch/powerpc/kvm/book3s_segment.S
index aed32e5..678b6be 100644
--- a/arch/powerpc/kvm/book3s_segment.S
+++ b/arch/powerpc/kvm/book3s_segment.S
@@ -213,11 +213,16 @@ END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
beq ld_last_inst
cmpwi r12, BOOK3S_INTERRUPT_PROGRAM
beq ld_last_inst
+ cmpwi r12, BOOK3S_INTERRUPT_SYSCALL
+ beq ld_last_prev_inst
cmpwi r12, BOOK3S_INTERRUPT_ALIGNMENT
beq- ld_last_inst
b no_ld_last_inst
+ld_last_prev_inst:
+ addi r3, r3, -4
+
ld_last_inst:
/* Save off the guest instruction we're at */
--
1.6.0.2
^ permalink raw reply related
* [PATCH 01/10] KVM: PPC: move compute_tlbie_rb to book3s common header
From: Alexander Graf @ 2011-08-09 16:31 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, paulus, kvm
In-Reply-To: <1312907508-14599-1-git-send-email-agraf@suse.de>
We need the compute_tlbie_rb in _pr and _hv implementations for papr
soon, so let's move it over to a common header file that both
implementations can leverage.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/include/asm/kvm_book3s.h | 33 +++++++++++++++++++++++++++++++++
arch/powerpc/kvm/book3s_hv_rm_mmu.c | 33 ---------------------------------
2 files changed, 33 insertions(+), 33 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
index 98da010..37dd748 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -382,6 +382,39 @@ static inline bool kvmppc_critical_section(struct kvm_vcpu *vcpu)
}
#endif
+static inline unsigned long compute_tlbie_rb(unsigned long v, unsigned long r,
+ unsigned long pte_index)
+{
+ unsigned long rb, va_low;
+
+ rb = (v & ~0x7fUL) << 16; /* AVA field */
+ va_low = pte_index >> 3;
+ if (v & HPTE_V_SECONDARY)
+ va_low = ~va_low;
+ /* xor vsid from AVA */
+ if (!(v & HPTE_V_1TB_SEG))
+ va_low ^= v >> 12;
+ else
+ va_low ^= v >> 24;
+ va_low &= 0x7ff;
+ if (v & HPTE_V_LARGE) {
+ rb |= 1; /* L field */
+ if (cpu_has_feature(CPU_FTR_ARCH_206) &&
+ (r & 0xff000)) {
+ /* non-16MB large page, must be 64k */
+ /* (masks depend on page size) */
+ rb |= 0x1000; /* page encoding in LP field */
+ rb |= (va_low & 0x7f) << 16; /* 7b of VA in AVA/LP field */
+ rb |= (va_low & 0xfe); /* AVAL field (P7 doesn't seem to care) */
+ }
+ } else {
+ /* 4kB page */
+ rb |= (va_low & 0x7ff) << 12; /* remaining 11b of VA */
+ }
+ rb |= (v >> 54) & 0x300; /* B field */
+ return rb;
+}
+
/* Magic register values loaded into r3 and r4 before the 'sc' assembly
* instruction for the OSI hypercalls */
#define OSI_SC_MAGIC_R3 0x113724FA
diff --git a/arch/powerpc/kvm/book3s_hv_rm_mmu.c b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
index fcfe6b0..bacb0cf 100644
--- a/arch/powerpc/kvm/book3s_hv_rm_mmu.c
+++ b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
@@ -110,39 +110,6 @@ long kvmppc_h_enter(struct kvm_vcpu *vcpu, unsigned long flags,
return H_SUCCESS;
}
-static unsigned long compute_tlbie_rb(unsigned long v, unsigned long r,
- unsigned long pte_index)
-{
- unsigned long rb, va_low;
-
- rb = (v & ~0x7fUL) << 16; /* AVA field */
- va_low = pte_index >> 3;
- if (v & HPTE_V_SECONDARY)
- va_low = ~va_low;
- /* xor vsid from AVA */
- if (!(v & HPTE_V_1TB_SEG))
- va_low ^= v >> 12;
- else
- va_low ^= v >> 24;
- va_low &= 0x7ff;
- if (v & HPTE_V_LARGE) {
- rb |= 1; /* L field */
- if (cpu_has_feature(CPU_FTR_ARCH_206) &&
- (r & 0xff000)) {
- /* non-16MB large page, must be 64k */
- /* (masks depend on page size) */
- rb |= 0x1000; /* page encoding in LP field */
- rb |= (va_low & 0x7f) << 16; /* 7b of VA in AVA/LP field */
- rb |= (va_low & 0xfe); /* AVAL field (P7 doesn't seem to care) */
- }
- } else {
- /* 4kB page */
- rb |= (va_low & 0x7ff) << 12; /* remaining 11b of VA */
- }
- rb |= (v >> 54) & 0x300; /* B field */
- return rb;
-}
-
#define LOCK_TOKEN (*(u32 *)(&get_paca()->lock_token))
static inline int try_lock_tlbie(unsigned int *lock)
--
1.6.0.2
^ permalink raw reply related
* [PATCH 02/10] KVM: PPC: Add papr_enabled flag
From: Alexander Graf @ 2011-08-09 16:31 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, paulus, kvm
In-Reply-To: <1312907508-14599-1-git-send-email-agraf@suse.de>
When running a PAPR guest, some things change. The privilege level drops
from hypervisor to supervisor, SDR1 gets treated differently and we interpret
hypercalls. For bisectability sake, add the flag now, but only enable it when
all the support code is there.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/include/asm/kvm_host.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index cc22b28..e681302 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -389,6 +389,7 @@ struct kvm_vcpu_arch {
u8 dcr_is_write;
u8 osi_needed;
u8 osi_enabled;
+ u8 papr_enabled;
u8 hcall_needed;
u32 cpr0_cfgaddr; /* holds the last set cpr0_cfgaddr */
--
1.6.0.2
^ permalink raw reply related
* [PATCH 04/10] KVM: PPC: Interpret SDR1 as HVA in PAPR mode
From: Alexander Graf @ 2011-08-09 16:31 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, paulus, kvm
In-Reply-To: <1312907508-14599-1-git-send-email-agraf@suse.de>
When running a PAPR guest, the guest is not allowed to set SDR1 - instead
the HTAB information is held in internal hypervisor structures. But all of
our current code relies on SDR1 and walking the HTAB like on real hardware.
So in order to not be too intrusive, we simply set SDR1 to the HTAB we hold
in host memory. That way we can keep the HTAB in user space, but use it from
kernel space to map the guest.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/book3s_64_mmu.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_64_mmu.c b/arch/powerpc/kvm/book3s_64_mmu.c
index c6d3e19..b871721 100644
--- a/arch/powerpc/kvm/book3s_64_mmu.c
+++ b/arch/powerpc/kvm/book3s_64_mmu.c
@@ -128,7 +128,13 @@ static hva_t kvmppc_mmu_book3s_64_get_pteg(
dprintk("MMU: page=0x%x sdr1=0x%llx pteg=0x%llx vsid=0x%llx\n",
page, vcpu_book3s->sdr1, pteg, slbe->vsid);
- r = gfn_to_hva(vcpu_book3s->vcpu.kvm, pteg >> PAGE_SHIFT);
+ /* When running a PAPR guest, SDR1 contains a HVA address instead
+ of a GPA */
+ if (vcpu_book3s->vcpu.arch.papr_enabled)
+ r = pteg;
+ else
+ r = gfn_to_hva(vcpu_book3s->vcpu.kvm, pteg >> PAGE_SHIFT);
+
if (kvm_is_error_hva(r))
return r;
return r | (pteg & ~PAGE_MASK);
--
1.6.0.2
^ permalink raw reply related
* [PATCH 00/10] PAPR virtualization on PR KVM
From: Alexander Graf @ 2011-08-09 16:31 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, paulus, kvm
In KVM for Book3S PPC we currently have 2 implementations. There
is the PR based implementation which works on any POWER system
you pass in and the super fast HV implementation which requires
libre firmware (so almost nobody can use it).
Currently, the two target two different machine types, with PR KVM
being used for bare metal system virtualization, while the HV KVM
is used to virtualize PAPR.
In an effort to make things more cozy and transparent to the user,
this patch set implements PAPR capabilities to the PR KVM side, so
a user doesn't have to worry what the respective kernel module
supports. Any machine he's virtualizing "just works".
Alex
Alexander Graf (10):
KVM: PPC: move compute_tlbie_rb to book3s common header
KVM: PPC: Add papr_enabled flag
KVM: PPC: Check privilege level on SPRs
KVM: PPC: Interpret SDR1 as HVA in PAPR mode
KVM: PPC: Read out syscall instruction on trap
KVM: PPC: Add support for explicit HIOR setting
KVM: PPC: Add PAPR hypercall code for PR mode
KVM: PPC: Stub emulate CFAR and PURR SPRs
KVM: PPC: Support SC1 hypercalls for PAPR in PR mode
KVM: PPC: Enable the PAPR CAP for Book3S
arch/powerpc/include/asm/kvm.h | 8 ++
arch/powerpc/include/asm/kvm_book3s.h | 36 ++++++++
arch/powerpc/include/asm/kvm_host.h | 1 +
arch/powerpc/kvm/Makefile | 1 +
arch/powerpc/kvm/book3s_64_mmu.c | 8 ++-
arch/powerpc/kvm/book3s_emulate.c | 29 ++++++
arch/powerpc/kvm/book3s_hv_rm_mmu.c | 33 -------
arch/powerpc/kvm/book3s_pr.c | 36 +++++++-
arch/powerpc/kvm/book3s_pr_papr.c | 158 +++++++++++++++++++++++++++++++++
arch/powerpc/kvm/book3s_segment.S | 5 +
arch/powerpc/kvm/powerpc.c | 6 ++
include/linux/kvm.h | 2 +
12 files changed, 286 insertions(+), 37 deletions(-)
create mode 100644 arch/powerpc/kvm/book3s_pr_papr.c
^ permalink raw reply
* [PATCH 03/10] KVM: PPC: Check privilege level on SPRs
From: Alexander Graf @ 2011-08-09 16:31 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, paulus, kvm
In-Reply-To: <1312907508-14599-1-git-send-email-agraf@suse.de>
We have 3 privilege levels: problem state, supervisor state and hypervisor
state. Each of them can access different SPRs, so we need to check on every
SPR if it's accessible in the respective mode.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/book3s_emulate.c | 25 +++++++++++++++++++++++++
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_emulate.c b/arch/powerpc/kvm/book3s_emulate.c
index 4668465..bf0ddcd 100644
--- a/arch/powerpc/kvm/book3s_emulate.c
+++ b/arch/powerpc/kvm/book3s_emulate.c
@@ -63,6 +63,25 @@
* function pointers, so let's just disable the define. */
#undef mfsrin
+enum priv_level {
+ PRIV_PROBLEM = 0,
+ PRIV_SUPER = 1,
+ PRIV_HYPER = 2,
+};
+
+static bool spr_allowed(struct kvm_vcpu *vcpu, enum priv_level level)
+{
+ /* PAPR VMs only access supervisor SPRs */
+ if (vcpu->arch.papr_enabled && (level > PRIV_SUPER))
+ return false;
+
+ /* Limit user space to its own small SPR set */
+ if ((vcpu->arch.shared->msr & MSR_PR) && level > PRIV_PROBLEM)
+ return false;
+
+ return true;
+}
+
int kvmppc_core_emulate_op(struct kvm_run *run, struct kvm_vcpu *vcpu,
unsigned int inst, int *advance)
{
@@ -296,6 +315,8 @@ int kvmppc_core_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, int rs)
switch (sprn) {
case SPRN_SDR1:
+ if (!spr_allowed(vcpu, PRIV_HYPER))
+ goto unprivileged;
to_book3s(vcpu)->sdr1 = spr_val;
break;
case SPRN_DSISR:
@@ -390,6 +411,7 @@ int kvmppc_core_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, int rs)
case SPRN_PMC4_GEKKO:
case SPRN_WPAR_GEKKO:
break;
+unprivileged:
default:
printk(KERN_INFO "KVM: invalid SPR write: %d\n", sprn);
#ifndef DEBUG_SPR
@@ -421,6 +443,8 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int sprn, int rt)
break;
}
case SPRN_SDR1:
+ if (!spr_allowed(vcpu, PRIV_HYPER))
+ goto unprivileged;
kvmppc_set_gpr(vcpu, rt, to_book3s(vcpu)->sdr1);
break;
case SPRN_DSISR:
@@ -476,6 +500,7 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int sprn, int rt)
kvmppc_set_gpr(vcpu, rt, 0);
break;
default:
+unprivileged:
printk(KERN_INFO "KVM: invalid SPR read: %d\n", sprn);
#ifndef DEBUG_SPR
emulated = EMULATE_FAIL;
--
1.6.0.2
^ permalink raw reply related
* [PATCH 08/10] KVM: PPC: Stub emulate CFAR and PURR SPRs
From: Alexander Graf @ 2011-08-09 16:31 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, paulus, kvm
In-Reply-To: <1312907508-14599-1-git-send-email-agraf@suse.de>
Recent Linux versions use the CFAR and PURR SPRs, but don't really care about
their contents (yet). So for now, we can simply return 0 when the guest wants
to read them.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/book3s_emulate.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_emulate.c b/arch/powerpc/kvm/book3s_emulate.c
index bf0ddcd..0c9dc62 100644
--- a/arch/powerpc/kvm/book3s_emulate.c
+++ b/arch/powerpc/kvm/book3s_emulate.c
@@ -473,6 +473,10 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int sprn, int rt)
case SPRN_HID5:
kvmppc_set_gpr(vcpu, rt, to_book3s(vcpu)->hid[5]);
break;
+ case SPRN_CFAR:
+ case SPRN_PURR:
+ kvmppc_set_gpr(vcpu, rt, 0);
+ break;
case SPRN_GQR0:
case SPRN_GQR1:
case SPRN_GQR2:
--
1.6.0.2
^ permalink raw reply related
* [PATCH 09/10] KVM: PPC: Support SC1 hypercalls for PAPR in PR mode
From: Alexander Graf @ 2011-08-09 16:31 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, paulus, kvm
In-Reply-To: <1312907508-14599-1-git-send-email-agraf@suse.de>
PAPR defines hypercalls as SC1 instructions. Using these, the guest modifies
page tables and does other privileged operations that it wouldn't be allowed
to do in supervisor mode.
This patch adds support for PR KVM to trap these instructions and route them
through the same PAPR hypercall interface that we already use for HV style
KVM.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/book3s_pr.c | 22 +++++++++++++++++++++-
1 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index 78dcf65..48558f6 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -648,7 +648,27 @@ program_interrupt:
break;
}
case BOOK3S_INTERRUPT_SYSCALL:
- if (vcpu->arch.osi_enabled &&
+ if (vcpu->arch.papr_enabled &&
+ (kvmppc_get_last_inst(vcpu) == 0x44000022) &&
+ !(vcpu->arch.shared->msr & MSR_PR)) {
+ /* SC 1 papr hypercalls */
+ ulong cmd = kvmppc_get_gpr(vcpu, 3);
+ int i;
+
+ if (kvmppc_h_pr(vcpu, cmd) == EMULATE_DONE) {
+ r = RESUME_GUEST;
+ break;
+ }
+
+ run->papr_hcall.nr = cmd;
+ for (i = 0; i < 9; ++i) {
+ ulong gpr = kvmppc_get_gpr(vcpu, 4 + i);
+ run->papr_hcall.args[i] = gpr;
+ }
+ run->exit_reason = KVM_EXIT_PAPR_HCALL;
+ vcpu->arch.hcall_needed = 1;
+ r = RESUME_HOST;
+ } else if (vcpu->arch.osi_enabled &&
(((u32)kvmppc_get_gpr(vcpu, 3)) == OSI_SC_MAGIC_R3) &&
(((u32)kvmppc_get_gpr(vcpu, 4)) == OSI_SC_MAGIC_R4)) {
/* MOL hypercalls */
--
1.6.0.2
^ permalink raw reply related
* [PATCH 10/10] KVM: PPC: Enable the PAPR CAP for Book3S
From: Alexander Graf @ 2011-08-09 16:31 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, paulus, kvm
In-Reply-To: <1312907508-14599-1-git-send-email-agraf@suse.de>
Now that Book3S PV mode can also run PAPR guests, we can add a PAPR cap and
enable it for all Book3S targets. Enabling that CAP switches KVM into PAPR
mode.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/powerpc.c | 5 +++++
include/linux/kvm.h | 1 +
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 17a5c83..13bc798 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -189,6 +189,7 @@ int kvm_dev_ioctl_check_extension(long ext)
#else
case KVM_CAP_PPC_SEGSTATE:
case KVM_CAP_PPC_HIOR:
+ case KVM_CAP_PPC_PAPR:
#endif
case KVM_CAP_PPC_UNSET_IRQ:
case KVM_CAP_PPC_IRQ_LEVEL:
@@ -572,6 +573,10 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu,
r = 0;
vcpu->arch.osi_enabled = true;
break;
+ case KVM_CAP_PPC_PAPR:
+ r = 0;
+ vcpu->arch.papr_enabled = true;
+ break;
default:
r = -EINVAL;
break;
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 4d33f78..2d7161c 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -555,6 +555,7 @@ struct kvm_ppc_pvinfo {
#define KVM_CAP_PPC_RMA 65
#define KVM_CAP_MAX_VCPUS 66 /* returns max vcpus per vm */
#define KVM_CAP_PPC_HIOR 67
+#define KVM_CAP_PPC_PAPR 68
#ifdef KVM_CAP_IRQ_ROUTING
--
1.6.0.2
^ permalink raw reply related
* [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode
From: Alexander Graf @ 2011-08-09 16:31 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, paulus, kvm
In-Reply-To: <1312907508-14599-1-git-send-email-agraf@suse.de>
When running a PAPR guest, we need to handle a few hypercalls in kernel space,
most prominently the page table invalidation (to sync the shadows).
So this patch adds handling for a few PAPR hypercalls to PR mode KVM. I tried
to share the code with HV mode, but it ended up being a lot easier this way
around, as the two differ too much in those details.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/include/asm/kvm_book3s.h | 1 +
arch/powerpc/kvm/Makefile | 1 +
arch/powerpc/kvm/book3s_pr_papr.c | 158 +++++++++++++++++++++++++++++++++
3 files changed, 160 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/kvm/book3s_pr_papr.c
diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
index 472437b..91d41fa 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -150,6 +150,7 @@ extern void kvmppc_load_up_altivec(void);
extern void kvmppc_load_up_vsx(void);
extern u32 kvmppc_alignment_dsisr(struct kvm_vcpu *vcpu, unsigned int inst);
extern ulong kvmppc_alignment_dar(struct kvm_vcpu *vcpu, unsigned int inst);
+extern int kvmppc_h_pr(struct kvm_vcpu *vcpu, unsigned long cmd);
static inline struct kvmppc_vcpu_book3s *to_book3s(struct kvm_vcpu *vcpu)
{
diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
index 08428e2..4c66d51 100644
--- a/arch/powerpc/kvm/Makefile
+++ b/arch/powerpc/kvm/Makefile
@@ -43,6 +43,7 @@ kvm-book3s_64-objs-$(CONFIG_KVM_BOOK3S_64_PR) := \
fpu.o \
book3s_paired_singles.o \
book3s_pr.o \
+ book3s_pr_papr.o \
book3s_emulate.o \
book3s_interrupts.o \
book3s_mmu_hpte.o \
diff --git a/arch/powerpc/kvm/book3s_pr_papr.c b/arch/powerpc/kvm/book3s_pr_papr.c
new file mode 100644
index 0000000..b8ec55f
--- /dev/null
+++ b/arch/powerpc/kvm/book3s_pr_papr.c
@@ -0,0 +1,158 @@
+/*
+ * 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.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ */
+
+#include <asm/uaccess.h>
+#include <asm/kvm_ppc.h>
+#include <asm/kvm_book3s.h>
+
+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);
+ unsigned long pteg[2 * 8];
+ unsigned long pteg_addr, i, *hpte;
+
+ pte_index &= ~7UL;
+ pteg_addr = get_pteg_addr(vcpu, pte_index);
+
+ copy_from_user(pteg, (void __user *)pteg_addr, sizeof(pteg));
+ hpte = pteg;
+
+ if (likely((flags & H_EXACT) == 0)) {
+ pte_index &= ~7UL;
+ for (i = 0; ; ++i) {
+ if (i == 8)
+ return H_PTEG_FULL;
+ if ((*hpte & HPTE_V_VALID) == 0)
+ break;
+ hpte += 2;
+ }
+ } else {
+ i = kvmppc_get_gpr(vcpu, 5) & 7UL;
+ hpte += i * 2;
+ }
+
+ hpte[0] = kvmppc_get_gpr(vcpu, 6);
+ hpte[1] = kvmppc_get_gpr(vcpu, 7);
+ copy_to_user((void __user *)pteg_addr, pteg, sizeof(pteg));
+ kvmppc_set_gpr(vcpu, 3, H_SUCCESS);
+ kvmppc_set_gpr(vcpu, 4, pte_index | i);
+
+ 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];
+
+ pteg = get_pteg_addr(vcpu, pte_index);
+ copy_from_user(pte, (void __user *)pteg, sizeof(pte));
+
+ if ((pte[0] & HPTE_V_VALID) == 0 ||
+ ((flags & H_AVPN) && (pte[0] & ~0x7fUL) != avpn) ||
+ ((flags & H_ANDCOND) && (pte[0] & avpn) != 0)) {
+ kvmppc_set_gpr(vcpu, 3, H_NOT_FOUND);
+ return EMULATE_DONE;
+ }
+
+ copy_to_user((void __user *)pteg, &v, sizeof(v));
+
+ rb = compute_tlbie_rb(pte[0], pte[1], pte_index);
+ vcpu->arch.mmu.tlbie(vcpu, rb, rb & 1 ? true : false);
+
+ kvmppc_set_gpr(vcpu, 3, H_SUCCESS);
+ kvmppc_set_gpr(vcpu, 4, pte[0]);
+ kvmppc_set_gpr(vcpu, 5, pte[1]);
+
+ return EMULATE_DONE;
+}
+
+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];
+
+ pteg = get_pteg_addr(vcpu, pte_index);
+ copy_from_user(pte, (void __user *)pteg, sizeof(pte));
+
+ if ((pte[0] & HPTE_V_VALID) == 0 ||
+ ((flags & H_AVPN) && (pte[0] & ~0x7fUL) != avpn)) {
+ kvmppc_set_gpr(vcpu, 3, H_NOT_FOUND);
+ return EMULATE_DONE;
+ }
+
+ 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);
+ copy_to_user((void __user *)pteg, pte, sizeof(pte));
+
+ kvmppc_set_gpr(vcpu, 3, H_SUCCESS);
+
+ return EMULATE_DONE;
+}
+
+int kvmppc_h_pr(struct kvm_vcpu *vcpu, unsigned long cmd)
+{
+ 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:
+ /* We just flush all PTEs, so user space can
+ handle the HPT modifications */
+ kvmppc_mmu_pte_flush(vcpu, 0, 0);
+ break;
+ case H_CEDE:
+ kvm_vcpu_block(vcpu);
+ vcpu->stat.halt_wakeup++;
+ return EMULATE_DONE;
+ }
+
+ return EMULATE_FAIL;
+}
--
1.6.0.2
^ permalink raw reply related
* [PATCH 06/10] KVM: PPC: Add support for explicit HIOR setting
From: Alexander Graf @ 2011-08-09 16:31 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, paulus, kvm
In-Reply-To: <1312907508-14599-1-git-send-email-agraf@suse.de>
Until now, we always set HIOR based on the PVR, but this is just wrong.
Instead, we should be setting HIOR explicitly, so user space can decide
what the initial HIOR value is - just like on real hardware.
We keep the old PVR based way around for backwards compatibility, but
once user space uses the SREGS based method, we drop the PVR logic.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/include/asm/kvm.h | 8 ++++++++
arch/powerpc/include/asm/kvm_book3s.h | 2 ++
arch/powerpc/kvm/book3s_pr.c | 14 ++++++++++++--
arch/powerpc/kvm/powerpc.c | 1 +
include/linux/kvm.h | 1 +
5 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index a4f6c85..a6a253e 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -149,6 +149,12 @@ struct kvm_regs {
#define KVM_SREGS_E_UPDATE_DBSR (1 << 3)
/*
+ * Book3S special bits to indicate contents in the struct by maintaining
+ * backwards compatibility with older structs. If adding a new field,
+ * please make sure to add a flag for that new field */
+#define KVM_SREGS_S_HIOR (1 << 0)
+
+/*
* In KVM_SET_SREGS, reserved/pad fields must be left untouched from a
* previous KVM_GET_REGS.
*
@@ -173,6 +179,8 @@ struct kvm_sregs {
__u64 ibat[8];
__u64 dbat[8];
} ppc32;
+ __u64 flags; /* KVM_SREGS_S_ */
+ __u64 hior;
} s;
struct {
union {
diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
index 37dd748..472437b 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -90,6 +90,8 @@ struct kvmppc_vcpu_book3s {
#endif
int context_id[SID_CONTEXTS];
+ bool hior_sregs; /* HIOR is set by SREGS, not PVR */
+
struct hlist_head hpte_hash_pte[HPTEG_HASH_NUM_PTE];
struct hlist_head hpte_hash_pte_long[HPTEG_HASH_NUM_PTE_LONG];
struct hlist_head hpte_hash_vpte[HPTEG_HASH_NUM_VPTE];
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index 0c0d3f2..78dcf65 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -150,13 +150,15 @@ void kvmppc_set_pvr(struct kvm_vcpu *vcpu, u32 pvr)
#ifdef CONFIG_PPC_BOOK3S_64
if ((pvr >= 0x330000) && (pvr < 0x70330000)) {
kvmppc_mmu_book3s_64_init(vcpu);
- to_book3s(vcpu)->hior = 0xfff00000;
+ if (!to_book3s(vcpu)->hior_sregs)
+ to_book3s(vcpu)->hior = 0xfff00000;
to_book3s(vcpu)->msr_mask = 0xffffffffffffffffULL;
} else
#endif
{
kvmppc_mmu_book3s_32_init(vcpu);
- to_book3s(vcpu)->hior = 0;
+ if (!to_book3s(vcpu)->hior_sregs)
+ to_book3s(vcpu)->hior = 0;
to_book3s(vcpu)->msr_mask = 0xffffffffULL;
}
@@ -770,6 +772,9 @@ int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu,
}
}
+ if (sregs->u.s.flags & KVM_SREGS_S_HIOR)
+ sregs->u.s.hior = to_book3s(vcpu)->hior;
+
return 0;
}
@@ -806,6 +811,11 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
/* Flush the MMU after messing with the segments */
kvmppc_mmu_pte_flush(vcpu, 0, 0);
+ if (sregs->u.s.flags & KVM_SREGS_S_HIOR) {
+ to_book3s(vcpu)->hior_sregs = true;
+ to_book3s(vcpu)->hior = sregs->u.s.hior;
+ }
+
return 0;
}
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index a107c9b..17a5c83 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -188,6 +188,7 @@ int kvm_dev_ioctl_check_extension(long ext)
case KVM_CAP_PPC_BOOKE_SREGS:
#else
case KVM_CAP_PPC_SEGSTATE:
+ case KVM_CAP_PPC_HIOR:
#endif
case KVM_CAP_PPC_UNSET_IRQ:
case KVM_CAP_PPC_IRQ_LEVEL:
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 55f5afb..4d33f78 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -554,6 +554,7 @@ struct kvm_ppc_pvinfo {
#define KVM_CAP_PPC_SMT 64
#define KVM_CAP_PPC_RMA 65
#define KVM_CAP_MAX_VCPUS 66 /* returns max vcpus per vm */
+#define KVM_CAP_PPC_HIOR 67
#ifdef KVM_CAP_IRQ_ROUTING
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode
From: Avi Kivity @ 2011-08-09 16:40 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, paulus, kvm, kvm-ppc
In-Reply-To: <1312907508-14599-8-git-send-email-agraf@suse.de>
On 08/09/2011 07:31 PM, Alexander Graf wrote:
> When running a PAPR guest, we need to handle a few hypercalls in kernel space,
> most prominently the page table invalidation (to sync the shadows).
>
> So this patch adds handling for a few PAPR hypercalls to PR mode KVM. I tried
> to share the code with HV mode, but it ended up being a lot easier this way
> around, as the two differ too much in those details.
>
>
> +++ b/arch/powerpc/kvm/book3s_pr_papr.c
> @@ -0,0 +1,158 @@
> +/*
> + * 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.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License, version 2, as
> + * published by the Free Software Foundation.
> + */
Copyright freescale, authors Paul and yourself?
> +
> +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;
> +}
Evil space crept in.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH 00/10] PAPR virtualization on PR KVM
From: Avi Kivity @ 2011-08-09 16:42 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, paulus, kvm, kvm-ppc
In-Reply-To: <1312907508-14599-1-git-send-email-agraf@suse.de>
On 08/09/2011 07:31 PM, Alexander Graf wrote:
> In KVM for Book3S PPC we currently have 2 implementations. There
> is the PR based implementation which works on any POWER system
> you pass in and the super fast HV implementation which requires
> libre firmware (so almost nobody can use it).
Did you mean, non-libre?
>
> Currently, the two target two different machine types, with PR KVM
> being used for bare metal system virtualization, while the HV KVM
> is used to virtualize PAPR.
>
> In an effort to make things more cozy and transparent to the user,
> this patch set implements PAPR capabilities to the PR KVM side, so
> a user doesn't have to worry what the respective kernel module
> supports. Any machine he's virtualizing "just works".
>
Nice. I went though it and nothing shouted "I'm wrong, kill me please",
though I don't claim to understand more than 5% of it.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode
From: Alexander Graf @ 2011-08-09 16:46 UTC (permalink / raw)
To: Avi Kivity; +Cc: linuxppc-dev, paulus, kvm, kvm-ppc
In-Reply-To: <4E416315.2080800@redhat.com>
On 08/09/2011 06:40 PM, Avi Kivity wrote:
> On 08/09/2011 07:31 PM, Alexander Graf wrote:
>> When running a PAPR guest, we need to handle a few hypercalls in
>> kernel space,
>> most prominently the page table invalidation (to sync the shadows).
>>
>> So this patch adds handling for a few PAPR hypercalls to PR mode KVM.
>> I tried
>> to share the code with HV mode, but it ended up being a lot easier
>> this way
>> around, as the two differ too much in those details.
>>
>>
>> +++ b/arch/powerpc/kvm/book3s_pr_papr.c
>> @@ -0,0 +1,158 @@
>> +/*
>> + * 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.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License, version 2, as
>> + * published by the Free Software Foundation.
>> + */
>
> Copyright freescale, authors Paul and yourself?
Yeah, I'm reasonably clueless when it comes to legal stuff. This code is
inspired by Paul's, but is mostly rewritten since it's so tied into the
virtual MMU. What would the copyright be in that case?
>
>> +
>> +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;
>> +}
>
> Evil space crept in.
Oh noez! Fixed it :)
Alex
^ permalink raw reply
* Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode
From: Avi Kivity @ 2011-08-09 16:49 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, paulus, kvm, kvm-ppc
In-Reply-To: <4E41646C.1070500@suse.de>
On 08/09/2011 07:46 PM, Alexander Graf wrote:
> On 08/09/2011 06:40 PM, Avi Kivity wrote:
>> On 08/09/2011 07:31 PM, Alexander Graf wrote:
>>> When running a PAPR guest, we need to handle a few hypercalls in
>>> kernel space,
>>> most prominently the page table invalidation (to sync the shadows).
>>>
>>> So this patch adds handling for a few PAPR hypercalls to PR mode
>>> KVM. I tried
>>> to share the code with HV mode, but it ended up being a lot easier
>>> this way
>>> around, as the two differ too much in those details.
>>>
>>>
>>> +++ b/arch/powerpc/kvm/book3s_pr_papr.c
>>> @@ -0,0 +1,158 @@
>>> +/*
>>> + * 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.
>>> + *
>>> + * This program is free software; you can redistribute it and/or
>>> modify
>>> + * it under the terms of the GNU General Public License, version 2, as
>>> + * published by the Free Software Foundation.
>>> + */
>>
>> Copyright freescale, authors Paul and yourself?
>
> Yeah, I'm reasonably clueless when it comes to legal stuff. This code
> is inspired by Paul's, but is mostly rewritten since it's so tied into
> the virtual MMU. What would the copyright be in that case?
Just put your own (or your employers'). If someone contributed to the
code they can add their copyrights (or ask you do do it before inclusion).
It would be good to get Paul's or Ben's so that the unimportant
characters between the whitespace get some braintime.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH 00/10] PAPR virtualization on PR KVM
From: Alexander Graf @ 2011-08-09 16:49 UTC (permalink / raw)
To: Avi Kivity; +Cc: linuxppc-dev, paulus, kvm, kvm-ppc
In-Reply-To: <4E41638A.2010707@redhat.com>
On 08/09/2011 06:42 PM, Avi Kivity wrote:
> On 08/09/2011 07:31 PM, Alexander Graf wrote:
>> In KVM for Book3S PPC we currently have 2 implementations. There
>> is the PR based implementation which works on any POWER system
>> you pass in and the super fast HV implementation which requires
>> libre firmware (so almost nobody can use it).
>
> Did you mean, non-libre?
No, I did mean libre :). Usually firmware on IBM POWER systems already
uses the hypervisor mode for itself, so we can't leverage it. The only
system that is publicly available and can run HV KVM is the YDL
PowerStation which is running SLOF, an open source firmware.
>
>>
>> Currently, the two target two different machine types, with PR KVM
>> being used for bare metal system virtualization, while the HV KVM
>> is used to virtualize PAPR.
>>
>> In an effort to make things more cozy and transparent to the user,
>> this patch set implements PAPR capabilities to the PR KVM side, so
>> a user doesn't have to worry what the respective kernel module
>> supports. Any machine he's virtualizing "just works".
>>
>
> Nice. I went though it and nothing shouted "I'm wrong, kill me
> please", though I don't claim to understand more than 5% of it.
Heh :). The thing giving me the most headaches here is the ENABLE_CAP
part on PAPR. I'd love to have a more flexible framework there that can
configure kvm into the right mode of operation completely, so we get the
chance of passing back "Sorry, that mode doesn't work for me" at the end
of the day.
But I guess we can just do that with the cap enablings too. It's just
slightly more icky.
Alex
^ permalink raw reply
* Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode
From: Alexander Graf @ 2011-08-09 16:51 UTC (permalink / raw)
To: Avi Kivity; +Cc: linuxppc-dev, paulus, kvm, kvm-ppc
In-Reply-To: <4E41651C.7050709@redhat.com>
On 08/09/2011 06:49 PM, Avi Kivity wrote:
> On 08/09/2011 07:46 PM, Alexander Graf wrote:
>> On 08/09/2011 06:40 PM, Avi Kivity wrote:
>>> On 08/09/2011 07:31 PM, Alexander Graf wrote:
>>>> When running a PAPR guest, we need to handle a few hypercalls in
>>>> kernel space,
>>>> most prominently the page table invalidation (to sync the shadows).
>>>>
>>>> So this patch adds handling for a few PAPR hypercalls to PR mode
>>>> KVM. I tried
>>>> to share the code with HV mode, but it ended up being a lot easier
>>>> this way
>>>> around, as the two differ too much in those details.
>>>>
>>>>
>>>> +++ b/arch/powerpc/kvm/book3s_pr_papr.c
>>>> @@ -0,0 +1,158 @@
>>>> +/*
>>>> + * 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.
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or
>>>> modify
>>>> + * it under the terms of the GNU General Public License, version
>>>> 2, as
>>>> + * published by the Free Software Foundation.
>>>> + */
>>>
>>> Copyright freescale, authors Paul and yourself?
>>
>> Yeah, I'm reasonably clueless when it comes to legal stuff. This code
>> is inspired by Paul's, but is mostly rewritten since it's so tied
>> into the virtual MMU. What would the copyright be in that case?
>
> Just put your own (or your employers'). If someone contributed to the
> code they can add their copyrights (or ask you do do it before
> inclusion).
>
> It would be good to get Paul's or Ben's so that the unimportant
> characters between the whitespace get some braintime.
So you mean I just put both copyright statements there? That's a nice idea!
Alex
^ permalink raw reply
* Re: [PATCH 07/10] KVM: PPC: Add PAPR hypercall code for PR mode
From: Avi Kivity @ 2011-08-09 17:01 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, paulus, kvm, kvm-ppc
In-Reply-To: <4E4165AB.8030704@suse.de>
On 08/09/2011 07:51 PM, Alexander Graf wrote:
>> Just put your own (or your employers'). If someone contributed to
>> the code they can add their copyrights (or ask you do do it before
>> inclusion).
>>
>> It would be good to get Paul's or Ben's so that the unimportant
>> characters between the whitespace get some braintime.
>
>
> So you mean I just put both copyright statements there? That's a nice
> idea!
>
>
I meant Paul's or Ben's *review*.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: FW: Ethernet driver WR linux
From: Scott Wood @ 2011-08-09 17:56 UTC (permalink / raw)
To: smitha.vanga; +Cc: linuxppc-dev
In-Reply-To: <07ACDFB8ECA8EF47863A613BC01BBB220344EACF@HYD-MKD-MBX02.wipro.com>
On 08/09/2011 12:46 AM, smitha.vanga@wipro.com wrote:
> Thank Scott. I am working on a legacy project Which is using 2.6.21
> linux kernel so the device tree is based on that.
Your original e-mail said you were using 2.6.38 ("I have bringup WR
linux 2.6.38 on a custom mpc8247 board").
> Can you let me why the probe error of the driver happens.
No. There were a lot of fixes and improvements that went into this code
since then, including removing hardcoded assumptions about the hardware
that are described in the device tree with the current binding. If you
don't want the fixes that come with a newer version, you're on your own
repeating that work.
-Scott
^ permalink raw reply
* Re: [PATCH 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
From: Scott Wood @ 2011-08-09 18:17 UTC (permalink / raw)
To: Robin Holt; +Cc: netdev, U Bhaskar-B22300, socketcan-core, PPC list
In-Reply-To: <1312901031-29887-6-git-send-email-holt@sgi.com>
On 08/09/2011 09:43 AM, Robin Holt wrote:
> In working with the socketcan developers, we have come to the conclusion
> the fsl-flexcan device tree bindings need to be cleaned up.
> The driver does not depend upon any properties other than the required properties
> so we are removing the file.
That is not the criterion for whether something should be expresed in
the device tree. It's a description of the hardware, not a Linux driver
configuration file. If there are integration parameters that can not be
inferred from "this is FSL flexcan v1.0", they should be expressed in
the node.
Removing the binding altogether seems extreme as well -- we should have
bindings for all devices, even if there are no special properties.
> Additionally, the p1010*dts files are not
> following the standard for node naming in that they have a trailing -v1.0.
What "standard for node naming"? There's nothing wrong with putting a
block version number in the compatible string, and it looks like the
p1010 dts files were following the binding document in this regard. It
is common practice when the block version is publicly documented but
there's no register it can be read from at runtime.
-Scott
^ permalink raw reply
* Re: [PATCH 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
From: Robin Holt @ 2011-08-09 18:45 UTC (permalink / raw)
To: Scott Wood; +Cc: netdev, U Bhaskar-B22300, socketcan-core, Robin Holt, PPC list
In-Reply-To: <4E4179CB.6030101@freescale.com>
On Tue, Aug 09, 2011 at 01:17:47PM -0500, Scott Wood wrote:
> On 08/09/2011 09:43 AM, Robin Holt wrote:
> > In working with the socketcan developers, we have come to the conclusion
> > the fsl-flexcan device tree bindings need to be cleaned up.
> > The driver does not depend upon any properties other than the required properties
> > so we are removing the file.
>
> That is not the criterion for whether something should be expresed in
> the device tree. It's a description of the hardware, not a Linux driver
> configuration file. If there are integration parameters that can not be
> inferred from "this is FSL flexcan v1.0", they should be expressed in
> the node.
There are no properties other than the required properties. The others
were wrongly introduced and are not needed by the driver. When we
removed the other properties and the wrong documentation of the mscan
oscillator source in the fsl-flexcan.txt file, we were left with an
Example: section and a one-line statement "The only properties supported
are the required properties." That seemed like the fsl-flexcan.txt
file was then pointless.
> Removing the binding altogether seems extreme as well -- we should have
> bindings for all devices, even if there are no special properties.
Ok. I can do that too. Who is the definitive source for that answer?
I assume we are talking about the fsl-flexcan.txt file when we say
binding. Is that correct?
> > Additionally, the p1010*dts files are not
> > following the standard for node naming in that they have a trailing -v1.0.
>
> What "standard for node naming"? There's nothing wrong with putting a
For the answer to that, you will need to ask Wolfgang Grandegger. I was
working from his feedback. Looking at the plethora of other node names,
the vast majority do not have any -v#.#, and the ones that do also tend
to have multiple versions. Based upon that, I suspect he is correct,
but I do not know where the documentation is or if it even exists.
> block version number in the compatible string, and it looks like the
> p1010 dts files were following the binding document in this regard. It
> is common practice when the block version is publicly documented but
> there's no register it can be read from at runtime.
Thanks,
Robin
^ permalink raw reply
* Re: [PATCH 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
From: Scott Wood @ 2011-08-09 19:13 UTC (permalink / raw)
To: Robin Holt
Cc: netdev, devicetree-discuss@lists.ozlabs.org, U Bhaskar-B22300,
socketcan-core, PPC list
In-Reply-To: <20110809184524.GB4926@sgi.com>
On 08/09/2011 01:45 PM, Robin Holt wrote:
> On Tue, Aug 09, 2011 at 01:17:47PM -0500, Scott Wood wrote:
>> On 08/09/2011 09:43 AM, Robin Holt wrote:
>>> In working with the socketcan developers, we have come to the conclusion
>>> the fsl-flexcan device tree bindings need to be cleaned up.
>>> The driver does not depend upon any properties other than the required properties
>>> so we are removing the file.
>>
>> That is not the criterion for whether something should be expresed in
>> the device tree. It's a description of the hardware, not a Linux driver
>> configuration file. If there are integration parameters that can not be
>> inferred from "this is FSL flexcan v1.0", they should be expressed in
>> the node.
>
> There are no properties other than the required properties. The others
> were wrongly introduced and are not needed by the driver.
Not needed by this driver, or will never be needed by any reasonable
driver (or is not a good description of the hardware)?
The device tree is not an internal Linux implementation detail. It is
shared by other OSes, firmwares, hypervisors, etc. Bindings should be
created with care, and kept stable unless there's a good reason to break
compatibility.
devicetree-discuss@lists.ozlabs.org should be CCed on device tree
discussions.
> When we
> removed the other properties and the wrong documentation of the mscan
> oscillator source in the fsl-flexcan.txt file, we were left with an
> Example: section and a one-line statement "The only properties supported
> are the required properties." That seemed like the fsl-flexcan.txt
> file was then pointless.
There is the compatible string, and you could mention that there is a
single reg resource and a single interrupt.
>> Removing the binding altogether seems extreme as well -- we should have
>> bindings for all devices, even if there are no special properties.
>
> Ok. I can do that too. Who is the definitive source for that answer?
For policy questions on device tree bindings? Grant Likely is the
maintainer for device tree stuff.
A lot of the simpler bindings have been left undocumented so far, IMHO
it should be a goal to document them all. There are some existing ones
that are documented despite not having special properties, e.g.
Documentation/devicetree/bindings/serio/altera_ps2.txt,
Documentation/devicetree/bindings/arm/sirf.txt,
Documentation/devicetree/bindings/powerpc/nintendo/wii.txt, etc.
> I assume we are talking about the fsl-flexcan.txt file when we say
> binding. Is that correct?
Yes, although devicetree.org is another possibility.
>>> Additionally, the p1010*dts files are not
>>> following the standard for node naming in that they have a trailing -v1.0.
>>
>> What "standard for node naming"? There's nothing wrong with putting a
>
> For the answer to that, you will need to ask Wolfgang Grandegger. I was
> working from his feedback. Looking at the plethora of other node names,
> the vast majority do not have any -v#.#, and the ones that do also tend
> to have multiple versions. Based upon that, I suspect he is correct,
> but I do not know where the documentation is or if it even exists.
There's a lot of crap in old bindings, plus it's not appropriate for all
circumstances (specifying bindings should be done a little more
carefully than "what do most other bindings do?"). It's something we've
been doing lately for blocks that have a version number, but it's not
dynamically readable.
Looking in the FlexCAN chapter of the p1010 manual, I don't see any
reference to a block version, and I do see references to "previous
FlexCAN versions". So I suggest "fsl,p1010-flexcan".
-Scott
^ permalink raw reply
* Re: [PATCH 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
From: Wolfgang Grandegger @ 2011-08-09 19:32 UTC (permalink / raw)
To: Scott Wood
Cc: netdev, Devicetree-discuss@lists.ozlabs.org, U Bhaskar-B22300,
socketcan-core, Robin Holt, PPC list
In-Reply-To: <4E4179CB.6030101@freescale.com>
On 08/09/2011 08:17 PM, Scott Wood wrote:
> On 08/09/2011 09:43 AM, Robin Holt wrote:
>> In working with the socketcan developers, we have come to the conclusion
>> the fsl-flexcan device tree bindings need to be cleaned up.
>> The driver does not depend upon any properties other than the required properties
>> so we are removing the file.
>
> That is not the criterion for whether something should be expresed in
> the device tree. It's a description of the hardware, not a Linux driver
> configuration file. If there are integration parameters that can not be
> inferred from "this is FSL flexcan v1.0", they should be expressed in
> the node.
>
> Removing the binding altogether seems extreme as well -- we should have
> bindings for all devices, even if there are no special properties.
Yes, of course. The commit message misleading. We do not intend to
remove the binding but just a few unused and confusing properties.
Concerning the compatible string, Freescale introduced for the Flexcan
on the P1010 "fsl,flexcan-v1.0". That's not the usual convention also
because the v1.0 if for the PowerPC cores only, I assume, but we have
ARM cores as well. If we need to distinguish I think we should use:
"fsl,p1010-flexcan", "fsl,flexcan"
Do you agree?
>> Additionally, the p1010*dts files are not
>> following the standard for node naming in that they have a trailing -v1.0.
>
> What "standard for node naming"? There's nothing wrong with putting a
> block version number in the compatible string, and it looks like the
> p1010 dts files were following the binding document in this regard. It
> is common practice when the block version is publicly documented but
> there's no register it can be read from at runtime.
See above.
Furthermore I must admit, that the bindings shown up mainline Linux have
never been presented on any mailing list.
Wolfgang.
^ permalink raw reply
* Re: [PATCH 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
From: Wolfgang Grandegger @ 2011-08-09 19:49 UTC (permalink / raw)
To: Scott Wood
Cc: netdev, devicetree-discuss@lists.ozlabs.org, U Bhaskar-B22300,
socketcan-core, Robin Holt, PPC list
In-Reply-To: <4E4186BD.5000602@freescale.com>
On 08/09/2011 09:13 PM, Scott Wood wrote:
> On 08/09/2011 01:45 PM, Robin Holt wrote:
>> On Tue, Aug 09, 2011 at 01:17:47PM -0500, Scott Wood wrote:
>>> On 08/09/2011 09:43 AM, Robin Holt wrote:
>>>> In working with the socketcan developers, we have come to the conclusion
>>>> the fsl-flexcan device tree bindings need to be cleaned up.
>>>> The driver does not depend upon any properties other than the required properties
>>>> so we are removing the file.
>>>
>>> That is not the criterion for whether something should be expresed in
>>> the device tree. It's a description of the hardware, not a Linux driver
>>> configuration file. If there are integration parameters that can not be
>>> inferred from "this is FSL flexcan v1.0", they should be expressed in
>>> the node.
>>
>> There are no properties other than the required properties. The others
>> were wrongly introduced and are not needed by the driver.
>
> Not needed by this driver, or will never be needed by any reasonable
> driver (or is not a good description of the hardware)?
>
> The device tree is not an internal Linux implementation detail. It is
> shared by other OSes, firmwares, hypervisors, etc. Bindings should be
> created with care, and kept stable unless there's a good reason to break
> compatibility.
>
> devicetree-discuss@lists.ozlabs.org should be CCed on device tree
> discussions.
Yes. The doc for the bindings we speak about
http://lxr.linux.no/#linux+v3.0.1/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
sneaked into the kernel without been presented on any mailing list and
without the corresponding driver patch.
>> When we
>> removed the other properties and the wrong documentation of the mscan
>> oscillator source in the fsl-flexcan.txt file, we were left with an
>> Example: section and a one-line statement "The only properties supported
>> are the required properties." That seemed like the fsl-flexcan.txt
>> file was then pointless.
>
> There is the compatible string, and you could mention that there is a
> single reg resource and a single interrupt.
>
>>> Removing the binding altogether seems extreme as well -- we should have
>>> bindings for all devices, even if there are no special properties.
>>
>> Ok. I can do that too. Who is the definitive source for that answer?
>
> For policy questions on device tree bindings? Grant Likely is the
> maintainer for device tree stuff.
>
> A lot of the simpler bindings have been left undocumented so far, IMHO
> it should be a goal to document them all. There are some existing ones
> that are documented despite not having special properties, e.g.
> Documentation/devicetree/bindings/serio/altera_ps2.txt,
> Documentation/devicetree/bindings/arm/sirf.txt,
> Documentation/devicetree/bindings/powerpc/nintendo/wii.txt, etc.
>
>> I assume we are talking about the fsl-flexcan.txt file when we say
>> binding. Is that correct?
>
> Yes, although devicetree.org is another possibility.
>
>>>> Additionally, the p1010*dts files are not
>>>> following the standard for node naming in that they have a trailing -v1.0.
>>>
>>> What "standard for node naming"? There's nothing wrong with putting a
>>
>> For the answer to that, you will need to ask Wolfgang Grandegger. I was
>> working from his feedback. Looking at the plethora of other node names,
>> the vast majority do not have any -v#.#, and the ones that do also tend
>> to have multiple versions. Based upon that, I suspect he is correct,
>> but I do not know where the documentation is or if it even exists.
>
> There's a lot of crap in old bindings, plus it's not appropriate for all
> circumstances (specifying bindings should be done a little more
> carefully than "what do most other bindings do?"). It's something we've
> been doing lately for blocks that have a version number, but it's not
> dynamically readable.
>
> Looking in the FlexCAN chapter of the p1010 manual, I don't see any
> reference to a block version, and I do see references to "previous
> FlexCAN versions". So I suggest "fsl,p1010-flexcan".
OK, just
"fsl,p1010-flexcan"
or
"fsl,p1010-flexcan", "fsl,flexcan"
Note that the Flexcan is used on Freescale ARM cores as well (and device
tree for ARM will show up soon).
Wolfgang.
^ permalink raw reply
* Re: [PATCH 5/5] [powerpc] Fix up fsl-flexcan device tree binding.
From: Scott Wood @ 2011-08-09 19:58 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: netdev, devicetree-discuss@lists.ozlabs.org, U Bhaskar-B22300,
socketcan-core, Robin Holt, PPC list
In-Reply-To: <4E418F2D.4060504@grandegger.com>
On 08/09/2011 02:49 PM, Wolfgang Grandegger wrote:
> Yes. The doc for the bindings we speak about
>
> http://lxr.linux.no/#linux+v3.0.1/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
>
> sneaked into the kernel without been presented on any mailing list and
> without the corresponding driver patch.
It was posted on linuxppc-dev:
http://patchwork.ozlabs.org/patch/91980/
Though I agree it should have been posted more widely.
> OK, just
>
> "fsl,p1010-flexcan"
>
> or
>
> "fsl,p1010-flexcan", "fsl,flexcan"
I'm ok with the latter, if there's enough in common that it's
conceivable that a driver wouldn't care. The more specific compatible
will be there if the driver wants to make use of it later.
-Scot
^ permalink raw reply
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