Re: linux-next: build failure after merge of the final tree
On Fri, Jul 06, 2012 at 01:01:37PM +1000, Stephen Rothwell wrote: solos-pci.c:(.text+0x1ff923c): relocation truncated to fit: R_PPC64_REL24 ^ I assume at this point, we are just too large. Yeah, but not in total. I didn't see any of these in the allyes kernel I built with our proof of concept hack to avoid ld -r. I think you'll find that these are all from ld -r output, as I assume no one in kernel land writes drivers or whatever with 33M of text in a single file. Branches in that monstrous section can't even reach the trampolines that ld inserts to extend branch reach. Did I mention that ld -r is a bad idea? One workaround might be to compile with -ffunction-sections. -- Alan Modra Australia Development Lab, IBM ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Qemu-ppc] [RFC PATCH 04/17] KVM: PPC64: booke: Add guest computation mode for irq delivery
On 06.07.2012, at 01:51, Scott Wood scottw...@freescale.com wrote: On 07/04/2012 08:40 AM, Alexander Graf wrote: On 25.06.2012, at 14:26, Mihai Caraman wrote: @@ -381,7 +386,8 @@ static int kvmppc_booke_irqprio_deliver(struct kvm_vcpu *vcpu, set_guest_esr(vcpu, vcpu-arch.queued_esr); if (update_dear == true) set_guest_dear(vcpu, vcpu-arch.queued_dear); -kvmppc_set_msr(vcpu, vcpu-arch.shared-msr msr_mask); +kvmppc_set_msr(vcpu, (vcpu-arch.shared-msr msr_mask) +| msr_cm); Please split this computation out into its own variable and apply the masking regardless. Something like ulong new_msr = vcpu-arch.shared-msr; if (vcpu-arch.epcr SPRN_EPCR_ICM) new_msr |= MSR_CM; new_msr = msr_mask; kvmppc_set_msr(vcpu, new_msr); This will fail to clear MSR[CM] in the odd but legal situation where you have MSR[CM] set but EPCR[ICM] unset. Ah. Good point. Then leave the msr_mask logic as before and only stretch it out into its own variable. Alex -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: put the gpr sabe/restore functions in their own section
This allows the linker to know that calls to them do not need to switch TOC and stop errors like the following when linking large configurations: powerpc64-linux-ld: drivers/built-in.o: In function `.gpiochip_is_requested': (.text+0x4): sibling call optimization to `_savegpr0_29' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_savegpr0_29' extern Signed-off-by: Stephen Rothwell s...@canb.auug.org.au --- arch/powerpc/lib/crtsavres.S |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/lib/crtsavres.S b/arch/powerpc/lib/crtsavres.S index 1c893f0..b2c68ce 100644 --- a/arch/powerpc/lib/crtsavres.S +++ b/arch/powerpc/lib/crtsavres.S @@ -41,12 +41,13 @@ #include asm/ppc_asm.h .file crtsavres.S - .section .text #ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE #ifndef CONFIG_PPC64 + .section .text + /* Routines for saving integer registers, called by the compiler. */ /* Called with r11 pointing to the stack header word of the caller of the */ /* function, just beyond the end of the integer save area. */ @@ -232,6 +233,8 @@ _GLOBAL(_rest32gpr_31_x) #else /* CONFIG_PPC64 */ + .section .text.save.restore,ax,@progbits + .globl _savegpr0_14 _savegpr0_14: std r14,-144(r1) -- 1.7.10.280.gaa39 -- Cheers, Stephen Rothwells...@canb.auug.org.au pgp0otnG8gtPN.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
ptrace and emulated mfspr/mtspr on DSCR
Hi!
I am trying to change DSCR's value of a specific process with pid=XXX. For
this, I attach by ptrace() to XXX, inject a piece of code which does
mfspr/mtspr, continue XXX and see how it is changing. So far so good.
The problem is with continue. The XXX process does not wake up until I press
a key (if XXX is waiting on something like scanf() or gets()) OR it exits from
sleep() if I change it to run sleep() in a loop.
Not sure if it matters but mfspr/mtspr are privileged instructions and are
emulated by the kernel.
How to wake XXX up?
#include sys/ptrace.h
#include sys/types.h
#include sys/wait.h
#include string.h
#include unistd.h
#include sys/user.h
#include stdio.h
#include stdlib.h
void getdata(pid_t child, long addr, void *str)
{
unsigned long *ptr = (unsigned long *) str;
ptr[0] = ptrace(PTRACE_PEEKDATA, child, addr, NULL);
}
void putdata(pid_t child, long addr, void *str)
{
unsigned long *ptr = (unsigned long *) str;
ptrace(PTRACE_POKEDATA, child, addr, ptr[0]);
}
int main(int argc, char *argv[])
{
pid_t traced_process;
struct pt_regs regs, backup_regs;
unsigned long dscr = -1;
/*.set_dscr:
* 7f d1 03 a6 mtspr 17,r30
7d 82 10 08 twger2,r2 - set breakpoint */
unsigned int insert_set[] = { 0x7fd103a6, 0x7d821008 };
/*.get_dscr:
7f d1 02 a6 mfspr r30,17
7d 82 10 08 twger2,r2 - set breakpoint */
unsigned int insert_get[] = { 0x7fd102a6, 0x7d821008 };
char backup[8];
int len = 8;
if((argc 2)||(sizeof(unsigned int)!=4)) {
printf(Usage: %s pid to be traced [dscr value]\n, argv[0],
argv[1]);
exit(1);
}
if (argc 2) {
dscr = atoi(argv[2]);
}
traced_process = atoi(argv[1]);
ptrace(PTRACE_ATTACH, traced_process, NULL, NULL);
wait(NULL);
printf(Attached to pid=%u\n, traced_process);
ptrace(PTRACE_GETREGS, traced_process, NULL, regs);
backup_regs = regs;
getdata(traced_process, regs.nip, backup);
if (dscr != -1) {
regs.gpr[30] = dscr;
putdata(traced_process, regs.nip, insert_set);
ptrace(PTRACE_SETREGS, traced_process, NULL, regs);
printf(Setting DSCR = %x to gpr0\n, regs.gpr[30]);
} else {
putdata(traced_process, regs.nip, insert_get);
printf(Reading DSCR\n);
}
printf(Continued pid=%u\n, traced_process);
ptrace(PTRACE_CONT, traced_process, NULL, SIGCONT);
printf(waiting...\n);
wait(NULL); // HERE IS THE PROBLEM
if (dscr == -1) {
printf(DSCR has been read\n);
ptrace(PTRACE_GETREGS, traced_process, NULL, regs);
printf(Reading DSCR from gpr30 = %x\n, regs.gpr[30]);
}
printf(The process stopped, Putting back the original instructions\n);
putdata(traced_process, backup_regs.nip, backup);
ptrace(PTRACE_SETREGS, traced_process, NULL, backup_regs);
printf(Letting it continue with original flow\n);
ptrace(PTRACE_DETACH, traced_process, NULL, NULL);
return 0;
}
--
Alexey
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH SLAB 1/2 v3] duplicate the cache name in SLUB's saved_alias list, SLAB, and SLOB
SLUB duplicates the cache name string passed into kmem_cache_create().
However if the cache could be merged to others during early boot, the
name pointer is saved in saved_alias list, and the string needs to be
kept valid before slab_sysfs_init() is finished. With this patch, the
name string (if kmalloced) could be kfreed after calling
kmem_cache_create().
Some more details:
kmem_cache_create() checks whether it is mergeable before creating one.
If not mergeable, the name is duplicated: n = kstrdup(name, GFP_KERNEL);
If it is mergeable, it calls sysfs_slab_alias(). If the sysfs is ready
(slab_state == SYSFS), then the name is duplicated (or dropped if no
SYSFS support) in sysfs_create_link() for use.
For the above cases, we could safely kfree the name string after calling
cache create.
However, during early boot, before sysfs is ready (slab_state SYSFS),
the sysfs_slab_alias() saves the pointer of name in the alias_list.
Those entries in the list are added to sysfs later in slab_sysfs_init()
to set up the sysfs stuff, and we need keep the name string passed in
valid until it finishes. By duplicating the name string here also, we
are able to safely kfree the name string after calling cache create.
v2: removed an unnecessary assignment in v1; some changes in change log,
added more details
v3: changed slab/slot to let them also duplicate the name string, so the
code is not slub-dependent, and in patch 2/2, we could call kfree()
after cache create without #ifdef slub.
for slab, the name of the sizes caches created before
slab_is_available() is not duplicated, and it is not checked in
kmem_cache_destroy(), as I think these caches won't be destroyed.
Signed-off-by: Li Zhong zh...@linux.vnet.ibm.com
---
mm/slab.c | 15 ++-
mm/slob.c | 17 ++---
mm/slub.c |7 ++-
3 files changed, 34 insertions(+), 5 deletions(-)
diff --git a/mm/slab.c b/mm/slab.c
index e901a36..87df7d1 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -2280,6 +2280,7 @@ kmem_cache_create (const char *name, size_t size,
size_t align,
size_t left_over, slab_size, ralign;
struct kmem_cache *cachep = NULL, *pc;
gfp_t gfp;
+ const char *lname;
/*
* Sanity checks... these are all serious usage bugs.
@@ -2291,6 +2292,13 @@ kmem_cache_create (const char *name, size_t size,
size_t align,
BUG();
}
+ if (slab_is_available()) {
+ lname = kstrdup(name, GFP_KERNEL);
+ if (!lname)
+ goto oops;
+ } else
+ lname = name;
+
/*
* We use cache_chain_mutex to ensure a consistent view of
* cpu_online_mask as well. Please see cpuup_callback
@@ -2526,7 +2534,7 @@ kmem_cache_create (const char *name, size_t size,
size_t align,
BUG_ON(ZERO_OR_NULL_PTR(cachep-slabp_cache));
}
cachep-ctor = ctor;
- cachep-name = name;
+ cachep-name = lname;
if (setup_cpu_cache(cachep, gfp)) {
__kmem_cache_destroy(cachep);
@@ -2550,6 +2558,9 @@ oops:
if (!cachep (flags SLAB_PANIC))
panic(kmem_cache_create(): failed to create slab `%s'\n,
name);
+ if (!cachep lname)
+ kfree(lname);
+
if (slab_is_available()) {
mutex_unlock(cache_chain_mutex);
put_online_cpus();
@@ -2752,6 +2763,8 @@ void kmem_cache_destroy(struct kmem_cache *cachep)
if (unlikely(cachep-flags SLAB_DESTROY_BY_RCU))
rcu_barrier();
+ /* sizes caches will not be destroyed? */
+ kfree(cachep-name);
__kmem_cache_destroy(cachep);
mutex_unlock(cache_chain_mutex);
put_online_cpus();
diff --git a/mm/slob.c b/mm/slob.c
index 8105be4..7bea3a3 100644
--- a/mm/slob.c
+++ b/mm/slob.c
@@ -569,13 +569,18 @@ struct kmem_cache {
struct kmem_cache *kmem_cache_create(const char *name, size_t size,
size_t align, unsigned long flags, void (*ctor)(void *))
{
- struct kmem_cache *c;
+ struct kmem_cache *c = NULL;
+ const char *lname;
+
+ lname = kstrdup(name, GFP_KERNEL);
+ if (!lname)
+ goto oops;
c = slob_alloc(sizeof(struct kmem_cache),
GFP_KERNEL, ARCH_KMALLOC_MINALIGN, -1);
if (c) {
- c-name = name;
+ c-name = lname;
c-size = size;
if (flags SLAB_DESTROY_BY_RCU) {
/* leave room for rcu footer at the end of object */
@@ -589,9 +594,14 @@ struct kmem_cache *kmem_cache_create(const char
*name, size_t size,
c-align = ARCH_SLAB_MINALIGN;
if (c-align align)
c-align = align;
- } else if (flags SLAB_PANIC)
+ }
+oops:
+ if (!c (flags SLAB_PANIC))
panic(Cannot create slab cache %s\n, name);
+ if (!c lname)
+
[PATCH powerpc 2/2 v3] kfree the cache name of pgtable cache
This patch tries to kfree the cache name of pgtables cache. It depends on patch 1/2 -- ([PATCH SLAB 1/2 v3] duplicate the cache name in SLUB's saved_alias list, SLAB, and SLOB) in this mail thread. For SLUB, as the pgtables cache might be mergeable to other caches. During early boot, the name string is saved in the save_alias list. In this case, the name could be safely kfreed after calling kmem_cache_create() with patch 1. For SLAB/SLOB, we need the changes in patch 1, which duplicates the name strings in cache create. v3: with patch 1/2 updated to make slab/slob consistent, #ifdef CONFIG_SLUB is no longer needed. Signed-off-by: Li Zhong zh...@linux.vnet.ibm.com --- arch/powerpc/mm/init_64.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c index 620b7ac..bc7f462 100644 --- a/arch/powerpc/mm/init_64.c +++ b/arch/powerpc/mm/init_64.c @@ -130,6 +130,7 @@ void pgtable_cache_add(unsigned shift, void (*ctor)(void *)) align = max_t(unsigned long, align, minalign); name = kasprintf(GFP_KERNEL, pgtable-2^%d, shift); new = kmem_cache_create(name, table_size, align, 0, ctor); + kfree(name); PGT_CACHE(shift) = new; pr_debug(Allocated pgtable cache for order %d\n, shift); -- 1.7.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ptrace and emulated mfspr/mtspr on DSCR
ha, forget it, it is all correct actually :)
On 06/07/12 17:30, Alexey Kardashevskiy wrote:
Hi!
I am trying to change DSCR's value of a specific process with pid=XXX. For
this, I attach by ptrace() to XXX, inject a piece of code which does
mfspr/mtspr, continue XXX and see how it is changing. So far so good.
The problem is with continue. The XXX process does not wake up until I
press a key (if XXX is waiting on something like scanf() or gets()) OR it
exits from sleep() if I change it to run sleep() in a loop.
Not sure if it matters but mfspr/mtspr are privileged instructions and are
emulated by the kernel.
How to wake XXX up?
#include sys/ptrace.h
#include sys/types.h
#include sys/wait.h
#include string.h
#include unistd.h
#include sys/user.h
#include stdio.h
#include stdlib.h
void getdata(pid_t child, long addr, void *str)
{
unsigned long *ptr = (unsigned long *) str;
ptr[0] = ptrace(PTRACE_PEEKDATA, child, addr, NULL);
}
void putdata(pid_t child, long addr, void *str)
{
unsigned long *ptr = (unsigned long *) str;
ptrace(PTRACE_POKEDATA, child, addr, ptr[0]);
}
int main(int argc, char *argv[])
{
pid_t traced_process;
struct pt_regs regs, backup_regs;
unsigned long dscr = -1;
/*.set_dscr:
* 7f d1 03 a6 mtspr 17,r30
7d 82 10 08 twger2,r2 - set breakpoint */
unsigned int insert_set[] = { 0x7fd103a6, 0x7d821008 };
/*.get_dscr:
7f d1 02 a6 mfspr r30,17
7d 82 10 08 twger2,r2 - set breakpoint */
unsigned int insert_get[] = { 0x7fd102a6, 0x7d821008 };
char backup[8];
int len = 8;
if((argc 2)||(sizeof(unsigned int)!=4)) {
printf(Usage: %s pid to be traced [dscr value]\n, argv[0],
argv[1]);
exit(1);
}
if (argc 2) {
dscr = atoi(argv[2]);
}
traced_process = atoi(argv[1]);
ptrace(PTRACE_ATTACH, traced_process, NULL, NULL);
wait(NULL);
printf(Attached to pid=%u\n, traced_process);
ptrace(PTRACE_GETREGS, traced_process, NULL, regs);
backup_regs = regs;
getdata(traced_process, regs.nip, backup);
if (dscr != -1) {
regs.gpr[30] = dscr;
putdata(traced_process, regs.nip, insert_set);
ptrace(PTRACE_SETREGS, traced_process, NULL, regs);
printf(Setting DSCR = %x to gpr0\n, regs.gpr[30]);
} else {
putdata(traced_process, regs.nip, insert_get);
printf(Reading DSCR\n);
}
printf(Continued pid=%u\n, traced_process);
ptrace(PTRACE_CONT, traced_process, NULL, SIGCONT);
printf(waiting...\n);
wait(NULL); // HERE IS THE PROBLEM
if (dscr == -1) {
printf(DSCR has been read\n);
ptrace(PTRACE_GETREGS, traced_process, NULL, regs);
printf(Reading DSCR from gpr30 = %x\n, regs.gpr[30]);
}
printf(The process stopped, Putting back the original instructions\n);
putdata(traced_process, backup_regs.nip, backup);
ptrace(PTRACE_SETREGS, traced_process, NULL, backup_regs);
printf(Letting it continue with original flow\n);
ptrace(PTRACE_DETACH, traced_process, NULL, NULL);
return 0;
}
--
Alexey
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 4/13] memory-hotplug : remove /sys/firmware/memmap/X sysfs
Hi Wen,
2012/07/04 19:01, Wen Congyang wrote:
At 07/04/2012 01:52 PM, Yasuaki Ishimatsu Wrote:
Hi Wen,
2012/07/04 14:08, Wen Congyang wrote:
At 07/04/2012 12:45 PM, Yasuaki Ishimatsu Wrote:
Hi Wen,
2012/07/03 15:35, Wen Congyang wrote:
At 07/03/2012 01:56 PM, Yasuaki Ishimatsu Wrote:
When (hot)adding memory into system, /sys/firmware/memmap/X/{end, start,
type}
sysfs files are created. But there is no code to remove these files. The
patch
implements the function to remove them.
Note : The code does not free firmware_map_entry since there is no way
to free
memory which is allocated by bootmem.
CC: David Rientjes rient...@google.com
CC: Jiang Liu liu...@gmail.com
CC: Len Brown len.br...@intel.com
CC: Benjamin Herrenschmidt b...@kernel.crashing.org
CC: Paul Mackerras pau...@samba.org
CC: Christoph Lameter c...@linux.com
Cc: Minchan Kim minchan@gmail.com
CC: Andrew Morton a...@linux-foundation.org
CC: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Signed-off-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
---
drivers/firmware/memmap.c| 70
+++
include/linux/firmware-map.h |6 +++
mm/memory_hotplug.c |6 +++
3 files changed, 81 insertions(+), 1 deletion(-)
Index: linux-3.5-rc4/mm/memory_hotplug.c
===
--- linux-3.5-rc4.orig/mm/memory_hotplug.c 2012-07-03
14:22:00.190240794 +0900
+++ linux-3.5-rc4/mm/memory_hotplug.c2012-07-03 14:22:03.549198802
+0900
@@ -661,7 +661,11 @@ EXPORT_SYMBOL_GPL(add_memory);
int remove_memory(int nid, u64 start, u64 size)
{
-return -EBUSY;
+lock_memory_hotplug();
+/* remove memmap entry */
+firmware_map_remove(start, start + size - 1, System RAM);
+unlock_memory_hotplug();
+return 0;
}
EXPORT_SYMBOL_GPL(remove_memory);
Index: linux-3.5-rc4/include/linux/firmware-map.h
===
--- linux-3.5-rc4.orig/include/linux/firmware-map.h 2012-07-03
14:21:45.766421116 +0900
+++ linux-3.5-rc4/include/linux/firmware-map.h 2012-07-03
14:22:03.550198789 +0900
@@ -25,6 +25,7 @@
int firmware_map_add_early(u64 start, u64 end, const char *type);
int firmware_map_add_hotplug(u64 start, u64 end, const char *type);
+int firmware_map_remove(u64 start, u64 end, const char *type);
#else /* CONFIG_FIRMWARE_MEMMAP */
@@ -38,6 +39,11 @@ static inline int firmware_map_add_hotpl
return 0;
}
+static inline int firmware_map_remove(u64 start, u64 end, const char
*type)
+{
+return 0;
+}
+
#endif /* CONFIG_FIRMWARE_MEMMAP */
#endif /* _LINUX_FIRMWARE_MAP_H */
Index: linux-3.5-rc4/drivers/firmware/memmap.c
===
--- linux-3.5-rc4.orig/drivers/firmware/memmap.c 2012-07-03
14:21:45.761421180 +0900
+++ linux-3.5-rc4/drivers/firmware/memmap.c 2012-07-03
14:22:03.569198549 +0900
@@ -79,7 +79,16 @@ static const struct sysfs_ops memmap_att
.show = memmap_attr_show,
};
+static void release_firmware_map_entry(struct kobject *kobj)
+{
+/*
+ * FIXME : There is no idea.
+ * How to free the entry which allocated bootmem?
+ */
I find a function free_bootmem(), but I am not sure whether it can work
here.
It cannot work here.
Another problem: how to check whether the entry uses bootmem?
When firmware_map_entry is allocated by kzalloc(), the page has PG_slab.
This is not true. In my test, I find the page does not have PG_slab
sometimes.
I think that it depends on the allocated size. firmware_map_entry size is
smaller than PAGE_SIZE. So the page has PG_Slab.
In my test, I add printk in the function firmware_map_add_hotplug() to display
page's flags. And sometimes the page is not allocated by slab(I use PageSlab()
to verify it).
How did you check it? Could you send your debug patch?
Thanks,
Yasuaki Ishimatsu
Thanks
Wen Congyang
Thanks,
Yasuaki Ishimatsu
Thanks
Wen Congyang.
So we can check whether the entry was allocated by bootmem or not.
If the eantry was allocated by kzalloc(), we can free the entry by kfree().
But if the entry was allocated by bootmem, we have no way to free the
entry.
Thanks,
Yasuaki Ishimatsu
Thanks
Wen Congyang
+}
+
static struct kobj_type memmap_ktype = {
+.release= release_firmware_map_entry,
.sysfs_ops = memmap_attr_ops,
.default_attrs = def_attrs,
};
@@ -123,6 +132,16 @@ static int firmware_map_add_entry(u64 st
return 0;
}
+/**
+ * firmware_map_remove_entry() - Does the real work to remove a firmware
+ * memmap entry.
+ * @entry: removed entry.
+ **/
+static inline void firmware_map_remove_entry(struct firmware_map_entry
Re: [PATCH SLAB 1/2 v3] duplicate the cache name in SLUB's saved_alias list, SLAB, and SLOB
On 07/06/2012 11:54 AM, Li Zhong wrote: + if (!c lname) + kfree(lname); + kfree can still be validly called with a NULL argument. No need for the lname in the conditional. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH v2 4/13] memory-hotplug : remove /sys/firmware/memmap/X sysfs
At 07/06/2012 04:27 PM, Yasuaki Ishimatsu Wrote:
Hi Wen,
2012/07/04 19:01, Wen Congyang wrote:
At 07/04/2012 01:52 PM, Yasuaki Ishimatsu Wrote:
Hi Wen,
2012/07/04 14:08, Wen Congyang wrote:
At 07/04/2012 12:45 PM, Yasuaki Ishimatsu Wrote:
Hi Wen,
2012/07/03 15:35, Wen Congyang wrote:
At 07/03/2012 01:56 PM, Yasuaki Ishimatsu Wrote:
When (hot)adding memory into system, /sys/firmware/memmap/X/{end,
start, type}
sysfs files are created. But there is no code to remove these files.
The patch
implements the function to remove them.
Note : The code does not free firmware_map_entry since there is no way
to free
memory which is allocated by bootmem.
CC: David Rientjes rient...@google.com
CC: Jiang Liu liu...@gmail.com
CC: Len Brown len.br...@intel.com
CC: Benjamin Herrenschmidt b...@kernel.crashing.org
CC: Paul Mackerras pau...@samba.org
CC: Christoph Lameter c...@linux.com
Cc: Minchan Kim minchan@gmail.com
CC: Andrew Morton a...@linux-foundation.org
CC: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Signed-off-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
---
drivers/firmware/memmap.c| 70
+++
include/linux/firmware-map.h |6 +++
mm/memory_hotplug.c |6 +++
3 files changed, 81 insertions(+), 1 deletion(-)
Index: linux-3.5-rc4/mm/memory_hotplug.c
===
--- linux-3.5-rc4.orig/mm/memory_hotplug.c 2012-07-03
14:22:00.190240794 +0900
+++ linux-3.5-rc4/mm/memory_hotplug.c 2012-07-03 14:22:03.549198802
+0900
@@ -661,7 +661,11 @@ EXPORT_SYMBOL_GPL(add_memory);
int remove_memory(int nid, u64 start, u64 size)
{
- return -EBUSY;
+ lock_memory_hotplug();
+ /* remove memmap entry */
+ firmware_map_remove(start, start + size - 1, System RAM);
+ unlock_memory_hotplug();
+ return 0;
}
EXPORT_SYMBOL_GPL(remove_memory);
Index: linux-3.5-rc4/include/linux/firmware-map.h
===
--- linux-3.5-rc4.orig/include/linux/firmware-map.h 2012-07-03
14:21:45.766421116 +0900
+++ linux-3.5-rc4/include/linux/firmware-map.h 2012-07-03
14:22:03.550198789 +0900
@@ -25,6 +25,7 @@
int firmware_map_add_early(u64 start, u64 end, const char *type);
int firmware_map_add_hotplug(u64 start, u64 end, const char *type);
+int firmware_map_remove(u64 start, u64 end, const char *type);
#else /* CONFIG_FIRMWARE_MEMMAP */
@@ -38,6 +39,11 @@ static inline int firmware_map_add_hotpl
return 0;
}
+static inline int firmware_map_remove(u64 start, u64 end, const char
*type)
+{
+ return 0;
+}
+
#endif /* CONFIG_FIRMWARE_MEMMAP */
#endif /* _LINUX_FIRMWARE_MAP_H */
Index: linux-3.5-rc4/drivers/firmware/memmap.c
===
--- linux-3.5-rc4.orig/drivers/firmware/memmap.c2012-07-03
14:21:45.761421180 +0900
+++ linux-3.5-rc4/drivers/firmware/memmap.c 2012-07-03
14:22:03.569198549 +0900
@@ -79,7 +79,16 @@ static const struct sysfs_ops memmap_att
.show = memmap_attr_show,
};
+static void release_firmware_map_entry(struct kobject *kobj)
+{
+ /*
+* FIXME : There is no idea.
+* How to free the entry which allocated bootmem?
+*/
I find a function free_bootmem(), but I am not sure whether it can work
here.
It cannot work here.
Another problem: how to check whether the entry uses bootmem?
When firmware_map_entry is allocated by kzalloc(), the page has PG_slab.
This is not true. In my test, I find the page does not have PG_slab
sometimes.
I think that it depends on the allocated size. firmware_map_entry size is
smaller than PAGE_SIZE. So the page has PG_Slab.
In my test, I add printk in the function firmware_map_add_hotplug() to
display
page's flags. And sometimes the page is not allocated by slab(I use
PageSlab()
to verify it).
How did you check it? Could you send your debug patch?
When the memory is not allocated from slab, the flags is 0x108000.
From 8dd51368d6c03edf7edc89cab17441e3741c39c7 Mon Sep 17 00:00:00 2001
From: Wen Congyang we...@cn.fujitsu.com
Date: Wed, 4 Jul 2012 16:05:26 +0800
Subject: [PATCH] debug
---
drivers/firmware/memmap.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/firmware/memmap.c b/drivers/firmware/memmap.c
index adc0710..993ba3f 100644
--- a/drivers/firmware/memmap.c
+++ b/drivers/firmware/memmap.c
@@ -21,6 +21,7 @@
#include linux/types.h
#include linux/bootmem.h
#include linux/slab.h
+#include linux/mm.h
/*
* Data types
--
@@ -160,11 +161,17 @@ static int add_sysfs_fw_map_entry(struct
firmware_map_entry *entry)
int __meminit firmware_map_add_hotplug(u64
Re: [PATCH v2 1/1] of: reform prom_update_property function
On Tue, Jun 26, 2012 at 07:40:10AM +0800, Rob Herring wrote: On 06/25/2012 01:28 AM, Dong Aisheng wrote: From: Dong Aisheng dong.aish...@linaro.org prom_update_property() currently fails if the property doesn't actually exist yet which isn't what we want. Change to add-or-update instead of update-only, then we can remove a lot duplicated lines. Suggested-by: Grant Likely grant.lik...@secretlab.ca Signed-off-by: Dong Aisheng dong.aish...@linaro.org Acked-by: Rob Herring rob.herr...@calxeda.com Ben, you can merge this via powerpc. Rob Ping... Regards Dong Aisheng ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH powerpc 2/2] kfree the cache name of pgtable cache if SLUB is used
On 07/05/2012 01:29 PM, Li Zhong wrote: On Thu, 2012-07-05 at 12:23 +0400, Glauber Costa wrote: On 07/05/2012 05:41 AM, Li Zhong wrote: On Wed, 2012-07-04 at 16:40 +0400, Glauber Costa wrote: On 07/04/2012 01:00 PM, Li Zhong wrote: On Tue, 2012-07-03 at 15:36 -0500, Christoph Lameter wrote: Looking through the emails it seems that there is an issue with alias strings. To be more precise, there seems no big issue currently. I just wanted to make following usage of kmem_cache_create (SLUB) possible: name = some string kmalloced kmem_cache_create(name, ...) kfree(name); Out of curiosity: Why? This is not (currently) possible with the other allocators (may change with christoph's unification patches), so you would be making your code slub-dependent. For slub itself, I think it's not good that: in some cases, the name string could be kfreed ( if it was kmalloced ) immediately after calling the cache create; in some other case, the name string needs to be kept valid until some init calls finished. I agree with you that it would make the code slub-dependent, so I'm now working on the consistency of the other allocators regarding this name string duplicating thing. If you really need to kfree the string, or even if it is easier for you this way, it can be done. As a matter of fact, this is the case for me. Just that your patch is not enough. Christoph has a patch that makes this behavior consistent over all allocators. Sorry, I didn't know that. Seems I don't need to continue the half-done work in slab. If possible, would you please give me a link of the patch? Thank you. Sorry for the delay. In case you haven't found it out yourself yet: http://www.spinics.net/lists/linux-mm/msg36149.html Please not this posted patch as is has a bug. I do believe that your take on the aliasing code adds value to it. But as I've already said once, might have to dig a bit deeper in that to get to end of the rabbit hole. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] printk: Have printk() never buffer its data
On Fri, Jul 6, 2012 at 5:47 AM, Michael Neuling mi...@neuling.org wrote: 4,89,24561;NIP: c0048164 LR: c0048160 CTR: 4,90,24576;REGS: c0007e59fb50 TRAP: 0700 Tainted: GW (3.5.0-rc4-mikey) 4,91,24583;MSR: 90021032 4,92,24586; 4,93,24591;SF 4,94,24596;,HV 4,95,24601;,ME 4,96,24606;,IR 4,97,24611;,DR 4,98,24616;,RI 4,99,24619; 4,100,24628; CR: 2842 XER: 2200 FWIW, compiling with the parent commit gives this: 4,89,1712;NIP: c0048164 LR: c0048160 CTR: 4,90,1713;REGS: c0007e59fb50 TRAP: 0700 Tainted: GW (3.5.0-rc4-mikey) 4,91,1716;MSR: 90021032 SF,HV,ME,IR,DR,RI CR: 2282 XER: 0200 Hmm, I don't understand, which parent commit do you mean? You maybe mean without 084681d? I think it's a race of the two CPUs printing continuation lines, and the continuation buffer is still occupied with data from one CPU and not available to the other one at the same time. What you see is likely not the direct output to the console (that would work) but the replay of the stored buffer when the console is registered. Because the cont buffer was still busy with one CPU, the other thread needs to store the continuation line prints in individual records, which leads to the (unwanted) printed newlines when replaying. The data we store looks all fine, it just looks needlessly separated when we replay fromt he buffer on a newly registered boot console. We need to merge the lines in the output, so they *look* like they are all in one line. I'll work on a fix for that now. Thanks, Kay ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] PPC Hardware Breakpoints: Fix incorrect pointer access
If arch_validate_hwbkpt_settings() fails, bp-ctx won't be valid and the kernel panics. Add a check to fix this. Reported-by: Edjunior Barbosa Machado emach...@linux.vnet.ibm.com Signed-off-by: Naveen N. Rao naveen.n@linux.vnet.ibm.com --- arch/powerpc/kernel/hw_breakpoint.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/hw_breakpoint.c b/arch/powerpc/kernel/hw_breakpoint.c index 2bc0584..f3a82dd 100644 --- a/arch/powerpc/kernel/hw_breakpoint.c +++ b/arch/powerpc/kernel/hw_breakpoint.c @@ -111,7 +111,7 @@ void arch_unregister_hw_breakpoint(struct perf_event *bp) * and the single_step_dabr_instruction(), then cleanup the breakpoint * restoration variables to prevent dangling pointers. */ - if (bp-ctx-task) + if (bp-ctx bp-ctx-task) bp-ctx-task-thread.last_hit_ubp = NULL; } ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] powerpc/e500: add paravirt QEMU platform
On 28.06.2012, at 01:50, Scott Wood wrote:
This gives the kernel a paravirtualized machine to target, without
requiring both sides to pretend to be targeting a specific board
that likely has little to do with the host in KVM scenarios. This
avoids the need to add new boards to QEMU just to be able to
run KVM on new CPUs.
As this is the first platform that can run with either e500v2 or
e500mc, CONFIG_PPC_E500MC is now a legitimately user configurable
option, so add a help text.
Signed-off-by: Scott Wood scottw...@freescale.com
---
arch/powerpc/platforms/85xx/Kconfig | 16 +++
arch/powerpc/platforms/85xx/Makefile|1 +
arch/powerpc/platforms/85xx/qemu_e500.c | 66 +++
arch/powerpc/platforms/Kconfig.cputype |4 ++
I really think we should document what exactly this machine expects.
4 files changed, 87 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/85xx/qemu_e500.c
diff --git a/arch/powerpc/platforms/85xx/Kconfig
b/arch/powerpc/platforms/85xx/Kconfig
index f000d81..7bbebe5 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -263,6 +263,22 @@ config P5020_DS
help
This option enables support for the P5020 DS board
+config PPC_QEMU_E500
+ bool QEMU generic e500 platform
+ depends on EXPERIMENTAL
+ select DEFAULT_UIMAGE
+ help
+ This option enables support for running as a QEMU guest using
+ QEMU's generic e500 machine. This is not required if you're
+ using a QEMU machine that targets a specific board, such as
+ mpc8544ds.
+
+ Unlike most e500 boards that target a specific CPU, this
+ platform works with any e500-family CPU that QEMU supports.
+ Thus, you'll need to make sure CONFIG_PPC_E500MC is set or
+ unset based on the emulated CPU (or actual host CPU in the case
+ of KVM).
+
endif # FSL_SOC_BOOKE
config TQM85xx
diff --git a/arch/powerpc/platforms/85xx/Makefile
b/arch/powerpc/platforms/85xx/Makefile
index 2125d4c..f841ac8 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -28,3 +28,4 @@ obj-$(CONFIG_SOCRATES)+= socrates.o socrates_fpga_pic.o
obj-$(CONFIG_KSI8560) += ksi8560.o
obj-$(CONFIG_XES_MPC85xx) += xes_mpc85xx.o
obj-$(CONFIG_GE_IMP3A) += ge_imp3a.o
+obj-$(CONFIG_PPC_QEMU_E500) += qemu_e500.o
diff --git a/arch/powerpc/platforms/85xx/qemu_e500.c
b/arch/powerpc/platforms/85xx/qemu_e500.c
new file mode 100644
index 000..77c8d5d
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/qemu_e500.c
@@ -0,0 +1,66 @@
+/*
+ * Paravirt target for a generic QEMU e500 machine
+ *
+ * Copyright 2012 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; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include linux/kernel.h
+#include linux/of_fdt.h
+#include asm/machdep.h
+#include asm/time.h
+#include asm/udbg.h
+#include asm/mpic.h
+#include sysdev/fsl_soc.h
+#include sysdev/fsl_pci.h
+#include smp.h
+#include mpc85xx.h
+
+void __init qemu_e500_pic_init(void)
+{
+ struct mpic *mpic;
+
+ mpic = mpic_alloc(NULL, 0, MPIC_BIG_ENDIAN | MPIC_SINGLE_DEST_CPU,
+ 0, 256, OpenPIC );
Does that mean we're configuring the MPIC regardless of what the guest tells
us? So the MPIC is a hard requirement. We can't use UIC or XPIC with this
machine, right? This needs to be documented.
+
+ BUG_ON(mpic == NULL);
+ mpic_init(mpic);
+}
+
+static void __init qemu_e500_setup_arch(void)
+{
+ ppc_md.progress(qemu_e500_setup_arch(), 0);
+
+ fsl_pci_init();
+ mpc85xx_smp_init();
+}
+
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+static int __init qemu_e500_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ return !!of_flat_dt_is_compatible(root, fsl,qemu-e500);
So the machine needs to be compatible fsl,qemu-e500. Needs documentation in
the machine spec.
I'm sure you'll find more constraints that appear logical, but really should be
written down so we have something formal that potentially someone not-QEMU or
not-Scott could write a machine implementation against ;).
Alex
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH SLAB 1/2 v3] duplicate the cache name in SLUB's saved_alias list, SLAB, and SLOB
I thought I posted this a couple of days ago. Would this not fix things
without having to change all the allocators?
Subject: slub: Dup name earlier in kmem_cache_create
Dup the name earlier in kmem_cache_create so that alias
processing is done using the copy of the string and not
the string itself.
Signed-off-by: Christoph Lameter c...@linux.com
---
mm/slub.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
Index: linux-2.6/mm/slub.c
===
--- linux-2.6.orig/mm/slub.c2012-06-11 08:49:56.0 -0500
+++ linux-2.6/mm/slub.c 2012-07-03 15:17:37.0 -0500
@@ -3933,8 +3933,12 @@ struct kmem_cache *kmem_cache_create(con
if (WARN_ON(!name))
return NULL;
+ n = kstrdup(name, GFP_KERNEL);
+ if (!n)
+ goto out;
+
down_write(slub_lock);
- s = find_mergeable(size, align, flags, name, ctor);
+ s = find_mergeable(size, align, flags, n, ctor);
if (s) {
s-refcount++;
/*
@@ -3944,7 +3948,7 @@ struct kmem_cache *kmem_cache_create(con
s-objsize = max(s-objsize, (int)size);
s-inuse = max_t(int, s-inuse, ALIGN(size, sizeof(void *)));
- if (sysfs_slab_alias(s, name)) {
+ if (sysfs_slab_alias(s, n)) {
s-refcount--;
goto err;
}
@@ -3952,31 +3956,26 @@ struct kmem_cache *kmem_cache_create(con
return s;
}
- n = kstrdup(name, GFP_KERNEL);
- if (!n)
- goto err;
-
s = kmalloc(kmem_size, GFP_KERNEL);
if (s) {
if (kmem_cache_open(s, n,
size, align, flags, ctor)) {
list_add(s-list, slab_caches);
up_write(slub_lock);
- if (sysfs_slab_add(s)) {
- down_write(slub_lock);
- list_del(s-list);
- kfree(n);
- kfree(s);
- goto err;
- }
- return s;
+ if (!sysfs_slab_add(s))
+ return s;
+
+ down_write(slub_lock);
+ list_del(s-list);
}
kfree(s);
}
- kfree(n);
+
err:
+ kfree(n);
up_write(slub_lock);
+out:
if (flags SLAB_PANIC)
panic(Cannot create slabcache %s\n, name);
else
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Revert powerpc/p3060qds: Add support for P3060QDS board
On Jul 5, 2012, at 5:07 PM, Timur Tabi wrote: This reverts commit 96cc017c5b7ec095ef047d3c1952b6b6bbf98943. The P3060 was cancelled before it went into production, so there's no point in supporting it. Signed-off-by: Timur Tabi ti...@freescale.com --- arch/powerpc/boot/dts/fsl/p3060si-post.dtsi | 302 -- arch/powerpc/boot/dts/fsl/p3060si-pre.dtsi | 125 --- arch/powerpc/boot/dts/p3060qds.dts | 242 - arch/powerpc/configs/corenet32_smp_defconfig |1 - arch/powerpc/platforms/85xx/Kconfig | 12 - arch/powerpc/platforms/85xx/Makefile |1 - arch/powerpc/platforms/85xx/p3060_qds.c | 77 --- 7 files changed, 0 insertions(+), 760 deletions(-) delete mode 100644 arch/powerpc/boot/dts/fsl/p3060si-post.dtsi delete mode 100644 arch/powerpc/boot/dts/fsl/p3060si-pre.dtsi delete mode 100644 arch/powerpc/boot/dts/p3060qds.dts delete mode 100644 arch/powerpc/platforms/85xx/p3060_qds.c I assume you're sending a similar patch to u-boot. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/4] powerpc/mpic: FSL MPIC error interrupt support.
On Jul 5, 2012, at 11:02 PM, Sethi Varun-B16395 wrote: -Original Message- From: Wood Scott-B07421 Sent: Tuesday, June 19, 2012 12:53 AM To: Sethi Varun-B16395 Cc: Wood Scott-B07421; Kumar Gala; Linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 4/4] powerpc/mpic: FSL MPIC error interrupt support. On 06/18/2012 02:19 PM, Sethi Varun-B16395 wrote: -Original Message- From: Wood Scott-B07421 Sent: Tuesday, June 19, 2012 12:47 AM To: Sethi Varun-B16395 Cc: Kumar Gala; Wood Scott-B07421; Linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 4/4] powerpc/mpic: FSL MPIC error interrupt support. On 06/18/2012 02:12 PM, Sethi Varun-B16395 wrote: +/* + * Error interrupt registers + */ + +#define MPIC_ERR_INT_BASE0x3900 +#define MPIC_ERR_INT_EISR0x +#define MPIC_ERR_INT_EIMR0x0010 + #define MPIC_MAX_IRQ_SOURCES 2048 #define MPIC_MAX_CPUS 32 #define MPIC_MAX_ISU 32 #define MPIC_MAX_TIMER8 #define MPIC_MAX_IPI 4 +#define MPIC_MAX_ERR 32 Should probably be 64 This patch supports MPIC 4.1 and EISR0. When support is added for EISR1 (didn't realize this was coming until your comment prompted me to check...), this should be updated, but this change alone would not make it work. Would prefer we handle this now rather than later (T4240 is going to need EISR1 support). Hi Kumar, As of now I don't have a proper mechanism to test this functionality. I will submit a follow up patch for EISR1/EIMR1 support once I have a mechanism to test this functionality. You could still write the code in a way that scales to multiple EISRs, and test that it works with EISR0. Yes, but I would like to submit the patch once I have tested it. So test it the way I described, and submit. :-P There just seem to be 32 error interrupts even in case of T4240, that means there is no need to handle multiple EISRs. Ok, but I had some other comments about this patch. I have already submitted a revised patch for handling MPIC error interrupts. [PATCH 3/3 v2] powerpc/mpic: FSL MPIC error interrupt support Please resubmit the full sequence of patches at this point. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Revert powerpc/p3060qds: Add support for P3060QDS board
Kumar Gala wrote: I assume you're sending a similar patch to u-boot. Yes, but I wanted to see if this one was accepted first. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 08/17] KVM: PPC: e500mc: Fix tlbilx emulation for 64-bit guests
On 25.06.2012, at 14:26, Mihai Caraman wrote: tlbilxva emulation was using an u32 variable for guest effective address. Replace it with gva_t type to handle 64-bit guests. Signed-off-by: Mihai Caraman mihai.cara...@freescale.com Thanks, applied to kvm-ppc-next. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] printk: Have printk() never buffer its data
On Fri, Jul 6, 2012 at 12:46 PM, Kay Sievers k...@vrfy.org wrote: On Fri, Jul 6, 2012 at 5:47 AM, Michael Neuling mi...@neuling.org wrote: 4,89,24561;NIP: c0048164 LR: c0048160 CTR: 4,90,24576;REGS: c0007e59fb50 TRAP: 0700 Tainted: GW (3.5.0-rc4-mikey) 4,91,24583;MSR: 90021032 4,92,24586; 4,93,24591;SF 4,94,24596;,HV 4,95,24601;,ME 4,96,24606;,IR 4,97,24611;,DR 4,98,24616;,RI 4,99,24619; 4,100,24628; CR: 2842 XER: 2200 FWIW, compiling with the parent commit gives this: 4,89,1712;NIP: c0048164 LR: c0048160 CTR: 4,90,1713;REGS: c0007e59fb50 TRAP: 0700 Tainted: GW (3.5.0-rc4-mikey) 4,91,1716;MSR: 90021032 SF,HV,ME,IR,DR,RI CR: 2282 XER: 0200 Hmm, I don't understand, which parent commit do you mean? You maybe mean without 084681d? I think it's a race of the two CPUs printing continuation lines, and the continuation buffer is still occupied with data from one CPU and not available to the other one at the same time. What you see is likely not the direct output to the console (that would work) but the replay of the stored buffer when the console is registered. Because the cont buffer was still busy with one CPU, the other thread needs to store the continuation line prints in individual records, which leads to the (unwanted) printed newlines when replaying. The data we store looks all fine, it just looks needlessly separated when we replay fromt he buffer on a newly registered boot console. We need to merge the lines in the output, so they *look* like they are all in one line. I'll work on a fix for that now. It could be that the console semaphore is still help by the other CPU, for whatever reason, when your box runs into this situation. Mind pasting more context (/dev/kmsg) of the log when this happens, not only the one line that get split-up? Is this possibly during an oops or backtrace going on when you see this? Which code calls show_regs() here? Kay ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] powerpc/e500: add paravirt QEMU platform
On 07/06/2012 07:29 AM, Alexander Graf wrote:
On 28.06.2012, at 01:50, Scott Wood wrote:
This gives the kernel a paravirtualized machine to target, without
requiring both sides to pretend to be targeting a specific board
that likely has little to do with the host in KVM scenarios. This
avoids the need to add new boards to QEMU just to be able to
run KVM on new CPUs.
As this is the first platform that can run with either e500v2 or
e500mc, CONFIG_PPC_E500MC is now a legitimately user configurable
option, so add a help text.
Signed-off-by: Scott Wood scottw...@freescale.com
---
arch/powerpc/platforms/85xx/Kconfig | 16 +++
arch/powerpc/platforms/85xx/Makefile|1 +
arch/powerpc/platforms/85xx/qemu_e500.c | 66
+++
arch/powerpc/platforms/Kconfig.cputype |4 ++
I really think we should document what exactly this machine expects.
Well, the point of this paravirt machine is to avoid such assumptions --
it's all device-tree driven, at least in theory. If a certain qemu
configuration ends up breaking the Linux platform (such as using a
different PIC), then that's a lack of flexibility on Linux's part that
should get fixed if someone finds it useful enough to justify the
effort. Same with real hardware -- if you care about it, you add
support -- we just don't have a unique name for every configuration.
The information is there in the device tree, though.
Honestly, even having qemu in there is more specific than I'd prefer,
but I don't want to stir up the generic platform argument again
without at least limiting the scope.
+void __init qemu_e500_pic_init(void)
+{
+struct mpic *mpic;
+
+mpic = mpic_alloc(NULL, 0, MPIC_BIG_ENDIAN | MPIC_SINGLE_DEST_CPU,
+0, 256, OpenPIC );
Does that mean we're configuring the MPIC regardless of what the
guest tells us? So the MPIC is a hard requirement. We can't use UIC
or XPIC with this machine, right? This needs to be documented.
Then what would we do if we want to add an ePAPR virtual PIC instead?
Or if something replaces MPIC on future FSL chips?
Better to change the Linux implementation as needed than to change a spec.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] powerpc/e500: add paravirt QEMU platform
On 06.07.2012, at 18:25, Scott Wood wrote:
On 07/06/2012 07:29 AM, Alexander Graf wrote:
On 28.06.2012, at 01:50, Scott Wood wrote:
This gives the kernel a paravirtualized machine to target, without
requiring both sides to pretend to be targeting a specific board
that likely has little to do with the host in KVM scenarios. This
avoids the need to add new boards to QEMU just to be able to
run KVM on new CPUs.
As this is the first platform that can run with either e500v2 or
e500mc, CONFIG_PPC_E500MC is now a legitimately user configurable
option, so add a help text.
Signed-off-by: Scott Wood scottw...@freescale.com
---
arch/powerpc/platforms/85xx/Kconfig | 16 +++
arch/powerpc/platforms/85xx/Makefile|1 +
arch/powerpc/platforms/85xx/qemu_e500.c | 66
+++
arch/powerpc/platforms/Kconfig.cputype |4 ++
I really think we should document what exactly this machine expects.
Well, the point of this paravirt machine is to avoid such assumptions --
it's all device-tree driven, at least in theory. If a certain qemu
configuration ends up breaking the Linux platform (such as using a
different PIC), then that's a lack of flexibility on Linux's part that
should get fixed if someone finds it useful enough to justify the
effort. Same with real hardware -- if you care about it, you add
support -- we just don't have a unique name for every configuration.
The information is there in the device tree, though.
Honestly, even having qemu in there is more specific than I'd prefer,
but I don't want to stir up the generic platform argument again
without at least limiting the scope.
Well, can't we note down the assumptions we make to make sure that whoever
develops an implementation of it knows what to implement? It's ppc specific for
example. I also don't think that plugging a G3 in there works, would it?
+void __init qemu_e500_pic_init(void)
+{
+ struct mpic *mpic;
+
+ mpic = mpic_alloc(NULL, 0, MPIC_BIG_ENDIAN | MPIC_SINGLE_DEST_CPU,
+ 0, 256, OpenPIC );
Does that mean we're configuring the MPIC regardless of what the
guest tells us? So the MPIC is a hard requirement. We can't use UIC
or XPIC with this machine, right? This needs to be documented.
Then what would we do if we want to add an ePAPR virtual PIC instead?
Or if something replaces MPIC on future FSL chips?
Then we need a different compatible anyways, because we wouldn't be backwards
compatible, no?
Better to change the Linux implementation as needed than to change a spec.
Why not keep the 2 in sync in the same patch? Just throw a file with a rough
outline of the machine in Documentation/.
Alex
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] powerpc/e500: add paravirt QEMU platform
On 07/06/2012 11:30 AM, Alexander Graf wrote:
On 06.07.2012, at 18:25, Scott Wood wrote:
On 07/06/2012 07:29 AM, Alexander Graf wrote:
I really think we should document what exactly this machine expects.
Well, the point of this paravirt machine is to avoid such assumptions --
it's all device-tree driven, at least in theory. If a certain qemu
configuration ends up breaking the Linux platform (such as using a
different PIC), then that's a lack of flexibility on Linux's part that
should get fixed if someone finds it useful enough to justify the
effort. Same with real hardware -- if you care about it, you add
support -- we just don't have a unique name for every configuration.
The information is there in the device tree, though.
Honestly, even having qemu in there is more specific than I'd prefer,
but I don't want to stir up the generic platform argument again
without at least limiting the scope.
Well, can't we note down the assumptions we make to make sure that
whoever develops an implementation of it knows what to implement?
It's ppc specific for example. I also don't think that plugging a G3
in there works, would it?
Well, it does have e500 in the name. :-P
+void __init qemu_e500_pic_init(void)
+{
+ struct mpic *mpic;
+
+ mpic = mpic_alloc(NULL, 0, MPIC_BIG_ENDIAN | MPIC_SINGLE_DEST_CPU,
+ 0, 256, OpenPIC );
Does that mean we're configuring the MPIC regardless of what the
guest tells us? So the MPIC is a hard requirement. We can't use UIC
or XPIC with this machine, right? This needs to be documented.
Then what would we do if we want to add an ePAPR virtual PIC instead?
Or if something replaces MPIC on future FSL chips?
Then we need a different compatible anyways, because we wouldn't be backwards
compatible, no?
No, that's exactly what I'm trying to avoid. This notion of a toplevel
compatible that tells you everything you need to know about the machine
(even if Linux chooses to be device-tree-based for some arbitrary subset
of that information) is incompatible with a flexible virtual platform.
All this compatible is saying is see the rest of the device tree.
How well Linux does so is a quality of implementation issue that can be
addressed as needed. The information about what sort of interrupt
controller you have is already in the device tree. The device tree is
the machine spec.
Another assumption this patch makes is that it doesn't need SWIOTLB. Is
has more than 4GiB RAM a machine attribute that would warrant a
separate toplevel compatible? SWIOTLB for PCI is handled due to the
previous patch that provides common PCI code -- but in a previous
version of the patch it was not handled. Is it yet another incompatible
machine spec if RAM must be less than 4GiB minus PCICSRBAR (ignoring the
QEMU bug that PCICSRBAR is not implemented)?
Better to change the Linux implementation as needed than to change a spec.
Why not keep the 2 in sync in the same patch? Just throw a file with a rough
outline of the machine in Documentation/.
Because that would give people the wrong impression about what this
machine is, and be unlikely to stay in sync or be a complete listing of
current assumptions. You're basically suggesting to use Documentation/
as a bug tracker.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] powerpc/e500: add paravirt QEMU platform
On 06.07.2012, at 18:52, Scott Wood wrote:
On 07/06/2012 11:30 AM, Alexander Graf wrote:
On 06.07.2012, at 18:25, Scott Wood wrote:
On 07/06/2012 07:29 AM, Alexander Graf wrote:
I really think we should document what exactly this machine expects.
Well, the point of this paravirt machine is to avoid such assumptions --
it's all device-tree driven, at least in theory. If a certain qemu
configuration ends up breaking the Linux platform (such as using a
different PIC), then that's a lack of flexibility on Linux's part that
should get fixed if someone finds it useful enough to justify the
effort. Same with real hardware -- if you care about it, you add
support -- we just don't have a unique name for every configuration.
The information is there in the device tree, though.
Honestly, even having qemu in there is more specific than I'd prefer,
but I don't want to stir up the generic platform argument again
without at least limiting the scope.
Well, can't we note down the assumptions we make to make sure that
whoever develops an implementation of it knows what to implement?
It's ppc specific for example. I also don't think that plugging a G3
in there works, would it?
Well, it does have e500 in the name. :-P
+void __init qemu_e500_pic_init(void)
+{
+ struct mpic *mpic;
+
+ mpic = mpic_alloc(NULL, 0, MPIC_BIG_ENDIAN | MPIC_SINGLE_DEST_CPU,
+ 0, 256, OpenPIC );
Does that mean we're configuring the MPIC regardless of what the
guest tells us? So the MPIC is a hard requirement. We can't use UIC
or XPIC with this machine, right? This needs to be documented.
Then what would we do if we want to add an ePAPR virtual PIC instead?
Or if something replaces MPIC on future FSL chips?
Then we need a different compatible anyways, because we wouldn't be
backwards compatible, no?
No, that's exactly what I'm trying to avoid. This notion of a toplevel
compatible that tells you everything you need to know about the machine
(even if Linux chooses to be device-tree-based for some arbitrary subset
of that information) is incompatible with a flexible virtual platform.
All this compatible is saying is see the rest of the device tree.
How well Linux does so is a quality of implementation issue that can be
addressed as needed. The information about what sort of interrupt
controller you have is already in the device tree. The device tree is
the machine spec.
Another assumption this patch makes is that it doesn't need SWIOTLB. Is
has more than 4GiB RAM a machine attribute that would warrant a
separate toplevel compatible? SWIOTLB for PCI is handled due to the
previous patch that provides common PCI code -- but in a previous
version of the patch it was not handled. Is it yet another incompatible
machine spec if RAM must be less than 4GiB minus PCICSRBAR (ignoring the
QEMU bug that PCICSRBAR is not implemented)?
Well, the thing that I'm wary of is the following. Imagine we make this the
default machine type for all e500 user cases. Which is reasonable. Now we
release 3.6 which works awesome with QEMU 1.2. We change something in QEMU.
QEMU 1.3 comes out. It can no longer boot your old kernel 3.6.
That's the type of situation I don't want to be in. We need to be backwards
compatible with what we used to be able to run. We can get away with declaring
things as experimental for now, until we settled on a reasonable compromise to
achieve said compatibility. But it needs to be our goal somewhere.
One idea would be to version the machine type according to what Linux
implements. If Linux finds a machine type that is newer than what it
implements, it spawns a warning. If we want, we can implement backwards
compatible machine types in QEMU, similar to how we implement -M pc-0.12 and
friends today.
Again, no need to do so as long as we tell users to not use it. As soon as we
want them to actually run the machine, we need to have independent upgrade
paths in place. New QEMU needs to be able to run old kernels. New kernels need
to be run on old QEMU.
Better to change the Linux implementation as needed than to change a spec.
Why not keep the 2 in sync in the same patch? Just throw a file with a rough
outline of the machine in Documentation/.
Because that would give people the wrong impression about what this
machine is, and be unlikely to stay in sync or be a complete listing of
current assumptions. You're basically suggesting to use Documentation/
as a bug tracker.
I'm just saying that every time we hardcode assumptions, we need to make sure
we document it somewhere. And currently we do hardcode assumptions, even though
only a few.
Alex
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][v3] powerpc/85xx:Add BSC9131 RDB Support
On Mar 21, 2012, at 11:54 PM, Prabhakar Kushwaha wrote: BSC9131RDB is a Freescale reference design board for BSC9131 SoC.The BSC9131 is integrated SoC that targets Femto base station market. It combines Power Architecture e500v2 and DSP StarCore SC3850 core technologies with MAPLE-B2F baseband acceleration processing elements. The BSC9131 SoC includes the following function and features: . Power Architecture subsystem including a e500 processor with 256-Kbyte shared L2 cache . StarCore SC3850 DSP subsystem with a 512-Kbyte private L2 cache . The Multi Accelerator Platform Engine for Femto BaseStation Baseband Processing (MAPLE-B2F) . A multi-standard baseband algorithm accelerator for Channel Decoding/Encoding, Fourier Transforms, UMTS chip rate processing, LTE UP/DL Channel processing, and CRC algorithms . Consists of accelerators for Convolution, Filtering, Turbo Encoding, Turbo Decoding, Viterbi decoding, Chiprate processing, and Matrix Inversion operations . DDR3/3L memory interface with 32-bit data width without ECC and 16-bit with ECC, up to 400-MHz clock/800 MHz data rate . Dedicated security engine featuring trusted boot . DMA controller . OCNDMA with four bidirectional channels . Interfaces . Two triple-speed Gigabit Ethernet controllers featuring network acceleration including IEEE 1588. v2 hardware support and virtualization (eTSEC) . eTSEC 1 supports RGMII/RMII . eTSEC 2 supports RGMII . High-speed USB 2.0 host and device controller with ULPI interface . Enhanced secure digital (SD/MMC) host controller (eSDHC) . Antenna interface controller (AIC), supporting three industry standard JESD207/three custom ADI RF interfaces (two dual port and one single port) and three MAXIM's MaxPHY serial interfaces . ADI lanes support both full duplex FDD support and half duplex TDD support . Universal Subscriber Identity Module (USIM) interface that facilitates communication to SIM cards or Eurochip pre-paid phone cards . TDM with one TDM port . Two DUART, four eSPI, and two I2C controllers . Integrated Flash memory controller (IFC) . TDM with 256 channels . GPIO . Sixteen 32-bit timers The DSP portion of the SoC consists of DSP core (SC3850) and various accelerators pertaining to DSP operations. BSC9131RDB Overview -- BSC9131 SoC 1Gbyte DDR3 (on board DDR) 128Mbyte 2K page size NAND Flash 256 Kbit M24256 I2C EEPROM 128 Mbit SPI Flash memory USB-ULPI eTSEC1: Connected to RGMII PHY eTSEC2: Connected to RGMII PHY DUART interface: supports one UARTs up to 115200 bps for console display Linux runs on e500v2 core and access some DSP peripherals like AIC Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com Signed-off-by: Priyanka Jain priyanka.j...@freescale.com Signed-off-by: Akhil Goyal akhil.go...@freescale.com Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com Signed-off-by: Rajan Srivastava rajan.srivast...@freescale.com Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- applied to next. (Made some minor changes to match upstream board ports like p1010, also sorted Makefile Kconfig by Alphabet) - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Revert powerpc/p3060qds: Add support for P3060QDS board
On Jul 5, 2012, at 5:07 PM, Timur Tabi wrote: This reverts commit 96cc017c5b7ec095ef047d3c1952b6b6bbf98943. The P3060 was cancelled before it went into production, so there's no point in supporting it. Signed-off-by: Timur Tabi ti...@freescale.com --- arch/powerpc/boot/dts/fsl/p3060si-post.dtsi | 302 -- arch/powerpc/boot/dts/fsl/p3060si-pre.dtsi | 125 --- arch/powerpc/boot/dts/p3060qds.dts | 242 - arch/powerpc/configs/corenet32_smp_defconfig |1 - arch/powerpc/platforms/85xx/Kconfig | 12 - arch/powerpc/platforms/85xx/Makefile |1 - arch/powerpc/platforms/85xx/p3060_qds.c | 77 --- 7 files changed, 0 insertions(+), 760 deletions(-) delete mode 100644 arch/powerpc/boot/dts/fsl/p3060si-post.dtsi delete mode 100644 arch/powerpc/boot/dts/fsl/p3060si-pre.dtsi delete mode 100644 arch/powerpc/boot/dts/p3060qds.dts delete mode 100644 arch/powerpc/platforms/85xx/p3060_qds.c applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: use the BRx registers to enable indirect mode on the P1022DS
On Jul 5, 2012, at 10:08 AM, Timur Tabi wrote: In order to enable the DIU video controller on the P1022DS, the FPGA needs to be switched to indirect mode, where the localbus is disabled and the FPGA is accessed via writes to localbus chip select signals CS0 and CS1. To obtain the address of CS0 and CS1, the platform driver uses an indirect pixis mode device tree node. This node assumes that the localbus 'ranges' property is sorted in chip-select order. That is, reg value 0 maps to CS0, reg value 1 maps to CS1, etc. This is how the 'ranges' property is supposed to be arranged. Unfortunately, the 'ranges' property is often mis-arranged, and not just on the P1022DS. Linux normally does not care, since it does not program the localbus. But the indirect-mode code on the P1022DS does care. The proper fix is to have U-Boot fix the 'ranges' property, but this would be too cumbersome. The names and 'reg' properties of all the localbus devices would also need to be updated, and determining which localbus device maps to which chip select is board-specific. Instead, we determine the CS0/CS1 base addresses the same way that U-boot does -- by reading the BRx registers directly and mapping them to physical addresses. This code is simpler and more reliable, and it does not require a U-boot or device tree change. Since the indirect pixis device tree node is no longer needed, the node is deleted from the DTS. Signed-off-by: Timur Tabi ti...@freescale.com --- arch/powerpc/boot/dts/p1022ds.dtsi | 16 - arch/powerpc/platforms/85xx/p1022_ds.c | 106 2 files changed, 93 insertions(+), 29 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] printk: Have printk() never buffer its data
Kay Sievers k...@vrfy.org wrote: On Fri, Jul 6, 2012 at 12:46 PM, Kay Sievers k...@vrfy.org wrote: On Fri, Jul 6, 2012 at 5:47 AM, Michael Neuling mi...@neuling.org wrote: 4,89,24561;NIP: c0048164 LR: c0048160 CTR: 4,90,24576;REGS: c0007e59fb50 TRAP: 0700 Tainted: GW (3.5.0-rc4-mikey) 4,91,24583;MSR: 90021032 4,92,24586; 4,93,24591;SF 4,94,24596;,HV 4,95,24601;,ME 4,96,24606;,IR 4,97,24611;,DR 4,98,24616;,RI 4,99,24619; 4,100,24628; CR: 2842 XER: 2200 FWIW, compiling with the parent commit gives this: 4,89,1712;NIP: c0048164 LR: c0048160 CTR: 4,90,1713;REGS: c0007e59fb50 TRAP: 0700 Tainted: GW (3.5.0-rc4-mikey) 4,91,1716;MSR: 90021032 SF,HV,ME,IR,DR,RI CR: 2282 XER: 0200 Hmm, I don't understand, which parent commit do you mean? You maybe mean without 084681d? I think it's a race of the two CPUs printing continuation lines, and the continuation buffer is still occupied with data from one CPU and not available to the other one at the same time. What you see is likely not the direct output to the console (that would work) but the replay of the stored buffer when the console is registered. Because the cont buffer was still busy with one CPU, the other thread needs to store the continuation line prints in individual records, which leads to the (unwanted) printed newlines when replaying. The data we store looks all fine, it just looks needlessly separated when we replay fromt he buffer on a newly registered boot console. We need to merge the lines in the output, so they *look* like they are all in one line. I'll work on a fix for that now. It could be that the console semaphore is still help by the other CPU, for whatever reason, when your box runs into this situation. Mind pasting more context (/dev/kmsg) of the log when this happens, not only the one line that get split-up? Is this possibly during an oops or backtrace going on when you see this? Which code calls show_regs() here? Whole kmsg below. It is a backtrace. It's a warning in arch/powerpc/sysdev/xics/xics-common.c:xics_set_cpu_giq(). The firmware this machine is running on is non standard (Bare Metal Linux in the lab). The warning itself not an issue. We've had it for years and it tells us that our firmware/RTAS is not fully implemented. Mikey 7,0,0;Allocated 917504 bytes for 1024 pacas at cff2 6,1,0;Using pSeries machine description 7,2,0;Page orders: linear mapping = 24, virtual = 16, io = 12, vmemmap = 24 6,3,0;Using 1TB segments 4,4,0;Found initrd at 0xc2da5000:0xcbc8c200 6,5,0;CPU maps initialized for 2 threads per core 7,6,0; (thread shift is 1) 7,7,0;Freed 851968 bytes for unused pacas 4,8,0;Starting Linux PPC64 #100 SMP Sat Jul 7 06:55:43 EST 2012 4,9,0;- 4,10,0;ppc64_pft_size= 0x0 4,11,0;physicalMemorySize= 0x8000 4,12,0;htab_address = 0xc0007fe0 4,13,0;htab_hash_mask= 0x3fff 4,14,0;- 6,15,0;Initializing cgroup subsys cpuset 5,16,0;Linux version 3.5.0-rc4-mikey (mikey@ka1) (gcc version 4.6.0 (GCC) ) #100 SMP Sat Jul 7 06:55:43 EST 2012 4,17,0;[boot]0012 Setup Arch 7,18,0;Node 0 Memory: 0x0-0x8000 6,19,0;Section 1 and 127 (node 0) have a circular dependency on usemap and pgdat allocations 4,20,0;pseries_eeh_init: RTAS service ibm, set-slot-reset invalid 4,21,0;eeh_init: Failed to call platform init function (-22) 4,22,0;Zone ranges: 4,23,0; DMA [mem 0x-0x7fff] 4,24,0; Normal empty 4,25,0;Movable zone start for each node 4,26,0;Early memory node ranges 4,27,0; node 0: [mem 0x-0x7fff] 7,28,0;On node 0 totalpages: 32768 7,29,0; DMA zone: 28 pages used for memmap 7,30,0; DMA zone: 0 pages reserved 7,31,0; DMA zone: 32740 pages, LIFO batch:1 4,32,0;[boot]0015 Setup Done 6,33,0;PERCPU: Embedded 2 pages/cpu @c0e0 s84224 r0 d46848 u524288 7,34,0;pcpu-alloc: s84224 r0 d46848 u524288 alloc=1*1048576 7,35,0;pcpu-alloc: [0] 0 1 4,36,0;Built 1 zonelists in Node order, mobility grouping on. Total pages: 32740 4,37,0;Policy zone: DMA 5,38,0;Kernel command line: ipr.enabled=0 6,39,0;PID hash table entries: 4096 (order: -1, 32768 bytes) 4,40,0;freeing bootmem node 0 6,41,0;Memory: 1916096k/2097152k available (11200k kernel code, 181056k reserved, 1728k data, 1041k bss, 576k init) 6,42,0;SLUB: Genslabs=19, HWalign=128, Order=0-3, MinObjects=0, CPUs=2, Nodes=256 6,43,0;Hierarchical RCU implementation. 6,44,0;NR_IRQS:512 nr_irqs:512 16 4,45,0;set-indicator(9005, 0, 1) returned -22 4,46,0;[ cut here ] 4,47,0;WARNING: at /scratch/mikey/src/linux-ozlabs/arch/powerpc/sysdev/xics/xics-common.c:105 4,48,0;Modules linked in: 4,49,0;NIP:
Re: [PATCH 2/3] powerpc/e500: add paravirt QEMU platform
On 07/06/2012 11:59 AM, Alexander Graf wrote: On 06.07.2012, at 18:52, Scott Wood wrote: On 07/06/2012 11:30 AM, Alexander Graf wrote: On 06.07.2012, at 18:25, Scott Wood wrote: Then what would we do if we want to add an ePAPR virtual PIC instead? Or if something replaces MPIC on future FSL chips? Then we need a different compatible anyways, because we wouldn't be backwards compatible, no? No, that's exactly what I'm trying to avoid. This notion of a toplevel compatible that tells you everything you need to know about the machine (even if Linux chooses to be device-tree-based for some arbitrary subset of that information) is incompatible with a flexible virtual platform. All this compatible is saying is see the rest of the device tree. How well Linux does so is a quality of implementation issue that can be addressed as needed. The information about what sort of interrupt controller you have is already in the device tree. The device tree is the machine spec. Another assumption this patch makes is that it doesn't need SWIOTLB. Is has more than 4GiB RAM a machine attribute that would warrant a separate toplevel compatible? SWIOTLB for PCI is handled due to the previous patch that provides common PCI code -- but in a previous version of the patch it was not handled. Is it yet another incompatible machine spec if RAM must be less than 4GiB minus PCICSRBAR (ignoring the QEMU bug that PCICSRBAR is not implemented)? Well, the thing that I'm wary of is the following. Imagine we make this the default machine type for all e500 user cases. Which is reasonable. Now we release 3.6 which works awesome with QEMU 1.2. We change something in QEMU. QEMU 1.3 comes out. It can no longer boot your old kernel 3.6. Do you expect your old kernel to boot when you get new hardware? QEMU is basically hardware that is easy to change. The only thing that using a more specific compatible would do is make sure that the kernel wouldn't boot whenever it changes, rather than just having a chance of certain combinations having problems. Obviously we should make a reasonable effort to avoid gratuitous breakage in the default config, but I just don't see how overspecifying things is going to help. That's the type of situation I don't want to be in. We need to be backwards compatible with what we used to be able to run. We can get away with declaring things as experimental for now, until we settled on a reasonable compromise to achieve said compatibility. But it needs to be our goal somewhere. One idea would be to version the machine type according to what Linux implements. If Linux finds a machine type that is newer than what it implements, it spawns a warning. What does it mean to have a version number for a platform which is intended to eventually be arbitrarily configurable? If we want, we can implement backwards compatible machine types in QEMU, similar to how we implement -M pc-0.12 and friends today. Heh, I was just about to respond by saying how would you version a PC? :-) If you want a stable versioned platform that happens to not pretend to be a real board, go ahead and add one -- that's not what this is for. Maybe instead of documenting things like has an MPIC, there should be some comment mentioning that this platform is intended to be flexible and device tree driven, not static. The device tree is the machine spec. I could see an argument for versioning individual devices, OTOH, rather than e.g. pretending the PCI is really equivalent to an mpc8540-pci despite significant missing functionality. BTW, could you point me to the documentation that explains exactly what a pc-0.12 is? And is there any place in Linux that actually sees this version number and does anything with it? How would a user know what version of a PC to request? What version do you get by default? Under what conditions are the version number bumped? Again, no need to do so as long as we tell users to not use it. As soon as we want them to actually run the machine, we need to have independent upgrade paths in place. New QEMU needs to be able to run old kernels. New kernels need to be run on old QEMU. They will, usually. We can't guarantee this will always be true regardless of a versioning scheme, since bugs will happen. Better to change the Linux implementation as needed than to change a spec. Why not keep the 2 in sync in the same patch? Just throw a file with a rough outline of the machine in Documentation/. Because that would give people the wrong impression about what this machine is, and be unlikely to stay in sync or be a complete listing of current assumptions. You're basically suggesting to use Documentation/ as a bug tracker. I'm just saying that every time we hardcode assumptions, we need to make sure we document it somewhere. And currently we do hardcode assumptions, even though only a few. If you want a bug tracker, use a bug tracker. Linux
RE: [Qemu-ppc] [RFC PATCH 12/17] PowerPC: booke64: Add DO_KVM kernel hooks
-Original Message- From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] Sent: Thursday, July 05, 2012 1:26 AM To: Alexander Graf Cc: Caraman Mihai Claudiu-B02008; kvm-...@vger.kernel.org; KVM list; linuxppc-dev; qemu-...@nongnu.org List Subject: Re: [Qemu-ppc] [RFC PATCH 12/17] PowerPC: booke64: Add DO_KVM kernel hooks On Wed, 2012-07-04 at 16:29 +0200, Alexander Graf wrote: +#ifdef CONFIG_KVM_BOOKE_HV +#define KVM_BOOKE_HV_MFSPR(reg, spr) \ + BEGIN_FTR_SECTION \ + mfspr reg, spr; \ + END_FTR_SECTION_IFSET(CPU_FTR_EMB_HV) +#else +#define KVM_BOOKE_HV_MFSPR(reg, spr) +#endif Bleks - this is ugly. Do we really need to open-code the #ifdef here? Can't the feature section code determine that the feature is disabled and just always not include the code? You can't but in any case I don't see the point of the conditional here, we'll eventually have to load srr1 no ? We can move the load up to here in all cases or can't we ? I like the idea, but there is a problem with addition macros which may clobber r11 and PROLOG_ADDITION_MASKABLE_GEN is such a case. If really not, we could have it inside DO_KVM and be done with it no ? 32-bit exception prolog loads srr1 unconditionally, as Alex and Scott mentioned earlier, so we will be suboptimal for this case. -Mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Qemu-ppc] [RFC PATCH 12/17] PowerPC: booke64: Add DO_KVM kernel hooks
On 07.07.2012, at 00:33, Caraman Mihai Claudiu-B02008 wrote: -Original Message- From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] Sent: Thursday, July 05, 2012 1:26 AM To: Alexander Graf Cc: Caraman Mihai Claudiu-B02008; kvm-...@vger.kernel.org; KVM list; linuxppc-dev; qemu-...@nongnu.org List Subject: Re: [Qemu-ppc] [RFC PATCH 12/17] PowerPC: booke64: Add DO_KVM kernel hooks On Wed, 2012-07-04 at 16:29 +0200, Alexander Graf wrote: +#ifdef CONFIG_KVM_BOOKE_HV +#define KVM_BOOKE_HV_MFSPR(reg, spr) \ + BEGIN_FTR_SECTION \ + mfspr reg, spr; \ + END_FTR_SECTION_IFSET(CPU_FTR_EMB_HV) +#else +#define KVM_BOOKE_HV_MFSPR(reg, spr) +#endif Bleks - this is ugly. Do we really need to open-code the #ifdef here? Can't the feature section code determine that the feature is disabled and just always not include the code? You can't but in any case I don't see the point of the conditional here, we'll eventually have to load srr1 no ? We can move the load up to here in all cases or can't we ? I like the idea, but there is a problem with addition macros which may clobber r11 and PROLOG_ADDITION_MASKABLE_GEN is such a case. Mike -v please :) Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
