[PATCH] powerpc/pmac: Don't register pmac PIC syscore ops when HW not present
The Apple custom PIC only exist in some earlier machine models,
anything with an MPIC will crash on suspend if we register those
syscore ops unconditionally.
This is a regression caused by:
f5a592f7d74e38c5007876c731e6bf5580072e63
PM / PowerPC: Use struct syscore_ops instead of sysdevs for PM
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
Linus, can you just pop that in ? I can put it in a git tree tomorrow
if you prefer...
arch/powerpc/platforms/powermac/pic.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/powermac/pic.c
b/arch/powerpc/platforms/powermac/pic.c
index 9089b04..7667db4 100644
--- a/arch/powerpc/platforms/powermac/pic.c
+++ b/arch/powerpc/platforms/powermac/pic.c
@@ -715,7 +715,8 @@ static struct syscore_ops pmacpic_syscore_ops = {
static int __init init_pmacpic_syscore(void)
{
- register_syscore_ops(pmacpic_syscore_ops);
+ if (pmac_irq_hw[0])
+ register_syscore_ops(pmacpic_syscore_ops);
return 0;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 0/12] Hypervisor-mode KVM on POWER7
The following series of patches enable KVM to exploit the hardware hypervisor mode on 64-bit Power ISA Book3S machines. At present only POWER7 is supported, but it would be easy to add other processors. Running the KVM host in hypervisor mode means that the guest can use both supervisor mode and user mode. That means that the guest can execute supervisor-privilege instructions and access supervisor- privilege registers. In addition the hardware directs most exceptions to the guest. Thus we don't need to emulate any instructions in the host. Generally, the only times we need to exit the guest are when it does a hypercall or when an external interrupt or host timer (decrementer) interrupt occurs. The focus of this KVM implementation is to run guests that use the PAPR (Power Architecture Platform Requirements) paravirtualization interface, which is the interface supplied by PowerVM on IBM pSeries machines. Currently the pseries machine type in qemu is only supported by book3s_hv KVM, and book3s_hv KVM only supports the pseries machine type. That will hopefully change in future. These patches are against Linus' v3.0-rc1 tree. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 01/12] kvm/powerpc: Move fields between struct kvm_vcpu_arch and kvmppc_vcpu_book3s
This moves the slb field, which represents the state of the emulated
SLB, from the kvmppc_vcpu_book3s struct to the kvm_vcpu_arch, and the
hpte_hash_[v]pte[_long] fields from kvm_vcpu_arch to kvmppc_vcpu_book3s.
This is in accord with the principle that the kvm_vcpu_arch struct
represents the state of the emulated CPU, and the kvmppc_vcpu_book3s
struct holds the auxiliary data structures used in the emulation.
Signed-off-by: Paul Mackerras pau...@samba.org
---
arch/powerpc/include/asm/kvm_book3s.h | 35 +---
arch/powerpc/include/asm/kvm_host.h | 34 +++-
arch/powerpc/kvm/book3s.c |9 ++--
arch/powerpc/kvm/book3s_64_mmu.c | 54 +++-
arch/powerpc/kvm/book3s_mmu_hpte.c| 71 +++-
arch/powerpc/kvm/trace.h |2 +-
6 files changed, 107 insertions(+), 98 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s.h
b/arch/powerpc/include/asm/kvm_book3s.h
index d62e703..e1e8d43 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -24,20 +24,6 @@
#include linux/kvm_host.h
#include asm/kvm_book3s_asm.h
-struct kvmppc_slb {
- u64 esid;
- u64 vsid;
- u64 orige;
- u64 origv;
- bool valid : 1;
- bool Ks : 1;
- bool Kp : 1;
- bool nx : 1;
- bool large : 1;/* PTEs are 16MB */
- bool tb : 1;/* 1TB segment */
- bool class : 1;
-};
-
struct kvmppc_bat {
u64 raw;
u32 bepi;
@@ -67,11 +53,22 @@ struct kvmppc_sid_map {
#define VSID_POOL_SIZE (SID_CONTEXTS * 16)
#endif
+struct hpte_cache {
+ struct hlist_node list_pte;
+ struct hlist_node list_pte_long;
+ struct hlist_node list_vpte;
+ struct hlist_node list_vpte_long;
+ struct rcu_head rcu_head;
+ u64 host_va;
+ u64 pfn;
+ ulong slot;
+ struct kvmppc_pte pte;
+};
+
struct kvmppc_vcpu_book3s {
struct kvm_vcpu vcpu;
struct kvmppc_book3s_shadow_vcpu *shadow_vcpu;
struct kvmppc_sid_map sid_map[SID_MAP_NUM];
- struct kvmppc_slb slb[64];
struct {
u64 esid;
u64 vsid;
@@ -81,7 +78,6 @@ struct kvmppc_vcpu_book3s {
struct kvmppc_bat dbat[8];
u64 hid[6];
u64 gqr[8];
- int slb_nr;
u64 sdr1;
u64 hior;
u64 msr_mask;
@@ -94,6 +90,13 @@ struct kvmppc_vcpu_book3s {
#endif
int context_id[SID_CONTEXTS];
ulong prog_flags; /* flags to inject when giving a 700 trap */
+
+ 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];
+ struct hlist_head hpte_hash_vpte_long[HPTEG_HASH_NUM_VPTE_LONG];
+ int hpte_cache_count;
+ spinlock_t mmu_lock;
};
#define CONTEXT_HOST 0
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index 186f150..8bb47e0 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -163,16 +163,18 @@ struct kvmppc_mmu {
bool (*is_dcbz32)(struct kvm_vcpu *vcpu);
};
-struct hpte_cache {
- struct hlist_node list_pte;
- struct hlist_node list_pte_long;
- struct hlist_node list_vpte;
- struct hlist_node list_vpte_long;
- struct rcu_head rcu_head;
- u64 host_va;
- u64 pfn;
- ulong slot;
- struct kvmppc_pte pte;
+struct kvmppc_slb {
+ u64 esid;
+ u64 vsid;
+ u64 orige;
+ u64 origv;
+ bool valid : 1;
+ bool Ks : 1;
+ bool Kp : 1;
+ bool nx : 1;
+ bool large : 1;/* PTEs are 16MB */
+ bool tb : 1;/* 1TB segment */
+ bool class : 1;
};
struct kvm_vcpu_arch {
@@ -187,6 +189,9 @@ struct kvm_vcpu_arch {
ulong highmem_handler;
ulong rmcall;
ulong host_paca_phys;
+ struct kvmppc_slb slb[64];
+ int slb_max;/* # valid entries in slb[] */
+ int slb_nr; /* total number of entries in SLB */
struct kvmppc_mmu mmu;
#endif
@@ -298,15 +303,6 @@ struct kvm_vcpu_arch {
struct kvm_vcpu_arch_shared *shared;
unsigned long magic_page_pa; /* phys addr to map the magic page to */
unsigned long magic_page_ea; /* effect. addr to map the magic page to */
-
-#ifdef CONFIG_PPC_BOOK3S
- 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];
- struct hlist_head hpte_hash_vpte_long[HPTEG_HASH_NUM_VPTE_LONG];
- int hpte_cache_count;
- spinlock_t mmu_lock;
-#endif
};
#endif /* __POWERPC_KVM_HOST_H__ */
diff --git a/arch/powerpc/kvm/book3s.c
Re: [PATCH] ssb: pci: implement serdes workaround
Rafał Miłecki zajec5-re5jqeeqqe8avxtiumw...@public.gmane.org writes:
+/**
+ * Workarounds.
+ **/
+
+static u8 ssb_pcicore_polarity_workaround(struct ssb_pcicore *pc)
+{
+ return (ssb_pcie_read(pc, 0x204) 0x10) ? 0xC0 : 0x80;
+}
+
+static void ssb_pcicore_serdes_workaround(struct ssb_pcicore *pc)
+{
+ const u8 serdes_pll_device = 0x1D;
+ const u8 serdes_rx_device = 0x1F;
+ u16 tmp;
+
+ ssb_pcie_mdio_write(pc, serdes_rx_device, 1 /* Control */,
+ ssb_pcicore_polarity_workaround(pc));
+ tmp = ssb_pcie_mdio_read(pc, serdes_pll_device, 1 /* Control */);
+ if (tmp 0x4000)
+ ssb_pcie_mdio_write(pc, serdes_pll_device, 1, tmp ~0x4000);
+}
b43-pci-bridge 0001:10:12.0: enabling device (0004 - 0006)
ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x0D, vendor 0x4243)
ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x09, vendor 0x4243)
ssb: Core 2 found: PCI (cc 0x804, rev 0x0C, vendor 0x4243)
ssb: Core 3 found: PCMCIA (cc 0x80D, rev 0x07, vendor 0x4243)
Machine check in kernel mode.
Caused by (from SRR1=149030): Transfer error ack signal
Oops: Machine check, sig: 7 [#1]
PowerMac
Modules linked in: crc_itu_t ssb(+) snd_aoa_soundbus sungem sungem_phy
NIP: c0013324 LR: f2143e84 CTR: c001331c
REGS: c2ca5b80 TRAP: 0200 Not tainted (3.0.0-rc1)
MSR: 00149030 EE,ME,IR,DR CR: 22004422 XER: 2000
TASK = ef9cef90[285] 'modprobe' THREAD: c2ca4000
GPR00: c2d1f87c c2ca5c30 ef9cef90 2381 0134 0204 0080 c2ca5bc8
GPR08: 04773e80 c2d1f87c c001331c 1002833c f2141968 f214821c
GPR16: f21478b7 f2148250 f21478c0 f2147894 00100100 00200200 1310 c2d1fb2c
GPR24: f2147ee8 f2148204 c2d1f800 0134 c2d1f800
NIP [c0013324] ioread32+0x8/0x14
LR [f2143e84] ssb_pci_read32+0x4c/0x5c [ssb]
Call Trace:
[c2ca5c30] [c2d1f800] 0xc2d1f800 (unreliable)
[c2ca5c40] [f2146244] ssb_pcie_read+0x4c/0x54 [ssb]
[c2ca5c50] [f2146440] ssb_pcicore_serdes_workaround+0x1c/0x170 [ssb]
[c2ca5c70] [f2141c24] ssb_attach_queued_buses+0x94/0x288 [ssb]
[c2ca5cd0] [f2142078] ssb_bus_register+0xe4/0x160 [ssb]
[c2ca5cf0] [f2142134] ssb_bus_pcibus_register+0x40/0x80 [ssb]
[c2ca5d00] [f2144a60] ssb_pcihost_probe+0xd8/0x114 [ssb]
[c2ca5d30] [c018f6ac] local_pci_probe+0x28/0x38
[c2ca5d40] [c0190690] pci_device_probe+0x68/0x94
[c2ca5d70] [c02bc8a4] driver_probe_device+0xc8/0x170
[c2ca5d90] [c02bc9bc] __driver_attach+0x70/0x98
[c2ca5db0] [c02bb9ec] bus_for_each_dev+0x60/0x90
[c2ca5de0] [c02bc538] driver_attach+0x24/0x34
[c2ca5df0] [c02bc11c] bus_add_driver+0xbc/0x23c
[c2ca5e10] [c02bcfc8] driver_register+0xb8/0x144
[c2ca5e30] [c01908c8] __pci_register_driver+0x4c/0xc8
[c2ca5e50] [f214486c] ssb_pcihost_register+0x50/0x60 [ssb]
[c2ca5e60] [f214c094] b43_pci_ssb_bridge_init+0x18/0xbc [ssb]
[c2ca5e70] [f214c05c] ssb_modinit+0x5c/0x7c [ssb]
[c2ca5e80] [c00049d8] do_one_initcall+0xe0/0x1c0
[c2ca5eb0] [c005f7b0] sys_init_module+0x164c/0x1850
[c2ca5f40] [c0010cd8] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0xff0b714
LR = 0x100050f0
Instruction dump:
0c03 4c00012c 5463043e 4e800020 7c0004ac a063 0c03 4c00012c
5463043e 4e800020 7c0004ac 7c601c2c 0c03 4c00012c 4e800020 7c0004ac
---[ end trace 9824f03a7724930b ]---
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 11/12] kvm/powerpc: Accelerate H_PUT_TCE by implementing it in real mode
From: David Gibson d...@au1.ibm.com
This improves I/O performance for guests using the PAPR
paravirtualization interface by making the H_PUT_TCE hcall faster, by
implementing it in real mode. H_PUT_TCE is used for updating virtual
IOMMU tables, and is used both for virtual I/O and for real I/O in the
PAPR interface.
Since this moves the IOMMU tables into the kernel, we define a new
KVM_CREATE_SPAPR_TCE ioctl to allow qemu to create the tables. The
ioctl returns a file descriptor which can be used to mmap the newly
created table. The qemu driver models use them in the same way as
userspace managed tables, but they can be updated directly by the
guest with a real-mode H_PUT_TCE implementation, reducing the number
of host/guest context switches during guest IO.
There are certain circumstances where it is useful for userland qemu
to write to the TCE table even if the kernel H_PUT_TCE path is used
most of the time. Specifically, allowing this will avoid awkwardness
when we need to reset the table. More importantly, we will in the
future need to write the table in order to restore its state after a
checkpoint resume or migration.
Signed-off-by: David Gibson da...@gibson.dropbear.id.au
Signed-off-by: Paul Mackerras pau...@samba.org
---
Documentation/virtual/kvm/api.txt| 35 +
arch/powerpc/include/asm/kvm.h |9 +++
arch/powerpc/include/asm/kvm_book3s_64.h |2 +
arch/powerpc/include/asm/kvm_host.h |9 +++
arch/powerpc/include/asm/kvm_ppc.h |2 +
arch/powerpc/kvm/Makefile|3 +-
arch/powerpc/kvm/book3s_64_vio_hv.c | 73 +++
arch/powerpc/kvm/book3s_hv.c | 116 +-
arch/powerpc/kvm/book3s_hv_rmhandlers.S |2 +-
arch/powerpc/kvm/powerpc.c | 18 +
include/linux/kvm.h |3 +
11 files changed, 269 insertions(+), 3 deletions(-)
create mode 100644 arch/powerpc/kvm/book3s_64_vio_hv.c
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index f61e986..acf0fcd 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1291,6 +1291,41 @@ Returns the tsc frequency of the guest. The unit of the
return value is
KHz. If the host has unstable tsc this ioctl returns -EIO instead as an
error.
+4.56 KVM_CREATE_SPAPR_TCE
+
+Capability: KVM_CAP_SPAPR_TCE
+Architectures: powerpc
+Type: vm ioctl
+Parameters: struct kvm_create_spapr_tce (in)
+Returns: file descriptor for manipulating the created TCE table
+
+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 */
+struct kvm_create_spapr_tce {
+ __u64 liobn;
+ __u32 window_size;
+};
+
+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 4kiB of the DMA window.
+
+When the guest issues an H_PUT_TCE hcall on a liobn for which a TCE
+table has been created using this ioctl(), the kernel will handle it
+in real mode, updating the TCE table. H_PUT_TCE calls for other
+liobns 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
Application code obtains a pointer to the kvm_run structure by
diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index d2ca5ed..c3ec990 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -22,6 +22,9 @@
#include linux/types.h
+/* Select powerpc specific features in linux/kvm.h */
+#define __KVM_HAVE_SPAPR_TCE
+
struct kvm_regs {
__u64 pc;
__u64 cr;
@@ -272,4 +275,10 @@ struct kvm_guest_debug_arch {
#define KVM_INTERRUPT_UNSET-2U
#define KVM_INTERRUPT_SET_LEVEL-3U
+/* for KVM_CAP_SPAPR_TCE */
+struct kvm_create_spapr_tce {
+ __u64 liobn;
+ __u32 window_size;
+};
+
#endif /* __LINUX_KVM_POWERPC_H */
diff --git a/arch/powerpc/include/asm/kvm_book3s_64.h
b/arch/powerpc/include/asm/kvm_book3s_64.h
index 5f73388..e43fe42 100644
--- a/arch/powerpc/include/asm/kvm_book3s_64.h
+++ b/arch/powerpc/include/asm/kvm_book3s_64.h
@@ -27,4 +27,6 @@ static inline struct kvmppc_book3s_shadow_vcpu
*to_svcpu(struct kvm_vcpu *vcpu)
}
#endif
+#define SPAPR_TCE_SHIFT12
+
#endif /* __ASM_KVM_BOOK3S_64_H__ */
diff --git
[PATCH v2 08/12] kvm/powerpc: Split host-state fields out of kvmppc_book3s_shadow_vcpu
There are several fields in struct kvmppc_book3s_shadow_vcpu that
temporarily store bits of host state while a guest is running,
rather than anything relating to the particular guest or vcpu.
This splits them out into a new kvmppc_host_state structure and
modifies the definitions in asm-offsets.c to suit.
On 32-bit, we have a kvmppc_host_state structure inside the
kvmppc_book3s_shadow_vcpu since the assembly code needs to be able
to get to them both with one pointer. On 64-bit they are separate
fields in the PACA. This means that on 64-bit we don't need to
copy the kvmppc_host_state in and out on vcpu load/unload, and
in future will mean that the book3s_hv code doesn't need a
shadow_vcpu struct in the PACA at all.
Signed-off-by: Paul Mackerras pau...@samba.org
---
arch/powerpc/include/asm/exception-64s.h | 10 ++--
arch/powerpc/include/asm/kvm_book3s_asm.h | 27 ++---
arch/powerpc/include/asm/paca.h |1 +
arch/powerpc/kernel/asm-offsets.c | 94 ++--
arch/powerpc/kvm/book3s_interrupts.S | 17 +++---
arch/powerpc/kvm/book3s_rmhandlers.S | 18 +++---
arch/powerpc/kvm/book3s_segment.S | 72 +++---
7 files changed, 124 insertions(+), 115 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h
b/arch/powerpc/include/asm/exception-64s.h
index b6a3a44..296c9b6 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -96,16 +96,16 @@
EXCEPTION_PROLOG_PSERIES_1(label, h);
#define __KVMTEST(n) \
- lbz r10,PACA_KVM_SVCPU+SVCPU_IN_GUEST(r13); \
+ lbz r10,HSTATE_IN_GUEST(r13); \
cmpwi r10,0; \
bne do_kvm_##n
#define __KVM_HANDLER(area, h, n) \
do_kvm_##n:\
ld r10,area+EX_R10(r13); \
- stw r9,PACA_KVM_SVCPU+SVCPU_SCRATCH1(r13); \
+ stw r9,HSTATE_SCRATCH1(r13);\
ld r9,area+EX_R9(r13); \
- std r12,PACA_KVM_SVCPU+SVCPU_SCRATCH0(r13); \
+ std r12,HSTATE_SCRATCH0(r13); \
li r12,n; \
b kvmppc_interrupt
@@ -114,9 +114,9 @@ do_kvm_##n:
\
cmpwi r10,KVM_GUEST_MODE_SKIP;\
ld r10,area+EX_R10(r13); \
beq 89f;\
- stw r9,PACA_KVM_SVCPU+SVCPU_SCRATCH1(r13); \
+ stw r9,HSTATE_SCRATCH1(r13);\
ld r9,area+EX_R9(r13); \
- std r12,PACA_KVM_SVCPU+SVCPU_SCRATCH0(r13); \
+ std r12,HSTATE_SCRATCH0(r13); \
li r12,n; \
b kvmppc_interrupt; \
89:mtocrf 0x80,r9;\
diff --git a/arch/powerpc/include/asm/kvm_book3s_asm.h
b/arch/powerpc/include/asm/kvm_book3s_asm.h
index d5a8a38..3126175 100644
--- a/arch/powerpc/include/asm/kvm_book3s_asm.h
+++ b/arch/powerpc/include/asm/kvm_book3s_asm.h
@@ -60,6 +60,22 @@ kvmppc_resume_\intno:
#else /*__ASSEMBLY__ */
+/*
+ * This struct goes in the PACA on 64-bit processors. It is used
+ * to store host state that needs to be saved when we enter a guest
+ * and restored when we exit, but isn't specific to any particular
+ * guest or vcpu. It also has some scratch fields used by the guest
+ * exit code.
+ */
+struct kvmppc_host_state {
+ ulong host_r1;
+ ulong host_r2;
+ ulong vmhandler;
+ ulong scratch0;
+ ulong scratch1;
+ u8 in_guest;
+};
+
struct kvmppc_book3s_shadow_vcpu {
ulong gpr[14];
u32 cr;
@@ -73,17 +89,12 @@ struct kvmppc_book3s_shadow_vcpu {
ulong shadow_srr1;
ulong fault_dar;
- ulong host_r1;
- ulong host_r2;
- ulong handler;
- ulong scratch0;
- ulong scratch1;
- ulong vmhandler;
- u8 in_guest;
-
#ifdef CONFIG_PPC_BOOK3S_32
u32 sr[16]; /* Guest SRs */
+
+ struct kvmppc_host_state hstate;
#endif
+
#ifdef CONFIG_PPC_BOOK3S_64
u8 slb_max; /* highest used guest slb entry */
struct {
diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index 7412676..58f4a18 100644
--- a/arch/powerpc/include/asm/paca.h
+++
[PATCH v2 03/12] powerpc, kvm: Rework KVM checks in first-level interrupt handlers
Instead of branching out-of-line with the DO_KVM macro to check if we are in a KVM guest at the time of an interrupt, this moves the KVM check inline in the first-level interrupt handlers. This speeds up the non-KVM case and makes sure that none of the interrupt handlers are missing the check. Because the first-level interrupt handlers are now larger, some things had to be move out of line in exceptions-64s.S. This all necessitated some minor changes to the interrupt entry code in KVM. This also streamlines the book3s_32 KVM test. Signed-off-by: Paul Mackerras pau...@samba.org --- arch/powerpc/include/asm/exception-64s.h | 121 -- arch/powerpc/kernel/exceptions-64s.S | 189 +--- arch/powerpc/kvm/book3s_rmhandlers.S | 78 ++-- arch/powerpc/kvm/book3s_segment.S |7 + arch/powerpc/platforms/iseries/exception.S |2 +- arch/powerpc/platforms/iseries/exception.h |4 +- 6 files changed, 247 insertions(+), 154 deletions(-) diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h index f5dfe34..b6a3a44 100644 --- a/arch/powerpc/include/asm/exception-64s.h +++ b/arch/powerpc/include/asm/exception-64s.h @@ -61,19 +61,22 @@ #define EXC_HV H #define EXC_STD -#define EXCEPTION_PROLOG_1(area) \ +#define __EXCEPTION_PROLOG_1(area, extra, vec) \ GET_PACA(r13); \ std r9,area+EX_R9(r13); /* save r9 - r12 */ \ std r10,area+EX_R10(r13); \ - std r11,area+EX_R11(r13); \ - std r12,area+EX_R12(r13); \ BEGIN_FTR_SECTION_NESTED(66); \ mfspr r10,SPRN_CFAR; \ std r10,area+EX_CFAR(r13); \ END_FTR_SECTION_NESTED(CPU_FTR_CFAR, CPU_FTR_CFAR, 66); \ - GET_SCRATCH0(r9); \ - std r9,area+EX_R13(r13);\ - mfcrr9 + mfcrr9; \ + extra(vec); \ + std r11,area+EX_R11(r13); \ + std r12,area+EX_R12(r13); \ + GET_SCRATCH0(r10); \ + std r10,area+EX_R13(r13) +#define EXCEPTION_PROLOG_1(area, extra, vec) \ + __EXCEPTION_PROLOG_1(area, extra, vec) #define __EXCEPTION_PROLOG_PSERIES_1(label, h) \ ld r12,PACAKBASE(r13); /* get high part of label */ \ @@ -85,13 +88,54 @@ mtspr SPRN_##h##SRR1,r10; \ h##rfid;\ b . /* prevent speculative execution */ -#define EXCEPTION_PROLOG_PSERIES_1(label, h) \ +#define EXCEPTION_PROLOG_PSERIES_1(label, h) \ __EXCEPTION_PROLOG_PSERIES_1(label, h) -#define EXCEPTION_PROLOG_PSERIES(area, label, h) \ - EXCEPTION_PROLOG_1(area); \ +#define EXCEPTION_PROLOG_PSERIES(area, label, h, extra, vec) \ + EXCEPTION_PROLOG_1(area, extra, vec); \ EXCEPTION_PROLOG_PSERIES_1(label, h); +#define __KVMTEST(n) \ + lbz r10,PACA_KVM_SVCPU+SVCPU_IN_GUEST(r13); \ + cmpwi r10,0; \ + bne do_kvm_##n + +#define __KVM_HANDLER(area, h, n) \ +do_kvm_##n:\ + ld r10,area+EX_R10(r13); \ + stw r9,PACA_KVM_SVCPU+SVCPU_SCRATCH1(r13); \ + ld r9,area+EX_R9(r13); \ + std r12,PACA_KVM_SVCPU+SVCPU_SCRATCH0(r13); \ + li r12,n; \ + b kvmppc_interrupt + +#define __KVM_HANDLER_SKIP(area, h, n) \ +do_kvm_##n:\ + cmpwi r10,KVM_GUEST_MODE_SKIP;\ + ld r10,area+EX_R10(r13); \ + beq 89f;\ + stw r9,PACA_KVM_SVCPU+SVCPU_SCRATCH1(r13); \ + ld r9,area+EX_R9(r13);
[PATCH v2 06/12] kvm/powerpc: Move guest enter/exit down into subarch-specific code
Instead of doing the kvm_guest_enter/exit() and local_irq_dis/enable()
calls in powerpc.c, this moves them down into the subarch-specific
book3s_pr.c and booke.c. This eliminates an extra local_irq_enable()
call in book3s_pr.c, and will be needed for when we do SMT4 guest
support in the book3s hypervisor mode code.
Signed-off-by: Paul Mackerras pau...@samba.org
---
arch/powerpc/include/asm/kvm_ppc.h |1 +
arch/powerpc/kvm/book3s_interrupts.S |2 +-
arch/powerpc/kvm/book3s_pr.c | 12 ++--
arch/powerpc/kvm/booke.c | 13 +
arch/powerpc/kvm/powerpc.c |6 +-
5 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index 3a925fa..c3dde27 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -42,6 +42,7 @@ enum emulation_result {
EMULATE_AGAIN,/* something went wrong. go again */
};
+extern int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu);
extern int __kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu);
extern char kvmppc_handlers_start[];
extern unsigned long kvmppc_handler_len;
diff --git a/arch/powerpc/kvm/book3s_interrupts.S
b/arch/powerpc/kvm/book3s_interrupts.S
index 2f0bc92..8c5e0e1 100644
--- a/arch/powerpc/kvm/book3s_interrupts.S
+++ b/arch/powerpc/kvm/book3s_interrupts.S
@@ -85,7 +85,7 @@
* r3: kvm_run pointer
* r4: vcpu pointer
*/
-_GLOBAL(__kvmppc_vcpu_entry)
+_GLOBAL(__kvmppc_vcpu_run)
kvm_start_entry:
/* Write correct stack frame */
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index 82aaf65..f0de167 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -891,8 +891,7 @@ void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
vfree(vcpu_book3s);
}
-extern int __kvmppc_vcpu_entry(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu);
-int __kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)
+int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)
{
int ret;
double fpr[32][TS_FPRWIDTH];
@@ -944,14 +943,15 @@ int __kvmppc_vcpu_run(struct kvm_run *kvm_run, struct
kvm_vcpu *vcpu)
/* Remember the MSR with disabled extensions */
ext_msr = current-thread.regs-msr;
- /* XXX we get called with irq disabled - change that! */
- local_irq_enable();
-
/* Preload FPU if it's enabled */
if (vcpu-arch.shared-msr MSR_FP)
kvmppc_handle_ext(vcpu, BOOK3S_INTERRUPT_FP_UNAVAIL, MSR_FP);
- ret = __kvmppc_vcpu_entry(kvm_run, vcpu);
+ kvm_guest_enter();
+
+ ret = __kvmppc_vcpu_run(kvm_run, vcpu);
+
+ kvm_guest_exit();
local_irq_disable();
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 7a0bc11..39c34c6 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -257,6 +257,19 @@ void kvmppc_core_deliver_interrupts(struct kvm_vcpu *vcpu)
vcpu-arch.shared-int_pending = 0;
}
+int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)
+{
+ int ret;
+
+ local_irq_disable();
+ kvm_guest_enter();
+ ret = __kvmppc_vcpu_run(kvm_run, vcpu);
+ kvm_guest_exit();
+ local_irq_enable();
+
+ return ret;
+}
+
/**
* kvmppc_handle_exit
*
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 216905b..74179b9 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -499,11 +499,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct
kvm_run *run)
kvmppc_core_deliver_interrupts(vcpu);
- local_irq_disable();
- kvm_guest_enter();
- r = __kvmppc_vcpu_run(run, vcpu);
- kvm_guest_exit();
- local_irq_enable();
+ r = kvmppc_vcpu_run(run, vcpu);
if (vcpu-sigset_active)
sigprocmask(SIG_SETMASK, sigsaved, NULL);
--
1.7.5.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 07/12] powerpc: Set up LPCR for running guest partitions
In hypervisor mode, the LPCR controls several aspects of guest partitions, including virtual partition memory mode, and also controls whether the hypervisor decrementer interrupts are enabled. This sets up LPCR at boot time so that guest partitions will use a virtual real memory area (VRMA) composed of 16MB large pages, and hypervisor decrementer interrupts are disabled. Signed-off-by: Paul Mackerras pau...@samba.org --- arch/powerpc/include/asm/reg.h |4 arch/powerpc/kernel/cpu_setup_power7.S | 18 +++--- 2 files changed, 15 insertions(+), 7 deletions(-) diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h index c5cae0d..d879a6b 100644 --- a/arch/powerpc/include/asm/reg.h +++ b/arch/powerpc/include/asm/reg.h @@ -232,10 +232,12 @@ #define LPCR_VPM0(1ul (63-0)) #define LPCR_VPM1(1ul (63-1)) #define LPCR_ISL (1ul (63-2)) +#define LPCR_VC_SH (63-2) #define LPCR_DPFD_SH (63-11) #define LPCR_VRMA_L (1ul (63-12)) #define LPCR_VRMA_LP0(1ul (63-15)) #define LPCR_VRMA_LP1(1ul (63-16)) +#define LPCR_VRMASD_SH (63-16) #define LPCR_RMLS0x1C00 /* impl dependent rmo limit sel */ #define LPCR_ILE 0x0200 /* !HV irqs set MSR:LE */ #define LPCR_PECE0x7000 /* powersave exit cause enable */ @@ -243,8 +245,10 @@ #define LPCR_PECE1 0x2000 /* decrementer can cause exit */ #define LPCR_PECE2 0x1000 /* machine check etc can cause exit */ #define LPCR_MER 0x0800 /* Mediated External Exception */ +#define LPCR_LPES0x000c #define LPCR_LPES0 0x0008 /* LPAR Env selector 0 */ #define LPCR_LPES1 0x0004 /* LPAR Env selector 1 */ +#define LPCR_LPES_SH 2 #define LPCR_RMI 0x0002 /* real mode is cache inhibit */ #define LPCR_HDICE 0x0001 /* Hyp Decr enable (HV,PR,EE) */ #define SPRN_LPID 0x13F /* Logical Partition Identifier */ diff --git a/arch/powerpc/kernel/cpu_setup_power7.S b/arch/powerpc/kernel/cpu_setup_power7.S index 4f9a93f..2ef6749 100644 --- a/arch/powerpc/kernel/cpu_setup_power7.S +++ b/arch/powerpc/kernel/cpu_setup_power7.S @@ -61,19 +61,23 @@ __init_LPCR: * LPES = 0b01 (HSRR0/1 used for 0x500) * PECE = 0b111 * DPFD = 4 +* HDICE = 0 +* VC = 0b100 (VPM0=1, VPM1=0, ISL=0) +* VRMASD = 0b1 (L=1, LP=00) * * Other bits untouched for now */ mfspr r3,SPRN_LPCR - ori r3,r3,(LPCR_LPES0|LPCR_LPES1) - xorir3,r3, LPCR_LPES0 + li r5,1 + rldimi r3,r5, LPCR_LPES_SH, 64-LPCR_LPES_SH-2 ori r3,r3,(LPCR_PECE0|LPCR_PECE1|LPCR_PECE2) - li r5,7 - sldir5,r5,LPCR_DPFD_SH - andcr3,r3,r5 li r5,4 - sldir5,r5,LPCR_DPFD_SH - or r3,r3,r5 + rldimi r3,r5, LPCR_DPFD_SH, 64-LPCR_DPFD_SH-3 + clrrdi r3,r3,1 /* clear HDICE */ + li r5,4 + rldimi r3,r5, LPCR_VC_SH, 0 + li r5,0x10 + rldimi r3,r5, LPCR_VRMASD_SH, 64-LPCR_VRMASD_SH-5 mtspr SPRN_LPCR,r3 isync blr -- 1.7.5.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 05/12] kvm/powerpc: Pass init/destroy vm and prepare/commit memory region ops down
This arranges for the top-level arch/powerpc/kvm/powerpc.c file to
pass down some of the calls it gets to the lower-level subarchitecture
specific code. The lower-level implementations (in booke.c and book3s.c)
are no-ops. The coming book3s_hv.c will need this.
Signed-off-by: Paul Mackerras pau...@samba.org
---
arch/powerpc/include/asm/kvm_ppc.h |7 +++
arch/powerpc/kvm/book3s_pr.c | 20
arch/powerpc/kvm/booke.c | 20
arch/powerpc/kvm/powerpc.c |9 ++---
4 files changed, 53 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index 9345238..3a925fa 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -110,6 +110,13 @@ extern void kvmppc_booke_exit(void);
extern void kvmppc_core_destroy_mmu(struct kvm_vcpu *vcpu);
extern int kvmppc_kvm_pv(struct kvm_vcpu *vcpu);
+extern int kvmppc_core_init_vm(struct kvm *kvm);
+extern void kvmppc_core_destroy_vm(struct kvm *kvm);
+extern int kvmppc_core_prepare_memory_region(struct kvm *kvm,
+ struct kvm_userspace_memory_region *mem);
+extern void kvmppc_core_commit_memory_region(struct kvm *kvm,
+ struct kvm_userspace_memory_region *mem);
+
/*
* Cuts out inst bits with ordering according to spec.
* That means the leftmost bit is zero. All given bits are included.
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index 82df775..82aaf65 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -984,6 +984,26 @@ int __kvmppc_vcpu_run(struct kvm_run *kvm_run, struct
kvm_vcpu *vcpu)
return ret;
}
+int kvmppc_core_prepare_memory_region(struct kvm *kvm,
+ struct kvm_userspace_memory_region *mem)
+{
+ return 0;
+}
+
+void kvmppc_core_commit_memory_region(struct kvm *kvm,
+ struct kvm_userspace_memory_region *mem)
+{
+}
+
+int kvmppc_core_init_vm(struct kvm *kvm)
+{
+ return 0;
+}
+
+void kvmppc_core_destroy_vm(struct kvm *kvm)
+{
+}
+
static int kvmppc_book3s_init(void)
{
int r;
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 8462b3a..7a0bc11 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -770,6 +770,26 @@ int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm, struct
kvm_dirty_log *log)
return -ENOTSUPP;
}
+int kvmppc_core_prepare_memory_region(struct kvm *kvm,
+ struct kvm_userspace_memory_region *mem)
+{
+ return 0;
+}
+
+void kvmppc_core_commit_memory_region(struct kvm *kvm,
+ struct kvm_userspace_memory_region *mem)
+{
+}
+
+int kvmppc_core_init_vm(struct kvm *kvm)
+{
+ return 0;
+}
+
+void kvmppc_core_destroy_vm(struct kvm *kvm)
+{
+}
+
int __init kvmppc_booke_init(void)
{
unsigned long ivor[16];
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 616dd51..216905b 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -147,7 +147,7 @@ void kvm_arch_check_processor_compat(void *rtn)
int kvm_arch_init_vm(struct kvm *kvm)
{
- return 0;
+ return kvmppc_core_init_vm(kvm);
}
void kvm_arch_destroy_vm(struct kvm *kvm)
@@ -163,6 +163,9 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
kvm-vcpus[i] = NULL;
atomic_set(kvm-online_vcpus, 0);
+
+ kvmppc_core_destroy_vm(kvm);
+
mutex_unlock(kvm-lock);
}
@@ -211,7 +214,7 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
struct kvm_userspace_memory_region *mem,
int user_alloc)
{
- return 0;
+ return kvmppc_core_prepare_memory_region(kvm, mem);
}
void kvm_arch_commit_memory_region(struct kvm *kvm,
@@ -219,7 +222,7 @@ void kvm_arch_commit_memory_region(struct kvm *kvm,
struct kvm_memory_slot old,
int user_alloc)
{
- return;
+ kvmppc_core_commit_memory_region(kvm, mem);
}
--
1.7.5.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 10/12] kvm/powerpc: Handle some PAPR hcalls in the kernel
This adds the infrastructure for handling PAPR hcalls in the kernel,
either early in the guest exit path while we are still in real mode,
or later once the MMU has been turned back on and we are in the full
kernel context. The advantage of handling hcalls in real mode if
possible is that we avoid two partition switches -- and this will
become more important when we support SMT4 guests, since a partition
switch means we have to pull all of the threads in the core out of
the guest. The disadvantage is that we can only access the kernel
linear mapping, not anything vmalloced or ioremapped, since the MMU
is off.
This also adds code to handle the following hcalls in real mode:
H_ENTER Add an HPTE to the hashed page table
H_REMOVE Remove an HPTE from the hashed page table
H_READRead HPTEs from the hashed page table
H_PROTECT Change the protection bits in an HPTE
H_BULK_REMOVE Remove up to 4 HPTEs from the hashed page table
H_SET_DABRSet the data address breakpoint register
Plus code to handle the following hcalls in the kernel:
H_CEDEIdle the vcpu until an interrupt or H_PROD hcall arrives
H_PRODWake up a ceded vcpu
H_REGISTER_VPA Register a virtual processor area (VPA)
Signed-off-by: Paul Mackerras pau...@samba.org
---
arch/powerpc/include/asm/hvcall.h |5 +
arch/powerpc/include/asm/kvm_host.h | 11 +
arch/powerpc/include/asm/kvm_ppc.h |1 +
arch/powerpc/kernel/asm-offsets.c |2 +
arch/powerpc/kvm/book3s_64_mmu_hv.c | 342 +++
arch/powerpc/kvm/book3s_hv.c| 170 +++-
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 156 ++-
arch/powerpc/kvm/powerpc.c |2 +-
8 files changed, 685 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/hvcall.h
b/arch/powerpc/include/asm/hvcall.h
index fd8201d..1c324ff 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -29,6 +29,10 @@
#define H_LONG_BUSY_ORDER_100_SEC 9905 /* Long busy, hint that 100sec \
is a good time to retry */
#define H_LONG_BUSY_END_RANGE 9905 /* End of long busy range */
+
+/* Internal value used in book3s_hv kvm support; not returned to guests */
+#define H_TOO_HARD
+
#define H_HARDWARE -1 /* Hardware error */
#define H_FUNCTION -2 /* Function not supported */
#define H_PRIVILEGE-3 /* Caller not privileged */
@@ -100,6 +104,7 @@
#define H_PAGE_SET_ACTIVE H_PAGE_STATE_CHANGE
#define H_AVPN (1UL(63-32)) /* An avpn is provided as a
sanity test */
#define H_ANDCOND (1UL(63-33))
+#define H_LOCAL(1UL(63-35))
#define H_ICACHE_INVALIDATE(1UL(63-40)) /* icbi, etc. (ignored for IO
pages) */
#define H_ICACHE_SYNCHRONIZE (1UL(63-41)) /* dcbst, icbi, etc (ignored
for IO pages */
#define H_COALESCE_CAND(1UL(63-42)) /* page is a good candidate for
coalescing */
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index 5645532..359db37 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -59,6 +59,10 @@ struct kvm;
struct kvm_run;
struct kvm_vcpu;
+struct lppaca;
+struct slb_shadow;
+struct dtl;
+
struct kvm_vm_stat {
u32 remote_tlb_flush;
};
@@ -337,7 +341,14 @@ struct kvm_vcpu_arch {
u64 dec_expires;
unsigned long pending_exceptions;
u16 last_cpu;
+ u8 ceded;
+ u8 prodded;
u32 last_inst;
+
+ struct lppaca *vpa;
+ struct slb_shadow *slb_shadow;
+ struct dtl *dtl;
+ struct dtl *dtl_end;
int trap;
struct kvm_vcpu_arch_shared *shared;
unsigned long magic_page_pa; /* phys addr to map the magic page to */
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index 2a10e82..d809e58 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -117,6 +117,7 @@ extern long kvmppc_prepare_vrma(struct kvm *kvm,
struct kvm_userspace_memory_region *mem);
extern void kvmppc_map_vrma(struct kvm *kvm,
struct kvm_userspace_memory_region *mem);
+extern int kvmppc_pseries_do_hcall(struct kvm_vcpu *vcpu);
extern int kvmppc_core_init_vm(struct kvm *kvm);
extern void kvmppc_core_destroy_vm(struct kvm *kvm);
extern int kvmppc_core_prepare_memory_region(struct kvm *kvm,
diff --git a/arch/powerpc/kernel/asm-offsets.c
b/arch/powerpc/kernel/asm-offsets.c
index a2f540b..d29f19a 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -189,6 +189,7 @@ int main(void)
DEFINE(LPPACADECRINT, offsetof(struct lppaca,
int_dword.fields.decr_int));
DEFINE(LPPACA_PMCINUSE, offsetof(struct lppaca, pmcregs_in_use));
DEFINE(LPPACA_DTLIDX,
[PATCH v2 04/12] kvm/powerpc: Deliver program interrupts right away instead of queueing them
Doing so means that we don't have to save the flags anywhere and gets
rid of the last reference to to_book3s(vcpu) in arch/powerpc/kvm/book3s.c.
Doing so is OK because a program interrupt won't be generated at the
same time as any other synchronous interrupt. If a program interrupt
and an asynchronous interrupt (external or decrementer) are generated
at the same time, the program interrupt will be delivered, which is
correct because it has a higher priority, and then the asynchronous
interrupt will be masked.
We don't ever generate system reset or machine check interrupts to the
guest, but if we did, then we would need to make sure they got delivered
rather than the program interrupt. The current code would be wrong in
this situation anyway since it would deliver the program interrupt as
well as the reset/machine check interrupt.
Signed-off-by: Paul Mackerras pau...@samba.org
---
arch/powerpc/kvm/book3s.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index af63de3..096c711 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -128,8 +128,8 @@ void kvmppc_book3s_queue_irqprio(struct kvm_vcpu *vcpu,
unsigned int vec)
void kvmppc_core_queue_program(struct kvm_vcpu *vcpu, ulong flags)
{
- to_book3s(vcpu)-prog_flags = flags;
- kvmppc_book3s_queue_irqprio(vcpu, BOOK3S_INTERRUPT_PROGRAM);
+ /* might as well deliver this straight away */
+ kvmppc_inject_interrupt(vcpu, BOOK3S_INTERRUPT_PROGRAM, flags);
}
void kvmppc_core_queue_dec(struct kvm_vcpu *vcpu)
@@ -169,7 +169,6 @@ int kvmppc_book3s_irqprio_deliver(struct kvm_vcpu *vcpu,
unsigned int priority)
{
int deliver = 1;
int vec = 0;
- ulong flags = 0ULL;
bool crit = kvmppc_critical_section(vcpu);
switch (priority) {
@@ -205,7 +204,6 @@ int kvmppc_book3s_irqprio_deliver(struct kvm_vcpu *vcpu,
unsigned int priority)
break;
case BOOK3S_IRQPRIO_PROGRAM:
vec = BOOK3S_INTERRUPT_PROGRAM;
- flags = to_book3s(vcpu)-prog_flags;
break;
case BOOK3S_IRQPRIO_VSX:
vec = BOOK3S_INTERRUPT_VSX;
@@ -236,7 +234,7 @@ int kvmppc_book3s_irqprio_deliver(struct kvm_vcpu *vcpu,
unsigned int priority)
#endif
if (deliver)
- kvmppc_inject_interrupt(vcpu, vec, flags);
+ kvmppc_inject_interrupt(vcpu, vec, 0);
return deliver;
}
--
1.7.5.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 12/12] kvm/powerpc: Allow book3s_hv guests to use SMT processor modes
This lifts the restriction that book3s_hv guests can only run one hardware thread per core, and allows them to use up to 4 threads per core on POWER7. The host still has to run single-threaded. This capability is advertised to qemu through a new KVM_CAP_PPC_SMT capability. The return value of the ioctl querying this capability is the number of vcpus per virtual CPU core (vcore), currently 4. To use this, the host kernel should be booted with all threads active, and then all the secondary threads should be offlined. This will put the secondary threads into nap mode. KVM will then wake them from nap mode and use them for running guest code (while they are still offline). To wake the secondary threads, we send them an IPI using a new xics_wake_cpu() function, implemented in arch/powerpc/sysdev/xics/icp-native.c. In other words, at this stage we assume that the platform has a XICS interrupt controller and we are using icp-native.c to drive it. Since the woken thread will need to acknowledge and clear the IPI, we also export the base physical address of the XICS registers using kvmppc_set_xics_phys() for use in the low-level KVM book3s code. When a vcpu is created, it is assigned to a virtual CPU core. The vcore number is obtained by dividing the vcpu number by 4, since we assume at most 4 threads per core. Thus, if qemu wishes to run the guest in single-threaded mode, it should make all vcpu numbers be multiples of 4. We distinguish three states of a vcpu: runnable (i.e., ready to execute the guest), blocked (that is, idle), and busy in host. We currently implement a policy that the vcore can run only when all its threads are runnable or blocked. This way, if a vcpu needs to execute elsewhere in the kernel or in qemu, it can do so without being starved of CPU by the other vcpus. When a vcore starts to run, it executes in the context of one of the vcpu threads. The other vcpu threads all go to sleep and stay asleep until something happens requiring the vcpu thread to return to qemu, or to wake up to run the vcore (this can happen when another vcpu thread goes from busy in host state to blocked). It can happen that a vcpu goes from blocked to runnable state (e.g. because of an interrupt), and the vcore it belongs to is already running. In that case it can start to run immediately as long as the none of the vcpus in the vcore have started to exit the guest. We send the next free thread in the vcore an IPI to get it to start to execute the guest. It synchronizes with the other threads via the vcore-entry_exit_count field to make sure that it doesn't go into the guest if the other vcpus are exiting by the time that it is ready to actually enter the guest. Note that there is no fixed relationship between the hardware thread number and the vcpu number. Hardware threads are assigned to vcpus as they become runnable, so we will always use the lower-numbered hardware threads in preference to higher-numbered threads if not all the vcpus in the vcore are runnable, regardless of which vcpus are runnable. Signed-off-by: Paul Mackerras pau...@samba.org --- Documentation/virtual/kvm/api.txt | 13 ++ arch/powerpc/include/asm/kvm.h|1 + arch/powerpc/include/asm/kvm_book3s_asm.h |2 + arch/powerpc/include/asm/kvm_host.h | 45 +- arch/powerpc/include/asm/kvm_ppc.h| 13 ++ arch/powerpc/kernel/asm-offsets.c |6 + arch/powerpc/kernel/exceptions-64s.S | 31 +++- arch/powerpc/kernel/idle_power7.S |2 - arch/powerpc/kvm/Kconfig |2 +- arch/powerpc/kvm/book3s_hv.c | 265 +++-- arch/powerpc/kvm/book3s_hv_rmhandlers.S | 168 ++- arch/powerpc/kvm/powerpc.c|3 + arch/powerpc/sysdev/xics/icp-native.c |7 + include/linux/kvm.h |1 + 14 files changed, 529 insertions(+), 30 deletions(-) diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index acf0fcd..e25f3da 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -180,6 +180,19 @@ KVM_CHECK_EXTENSION ioctl() to determine the value for max_vcpus at run-time. If the KVM_CAP_NR_VCPUS does not exist, you should assume that max_vcpus is 4 cpus max. +On powerpc using book3s_hv mode, the vcpus are mapped onto virtual +threads in one or more virtual CPU cores. (This is because the +hardware requires all the hardware threads in a CPU core to be in the +same partition.) The KVM_CAP_PPC_SMT capability indicates the number +of vcpus per virtual core (vcore). The vcore id is obtained by +dividing the vcpu id by the number of vcpus per vcore. The vcpus in a +given vcore will always be in the same physical core as each other +(though that might be a different physical core from time to time). +Userspace can control the threading (SMT) mode of the guest by its +allocation of vcpu ids. For example,
Re: [PATCH v2 0/12] Hypervisor-mode KVM on POWER7
On 31.05.2011, at 08:40, Paul Mackerras wrote: The following series of patches enable KVM to exploit the hardware hypervisor mode on 64-bit Power ISA Book3S machines. At present only POWER7 is supported, but it would be easy to add other processors. Running the KVM host in hypervisor mode means that the guest can use both supervisor mode and user mode. That means that the guest can execute supervisor-privilege instructions and access supervisor- privilege registers. In addition the hardware directs most exceptions to the guest. Thus we don't need to emulate any instructions in the host. Generally, the only times we need to exit the guest are when it does a hypercall or when an external interrupt or host timer (decrementer) interrupt occurs. The focus of this KVM implementation is to run guests that use the PAPR (Power Architecture Platform Requirements) paravirtualization interface, which is the interface supplied by PowerVM on IBM pSeries machines. Currently the pseries machine type in qemu is only supported by book3s_hv KVM, and book3s_hv KVM only supports the pseries machine type. That will hopefully change in future. These patches are against Linus' v3.0-rc1 tree. Thinking about the testability of this a bit more ... how much effort would it be to get this code running on a 970MP with SLOF? There should only be a few POWER7 specific pieces, right? Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 0/12] Hypervisor-mode KVM on POWER7
On Tue, May 31, 2011 at 12:40:31PM +0200, Alexander Graf wrote: Thinking about the testability of this a bit more ... how much effort would it be to get this code running on a 970MP with SLOF? There should only be a few POWER7 specific pieces, right? Do you have a 970MP that has a usable hypervisor mode, i.e. not an Apple machine? The 970s in Apple machines have the HV hard-wired to 1, which means they do have a hypervisor mode but it isn't any use. If you do have such a machine, then we would have to look at some details like the instruction sequence for the partition switch, and make sure we don't try to use SMT4 mode. Also, I believe we will have to flush the TLB on partition switches, since Power processors prior to POWER7 didn't tag the TLB entries with the partition ID. So it should be quite feasible if you have a non-Apple machine. I will check whether the 970MP machines that Terrasoft were distributing would be suitable. We have one of them in the lab. Regards, Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 0/12] Hypervisor-mode KVM on POWER7
On 31.05.2011, at 14:35, Paul Mackerras wrote: On Tue, May 31, 2011 at 12:40:31PM +0200, Alexander Graf wrote: Thinking about the testability of this a bit more ... how much effort would it be to get this code running on a 970MP with SLOF? There should only be a few POWER7 specific pieces, right? Do you have a 970MP that has a usable hypervisor mode, i.e. not an Apple machine? The 970s in Apple machines have the HV hard-wired to 1, which means they do have a hypervisor mode but it isn't any use. If you do have such a machine, then we would have to look at some details like the instruction sequence for the partition switch, and make sure we don't try to use SMT4 mode. Also, I believe we will have to flush the TLB on partition switches, since Power processors prior to POWER7 didn't tag the TLB entries with the partition ID. So it should be quite feasible if you have a non-Apple machine. I will check whether the 970MP machines that Terrasoft were distributing would be suitable. We have one of them in the lab. That's the one I was thinking of and yes, I have one available. That way I could test 99% of your code, you don't have to release hardware, and everyone's happy :). Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
PCI EDAC on MPC85xx
Hello,
Long time ago (around July of 2010), I've reported a problem of binding
pci error reporting driver to the hardware (See
http://thread.gmane.org/gmane.linux.kernel.edac/181). Grant Likely has
come with a patch to create platform devices (of_platform at that time),
for device_nodes which have compatible properties
(http://article.gmane.org/gmane.linux.ports.ppc.embedded/36981).
The patch was not applied at that time and the problem still arises at
3.0-rc1. Should the patch in question be applied, or is there any new
solution?
Current version of that patch which I have in my tree is attached
to this mail (no original signoff by Grant).
--
With best wishes
Dmitry
From 511ce78e6aeeb9562cff0f0bbc186419b53bc209 Mon Sep 17 00:00:00 2001
From: Grant Likely grant.lik...@secretlab.ca
Date: Thu, 22 Jul 2010 13:01:11 -0600
Subject: [PATCH] of/device: Register children with a compatible value in
of_platform_bus_probe()
Currently, of_platform_bus_probe() completely skips nodes which do not
explicitly match the 'matches' table passed in. Or, if the root node
matches, then it registers all the children unconditionally. However,
there are situations, such as registering devices from the root node,
when it is desirable to register child nodes, but only if they actually
represent devices. For example, the root node may contain both a local
bus and a PCI device, but it also contains the chosen, aliases and cpus
nodes which don't represent real devices.
This patch changes of_platform_bus_probe() to register all nodes at the
top level if they either match the matches table (the current behaviour),
or if they have a 'compatible' value (indicating it represents a device).
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
drivers/of/platform.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 63d3cb7..80f0682 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -269,7 +269,18 @@ int of_platform_bus_probe(struct device_node *root,
if (of_match_node(matches, root)) {
rc = of_platform_bus_create(root, matches, parent);
} else for_each_child_of_node(root, child) {
- if (!of_match_node(matches, child))
+
+ /* Register each child node if either:
+ * a) it has a 'compatible' value indicating they are a device, or
+ * b) it is specified by the 'matches' table (by name or device_type)
+ * If a node is specified in the matches table, then all its children
+ * also get registered.
+ */
+ const void *compat = of_get_property(child, compatible, NULL);
+ const struct of_device_id *match = of_match_node(matches, child);
+
+ /* Skip if node neither matches nor has a compatible property */
+ if (!compat !match)
continue;
rc = of_platform_bus_create(child, matches, parent);
if (rc)
--
1.7.4.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC][PATCH] Kexec support for PPC440x
Suzuki Poulose wrote: Index: powerpc/arch/powerpc/kernel/44x_kexec_mapping.S === --- /dev/null +++ powerpc/arch/powerpc/kernel/44x_kexec_mapping.S + * + */ +blnxtins/* Find our address */ +nxtins:mflrr5/* Make it accessible */ Please don't mix labels and instructions. +tlbsxr23,0,r5/* Find entry we are in */ using tabs instead of spaces would make it look nice. Please also separate the arguments of the instruction i.e. tlbsx r23, 0, r5 Index: powerpc/arch/powerpc/kernel/misc_32.S === --- powerpc.orig/arch/powerpc/kernel/misc_32.S +++ powerpc/arch/powerpc/kernel/misc_32.S @@ -736,6 +736,28 @@ relocate_new_kernel: mr r5, r31 lir0, 0 +#elif defined(CONFIG_44x) !defined(CONFIG_47x) + +mrr29, r3 +mrr30, r4 +mrr31, r5 + +#include 44x_kexec_mapping.S The way you setup the 1:1 mapping should be close to what you are doing on kernel entry. Isn't it possible to include the file here and in the entry code? Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ssb: pci: implement serdes workaround
On 05/31/2011 04:37 AM, Andreas Schwab wrote:
Rafał Miłeckizajec5-re5jqeeqqe8avxtiumw...@public.gmane.org writes:
+/**
+ * Workarounds.
+ **/
+
+static u8 ssb_pcicore_polarity_workaround(struct ssb_pcicore *pc)
+{
+ return (ssb_pcie_read(pc, 0x204) 0x10) ? 0xC0 : 0x80;
+}
+
+static void ssb_pcicore_serdes_workaround(struct ssb_pcicore *pc)
+{
+ const u8 serdes_pll_device = 0x1D;
+ const u8 serdes_rx_device = 0x1F;
+ u16 tmp;
+
+ ssb_pcie_mdio_write(pc, serdes_rx_device, 1 /* Control */,
+ ssb_pcicore_polarity_workaround(pc));
+ tmp = ssb_pcie_mdio_read(pc, serdes_pll_device, 1 /* Control */);
+ if (tmp 0x4000)
+ ssb_pcie_mdio_write(pc, serdes_pll_device, 1, tmp ~0x4000);
+}
b43-pci-bridge 0001:10:12.0: enabling device (0004 - 0006)
ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x0D, vendor 0x4243)
ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x09, vendor 0x4243)
ssb: Core 2 found: PCI (cc 0x804, rev 0x0C, vendor 0x4243)
ssb: Core 3 found: PCMCIA (cc 0x80D, rev 0x07, vendor 0x4243)
Machine check in kernel mode.
Caused by (from SRR1=149030): Transfer error ack signal
Oops: Machine check, sig: 7 [#1]
PowerMac
Modules linked in: crc_itu_t ssb(+) snd_aoa_soundbus sungem sungem_phy
NIP: c0013324 LR: f2143e84 CTR: c001331c
REGS: c2ca5b80 TRAP: 0200 Not tainted (3.0.0-rc1)
MSR: 00149030EE,ME,IR,DR CR: 22004422 XER: 2000
TASK = ef9cef90[285] 'modprobe' THREAD: c2ca4000
GPR00: c2d1f87c c2ca5c30 ef9cef90 2381 0134 0204 0080 c2ca5bc8
GPR08: 04773e80 c2d1f87c c001331c 1002833c f2141968 f214821c
GPR16: f21478b7 f2148250 f21478c0 f2147894 00100100 00200200 1310 c2d1fb2c
GPR24: f2147ee8 f2148204 c2d1f800 0134 c2d1f800
NIP [c0013324] ioread32+0x8/0x14
LR [f2143e84] ssb_pci_read32+0x4c/0x5c [ssb]
Call Trace:
[c2ca5c30] [c2d1f800] 0xc2d1f800 (unreliable)
[c2ca5c40] [f2146244] ssb_pcie_read+0x4c/0x54 [ssb]
[c2ca5c50] [f2146440] ssb_pcicore_serdes_workaround+0x1c/0x170 [ssb]
[c2ca5c70] [f2141c24] ssb_attach_queued_buses+0x94/0x288 [ssb]
[c2ca5cd0] [f2142078] ssb_bus_register+0xe4/0x160 [ssb]
[c2ca5cf0] [f2142134] ssb_bus_pcibus_register+0x40/0x80 [ssb]
[c2ca5d00] [f2144a60] ssb_pcihost_probe+0xd8/0x114 [ssb]
[c2ca5d30] [c018f6ac] local_pci_probe+0x28/0x38
[c2ca5d40] [c0190690] pci_device_probe+0x68/0x94
[c2ca5d70] [c02bc8a4] driver_probe_device+0xc8/0x170
[c2ca5d90] [c02bc9bc] __driver_attach+0x70/0x98
[c2ca5db0] [c02bb9ec] bus_for_each_dev+0x60/0x90
[c2ca5de0] [c02bc538] driver_attach+0x24/0x34
[c2ca5df0] [c02bc11c] bus_add_driver+0xbc/0x23c
[c2ca5e10] [c02bcfc8] driver_register+0xb8/0x144
[c2ca5e30] [c01908c8] __pci_register_driver+0x4c/0xc8
[c2ca5e50] [f214486c] ssb_pcihost_register+0x50/0x60 [ssb]
[c2ca5e60] [f214c094] b43_pci_ssb_bridge_init+0x18/0xbc [ssb]
[c2ca5e70] [f214c05c] ssb_modinit+0x5c/0x7c [ssb]
[c2ca5e80] [c00049d8] do_one_initcall+0xe0/0x1c0
[c2ca5eb0] [c005f7b0] sys_init_module+0x164c/0x1850
[c2ca5f40] [c0010cd8] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0xff0b714
LR = 0x100050f0
Instruction dump:
0c03 4c00012c 5463043e 4e800020 7c0004ac a063 0c03 4c00012c
5463043e 4e800020 7c0004ac 7c601c2c0c03 4c00012c 4e800020 7c0004ac
---[ end trace 9824f03a7724930b ]---
We get a PPC machine check if we try to read a non-existent register, whereas
x86 returns all 1's on reads.
Obviously, this section needs to be conditionalized depending on revision info.
From the traceback, it must be the serdes_pll_device read that failed. The
specs say that should be a valid register for PCIe and PCI core rev 3 - 5. As
the PCI core in this device is 0xc, should we be in this routine? See
http://bcm-v4.sipsolutions.net/PCI-E.
Larry
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Using the BDI3k with the P4040
Hi, Apologies if this is the wrong forum for this message but I figured it was a good place to start. We have a new P4040 based board and are having lots of fun trying to get our BDI3k to work with it. The BDI isn't able to get control/halt the processor. I can go into more details if anybody is really interested but I was mainly interested if anybody had tried this combo before and if they knew of any gotcha's, example BDI configs etc. At the moment suspecting HW issue around the reset but of course the HW team would like us to check that we're not doing dumb things from the SW/BDI side of things too. Thanks in advance Mark Pearson ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ssb: pci: implement serdes workaround
Larry Finger larry.fin...@lwfinger.net writes: From the traceback, it must be the serdes_pll_device read that failed. Why not ssb_pcicore_polarity_workaround (note r4 == 0x134)? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Mapping an executable page
On Fri, May 27, 2011 at 8:25 AM, Thomas De Schampheleire patrickdepinguin+linux...@gmail.com wrote: Although I realize that what I need to achieve is unconventional, what is the correct way of mapping a certain address range into memory, and be able to execute from it? Can you look at using mpic_reset_core in arch/powerpc/sysdev/mpic.c? kexec on 85xx uses this to reset other cores the the hold off spin loop. -M ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ssb: pci: implement serdes workaround
On 05/31/2011 10:54 AM, Andreas Schwab wrote: Larry Fingerlarry.fin...@lwfinger.net writes: From the traceback, it must be the serdes_pll_device read that failed. Why not ssb_pcicore_polarity_workaround (note r4 == 0x134)? Mainly because the last two steps in the traceback are [c2ca5c40] [f2146244] ssb_pcie_read+0x4c/0x54 [ssb] [c2ca5c50] [f2146440] ssb_pcicore_serdes_workaround+0x1c/0x170 [ssb] Larry ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ssb: pci: implement serdes workaround
Larry Finger larry.fin...@lwfinger.net writes: On 05/31/2011 10:54 AM, Andreas Schwab wrote: Larry Fingerlarry.fin...@lwfinger.net writes: From the traceback, it must be the serdes_pll_device read that failed. Why not ssb_pcicore_polarity_workaround (note r4 == 0x134)? Mainly because the last two steps in the traceback are [c2ca5c40] [f2146244] ssb_pcie_read+0x4c/0x54 [ssb] [c2ca5c50] [f2146440] ssb_pcicore_serdes_workaround+0x1c/0x170 [ssb] Which exactly is what ssb_pcicore_polarity_workaround is doing. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ssb: pci: implement serdes workaround
Andreas Schwab sch...@linux-m68k.org writes: Larry Finger larry.fin...@lwfinger.net writes: On 05/31/2011 10:54 AM, Andreas Schwab wrote: Larry Fingerlarry.fin...@lwfinger.net writes: From the traceback, it must be the serdes_pll_device read that failed. Why not ssb_pcicore_polarity_workaround (note r4 == 0x134)? Mainly because the last two steps in the traceback are [c2ca5c40] [f2146244] ssb_pcie_read+0x4c/0x54 [ssb] [c2ca5c50] [f2146440] ssb_pcicore_serdes_workaround+0x1c/0x170 [ssb] Which exactly is what ssb_pcicore_polarity_workaround is doing. 022c ssb_pcicore_serdes_workaround: 22c: 94 21 ff e0 stwur1,-32(r1) 230: 7c 08 02 a6 mflrr0 234: 38 80 02 04 li r4,516 238: 90 01 00 24 stw r0,36(r1) 23c: bf a1 00 14 stmwr29,20(r1) 240: 7c 7f 1b 78 mr r31,r3 244: 4b ff fd bd bl 0 ssb_pcie_read Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PCI EDAC on MPC85xx
On May 31, 2011, at 8:17 AM, Dmitry Eremin-Solenikov wrote: Hello, Long time ago (around July of 2010), I've reported a problem of binding pci error reporting driver to the hardware (See http://thread.gmane.org/gmane.linux.kernel.edac/181). Grant Likely has come with a patch to create platform devices (of_platform at that time), for device_nodes which have compatible properties (http://article.gmane.org/gmane.linux.ports.ppc.embedded/36981). The patch was not applied at that time and the problem still arises at 3.0-rc1. Should the patch in question be applied, or is there any new solution? Current version of that patch which I have in my tree is attached to this mail (no original signoff by Grant). -- With best wishes Dmitry 0001-of-device-Register-children-with-a-compatible-value-.patch I think the desired solution here was to create a new node in the fsl_pci code that the edac code would bind against. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PCI EDAC on MPC85xx
On Tue, May 31, 2011 at 7:17 AM, Dmitry Eremin-Solenikov dbarysh...@gmail.com wrote: Hello, Long time ago (around July of 2010), I've reported a problem of binding pci error reporting driver to the hardware (See http://thread.gmane.org/gmane.linux.kernel.edac/181). Grant Likely has come with a patch to create platform devices (of_platform at that time), for device_nodes which have compatible properties (http://article.gmane.org/gmane.linux.ports.ppc.embedded/36981). The patch was not applied at that time and the problem still arises at 3.0-rc1. Should the patch in question be applied, or is there any new solution? Current version of that patch which I have in my tree is attached to this mail (no original signoff by Grant). Hi Dmitry, I've since looked at the problem more, and I've been working on refactoring both of_platform_bus_probe(), and creating a new function, of_platform_populate(), which implements the symantics that I think are needed for your use case. The work isn't done yet, but it has gone out for at least one round of review, and I hope to get it into the 3.1 merge window. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 0/2] powerpc: define and implement MPIC message register support
This patch set defines a binding for FSL MPIC message registers and implements an API for accessing those message registers. Testing was done on a MPC8572DS in an Linux-Linux AMP setup using OpenMCAPI (www.openmcapi.org) to communicate between OS instances. The message register API is used by the OpenMCAPI shared memory driver to send notifications between cores. * v3 - Clarified a point in the binding concerning the length of the 'interrupts' property. Pointed out by Scott Wood. * v2 - Incorporate feedback from Scott Wood * Make binding less implementation specific. * Add 'mpic-' prefix to message register node properties and aliases. * Remove 'interrupt-parent' from binding. * Fixed some example bugs with receive masks. Signed-off-by: Meador Inge meador_i...@mentor.com Cc: Hollis Blanchard hollis_blanch...@mentor.com Meador Inge (2): powerpc: document the FSL MPIC message register binding powerpc: add support for MPIC message register API .../devicetree/bindings/powerpc/fsl/mpic-msgr.txt | 62 + arch/powerpc/include/asm/mpic_msgr.h | 35 +++ arch/powerpc/platforms/Kconfig |8 + arch/powerpc/sysdev/Makefile |3 +- arch/powerpc/sysdev/mpic_msgr.c| 279 5 files changed, 386 insertions(+), 1 deletions(-) create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt create mode 100644 arch/powerpc/include/asm/mpic_msgr.h create mode 100644 arch/powerpc/sysdev/mpic_msgr.c ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 1/2] powerpc: document the FSL MPIC message register binding
This binding documents how the message register blocks found in some FSL
MPIC implementations shall be represented in a device tree.
Signed-off-by: Meador Inge meador_i...@mentor.com
Cc: Hollis Blanchard hollis_blanch...@mentor.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Scott Wood scottw...@freescale.com
---
.../devicetree/bindings/powerpc/fsl/mpic-msgr.txt | 62
1 files changed, 62 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
b/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
new file mode 100644
index 000..e1c19b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt
@@ -0,0 +1,62 @@
+* FSL MPIC Message Registers
+
+This binding specifies what properties must be available in the device tree
+representation of the message register blocks found in some FSL MPIC
+implementations.
+
+Required properties:
+
+- compatible: Specifies the compatibility list for the message register
+ block. The type shall be string and the value shall be of the form
+ fsl,mpic-vversion-msgr, where version is the version number of
+ the MPIC containing the message registers.
+
+- reg: Specifies the base physical address(s) and size(s) of the
+ message register block's addressable register space. The type shall be
+ prop-encoded-array.
+
+- interrupts: Specifies a list of interrupt source and level-sense pairs.
+ The type shall be prop-encoded-array. The length shall be equal to
+ the number of registers that are available for receiving interrupts.
+
+Optional properties:
+
+- mpic-msgr-receive-mask: Specifies what registers in the containing block
+ are allowed to receive interrupts. The value is a bit mask where a set
+ bit at bit 'n' indicates that message register 'n' can receive
interrupts.
+ The type shall be prop-encoded-array. If not present, then all of
+ the message registers in the block are available.
+
+Aliases:
+
+An alias should be created for every message register block. They are not
+required, though. However, a particular implementation of this binding
+may require aliases to be present. Aliases are of the form
+'mpic-msgr-blockn', where n is an integer specifying the block's
number.
+Numbers shall start at 0.
+
+Example:
+
+ aliases {
+ mpic-msgr-block0 = mpic_msgr_block0;
+ mpic-msgr-block1 = mpic_msgr_block1;
+ };
+
+ mpic_msgr_block0: mpic-msgr-block@41400 {
+ compatible = fsl,mpic-v3.1-msgr;
+ reg = 0x41400 0x200;
+ // Message registers 0 and 2 in this block can receive
interrupts on
+ // sources 0xb0 and 0xb2, respectively.
+ interrupts = 0xb0 2 0xb2 2;
+ mpic-msgr-receive-mask = 0x5;
+ };
+
+ mpic_msgr_block1: mpic-msgr-block@42400 {
+ compatible = fsl,mpic-v3.1-msgr;
+ reg = 0x42400 0x200;
+ // Message registers 0 and 2 in this block can receive
interrupts on
+ // sources 0xb4 and 0xb6, respectively.
+ interrupts = 0xb4 2 0xb6 2;
+ mpic-msgr-receive-mask = 0x5;
+ };
+
--
1.7.0.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 2/2] powerpc: add support for MPIC message register API
Some MPIC implementations contain one or more blocks of message registers
that are used to send messages between cores via IPIs. A simple API has
been added to access (get/put, read, write, etc ...) these message registers.
The available message registers are initially discovered via nodes in the
device tree. A separate commit contains a binding for the message register
nodes.
Signed-off-by: Meador Inge meador_i...@mentor.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Hollis Blanchard hollis_blanch...@mentor.com
---
arch/powerpc/include/asm/mpic_msgr.h | 35 +
arch/powerpc/platforms/Kconfig |8 +
arch/powerpc/sysdev/Makefile |3 +-
arch/powerpc/sysdev/mpic_msgr.c | 279 ++
4 files changed, 324 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/include/asm/mpic_msgr.h
create mode 100644 arch/powerpc/sysdev/mpic_msgr.c
diff --git a/arch/powerpc/include/asm/mpic_msgr.h
b/arch/powerpc/include/asm/mpic_msgr.h
new file mode 100644
index 000..370dcb4
--- /dev/null
+++ b/arch/powerpc/include/asm/mpic_msgr.h
@@ -0,0 +1,35 @@
+/*
+ * Copyright 2011-2012, Meador Inge, Mentor Graphics Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2 of the
+ * License.
+ *
+ */
+
+#ifndef _ASM_MPIC_MSGR_H
+#define _ASM_MPIC_MSGR_H
+
+#include linux/types.h
+
+struct mpic_msgr {
+ u32 __iomem *addr;
+ u32 __iomem *mer;
+ u32 __iomem *msr;
+ int irq;
+ atomic_t in_use;
+ int num;
+};
+
+extern struct mpic_msgr* mpic_msgr_get(unsigned int reg_num);
+extern void mpic_msgr_put(struct mpic_msgr* msgr);
+extern void mpic_msgr_enable(struct mpic_msgr *msgr);
+extern void mpic_msgr_disable(struct mpic_msgr *msgr);
+extern void mpic_msgr_write(struct mpic_msgr *msgr, u32 message);
+extern u32 mpic_msgr_read(struct mpic_msgr *msgr);
+extern void mpic_msgr_clear(struct mpic_msgr *msgr);
+extern void mpic_msgr_set_destination(struct mpic_msgr *msgr, u32 cpu_num);
+extern int mpic_msgr_get_irq(struct mpic_msgr *msgr);
+
+#endif
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index f7b0772..4d65593 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -78,6 +78,14 @@ config MPIC_WEIRD
bool
default n
+config MPIC_MSGR
+ bool MPIC message register support
+ depends on MPIC
+ default n
+ help
+ Enables support for the MPIC message registers. These
+ registers are used for inter-processor communication.
+
config PPC_I8259
bool
default n
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 1e0c933..6d40185 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -3,7 +3,8 @@ subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror
ccflags-$(CONFIG_PPC64):= -mno-minimal-toc
mpic-msi-obj-$(CONFIG_PCI_MSI) += mpic_msi.o mpic_u3msi.o mpic_pasemi_msi.o
-obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y)
+mpic-msgr-obj-$(CONFIG_MPIC_MSGR) += mpic_msgr.o
+obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y) $(mpic-msgr-obj-y)
fsl-msi-obj-$(CONFIG_PCI_MSI) += fsl_msi.o
obj-$(CONFIG_PPC_MSI_BITMAP) += msi_bitmap.o
diff --git a/arch/powerpc/sysdev/mpic_msgr.c b/arch/powerpc/sysdev/mpic_msgr.c
new file mode 100644
index 000..bfa0612
--- /dev/null
+++ b/arch/powerpc/sysdev/mpic_msgr.c
@@ -0,0 +1,279 @@
+/*
+ * Copyright 2011-2012, Meador Inge, Mentor Graphics Corporation.
+ *
+ * Some ideas based on un-pushed work done by Vivek Mahajan, Jason Jin, and
+ * Mingkai Hu from Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2 of the
+ * License.
+ *
+ */
+
+#include linux/list.h
+#include linux/of_platform.h
+#include linux/errno.h
+#include asm/prom.h
+#include asm/hw_irq.h
+#include asm/ppc-pci.h
+#include asm/mpic_msgr.h
+
+#define MPIC_MSGR_REGISTERS_PER_BLOCK 4
+#define MSGR_INUSE 0
+#define MSGR_FREE 1
+
+/* Internal structure used *only* for IO mapping register blocks. */
+struct mpic_msgr_block {
+ struct msgr {
+ u32 msgr;
+ u8 res[12];
+ } msgrs[MPIC_MSGR_REGISTERS_PER_BLOCK];
+ u8 res0[192];
+ u32 mer;
+ u8 res1[12];
+ u32 msr;
+};
+
+static struct mpic_msgr **mpic_msgrs = 0;
+static unsigned int mpic_msgr_count = 0;
+
+struct mpic_msgr* mpic_msgr_get(unsigned int reg_num)
+{
+ struct mpic_msgr* msgr;
+
+ if (reg_num = mpic_msgr_count)
+ return ERR_PTR(-ENODEV);
+
+ msgr = mpic_msgrs[reg_num];
+
+ if (atomic_cmpxchg(msgr-in_use, MSGR_FREE, MSGR_INUSE) == MSGR_FREE)
+
Re: [PATCH v2 1/2] powerpc: document the FSL MPIC message register binding
On 05/26/2011 03:06 PM, Scott Wood wrote: +- interrupts: Specifies a list of interrupt source and level-sense pairs. + The type shall be prop-encoded-array. The length shall be equal to + the number of bits set in the 'msg-receive-mask' property value. Oh, just noticed -- mismatch between msg-receive-mask here... + +Optional properties: + +- mpic-msgr-receive-mask: Specifies what registers in the containing block + are allowed to receive interrupts. The value is a bit mask where a set + bit at bit 'n' indicates that message register 'n' can receive interrupts. + The type shall be prop-encoded-array. If not present, then all of + the message registers in the block are available. ...and mpic-msgr-receive-mask here. Might want to just say equal to the number of registers that are available for receiving interrupts, to more clearly apply to the case where mpic-msgr-receive-mask is missing. Thanks; fixed. -- Meador Inge CodeSourcery / Mentor Embedded http://www.mentor.com/embedded-software ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/2] powerpc: document the FSL MPIC message register binding
On Tue, 31 May 2011 14:19:02 -0500 Meador Inge meador_i...@mentor.com wrote: This binding documents how the message register blocks found in some FSL MPIC implementations shall be represented in a device tree. Signed-off-by: Meador Inge meador_i...@mentor.com Cc: Hollis Blanchard hollis_blanch...@mentor.com Cc: Grant Likely grant.lik...@secretlab.ca Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Scott Wood scottw...@freescale.com --- .../devicetree/bindings/powerpc/fsl/mpic-msgr.txt | 62 1 files changed, 62 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt ACK -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PCI EDAC on MPC85xx
On 5/31/11, Kumar Gala ga...@kernel.crashing.org wrote: On May 31, 2011, at 8:17 AM, Dmitry Eremin-Solenikov wrote: Hello, Long time ago (around July of 2010), I've reported a problem of binding pci error reporting driver to the hardware (See http://thread.gmane.org/gmane.linux.kernel.edac/181). Grant Likely has come with a patch to create platform devices (of_platform at that time), for device_nodes which have compatible properties (http://article.gmane.org/gmane.linux.ports.ppc.embedded/36981). The patch was not applied at that time and the problem still arises at 3.0-rc1. Should the patch in question be applied, or is there any new solution? Current version of that patch which I have in my tree is attached to this mail (no original signoff by Grant). -- With best wishes Dmitry 0001-of-device-Register-children-with-a-compatible-value-.patch I think the desired solution here was to create a new node in the fsl_pci code that the edac code would bind against. Sorry, got mistaken then by Grant´s patch. Will provide an update on this topic soon. -- With best wishes Dmitry ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 0/12] Hypervisor-mode KVM on POWER7
On May 31, 2011, at 8:50 AM, Alexander Graf wrote: On 31.05.2011, at 14:35, Paul Mackerras wrote: On Tue, May 31, 2011 at 12:40:31PM +0200, Alexander Graf wrote: Thinking about the testability of this a bit more ... how much effort would it be to get this code running on a 970MP with SLOF? There should only be a few POWER7 specific pieces, right? Do you have a 970MP that has a usable hypervisor mode, i.e. not an Apple machine? The 970s in Apple machines have the HV hard-wired to 1, which means they do have a hypervisor mode but it isn't any use. If you do have such a machine, then we would have to look at some details like the instruction sequence for the partition switch, and make sure we don't try to use SMT4 mode. Also, I believe we will have to flush the TLB on partition switches, since Power processors prior to POWER7 didn't tag the TLB entries with the partition ID. So it should be quite feasible if you have a non-Apple machine. I will check whether the 970MP machines that Terrasoft were distributing would be suitable. We have one of them in the lab. That's the one I was thinking of and yes, I have one available. That way I could test 99% of your code, you don't have to release hardware, and everyone's happy :). Be aware that on 970s (off the top of my head): - did not have the LPCR architected so you'll have to access individual HID registers. - old style RMOR is supported, not VRMA - no MEDiated interrupt -jx Alex -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 10/13] kvm/powerpc: Add support for Book3S processors in hypervisor mode
Sure, but that shouldn't happen with HDEC during the odd 50 instructions that it takes to enter the guest :) It's more like 500 insns, including some ptesync, so lots of cycles too. I don't think its actually that bad. There's a loop of 128 iterations of 3 insns. I'm not saying it is actually bad, just that that 50 is slightly off ;-) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
3.0-rc1: powerpc hangs at Kernel virtual memory layout
Hi, trying to boot 3.0-rc1 on powerpc32 only progresses until: Kernel virtual memory layout: * 0xfffcf000..0xf000 : fixmap And then the system hangs, does not respond to keyboard (sysrq does not seem to work on this PowerBook G4). But after a while the system reboots itself, so I guess the machine panicked but did not print anything on the screen. Full messages (picture), config (working) dmesg: http://nerdbynature.de/bits/3.0-rc1/ I'm currently trying to bisect this, so far I have: -- git bisect start # good: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux 2.6.39 git bisect good 61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf # bad: [55922c9d1b84b89cb946c777fddccb3247e7df2c] Linux 3.0-rc1 git bisect bad 55922c9d1b84b89cb946c777fddccb3247e7df2c # bad: [c44dead70a841d90ddc01968012f323c33217c9e] Merge branch 'usb-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6 git bisect bad c44dead70a841d90ddc01968012f323c33217c9e # bad: [d93515611bbc70c2fe4db232e5feb448ed8e4cc9] macvlan: fix panic if lowerdev in a bond git bisect bad d93515611bbc70c2fe4db232e5feb448ed8e4cc9 -- Any ideas? Thanks, Christian. -- BOFH excuse #263: It's stuck in the Web. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 3.0-rc1: powerpc hangs at Kernel virtual memory layout
On Tue, 2011-05-31 at 16:50 -0700, Christian Kujau wrote: Hi, trying to boot 3.0-rc1 on powerpc32 only progresses until: Kernel virtual memory layout: * 0xfffcf000..0xf000 : fixmap And then the system hangs, does not respond to keyboard (sysrq does not seem to work on this PowerBook G4). But after a while the system reboots itself, so I guess the machine panicked but did not print anything on the screen. Full messages (picture), config (working) dmesg: http://nerdbynature.de/bits/3.0-rc1/ I'm currently trying to bisect this, so far I have: Hrm, I had it working on a pair of powerbooks yesterday. Can you try something like udbg-immortal on your kernel command line to see if that makes a difference in the output ? Cheers, Ben. -- git bisect start # good: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux 2.6.39 git bisect good 61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf # bad: [55922c9d1b84b89cb946c777fddccb3247e7df2c] Linux 3.0-rc1 git bisect bad 55922c9d1b84b89cb946c777fddccb3247e7df2c # bad: [c44dead70a841d90ddc01968012f323c33217c9e] Merge branch 'usb-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6 git bisect bad c44dead70a841d90ddc01968012f323c33217c9e # bad: [d93515611bbc70c2fe4db232e5feb448ed8e4cc9] macvlan: fix panic if lowerdev in a bond git bisect bad d93515611bbc70c2fe4db232e5feb448ed8e4cc9 -- Any ideas? Thanks, Christian. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 3.0-rc1: powerpc hangs at Kernel virtual memory layout
On Wed, 1 Jun 2011 at 10:25, Benjamin Herrenschmidt wrote: Hrm, I had it working on a pair of powerbooks yesterday. Can you try something like udbg-immortal on your kernel command line to see if that makes a difference in the output ? I'll try in a minute. In the meantime, git bisect behaves kinda weird, I don't know what went wrong here: $ git bisect start $ git bisect good # Linux 2.6.39 $ git bisect bad v3.0-rc1 # Linux 3.0-rc1 $ git bisect bad # c44dead70a... $ git bisect bad # d93515611b.. ...yet the ./Makefile shows[0] that I'm already way behind: 2.6.39-rc2. Maybe git bisect got confused with that whole 2.6.x - 3.0 renaming? Christian. [0] http://nerdbynature.de/bits/3.0-rc1/ -- BOFH excuse #383: Your processor has taken a ride to Heaven's Gate on the UFO behind Hale-Bopp's comet. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 3.0-rc1: powerpc hangs at Kernel virtual memory layout
On Tue, 31 May 2011 at 17:48, Christian Kujau wrote: On Wed, 1 Jun 2011 at 10:25, Benjamin Herrenschmidt wrote: Hrm, I had it working on a pair of powerbooks yesterday. Can you try something like udbg-immortal on your kernel command line to see if that makes a difference in the output ? I'll try in a minute. Wow, it really did make a difference: http://nerdbynature.de/bits/3.0-rc1/ * linux-3.0_powerpc_2.jpg * linux-3.0_powerpc_2.mp4 (only a few(!) seconds long, best to view with the slider in VLC oder Quicktime, to get at least a grasp what lead to linux-3.0_powerpc_2.jpg) Thanks, Christian. -- BOFH excuse #45: virus attack, luser responsible ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] document udbg-immortal
Back in 2006 the udbg-immortal kernel option has been introduced: commit 3b5e905ee3bd23e9311951890aba57a0dbc81ca4 Author: Benjamin Herrenschmidt b...@au1.ibm.com Date: Wed Jun 7 12:06:20 2006 +1000 [PATCH] powerpc: Add udbg-immortal kernel option ...but I could not find it documented anywhere in the sources. This patch adds it to Documentation/kernel-parameters.txt. Signed-off-by: Christian Kujau li...@nerdbynature.de diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index cc85a92..5d0df23 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2520,6 +2520,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. port#,js1,js2,js3,js4,js5,js6,js7 See also Documentation/input/joystick-parport.txt + udbg-immortal [PPC] When debugging early kernel crashes that + happen after console_init() and before a proper + console driver takes over, this boot options might + help seeing what's going on. + uhash_entries= [KNL,NET] Set number of hash buckets for UDP/UDP-Lite connections Thanks, Christian. -- BOFH excuse #45: virus attack, luser responsible ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 3.0-rc1: powerpc hangs at Kernel virtual memory layout
(Cc'in Linus) On Tue, 31 May 2011 at 17:48, Christian Kujau wrote: In the meantime, git bisect behaves kinda weird, I don't know what went wrong here: $ git bisect start $ git bisect good # Linux 2.6.39 $ git bisect bad v3.0-rc1 # Linux 3.0-rc1 $ git bisect bad # c44dead70a... $ git bisect bad # d93515611b.. ...yet the ./Makefile shows[0] that I'm already way behind: 2.6.39-rc2. Maybe git bisect got confused with that whole 2.6.x - 3.0 renaming? Hm, I tried again, from a clean v3.0-rc1 (git reset --hard), but after the 2nd git bad I'm at 2.6.39-rc2 again - while I /should/ be somwhere inbetween v2.6.39..v3.0-rc1, right? Help, please! Christian. [0] http://nerdbynature.de/bits/3.0-rc1/ -- BOFH excuse #54: Evil dogs hypnotised the night shift ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 11/13] powerpc: select HAVE_SECCOMP_FILTER and provide seccomp_execve
Facilitate the use of CONFIG_SECCOMP_FILTER by wrapping compatibility system call numbering for execve and selecting HAVE_SECCOMP_FILTER. Signed-off-by: Will Drewry w...@chromium.org --- arch/powerpc/Kconfig |1 + arch/powerpc/include/asm/seccomp.h |2 ++ 2 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 8f4d50b..0bd4574 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -137,6 +137,7 @@ config PPC select HAVE_HW_BREAKPOINT if PERF_EVENTS PPC_BOOK3S_64 select HAVE_GENERIC_HARDIRQS select HAVE_SPARSE_IRQ + select HAVE_SECCOMP_FILTER select IRQ_PER_CPU select GENERIC_IRQ_SHOW select GENERIC_IRQ_SHOW_LEVEL diff --git a/arch/powerpc/include/asm/seccomp.h b/arch/powerpc/include/asm/seccomp.h index 00c1d91..3cb9cc1 100644 --- a/arch/powerpc/include/asm/seccomp.h +++ b/arch/powerpc/include/asm/seccomp.h @@ -7,10 +7,12 @@ #define __NR_seccomp_write __NR_write #define __NR_seccomp_exit __NR_exit #define __NR_seccomp_sigreturn __NR_rt_sigreturn +#define __NR_seccomp_execve __NR_execve #define __NR_seccomp_read_32 __NR_read #define __NR_seccomp_write_32 __NR_write #define __NR_seccomp_exit_32 __NR_exit #define __NR_seccomp_sigreturn_32 __NR_sigreturn +#define __NR_seccomp_execve_32 __NR_execve #endif /* _ASM_POWERPC_SECCOMP_H */ -- 1.7.0.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 3.0-rc1: powerpc hangs at Kernel virtual memory layout
On Tue, 2011-05-31 at 20:02 -0700, Christian Kujau wrote: (Cc'in Linus) On Tue, 31 May 2011 at 17:48, Christian Kujau wrote: In the meantime, git bisect behaves kinda weird, I don't know what went wrong here: $ git bisect start $ git bisect good # Linux 2.6.39 $ git bisect bad v3.0-rc1 # Linux 3.0-rc1 $ git bisect bad # c44dead70a... $ git bisect bad # d93515611b.. ...yet the ./Makefile shows[0] that I'm already way behind: 2.6.39-rc2. Maybe git bisect got confused with that whole 2.6.x - 3.0 renaming? Hm, I tried again, from a clean v3.0-rc1 (git reset --hard), but after the 2nd git bad I'm at 2.6.39-rc2 again - while I /should/ be somwhere inbetween v2.6.39..v3.0-rc1, right? Kernel version is totally irrelevant when bisecting. You are not walking through a linear series of patches but a complex tree of merges which might have forked off different versions in the first place. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 0/1] ppc4xx: Fix PCIe scanning for the 460SX
The interesting question of course is whether that 460SX stuff is the same as what we're using internally :-) [marri] Sometimes open-source and internal releases may not be the same Because of open-source standards. Can we fix that ? [marri] Sure I will take a look at it. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 0/1] ppc4xx: Fix PCIe scanning for the 460SX
Not sure how I would know -- But with my eiger kit, I got a cd from amcc that had a patched 2.6.30 or something kernel in it to support the 460SX. The pci code was basically subverted by adding a port-link=1 at the very end of the link check to always force it to succeed. However this code never appeared in the public git repositories, so I am not sure how the 460SX functioned (if it ever did) since the link check that is in there now can't work on that SOC. [marri]I don't know what PCI-E devices you use. We use E1000 As a device for testing. Link-up was working before the submission. There were some changes happened afterwards to the common code Which seems to affected all 4xx devices. I will try latest code On our other SoCs. I took care of that in my patch. Basically it let the system go to gen-2 speeds and negotiate down. [marri] Great thx. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 0/12] Hypervisor-mode KVM on POWER7
On Tue, May 31, 2011 at 02:50:20PM +0200, Alexander Graf wrote: On 31.05.2011, at 14:35, Paul Mackerras wrote: On Tue, May 31, 2011 at 12:40:31PM +0200, Alexander Graf wrote: Thinking about the testability of this a bit more ... how much effort would it be to get this code running on a 970MP with SLOF? There should only be a few POWER7 specific pieces, right? Do you have a 970MP that has a usable hypervisor mode, i.e. not an Apple machine? The 970s in Apple machines have the HV hard-wired to 1, which means they do have a hypervisor mode but it isn't any use. If you do have such a machine, then we would have to look at some details like the instruction sequence for the partition switch, and make sure we don't try to use SMT4 mode. Also, I believe we will have to flush the TLB on partition switches, since Power processors prior to POWER7 didn't tag the TLB entries with the partition ID. So it should be quite feasible if you have a non-Apple machine. I will check whether the 970MP machines that Terrasoft were distributing would be suitable. We have one of them in the lab. That's the one I was thinking of and yes, I have one available. That way I could test 99% of your code, you don't have to release hardware, and everyone's happy :). I checked our YDL PowerStation and it does appear to have a usable hypervisor mode. :) As Jimi X pointed out, there are a few things that POWER7 has that 970 doesn't. In particular the lack of VRMA mode means that we will have to find 64MB of physically contiguous memory, aligned on a 64MB address boundary, for the real mode area (RMO) for the guest. 64MB is the smallest RMO size that the 970 supports; it also supports 128MB, 256MB, 1GB, 16GB and 256GB. I think we'll have to reserve some memory at boot. We may get away with bumping up CONFIG_FORCE_MAX_ZONEORDER, but relying on allocating a physically contiguous 64MB at runtime seems somewhat fragile. Also, we'll need some qemu changes since it won't be able to allocate the RMO itself. The other thing is that we have to flush the TLB on every partitions switch, plus make sure that we're not switching the partition ID while any other cpu in the same partition is doing a tlbie or tlbsync. Still, it should all be doable. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 10/13] kvm/powerpc: Add support for Book3S processors in hypervisor mode
On Wed, Jun 01, 2011 at 12:34:43AM +0200, Segher Boessenkool wrote: There's a loop of 128 iterations of 3 insns. I'm not saying it is actually bad, just that that 50 is slightly off ;-) That would be the TLB invalidation. On POWER7 we only need to do that if the virtual cpu last ran on a different physical cpu, or if this physical cpu last ran a different virtual cpu in the same partition. So hopefully we don't have to do it very often. The reason we have to do it in that case is to allow the optimization where we use tlbiel for TLB invalidations if the guest claims that the translation being invalidated was only ever used on this virtual cpu. That means that we have to guard against stale TLB entries left behind when a virtual cpu moves from one physical cpu to another. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Hooking up SM501 on TQM5200 (MPC5200) board via device tree?
We have a TQM5200 board, which has GPIO lines hooked up to an SM501.
I've managed to come up with the following patch to the tqm5200 device
tree, which manages to convince the sm501 driver to attach an sm501-fb:
--- a/arch/powerpc/boot/dts/tqm5200.dts 2009-11-23 03:13:27.0 -0800
+++ b/arch/powerpc/boot/dts/tqm5200.dts 2011-05-31 22:00:28.000580627 -0700
@@ -177,7 +177,8 @@
compatible = fsl,mpc5200-lpb,simple-bus;
#address-cells = 2;
#size-cells = 1;
- ranges = 0 0 0xfc00 0x0200;
+ ranges = 0 0 0xfc00 0x0200
+ 1 0 0xe000 0x0400;
flash@0,0 {
compatible = cfi-flash;
@@ -187,6 +188,13 @@
#size-cells = 1;
#address-cells = 1;
};
+
+ display@1,0 {
+ compatible = smi,sm501;
+ reg = 1 0x 0x0080
+ 1 0x03e0 0x0020;
+ interrupts = 1 1 3;
+ };
};
pci@fd00 {
However, this doesn't hook up the sm501-gpio bits. Reading the sm501
driver carefully, it looks like it only hooks up sm501-gpio if it has
platform_data available which sets some flags and other information.
So, if I understand correctly, hooking up sm501-gpio would require
adding functionality the driver to get the GPIO information from the
device tree in preference to the platform_data, if available, and fall
back to the platform_data for existing users?
What should the necessary device tree properties look like to replace
sm501_initdata?
- Josh Triplett
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 0/12] Hypervisor-mode KVM on POWER7
On Tue, May 31, 2011 at 5:35 AM, Paul Mackerras pau...@samba.org wrote: On Tue, May 31, 2011 at 12:40:31PM +0200, Alexander Graf wrote: Thinking about the testability of this a bit more ... how much effort would it be to get this code running on a 970MP with SLOF? There should only be a few POWER7 specific pieces, right? Do you have a 970MP that has a usable hypervisor mode, i.e. not an Apple machine? The 970s in Apple machines have the HV hard-wired to 1, which means they do have a hypervisor mode but it isn't any use. If you do have such a machine, then we would have to look at some details like the instruction sequence for the partition switch, and make sure we don't try to use SMT4 mode. Also, I believe we will have to flush the TLB on partition switches, since Power processors prior to POWER7 didn't tag the TLB entries with the partition ID. So it should be quite feasible if you have a non-Apple machine. I will check whether the 970MP machines that Terrasoft were distributing would be suitable. We have one of them in the lab. PA6T is closer to power7 than 970 when it comes to hypervisor features (i.e. VRMA, LPCR, mediated interrupts are all available there). I can try to find some old hardware if there's any interest from anyone to use it. Of course, there isn't much of a roadmap. But 970 isn't really going anywhere either. :) -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
