* Re: [PATCH powerpc 2/2] kfree the cache name of pgtable cache if SLUB is used
From: Christoph Lameter @ 2012-07-03 20:36 UTC (permalink / raw)
To: Li Zhong
Cc: LKML, Pekka Enberg, linux-mm, Paul Mackerras, Matt Mackall,
PowerPC email list
In-Reply-To: <alpine.DEB.2.00.1207031344240.14703@router.home>
Looking through the emails it seems that there is an issue with alias
strings. That can be solved by duping the name of the slab earlier in kmem_cache_create().
Does this patch fix the issue?
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 <cl@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.c 2012-06-11 08:49:56.000000000 -0500
+++ linux-2.6/mm/slub.c 2012-07-03 15:17:37.000000000 -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
^ permalink raw reply
* Re: [PATCH -v5 0/6] notifier error injection
From: Andrew Morton @ 2012-07-03 20:41 UTC (permalink / raw)
To: Akinobu Mita
Cc: Dave Jones, Greg KH, linux-kernel, Rafael J. Wysocki, linux-mm,
Paul Mackerras, Pavel Machek, Américo Wang, linux-pm,
linuxppc-dev
In-Reply-To: <1341035970-20490-1-git-send-email-akinobu.mita@gmail.com>
On Sat, 30 Jun 2012 14:59:24 +0900
Akinobu Mita <akinobu.mita@gmail.com> wrote:
> This provides kernel modules that can be used to test the error handling
> of notifier call chain failures by injecting artifical errors to the
> following notifier chain callbacks.
No updates to Documentation/fault-injection/?
^ permalink raw reply
* Re: [PATCH][v3] PPC: use CURRENT_THREAD_INFO instead of open coded assembly
From: Benjamin Herrenschmidt @ 2012-07-04 3:04 UTC (permalink / raw)
To: Stuart Yoder; +Cc: linuxppc-dev, agraf
In-Reply-To: <1341328312-17102-1-git-send-email-stuart.yoder@freescale.com>
On Tue, 2012-07-03 at 10:11 -0500, Stuart Yoder wrote:
> From: Stuart Yoder <stuart.yoder@freescale.com>
>
> Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com>
> ---
>
> -v3
> -moved CURRENT_THREAD_INFO out from under the assembly only
> #define as per comments on mailing list
> -reversed logic of 64-bit #ifdef for CURRENT_THREAD_INFO
> macro
Almost there :-)
> #define RUNLATCH_ON \
> BEGIN_FTR_SECTION \
> - clrrdi r3,r1,THREAD_SHIFT; \
> + CURRENT_THREAD_INFO(r3, r1) \
Missing semicolon (in a macro you need it)
> ld r4,TI_LOCAL_FLAGS(r3); \
> andi. r0,r4,_TLF_RUNLATCH; \
> beql ppc64_runlatch_on_trampoline; \
> @@ -332,7 +332,7 @@ label##_common: \
> #ifdef CONFIG_PPC_970_NAP
> #define FINISH_NAP \
> BEGIN_FTR_SECTION \
> - clrrdi r11,r1,THREAD_SHIFT; \
> + CURRENT_THREAD_INFO(r11, r1) \
Same
> --- a/arch/powerpc/kernel/exceptions-64e.S
> +++ b/arch/powerpc/kernel/exceptions-64e.S
> @@ -222,7 +222,7 @@ exc_##n##_bad_stack: \
> * interrupts happen before the wait instruction.
> */
> #define CHECK_NAPPING() \
> - clrrdi r11,r1,THREAD_SHIFT; \
> + CURRENT_THREAD_INFO(r11, r1)
Missing both semicolon and backslash
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v7 1/5] powerpc/85xx: implement hardware timebase sync
From: Zhao Chenhui @ 2012-07-04 3:14 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: Wood Scott-B07421, Zhao Chenhui-B35336,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAOZdJXUeY-_mmBLoA25_g4eLqwHxYX4c_ECbU+KYqfM307THNQ@mail.gmail.com>
On Tue, Jul 03, 2012 at 07:46:24AM -0500, Tabi Timur-B04825 wrote:
> On Tue, Jul 3, 2012 at 5:21 AM, Zhao Chenhui <chenhui.zhao@freescale.com> wrote:
>
> > + np = of_find_matching_node(NULL, mpc85xx_smp_guts_ids);
> > + if (np) {
> > + guts = of_iomap(np, 0);
> > + of_node_put(np);
> > + if (!guts) {
> > + pr_err("%s: Could not map guts node address\n",
> > + __func__);
> > + return;
> > + }
> > + smp_85xx_ops.give_timebase = mpc85xx_give_timebase;
> > + smp_85xx_ops.take_timebase = mpc85xx_take_timebase;
> > + }
>
> I had this in mind:
>
> guts = of_iomap(np, 0);
> of_node_put(np);
> if (guts) {
> smp_85xx_ops.give_timebase = mpc85xx_give_timebase;
> smp_85xx_ops.take_timebase = mpc85xx_take_timebase;
> } else {
> pr_err("%s: Could not map guts node address\n",
> __func__);
> }
>
> That way, a missing GUTS node does not break everything.
>
If the guts variable is NULL, it indicates there is error in dts or kernel.
We should fix the error, rather than ignore it.
Moreover, if smp_85xx_ops.give/take_timebase is NULL, kernel can not do the timebase sync.
-Chenhui
^ permalink raw reply
* Re: [PATCH v7 1/5] powerpc/85xx: implement hardware timebase sync
From: Tabi Timur-B04825 @ 2012-07-04 3:17 UTC (permalink / raw)
To: Zhao Chenhui-B35336
Cc: Wood Scott-B07421, Li Yang-R58472, Zhao Chenhui-B35336,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20120704031426.GA6133@localhost.localdomain>
Zhao Chenhui wrote:
> If the guts variable is NULL, it indicates there is error in dts or kerne=
l.
> We should fix the error, rather than ignore it.
And that's why there's a warning message. Crashing the kernel is not=20
going to fix anything.
> Moreover, if smp_85xx_ops.give/take_timebase is NULL, kernel can not do t=
he timebase sync.
Is that necessary for the kernel to boot?
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH v7 1/5] powerpc/85xx: implement hardware timebase sync
From: Zhao Chenhui @ 2012-07-04 3:45 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: Wood Scott-B07421, Li Yang-R58472, Zhao Chenhui-B35336,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4FF3B5B6.8090400@freescale.com>
On Tue, Jul 03, 2012 at 10:17:12PM -0500, Tabi Timur-B04825 wrote:
> Zhao Chenhui wrote:
> > If the guts variable is NULL, it indicates there is error in dts or kernel.
> > We should fix the error, rather than ignore it.
>
> And that's why there's a warning message. Crashing the kernel is not
> going to fix anything.
>
This error likely crashes the kenel somewhere.
> > Moreover, if smp_85xx_ops.give/take_timebase is NULL, kernel can not do the timebase sync.
>
> Is that necessary for the kernel to boot?
>
No. But in the cpu hotplug context, we need do the timebase sync.
-Chenhui
^ permalink raw reply
* Re: [RFC PATCH v2 4/13] memory-hotplug : remove /sys/firmware/memmap/X sysfs
From: Yasuaki Ishimatsu @ 2012-07-04 4:45 UTC (permalink / raw)
To: Wen Congyang
Cc: len.brown, linux-acpi, linux-kernel, linux-mm, paulus,
minchan.kim, kosaki.motohiro, rientjes, cl, linuxppc-dev, akpm,
liuj97
In-Reply-To: <4FF2929B.7030004@cn.fujitsu.com>
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 <rientjes@google.com>
>> CC: Jiang Liu <liuj97@gmail.com>
>> CC: Len Brown <len.brown@intel.com>
>> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> CC: Paul Mackerras <paulus@samba.org>
>> CC: Christoph Lameter <cl@linux.com>
>> Cc: Minchan Kim <minchan.kim@gmail.com>
>> CC: Andrew Morton <akpm@linux-foundation.org>
>> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>> Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@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.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.
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 *entry)
>> +{
>> + list_del(&entry->list);
>> +}
>> +
>> /*
>> * Add memmap entry on sysfs
>> */
>> @@ -144,6 +163,31 @@ static int add_sysfs_fw_map_entry(struct
>> return 0;
>> }
>>
>> +/*
>> + * Remove memmap entry on sysfs
>> + */
>> +static inline void remove_sysfs_fw_map_entry(struct firmware_map_entry *entry)
>> +{
>> + kobject_put(&entry->kobj);
>> +}
>> +
>> +/*
>> + * Search memmap entry
>> + */
>> +
>> +struct firmware_map_entry * __meminit
>> +find_firmware_map_entry(u64 start, u64 end, const char *type)
>> +{
>> + struct firmware_map_entry *entry;
>> +
>> + list_for_each_entry(entry, &map_entries, list)
>> + if ((entry->start == start) && (entry->end == end) &&
>> + (!strcmp(entry->type, type)))
>> + return entry;
>> +
>> + return NULL;
>> +}
>> +
>> /**
>> * firmware_map_add_hotplug() - Adds a firmware mapping entry when we do
>> * memory hotplug.
>> @@ -196,6 +240,32 @@ int __init firmware_map_add_early(u64 st
>> return firmware_map_add_entry(start, end, type, entry);
>> }
>>
>> +/**
>> + * firmware_map_remove() - remove a firmware mapping entry
>> + * @start: Start of the memory range.
>> + * @end: End of the memory range (inclusive).
>> + * @type: Type of the memory range.
>> + *
>> + * removes a firmware mapping entry.
>> + *
>> + * Returns 0 on success, or -EINVAL if no entry.
>> + **/
>> +int __meminit firmware_map_remove(u64 start, u64 end, const char *type)
>> +{
>> + struct firmware_map_entry *entry;
>> +
>> + entry = find_firmware_map_entry(start, end, type);
>> + if (!entry)
>> + return -EINVAL;
>> +
>> + /* remove the memmap entry */
>> + remove_sysfs_fw_map_entry(entry);
>> +
>> + firmware_map_remove_entry(entry);
>> +
>> + return 0;
>> +}
>> +
>> /*
>> * Sysfs functions -------------------------------------------------------------
>> */
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: [RFC PATCH v2 4/13] memory-hotplug : remove /sys/firmware/memmap/X sysfs
From: Wen Congyang @ 2012-07-04 5:08 UTC (permalink / raw)
To: Yasuaki Ishimatsu
Cc: len.brown, linux-acpi, linux-kernel, linux-mm, paulus,
minchan.kim, kosaki.motohiro, rientjes, cl, linuxppc-dev, akpm,
liuj97
In-Reply-To: <4FF3CA65.1020300@jp.fujitsu.com>
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 <rientjes@google.com>
>>> CC: Jiang Liu <liuj97@gmail.com>
>>> CC: Len Brown <len.brown@intel.com>
>>> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>> CC: Paul Mackerras <paulus@samba.org>
>>> CC: Christoph Lameter <cl@linux.com>
>>> Cc: Minchan Kim <minchan.kim@gmail.com>
>>> CC: Andrew Morton <akpm@linux-foundation.org>
>>> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>>> Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@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.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.
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 *entry)
>>> +{
>>> + list_del(&entry->list);
>>> +}
>>> +
>>> /*
>>> * Add memmap entry on sysfs
>>> */
>>> @@ -144,6 +163,31 @@ static int add_sysfs_fw_map_entry(struct
>>> return 0;
>>> }
>>>
>>> +/*
>>> + * Remove memmap entry on sysfs
>>> + */
>>> +static inline void remove_sysfs_fw_map_entry(struct firmware_map_entry *entry)
>>> +{
>>> + kobject_put(&entry->kobj);
>>> +}
>>> +
>>> +/*
>>> + * Search memmap entry
>>> + */
>>> +
>>> +struct firmware_map_entry * __meminit
>>> +find_firmware_map_entry(u64 start, u64 end, const char *type)
>>> +{
>>> + struct firmware_map_entry *entry;
>>> +
>>> + list_for_each_entry(entry, &map_entries, list)
>>> + if ((entry->start == start) && (entry->end == end) &&
>>> + (!strcmp(entry->type, type)))
>>> + return entry;
>>> +
>>> + return NULL;
>>> +}
>>> +
>>> /**
>>> * firmware_map_add_hotplug() - Adds a firmware mapping entry when we do
>>> * memory hotplug.
>>> @@ -196,6 +240,32 @@ int __init firmware_map_add_early(u64 st
>>> return firmware_map_add_entry(start, end, type, entry);
>>> }
>>>
>>> +/**
>>> + * firmware_map_remove() - remove a firmware mapping entry
>>> + * @start: Start of the memory range.
>>> + * @end: End of the memory range (inclusive).
>>> + * @type: Type of the memory range.
>>> + *
>>> + * removes a firmware mapping entry.
>>> + *
>>> + * Returns 0 on success, or -EINVAL if no entry.
>>> + **/
>>> +int __meminit firmware_map_remove(u64 start, u64 end, const char *type)
>>> +{
>>> + struct firmware_map_entry *entry;
>>> +
>>> + entry = find_firmware_map_entry(start, end, type);
>>> + if (!entry)
>>> + return -EINVAL;
>>> +
>>> + /* remove the memmap entry */
>>> + remove_sysfs_fw_map_entry(entry);
>>> +
>>> + firmware_map_remove_entry(entry);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> /*
>>> * Sysfs functions -------------------------------------------------------------
>>> */
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at http://www.tux.org/lkml/
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
>
>
>
^ permalink raw reply
* [PATCH] tty/hvc_opal: Fix debug function name
From: Benjamin Herrenschmidt @ 2012-07-04 5:52 UTC (permalink / raw)
To: linuxppc-dev
udbg_init_debug_opal() should be udbg_init_debug_opal_raw() as
the caller in arch/powerpc/kernel/udbg.c expects
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/tty/hvc/hvc_opal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/hvc/hvc_opal.c b/drivers/tty/hvc/hvc_opal.c
index ced26c8..0d2ea0c 100644
--- a/drivers/tty/hvc/hvc_opal.c
+++ b/drivers/tty/hvc/hvc_opal.c
@@ -401,7 +401,7 @@ out:
}
#ifdef CONFIG_PPC_EARLY_DEBUG_OPAL_RAW
-void __init udbg_init_debug_opal(void)
+void __init udbg_init_debug_opal_raw(void)
{
u32 index = CONFIG_PPC_EARLY_DEBUG_OPAL_VTERMNO;
hvc_opal_privs[index] = &hvc_opal_boot_priv;
^ permalink raw reply related
* Re: [RFC PATCH v2 4/13] memory-hotplug : remove /sys/firmware/memmap/X sysfs
From: Yasuaki Ishimatsu @ 2012-07-04 5:52 UTC (permalink / raw)
To: Wen Congyang
Cc: len.brown, linux-acpi, linux-kernel, linux-mm, paulus,
minchan.kim, kosaki.motohiro, rientjes, cl, linuxppc-dev, akpm,
liuj97
In-Reply-To: <4FF3CFDC.50802@cn.fujitsu.com>
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 <rientjes@google.com>
>>>> CC: Jiang Liu <liuj97@gmail.com>
>>>> CC: Len Brown <len.brown@intel.com>
>>>> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>>> CC: Paul Mackerras <paulus@samba.org>
>>>> CC: Christoph Lameter <cl@linux.com>
>>>> Cc: Minchan Kim <minchan.kim@gmail.com>
>>>> CC: Andrew Morton <akpm@linux-foundation.org>
>>>> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>>>> Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@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.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.
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 *entry)
>>>> +{
>>>> + list_del(&entry->list);
>>>> +}
>>>> +
>>>> /*
>>>> * Add memmap entry on sysfs
>>>> */
>>>> @@ -144,6 +163,31 @@ static int add_sysfs_fw_map_entry(struct
>>>> return 0;
>>>> }
>>>>
>>>> +/*
>>>> + * Remove memmap entry on sysfs
>>>> + */
>>>> +static inline void remove_sysfs_fw_map_entry(struct firmware_map_entry *entry)
>>>> +{
>>>> + kobject_put(&entry->kobj);
>>>> +}
>>>> +
>>>> +/*
>>>> + * Search memmap entry
>>>> + */
>>>> +
>>>> +struct firmware_map_entry * __meminit
>>>> +find_firmware_map_entry(u64 start, u64 end, const char *type)
>>>> +{
>>>> + struct firmware_map_entry *entry;
>>>> +
>>>> + list_for_each_entry(entry, &map_entries, list)
>>>> + if ((entry->start == start) && (entry->end == end) &&
>>>> + (!strcmp(entry->type, type)))
>>>> + return entry;
>>>> +
>>>> + return NULL;
>>>> +}
>>>> +
>>>> /**
>>>> * firmware_map_add_hotplug() - Adds a firmware mapping entry when we do
>>>> * memory hotplug.
>>>> @@ -196,6 +240,32 @@ int __init firmware_map_add_early(u64 st
>>>> return firmware_map_add_entry(start, end, type, entry);
>>>> }
>>>>
>>>> +/**
>>>> + * firmware_map_remove() - remove a firmware mapping entry
>>>> + * @start: Start of the memory range.
>>>> + * @end: End of the memory range (inclusive).
>>>> + * @type: Type of the memory range.
>>>> + *
>>>> + * removes a firmware mapping entry.
>>>> + *
>>>> + * Returns 0 on success, or -EINVAL if no entry.
>>>> + **/
>>>> +int __meminit firmware_map_remove(u64 start, u64 end, const char *type)
>>>> +{
>>>> + struct firmware_map_entry *entry;
>>>> +
>>>> + entry = find_firmware_map_entry(start, end, type);
>>>> + if (!entry)
>>>> + return -EINVAL;
>>>> +
>>>> + /* remove the memmap entry */
>>>> + remove_sysfs_fw_map_entry(entry);
>>>> +
>>>> + firmware_map_remove_entry(entry);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> /*
>>>> * Sysfs functions -------------------------------------------------------------
>>>> */
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>> Please read the FAQ at http://www.tux.org/lkml/
>>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at http://www.tux.org/lkml/
>>>
>>
>>
>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* [PATCH] powerpc: Move and fix MTMSR_EERI definition
From: Benjamin Herrenschmidt @ 2012-07-04 5:59 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev
Move this duplicated definition to ppc_asm.h and remove the
braces which prevent the use of %rN register names
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Alex: This is needed to fix the build with Mikey's patch series
that enforce proper register name usage in assembly files.
I'm about to merge the whole lot in powerpc -next, possibly
tomorrow. I've pushed it all to my "test" branch on k.org for
now so I can still rebase.
Please check with whatever you have pending in your or avi's
-next as it's possible that there will be build breakage...
If there is and you can send me a fix, I will slip it in before
the patch that turns on the enforcement, so please have a look
at what I have in 'test' asap.
arch/powerpc/include/asm/ppc_asm.h | 2 ++
arch/powerpc/kvm/book3s_rmhandlers.S | 1 -
arch/powerpc/kvm/book3s_segment.S | 2 --
3 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/ppc_asm.h b/arch/powerpc/include/asm/ppc_asm.h
index 2c7edd5..d4c589b 100644
--- a/arch/powerpc/include/asm/ppc_asm.h
+++ b/arch/powerpc/include/asm/ppc_asm.h
@@ -475,6 +475,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_601)
#ifdef CONFIG_PPC_BOOK3S_64
#define RFI rfid
#define MTMSRD(r) mtmsrd r
+#define MTMSR_EERI(reg) mtmsrd reg,1
#else
#define FIX_SRR1(ra, rb)
#ifndef CONFIG_40x
@@ -483,6 +484,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_601)
#define RFI rfi; b . /* Prevent prefetch past rfi */
#endif
#define MTMSRD(r) mtmsr r
+#define MTMSR_EERI(reg) mtmsr reg
#define CLR_TOP32(r)
#endif
diff --git a/arch/powerpc/kvm/book3s_rmhandlers.S b/arch/powerpc/kvm/book3s_rmhandlers.S
index 3418758..ab523f3 100644
--- a/arch/powerpc/kvm/book3s_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_rmhandlers.S
@@ -37,7 +37,6 @@
#if defined(CONFIG_PPC_BOOK3S_64)
#define FUNC(name) GLUE(.,name)
-#define MTMSR_EERI(reg) mtmsrd (reg),1
.globl kvmppc_skip_interrupt
kvmppc_skip_interrupt:
diff --git a/arch/powerpc/kvm/book3s_segment.S b/arch/powerpc/kvm/book3s_segment.S
index 798491a..1abe478 100644
--- a/arch/powerpc/kvm/book3s_segment.S
+++ b/arch/powerpc/kvm/book3s_segment.S
@@ -23,7 +23,6 @@
#define GET_SHADOW_VCPU(reg) \
mr reg, r13
-#define MTMSR_EERI(reg) mtmsrd (reg),1
#elif defined(CONFIG_PPC_BOOK3S_32)
@@ -31,7 +30,6 @@
tophys(reg, r2); \
lwz reg, (THREAD + THREAD_KVM_SVCPU)(reg); \
tophys(reg, reg)
-#define MTMSR_EERI(reg) mtmsr (reg)
#endif
^ permalink raw reply related
* [PATCH] cpuidle:(POWER) Fixes for pseries_idle hotplug notifier
From: Deepthi Dharwar @ 2012-07-04 6:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt, PowerPC email list
In-Reply-To: <1341351841.2346.11.camel@pasglop>
cpuidle:(POWER) Fixes for pseries_idle hotplug notifier
From: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
Currently the call to pseries_notify_cpuidle_add_cpu(), that takes
action on the cpuidle front when a cpu is added/removed
is being made from smp_xics_setup_cpu().
This caused lockdep issues as
reported https://lkml.org/lkml/2012/5/17/2
On addition of each cpu,
resources were cleared and re-allocated each time, all in critical
section as part of start_secondary() call were interrupts are disabled.
To resolve this issue, the pseries_notify_cpuidle_add_cpu() call is
is being replaced by a hotplug notifier which
would prevent cpuidle resources from being
released and allocated each time cpu is onlined in the critical code path.
It was fixed in https://lkml.org/lkml/2012/5/18/174.
Also it is essential to call cpuidle_enable/disable_device
between cpuidle_pause_and_lock() and
cpuidle_resume_and_unlock() when used externally
to avoid race conditions. Add support for CPU_ONLINE_FROZEN
and CPU_DEAD_FROZEN as part of hotplug notify event for
pseries_idle and unregister hotplug notifier
while exiting out. The above mentioned issues
are fixed as part of this patch.
Signed-off-by: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
---
This applies on 3.5-rc5.
arch/powerpc/platforms/pseries/processor_idle.c | 23 ++++++++++++++++++-----
1 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/processor_idle.c b/arch/powerpc/platforms/pseries/processor_idle.c
index a97ef66..d2d2d85 100644
--- a/arch/powerpc/platforms/pseries/processor_idle.c
+++ b/arch/powerpc/platforms/pseries/processor_idle.c
@@ -194,13 +194,25 @@ static int pseries_cpuidle_add_cpu_notifier(struct notifier_block *n,
struct cpuidle_device *dev =
per_cpu_ptr(pseries_cpuidle_devices, hotcpu);
- switch (action & 0xf) {
- case CPU_ONLINE:
- if (dev && cpuidle_get_driver()) {
- cpuidle_disable_device(dev);
+ if (dev && cpuidle_get_driver()) {
+ switch (action) {
+ case CPU_ONLINE:
+ case CPU_ONLINE_FROZEN:
+ cpuidle_pause_and_lock();
cpuidle_enable_device(dev);
+ cpuidle_resume_and_unlock();
+ break;
+
+ case CPU_DEAD:
+ case CPU_DEAD_FROZEN:
+ cpuidle_pause_and_lock();
+ cpuidle_disable_device(dev);
+ cpuidle_resume_and_unlock();
+ break;
+
+ default:
+ return NOTIFY_DONE;
}
- break;
}
return NOTIFY_OK;
}
@@ -342,6 +354,7 @@ static int __init pseries_processor_idle_init(void)
static void __exit pseries_processor_idle_exit(void)
{
+ unregister_cpu_notifier(&setup_hotplug_notifier);
pseries_idle_devices_uninit();
cpuidle_unregister_driver(&pseries_idle_driver);
Cheers,
Deepthi
^ permalink raw reply related
* rionet driver with MMIO DMA capability
From: Vineeth @ 2012-07-04 6:15 UTC (permalink / raw)
To: linux-embedded, linuxppc-dev, linuxppc-embedded, Scott Wood,
mporter
Cc: ranenikhil19
[-- Attachment #1: Type: text/plain, Size: 715 bytes --]
Hi,
With kernel mainstream version 3.5.rc-5 there's SRIO low level driver with
DMA support for MMIO. But the rionet driver in the same kernel version
doesnt support MMIO.
We are trying to find the maximum bandwidth that we can achieve using our
custom board's(quad MPC8641 ) 4-lane SRIO.
Now we are worried how to use this SRIO low level driver effectively ?
The RIOnet driver (with 3.5.-rc5) uses message based communication. This
doesnt use the DMA capability of low level driver. with this we are getting
a bandwidth of nearly 900Mbps, which is very less.
Is there any example code or modified middle ware driver for rionet/ or any
code which uses the low level driver apis with MMIO DMA??
Thanks
Vineeth
[-- Attachment #2: Type: text/html, Size: 782 bytes --]
^ permalink raw reply
* [PATCH] powerpc: Add a symbol for hypervisor trampolines
From: Michael Ellerman @ 2012-07-04 6:29 UTC (permalink / raw)
To: linuxppc-dev
Purely for cosmetic purposes, otherwise it can appear that we are in
single_step_pSeries() which is slightly confusing.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/exceptions-64s.S | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 1c06d29..211b28d 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -239,6 +239,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_REAL_LE)
* out of line to handle them
*/
. = 0xe00
+hv_exception_trampoline:
b h_data_storage_hv
. = 0xe20
b h_instr_storage_hv
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH powerpc 2/2] kfree the cache name of pgtable cache if SLUB is used
From: Li Zhong @ 2012-07-04 9:00 UTC (permalink / raw)
To: Christoph Lameter
Cc: LKML, Pekka Enberg, linux-mm, Paul Mackerras, Matt Mackall,
PowerPC email list
In-Reply-To: <alpine.DEB.2.00.1207031535330.14703@router.home>
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);
And from my understanding of the code, the saved_alias list, which is
used to keep track of the alias entries during early boot (slab_state <
SYSFS), is a blocker. It needs the name string to be valid until
slab_sysfs_init() is finished.
> That can be solved by duping the name of the slab earlier in kmem_cache_create().
> Does this patch fix the issue?
I'm afraid not...
With the patch below, we still need to kfree the duplicated name in
slab_sysfs_init().
And I think it would be easier to understand if we duplicate the name
string when creating one entry for saved_alias list, and kfree it when
we remove one entry from saved_alias list.
I'm not sure whether you got the patch #1 of the two I sent previously.
If not, would you kindly spend some time reviewing it to see if I missed
anything? Link below for your convenience:
https://lkml.org/lkml/2012/6/27/83
Btw, as Ben suggested, I'm now working on duplicating the name string in
SLAB to make them consistent, so we don't need the #ifdef CONFIG_SLUB
any more. Will send it out for your review after it is finished.
> 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 <cl@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.c 2012-06-11 08:49:56.000000000 -0500
> +++ linux-2.6/mm/slub.c 2012-07-03 15:17:37.000000000 -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
>
^ permalink raw reply
* Re: [RFC PATCH v2 4/13] memory-hotplug : remove /sys/firmware/memmap/X sysfs
From: Wen Congyang @ 2012-07-04 10:01 UTC (permalink / raw)
To: Yasuaki Ishimatsu
Cc: len.brown, linux-acpi, linux-kernel, linux-mm, paulus,
minchan.kim, kosaki.motohiro, rientjes, cl, linuxppc-dev, akpm,
liuj97
In-Reply-To: <4FF3DA1E.9060505@jp.fujitsu.com>
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 <rientjes@google.com>
>>>>> CC: Jiang Liu <liuj97@gmail.com>
>>>>> CC: Len Brown <len.brown@intel.com>
>>>>> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>>>> CC: Paul Mackerras <paulus@samba.org>
>>>>> CC: Christoph Lameter <cl@linux.com>
>>>>> Cc: Minchan Kim <minchan.kim@gmail.com>
>>>>> CC: Andrew Morton <akpm@linux-foundation.org>
>>>>> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>>>>> Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@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.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).
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 *entry)
>>>>> +{
>>>>> + list_del(&entry->list);
>>>>> +}
>>>>> +
>>>>> /*
>>>>> * Add memmap entry on sysfs
>>>>> */
>>>>> @@ -144,6 +163,31 @@ static int add_sysfs_fw_map_entry(struct
>>>>> return 0;
>>>>> }
>>>>>
>>>>> +/*
>>>>> + * Remove memmap entry on sysfs
>>>>> + */
>>>>> +static inline void remove_sysfs_fw_map_entry(struct firmware_map_entry *entry)
>>>>> +{
>>>>> + kobject_put(&entry->kobj);
>>>>> +}
>>>>> +
>>>>> +/*
>>>>> + * Search memmap entry
>>>>> + */
>>>>> +
>>>>> +struct firmware_map_entry * __meminit
>>>>> +find_firmware_map_entry(u64 start, u64 end, const char *type)
>>>>> +{
>>>>> + struct firmware_map_entry *entry;
>>>>> +
>>>>> + list_for_each_entry(entry, &map_entries, list)
>>>>> + if ((entry->start == start) && (entry->end == end) &&
>>>>> + (!strcmp(entry->type, type)))
>>>>> + return entry;
>>>>> +
>>>>> + return NULL;
>>>>> +}
>>>>> +
>>>>> /**
>>>>> * firmware_map_add_hotplug() - Adds a firmware mapping entry when we do
>>>>> * memory hotplug.
>>>>> @@ -196,6 +240,32 @@ int __init firmware_map_add_early(u64 st
>>>>> return firmware_map_add_entry(start, end, type, entry);
>>>>> }
>>>>>
>>>>> +/**
>>>>> + * firmware_map_remove() - remove a firmware mapping entry
>>>>> + * @start: Start of the memory range.
>>>>> + * @end: End of the memory range (inclusive).
>>>>> + * @type: Type of the memory range.
>>>>> + *
>>>>> + * removes a firmware mapping entry.
>>>>> + *
>>>>> + * Returns 0 on success, or -EINVAL if no entry.
>>>>> + **/
>>>>> +int __meminit firmware_map_remove(u64 start, u64 end, const char *type)
>>>>> +{
>>>>> + struct firmware_map_entry *entry;
>>>>> +
>>>>> + entry = find_firmware_map_entry(start, end, type);
>>>>> + if (!entry)
>>>>> + return -EINVAL;
>>>>> +
>>>>> + /* remove the memmap entry */
>>>>> + remove_sysfs_fw_map_entry(entry);
>>>>> +
>>>>> + firmware_map_remove_entry(entry);
>>>>> +
>>>>> + return 0;
>>>>> +}
>>>>> +
>>>>> /*
>>>>> * Sysfs functions -------------------------------------------------------------
>>>>> */
>>>>>
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>> Please read the FAQ at http://www.tux.org/lkml/
>>>>>
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>> Please read the FAQ at http://www.tux.org/lkml/
>>>>
>>>
>>>
>>>
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
>
>
>
^ permalink raw reply
* Re: [PATCH -v5 0/6] notifier error injection
From: Akinobu Mita @ 2012-07-04 10:07 UTC (permalink / raw)
To: Andrew Morton
Cc: Dave Jones, Greg KH, linux-kernel, Rafael J. Wysocki, linux-mm,
Paul Mackerras, Pavel Machek, Américo Wang, linux-pm,
linuxppc-dev
In-Reply-To: <20120703134120.dc89c7ae.akpm@linux-foundation.org>
2012/7/4 Andrew Morton <akpm@linux-foundation.org>:
> On Sat, 30 Jun 2012 14:59:24 +0900
> Akinobu Mita <akinobu.mita@gmail.com> wrote:
>
>> This provides kernel modules that can be used to test the error handling
>> of notifier call chain failures by injecting artifical errors to the
>> following notifier chain callbacks.
>
> No updates to Documentation/fault-injection/?
Thanks for the remainder.
I'll prepare to add a document to it.
^ permalink raw reply
* Re: [PATCH powerpc 2/2] kfree the cache name of pgtable cache if SLUB is used
From: Glauber Costa @ 2012-07-04 12:40 UTC (permalink / raw)
To: Li Zhong
Cc: LKML, Pekka Enberg, linux-mm, Paul Mackerras, Matt Mackall,
Christoph Lameter, PowerPC email list
In-Reply-To: <1341392420.18505.41.camel@ThinkPad-T420>
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.
^ permalink raw reply
* Re: [RFC PATCH 02/17] KVM: PPC64: booke: Add EPCR support in mtspr/mfspr emulation
From: Alexander Graf @ 2012-07-04 13:21 UTC (permalink / raw)
To: Mihai Caraman; +Cc: qemu-ppc, linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1340627195-11544-3-git-send-email-mihai.caraman@freescale.com>
On 25.06.2012, at 14:26, Mihai Caraman wrote:
> Add EPCR support in booke mtspr/mfspr emulation. EPCR register is =
defined
> only for 64-bit and HV categories, so it shoud be available only on =
64-bit
> virtual processors. Undefine the support for 32-bit builds.
> Define a reusable setter function for vcpu's EPCR.
>=20
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> ---
> arch/powerpc/kvm/booke.c | 12 +++++++++++-
> arch/powerpc/kvm/booke.h | 6 ++++++
> arch/powerpc/kvm/booke_emulate.c | 13 ++++++++++++-
> 3 files changed, 29 insertions(+), 2 deletions(-)
>=20
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index 72f13f4..f9fa260 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -13,7 +13,7 @@
> * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA =
02110-1301, USA.
> *
> * Copyright IBM Corp. 2007
> - * Copyright 2010-2011 Freescale Semiconductor, Inc.
> + * Copyright 2010-2012 Freescale Semiconductor, Inc.
> *
> * Authors: Hollis Blanchard <hollisb@us.ibm.com>
> * Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
> @@ -1243,6 +1243,16 @@ void kvmppc_core_commit_memory_region(struct =
kvm *kvm,
> {
> }
>=20
> +#ifdef CONFIG_64BIT
> +void kvmppc_set_epcr(struct kvm_vcpu *vcpu, u32 new_epcr)
> +{
> + vcpu->arch.epcr =3D new_epcr;
> + vcpu->arch.shadow_epcr &=3D ~SPRN_EPCR_GICM;
> + if (vcpu->arch.epcr & SPRN_EPCR_ICM)
> + vcpu->arch.shadow_epcr |=3D SPRN_EPCR_GICM;
Why would the setter be #ifdef CONFIG_64BIT? EPCR exists on e500mc too, =
no? Please only #ifdef the GICM bits out.
Alex
^ permalink raw reply
* Re: [RFC PATCH 01/17] KVM: PPC64: booke: Set interrupt computation mode for 64-bit host
From: Alexander Graf @ 2012-07-04 13:22 UTC (permalink / raw)
To: Mihai Caraman; +Cc: qemu-ppc, linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1340627195-11544-2-git-send-email-mihai.caraman@freescale.com>
On 25.06.2012, at 14:26, Mihai Caraman wrote:
> 64-bit host needs to remain in 64-bit mode when an exception take place.
> Set interrupt computaion mode in EPCR register.
>
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
Thanks, applied to kvm-ppc-next.
Alex
^ permalink raw reply
* Re: [Qemu-ppc] [RFC PATCH 03/17] KVM: PPC64: booke: Add EPCR support in sregs
From: Alexander Graf @ 2012-07-04 13:33 UTC (permalink / raw)
To: Mihai Caraman; +Cc: qemu-ppc, linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1340627195-11544-4-git-send-email-mihai.caraman@freescale.com>
On 25.06.2012, at 14:26, Mihai Caraman wrote:
> Add KVM_SREGS_E_64 feature and EPCR spr support in get/set sregs
> for 64-bit hosts.
Please also implement a ONE_REG interface while at it. Over time, I'd =
like to move towards ONE_REG instead of the messy regs/sregs API.
Alex
^ permalink raw reply
* Re: [Qemu-ppc] [RFC PATCH 04/17] KVM: PPC64: booke: Add guest computation mode for irq delivery
From: Alexander Graf @ 2012-07-04 13:40 UTC (permalink / raw)
To: Mihai Caraman; +Cc: qemu-ppc, linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1340627195-11544-5-git-send-email-mihai.caraman@freescale.com>
On 25.06.2012, at 14:26, Mihai Caraman wrote:
> When delivering guest IRQs, update MSR computaion
computation
> mode according to guest
> interrupt computation mode found in EPCR.
>=20
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> ---
> arch/powerpc/kvm/booke.c | 8 +++++++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>=20
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index d15c4b5..93b48e0 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -287,6 +287,7 @@ static int kvmppc_booke_irqprio_deliver(struct =
kvm_vcpu *vcpu,
> bool crit;
> bool keep_irq =3D false;
> enum int_class int_class;
> + ulong msr_cm =3D 0;
>=20
> /* Truncate crit indicators in 32 bit mode */
> if (!(vcpu->arch.shared->msr & MSR_SF)) {
> @@ -299,6 +300,10 @@ static int kvmppc_booke_irqprio_deliver(struct =
kvm_vcpu *vcpu,
> /* ... and we're in supervisor mode */
> crit =3D crit && !(vcpu->arch.shared->msr & MSR_PR);
>=20
> +#ifdef CONFIG_64BIT
> + msr_cm =3D vcpu->arch.epcr & SPRN_EPCR_ICM ? MSR_CM : 0;
> +#endif
No need for the ifdef, no?. Just mask EPCR_ICM out in the 32-bit host =
case, then this check is always false on 32-bit hosts.
> +
> if (priority =3D=3D BOOKE_IRQPRIO_EXTERNAL_LEVEL) {
> priority =3D BOOKE_IRQPRIO_EXTERNAL;
> keep_irq =3D true;
> @@ -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 =3D=3D 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 =3D vcpu->arch.shared->msr;
if (vcpu->arch.epcr & SPRN_EPCR_ICM)
new_msr |=3D MSR_CM;
new_msr &=3D msr_mask;
kvmppc_set_msr(vcpu, new_msr);
Alex
^ permalink raw reply
* Re: [Qemu-ppc] [RFC PATCH 05/17] KVM: PPC: booke: Extend MAS2 EPN mask for 64-bit
From: Alexander Graf @ 2012-07-04 13:49 UTC (permalink / raw)
To: Mihai Caraman; +Cc: qemu-ppc, linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1340627195-11544-6-git-send-email-mihai.caraman@freescale.com>
On 25.06.2012, at 14:26, Mihai Caraman wrote:
> Extend MAS2 EPN mask for 64-bit hosts, to retain most significant =
bits.
> Change get tlb eaddr to use this mask.
Please see section 6.11.4.8 in the PowerISA 2.06b:
MMU behavior is largely unaffected by whether the thread is in 32-bit =
computation mode (MSRCM=3D0) or 64- bit computation mode (MSRCM=3D1). =
The only differ- ences occur in the EPN field of the TLB entry and the =
EPN field of MAS2. The differences are summarized here.
=95 Executing a tlbwe instruction in 32-bit mode will set bits =
0:31 of the TLB EPN field to zero unless MAS0ATSEL is set, in which case =
those bits are not written to zero.
=95 In 32-bit implementations, MAS2U can be used to read or =
write EPN0:31 of MAS2.
So if MSR.CM is not set tlbwe should mask the upper 32 bits out - which =
can happen regardless of CONFIG_64BIT.
Also, we need to implement MAS2U, to potentially make the upper 32bits =
of MAS2 available, right? But that one isn't as important as the first =
bit.
Alex
^ permalink raw reply
* Re: [RFC PATCH 06/17] KVM: PPC: e500: Add emulation helper for getting instruction ea
From: Alexander Graf @ 2012-07-04 13:56 UTC (permalink / raw)
To: Mihai Caraman; +Cc: qemu-ppc, linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1340627195-11544-7-git-send-email-mihai.caraman@freescale.com>
On 25.06.2012, at 14:26, Mihai Caraman wrote:
> Add emulation helper for getting instruction ea and refactor tlb =
instruction
> emulation to use it.
>=20
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> ---
> arch/powerpc/kvm/e500.h | 6 +++---
> arch/powerpc/kvm/e500_emulate.c | 21 ++++++++++++++++++---
> arch/powerpc/kvm/e500_tlb.c | 23 ++++++-----------------
> 3 files changed, 27 insertions(+), 23 deletions(-)
>=20
> diff --git a/arch/powerpc/kvm/e500.h b/arch/powerpc/kvm/e500.h
> index 3e31098..70bfed4 100644
> --- a/arch/powerpc/kvm/e500.h
> +++ b/arch/powerpc/kvm/e500.h
> @@ -130,9 +130,9 @@ int kvmppc_e500_emul_mt_mmucsr0(struct =
kvmppc_vcpu_e500 *vcpu_e500,
> ulong value);
> int kvmppc_e500_emul_tlbwe(struct kvm_vcpu *vcpu);
> int kvmppc_e500_emul_tlbre(struct kvm_vcpu *vcpu);
> -int kvmppc_e500_emul_tlbivax(struct kvm_vcpu *vcpu, int ra, int rb);
> -int kvmppc_e500_emul_tlbilx(struct kvm_vcpu *vcpu, int rt, int ra, =
int rb);
> -int kvmppc_e500_emul_tlbsx(struct kvm_vcpu *vcpu, int rb);
> +int kvmppc_e500_emul_tlbivax(struct kvm_vcpu *vcpu, gva_t ea);
> +int kvmppc_e500_emul_tlbilx(struct kvm_vcpu *vcpu, int rt, gva_t ea);
> +int kvmppc_e500_emul_tlbsx(struct kvm_vcpu *vcpu, gva_t ea);
> int kvmppc_e500_tlb_init(struct kvmppc_vcpu_e500 *vcpu_e500);
> void kvmppc_e500_tlb_uninit(struct kvmppc_vcpu_e500 *vcpu_e500);
>=20
> diff --git a/arch/powerpc/kvm/e500_emulate.c =
b/arch/powerpc/kvm/e500_emulate.c
> index 8b99e07..81288f7 100644
> --- a/arch/powerpc/kvm/e500_emulate.c
> +++ b/arch/powerpc/kvm/e500_emulate.c
> @@ -82,6 +82,17 @@ static int kvmppc_e500_emul_msgsnd(struct kvm_vcpu =
*vcpu, int rb)
> }
> #endif
>=20
> +static inline ulong kvmppc_get_ea_indexed(struct kvm_vcpu *vcpu, int =
ra, int rb)
> +{
> + ulong ea;
> +
> + ea =3D kvmppc_get_gpr(vcpu, rb);
> + if (ra)
> + ea +=3D kvmppc_get_gpr(vcpu, ra);
> +
> + return ea;
> +}
> +
Please move this one to arch/powerpc/include/asm/kvm_ppc.h.
> int kvmppc_core_emulate_op(struct kvm_run *run, struct kvm_vcpu *vcpu,
> unsigned int inst, int *advance)
> {
> @@ -89,6 +100,7 @@ int kvmppc_core_emulate_op(struct kvm_run *run, =
struct kvm_vcpu *vcpu,
> int ra =3D get_ra(inst);
> int rb =3D get_rb(inst);
> int rt =3D get_rt(inst);
> + gva_t ea;
>=20
> switch (get_op(inst)) {
> case 31:
> @@ -113,15 +125,18 @@ int kvmppc_core_emulate_op(struct kvm_run *run, =
struct kvm_vcpu *vcpu,
> break;
>=20
> case XOP_TLBSX:
> - emulated =3D kvmppc_e500_emul_tlbsx(vcpu,rb);
> + ea =3D kvmppc_get_ea_indexed(vcpu, ra, rb);
> + emulated =3D kvmppc_e500_emul_tlbsx(vcpu, ea);
> break;
>=20
> case XOP_TLBILX:
> - emulated =3D kvmppc_e500_emul_tlbilx(vcpu, rt, =
ra, rb);
> + ea =3D kvmppc_get_ea_indexed(vcpu, ra, rb);
> + emulated =3D kvmppc_e500_emul_tlbilx(vcpu, rt, =
ea);
What's the point in hiding ra+rb, but not rt? I like the idea of hiding =
the register semantics, but please move rt into a local variable that =
gets passed as pointer to kvmppc_e500_emul_tlbilx.
Alex
^ permalink raw reply
* Re: [Qemu-ppc] [RFC PATCH 07/17] KVM: PPC: e500: Mask ea's high 32-bits in 32/64 instr emulation
From: Alexander Graf @ 2012-07-04 14:00 UTC (permalink / raw)
To: Mihai Caraman; +Cc: qemu-ppc, linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1340627195-11544-8-git-send-email-mihai.caraman@freescale.com>
On 25.06.2012, at 14:26, Mihai Caraman wrote:
> Mask high 32 bits of effective address in emulation layer, for guests =
running
> in 32-bit mode.
> MAS2's high-order 32 bits represents the upper 32 bits of the =
effective address
> of the page. Mask it too for tlbwe instruction emulation.
Ah, there is the tlbwe masking :). Please split this into 2 patches.
>=20
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> ---
> arch/powerpc/kvm/e500_emulate.c | 5 ++++-
> arch/powerpc/kvm/e500_tlb.c | 2 ++
> 2 files changed, 6 insertions(+), 1 deletions(-)
>=20
> diff --git a/arch/powerpc/kvm/e500_emulate.c =
b/arch/powerpc/kvm/e500_emulate.c
> index 81288f7..94305db 100644
> --- a/arch/powerpc/kvm/e500_emulate.c
> +++ b/arch/powerpc/kvm/e500_emulate.c
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (C) 2008-2011 Freescale Semiconductor, Inc. All rights =
reserved.
> + * Copyright (C) 2008-2012 Freescale Semiconductor, Inc. All rights =
reserved.
> *
> * Author: Yu Liu, <yu.liu@freescale.com>
> *
> @@ -90,6 +90,9 @@ static inline ulong kvmppc_get_ea_indexed(struct =
kvm_vcpu *vcpu, int ra, int rb)
> if (ra)
> ea +=3D kvmppc_get_gpr(vcpu, ra);
>=20
> + if (!(vcpu->arch.shared->msr & MSR_CM))
> + ea &=3D 0xffffffffUL;
Since this will be in generic code, please guard it with an #ifdef =
CONFIG_BOOKE.
Alex
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox