Re: [PATCH v2 04/10] DMA, CMA: support alignment constraint on cma region
On Thu, Jun 12, 2014 at 02:52:20PM +0900, Minchan Kim wrote:
On Thu, Jun 12, 2014 at 12:21:41PM +0900, Joonsoo Kim wrote:
ppc kvm's cma area management needs alignment constraint on
cma region. So support it to prepare generalization of cma area
management functionality.
Additionally, add some comments which tell us why alignment
constraint is needed on cma region.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 8a44c82..bc4c171 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -32,6 +32,7 @@
#include linux/swap.h
#include linux/mm_types.h
#include linux/dma-contiguous.h
+#include linux/log2.h
struct cma {
unsigned long base_pfn;
@@ -219,6 +220,7 @@ core_initcall(cma_init_reserved_areas);
* @size: Size of the reserved area (in bytes),
* @base: Base address of the reserved area optional, use 0 for any
* @limit: End address of the reserved memory (optional, 0 for any).
+ * @alignment: Alignment for the contiguous memory area, should be power
of 2
* @res_cma: Pointer to store the created cma region.
* @fixed: hint about where to place the reserved area
*
Pz, move the all description to new API function rather than internal one.
Reason I leave all description as is is that I will remove it in
following patch. I think that moving these makes patch bigger and hard
to review.
But, if it is necessary, I will do it. :)
@@ -233,15 +235,15 @@ core_initcall(cma_init_reserved_areas);
*/
static int __init __dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base, phys_addr_t limit,
+ phys_addr_t alignment,
struct cma **res_cma, bool fixed)
{
struct cma *cma = cma_areas[cma_area_count];
- phys_addr_t alignment;
int ret = 0;
- pr_debug(%s(size %lx, base %08lx, limit %08lx)\n, __func__,
-(unsigned long)size, (unsigned long)base,
-(unsigned long)limit);
+ pr_debug(%s(size %lx, base %08lx, limit %08lx align_order %08lx)\n,
Why is it called by align_order?
Oops... mistake.
I will fix it.
Thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 05/10] DMA, CMA: support arbitrary bitmap granularity
On Thu, Jun 12, 2014 at 12:21:42PM +0900, Joonsoo Kim wrote:
ppc kvm's cma region management requires arbitrary bitmap granularity,
since they want to reserve very large memory and manage this region
with bitmap that one bit for several pages to reduce management overheads.
So support arbitrary bitmap granularity for following generalization.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index bc4c171..9bc9340 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -38,6 +38,7 @@ struct cma {
unsigned long base_pfn;
unsigned long count;
unsigned long *bitmap;
+ int order_per_bit; /* Order of pages represented by one bit */
Hmm, I'm not sure it's good as *general* interface even though it covers
existing usecases.
It forces a cma area should be handled by same size unit. Right?
It's really important point for this patchset's motivation so I will stop
review and wait other opinions.
struct mutexlock;
};
@@ -157,9 +158,38 @@ void __init dma_contiguous_reserve(phys_addr_t limit)
static DEFINE_MUTEX(cma_mutex);
+static unsigned long cma_bitmap_aligned_mask(struct cma *cma, int
align_order)
+{
+ return (1 (align_order cma-order_per_bit)) - 1;
+}
+
+static unsigned long cma_bitmap_maxno(struct cma *cma)
+{
+ return cma-count cma-order_per_bit;
+}
+
+static unsigned long cma_bitmap_pages_to_bits(struct cma *cma,
+ unsigned long pages)
+{
+ return ALIGN(pages, 1 cma-order_per_bit) cma-order_per_bit;
+}
+
+static void clear_cma_bitmap(struct cma *cma, unsigned long pfn, int count)
+{
+ unsigned long bitmapno, nr_bits;
+
+ bitmapno = (pfn - cma-base_pfn) cma-order_per_bit;
+ nr_bits = cma_bitmap_pages_to_bits(cma, count);
+
+ mutex_lock(cma-lock);
+ bitmap_clear(cma-bitmap, bitmapno, nr_bits);
+ mutex_unlock(cma-lock);
+}
+
static int __init cma_activate_area(struct cma *cma)
{
- int bitmap_size = BITS_TO_LONGS(cma-count) * sizeof(long);
+ int bitmap_maxno = cma_bitmap_maxno(cma);
+ int bitmap_size = BITS_TO_LONGS(bitmap_maxno) * sizeof(long);
unsigned long base_pfn = cma-base_pfn, pfn = base_pfn;
unsigned i = cma-count pageblock_order;
struct zone *zone;
@@ -221,6 +251,7 @@ core_initcall(cma_init_reserved_areas);
* @base: Base address of the reserved area optional, use 0 for any
* @limit: End address of the reserved memory (optional, 0 for any).
* @alignment: Alignment for the contiguous memory area, should be power of 2
+ * @order_per_bit: Order of pages represented by one bit on bitmap.
* @res_cma: Pointer to store the created cma region.
* @fixed: hint about where to place the reserved area
*
@@ -235,7 +266,7 @@ core_initcall(cma_init_reserved_areas);
*/
static int __init __dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base, phys_addr_t limit,
- phys_addr_t alignment,
+ phys_addr_t alignment, int order_per_bit,
struct cma **res_cma, bool fixed)
{
struct cma *cma = cma_areas[cma_area_count];
@@ -269,6 +300,8 @@ static int __init
__dma_contiguous_reserve_area(phys_addr_t size,
base = ALIGN(base, alignment);
size = ALIGN(size, alignment);
limit = ~(alignment - 1);
+ /* size should be aligned with order_per_bit */
+ BUG_ON(!IS_ALIGNED(size PAGE_SHIFT, 1 order_per_bit));
/* Reserve memory */
if (base fixed) {
@@ -294,6 +327,7 @@ static int __init
__dma_contiguous_reserve_area(phys_addr_t size,
*/
cma-base_pfn = PFN_DOWN(base);
cma-count = size PAGE_SHIFT;
+ cma-order_per_bit = order_per_bit;
*res_cma = cma;
cma_area_count++;
@@ -313,7 +347,7 @@ int __init dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base,
{
int ret;
- ret = __dma_contiguous_reserve_area(size, base, limit, 0,
+ ret = __dma_contiguous_reserve_area(size, base, limit, 0, 0,
res_cma, fixed);
if (ret)
return ret;
@@ -324,13 +358,6 @@ int __init dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base,
return 0;
}
-static void clear_cma_bitmap(struct cma *cma, unsigned long pfn, int count)
-{
- mutex_lock(cma-lock);
- bitmap_clear(cma-bitmap, pfn - cma-base_pfn, count);
- mutex_unlock(cma-lock);
-}
-
/**
* dma_alloc_from_contiguous() - allocate pages from contiguous area
* @dev: Pointer to device for which the allocation is performed.
@@ -345,7 +372,8 @@ static void clear_cma_bitmap(struct cma *cma, unsigned
long pfn, int count)
static struct page *__dma_alloc_from_contiguous(struct cma *cma, int count,
Re: [PATCH v2 05/10] DMA, CMA: support arbitrary bitmap granularity
On Thu, Jun 12, 2014 at 03:06:10PM +0900, Minchan Kim wrote:
On Thu, Jun 12, 2014 at 12:21:42PM +0900, Joonsoo Kim wrote:
ppc kvm's cma region management requires arbitrary bitmap granularity,
since they want to reserve very large memory and manage this region
with bitmap that one bit for several pages to reduce management overheads.
So support arbitrary bitmap granularity for following generalization.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index bc4c171..9bc9340 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -38,6 +38,7 @@ struct cma {
unsigned long base_pfn;
unsigned long count;
unsigned long *bitmap;
+ int order_per_bit; /* Order of pages represented by one bit */
Hmm, I'm not sure it's good as *general* interface even though it covers
existing usecases.
It forces a cma area should be handled by same size unit. Right?
It's really important point for this patchset's motivation so I will stop
review and wait other opinions.
If you pass 0 to order_per_bit, you can manage cma area in every
size(page unit) you want. If you pass certain number to order_per_bit,
you can allocate and release cma area in multiple of such page order.
I think that this is more general implementation than previous versions.
Thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc, kexec: Fix Processor X is stuck issue during kexec from ST mode
Hi Srivatsa, On Sat, Jun 7, 2014 at 7:16 AM, Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com wrote: And with the following hunk added (which I had forgotten earlier), it worked just fine on powernv :-) How are the patches coming along? I just hung a machine here while attempting to kexec. It appears to have onlined all of the secondary threads, and then hung here: kexec: Waking offline cpu 1. kvm: enabling virtualization on CPU1 kexec: Waking offline cpu 2. kvm: enabling virtualization on CPU2 kexec: Waking offline cpu 3. kvm: enabling virtualization on CPU3 kexec: Waking offline cpu 5. kvm: enabling virtualization on CPU5 [...] kvm: enabling virtualization on CPU63 kexec: waiting for cpu 1 (physical 1) to enter OPAL kexec: waiting for cpu 2 (physical 2) to enter OPAL kexec: waiting for cpu 3 (physical 3) to enter OPAL I'm running benh's next branch as of thismorning, and SMT was off. Could you please post your latest patches a series? I will test them here. Cheers, Joel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 05/10] DMA, CMA: support arbitrary bitmap granularity
On Thu, Jun 12, 2014 at 03:43:55PM +0900, Joonsoo Kim wrote:
On Thu, Jun 12, 2014 at 03:06:10PM +0900, Minchan Kim wrote:
On Thu, Jun 12, 2014 at 12:21:42PM +0900, Joonsoo Kim wrote:
ppc kvm's cma region management requires arbitrary bitmap granularity,
since they want to reserve very large memory and manage this region
with bitmap that one bit for several pages to reduce management overheads.
So support arbitrary bitmap granularity for following generalization.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index bc4c171..9bc9340 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -38,6 +38,7 @@ struct cma {
unsigned long base_pfn;
unsigned long count;
unsigned long *bitmap;
+ int order_per_bit; /* Order of pages represented by one bit */
Hmm, I'm not sure it's good as *general* interface even though it covers
existing usecases.
It forces a cma area should be handled by same size unit. Right?
It's really important point for this patchset's motivation so I will stop
review and wait other opinions.
If you pass 0 to order_per_bit, you can manage cma area in every
size(page unit) you want. If you pass certain number to order_per_bit,
you can allocate and release cma area in multiple of such page order.
I think that this is more general implementation than previous versions.
Fair enough.
--
Kind regards,
Minchan Kim
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Reduce scariness of interrupt frames in stack traces
Some people see things like Exception: 501 in stack traces in dmesg and assume that means that something has gone badly wrong, when in fact Exception: 501 just means a device interrupt was taken. This changes Exception to interrupt to make it clearer that we are just recording the fact of a change in control flow rather than some error condition. Signed-off-by: Paul Mackerras pau...@samba.org --- arch/powerpc/kernel/process.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c index 31d0215..aa103dc 100644 --- a/arch/powerpc/kernel/process.c +++ b/arch/powerpc/kernel/process.c @@ -1577,7 +1577,7 @@ void show_stack(struct task_struct *tsk, unsigned long *stack) struct pt_regs *regs = (struct pt_regs *) (sp + STACK_FRAME_OVERHEAD); lr = regs-link; - printk(--- Exception: %lx at %pS\nLR = %pS\n, + printk(--- interrupt: %lx at %pS\nLR = %pS\n, regs-trap, (void *)regs-nip, (void *)lr); firstframe = 1; } -- 2.0.0.rc4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v1] fs2dt: Refine kdump device_tree sort
From: Yang Wei wei.y...@windriver.com
The commit b02d735bf was to rearrange the device-tree entries, and
assumed that these entries are sorted in the ascending order. but
acctually when I was validating kexec and kdump, the order of
serial node still is changed. We should not only compare the length
of directory name, but also compare the directory name, it would
ensure that the order of device node is really in ascending order.
Signed-off-by: Yang Wei wei.y...@windriver.com
---
kexec/fs2dt.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
It is validated on Freescale t4240qds.
diff --git a/kexec/fs2dt.c b/kexec/fs2dt.c
index 1e5f074..0bffaf5 100644
--- a/kexec/fs2dt.c
+++ b/kexec/fs2dt.c
@@ -479,6 +479,9 @@ static int comparefunc(const struct dirent **dentry1,
{
char *str1 = (*(struct dirent **)dentry1)-d_name;
char *str2 = (*(struct dirent **)dentry2)-d_name;
+ char* ptr1 = strchr(str1, '@');
+ char* ptr2 = strchr(str2, '@');
+ int len1, len2;
/*
* strcmp scans from left to right and fails to idetify for some
@@ -486,9 +489,13 @@ static int comparefunc(const struct dirent **dentry1,
* Therefore, we get the wrong sorted order like memory@1000 and
* memory@f00.
*/
- if (strchr(str1, '@') strchr(str2, '@')
- (strlen(str1) strlen(str2)))
- return 1;
+ if (ptr1 ptr2) {
+ len1 = ptr1 - str1;
+ len2 = ptr2 - str2;
+ if (!strncmp(str1, str2, len1 len2 ? len1: len2)
+ (strlen(str1) strlen(str2)))
+ return 1;
+ }
return strcmp(str1, str2);
}
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 05/10] DMA, CMA: support arbitrary bitmap granularity
On Thu, Jun 12, 2014 at 12:21:42PM +0900, Joonsoo Kim wrote:
ppc kvm's cma region management requires arbitrary bitmap granularity,
since they want to reserve very large memory and manage this region
with bitmap that one bit for several pages to reduce management overheads.
So support arbitrary bitmap granularity for following generalization.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
Acked-by: Minchan Kim minc...@kernel.org
Just a nit below.
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index bc4c171..9bc9340 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -38,6 +38,7 @@ struct cma {
unsigned long base_pfn;
unsigned long count;
unsigned long *bitmap;
+ int order_per_bit; /* Order of pages represented by one bit */
struct mutexlock;
};
@@ -157,9 +158,38 @@ void __init dma_contiguous_reserve(phys_addr_t limit)
static DEFINE_MUTEX(cma_mutex);
+static unsigned long cma_bitmap_aligned_mask(struct cma *cma, int
align_order)
+{
+ return (1 (align_order cma-order_per_bit)) - 1;
+}
+
+static unsigned long cma_bitmap_maxno(struct cma *cma)
+{
+ return cma-count cma-order_per_bit;
+}
+
+static unsigned long cma_bitmap_pages_to_bits(struct cma *cma,
+ unsigned long pages)
+{
+ return ALIGN(pages, 1 cma-order_per_bit) cma-order_per_bit;
+}
+
+static void clear_cma_bitmap(struct cma *cma, unsigned long pfn, int count)
+{
+ unsigned long bitmapno, nr_bits;
+
+ bitmapno = (pfn - cma-base_pfn) cma-order_per_bit;
+ nr_bits = cma_bitmap_pages_to_bits(cma, count);
+
+ mutex_lock(cma-lock);
+ bitmap_clear(cma-bitmap, bitmapno, nr_bits);
+ mutex_unlock(cma-lock);
+}
+
static int __init cma_activate_area(struct cma *cma)
{
- int bitmap_size = BITS_TO_LONGS(cma-count) * sizeof(long);
+ int bitmap_maxno = cma_bitmap_maxno(cma);
+ int bitmap_size = BITS_TO_LONGS(bitmap_maxno) * sizeof(long);
unsigned long base_pfn = cma-base_pfn, pfn = base_pfn;
unsigned i = cma-count pageblock_order;
struct zone *zone;
@@ -221,6 +251,7 @@ core_initcall(cma_init_reserved_areas);
* @base: Base address of the reserved area optional, use 0 for any
* @limit: End address of the reserved memory (optional, 0 for any).
* @alignment: Alignment for the contiguous memory area, should be power of 2
+ * @order_per_bit: Order of pages represented by one bit on bitmap.
* @res_cma: Pointer to store the created cma region.
* @fixed: hint about where to place the reserved area
*
@@ -235,7 +266,7 @@ core_initcall(cma_init_reserved_areas);
*/
static int __init __dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base, phys_addr_t limit,
- phys_addr_t alignment,
+ phys_addr_t alignment, int order_per_bit,
struct cma **res_cma, bool fixed)
{
struct cma *cma = cma_areas[cma_area_count];
@@ -269,6 +300,8 @@ static int __init
__dma_contiguous_reserve_area(phys_addr_t size,
base = ALIGN(base, alignment);
size = ALIGN(size, alignment);
limit = ~(alignment - 1);
+ /* size should be aligned with order_per_bit */
+ BUG_ON(!IS_ALIGNED(size PAGE_SHIFT, 1 order_per_bit));
/* Reserve memory */
if (base fixed) {
@@ -294,6 +327,7 @@ static int __init
__dma_contiguous_reserve_area(phys_addr_t size,
*/
cma-base_pfn = PFN_DOWN(base);
cma-count = size PAGE_SHIFT;
+ cma-order_per_bit = order_per_bit;
*res_cma = cma;
cma_area_count++;
@@ -313,7 +347,7 @@ int __init dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base,
{
int ret;
- ret = __dma_contiguous_reserve_area(size, base, limit, 0,
+ ret = __dma_contiguous_reserve_area(size, base, limit, 0, 0,
res_cma, fixed);
if (ret)
return ret;
@@ -324,13 +358,6 @@ int __init dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base,
return 0;
}
-static void clear_cma_bitmap(struct cma *cma, unsigned long pfn, int count)
-{
- mutex_lock(cma-lock);
- bitmap_clear(cma-bitmap, pfn - cma-base_pfn, count);
- mutex_unlock(cma-lock);
-}
-
/**
* dma_alloc_from_contiguous() - allocate pages from contiguous area
* @dev: Pointer to device for which the allocation is performed.
@@ -345,7 +372,8 @@ static void clear_cma_bitmap(struct cma *cma, unsigned
long pfn, int count)
static struct page *__dma_alloc_from_contiguous(struct cma *cma, int count,
unsigned int align)
{
- unsigned long mask, pfn, pageno, start = 0;
+ unsigned long mask, pfn, start = 0;
+ unsigned long bitmap_maxno, bitmapno,
Re: [PATCH v2 06/10] CMA: generalize CMA reserved area management functionality
On Thu, Jun 12, 2014 at 12:21:43PM +0900, Joonsoo Kim wrote:
Currently, there are two users on CMA functionality, one is the DMA
subsystem and the other is the kvm on powerpc. They have their own code
to manage CMA reserved area even if they looks really similar.
From my guess, it is caused by some needs on bitmap management. Kvm side
wants to maintain bitmap not for 1 page, but for more size. Eventually it
use bitmap where one bit represents 64 pages.
When I implement CMA related patches, I should change those two places
to apply my change and it seem to be painful to me. I want to change
this situation and reduce future code management overhead through
this patch.
This change could also help developer who want to use CMA in their
new feature development, since they can use CMA easily without
copying pasting this reserved area management code.
In previous patches, we have prepared some features to generalize
CMA reserved area management and now it's time to do it. This patch
moves core functions to mm/cma.c and change DMA APIs to use
these functions.
There is no functional change in DMA APIs.
v2: There is no big change from v1 in mm/cma.c. Mostly renaming.
Acked-by: Michal Nazarewicz min...@mina86.com
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
Acutally, I want to remove bool return of cma_release but it's not
a out of scope in this patchset.
Acked-by: Minchan Kim minc...@kernel.org
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 00e13ce..4eac559 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -283,16 +283,6 @@ config CMA_ALIGNMENT
If unsure, leave the default value 8.
-config CMA_AREAS
- int Maximum count of the CMA device-private areas
- default 7
- help
- CMA allows to create CMA areas for particular devices. This parameter
- sets the maximum number of such device private CMA areas in the
- system.
-
- If unsure, leave the default value 7.
-
endif
endmenu
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 9bc9340..f177f73 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -24,25 +24,10 @@
#include linux/memblock.h
#include linux/err.h
-#include linux/mm.h
-#include linux/mutex.h
-#include linux/page-isolation.h
#include linux/sizes.h
-#include linux/slab.h
-#include linux/swap.h
-#include linux/mm_types.h
#include linux/dma-contiguous.h
#include linux/log2.h
Should we remain log2.h in here?
-
-struct cma {
- unsigned long base_pfn;
- unsigned long count;
- unsigned long *bitmap;
- int order_per_bit; /* Order of pages represented by one bit */
- struct mutexlock;
-};
-
-struct cma *dma_contiguous_default_area;
+#include linux/cma.h
#ifdef CONFIG_CMA_SIZE_MBYTES
#define CMA_SIZE_MBYTES CONFIG_CMA_SIZE_MBYTES
@@ -50,6 +35,8 @@ struct cma *dma_contiguous_default_area;
#define CMA_SIZE_MBYTES 0
#endif
+struct cma *dma_contiguous_default_area;
+
/*
* Default global CMA area size can be defined in kernel's .config.
* This is useful mainly for distro maintainers to create a kernel
@@ -156,199 +143,13 @@ void __init dma_contiguous_reserve(phys_addr_t limit)
}
}
-static DEFINE_MUTEX(cma_mutex);
-
-static unsigned long cma_bitmap_aligned_mask(struct cma *cma, int
align_order)
-{
- return (1 (align_order cma-order_per_bit)) - 1;
-}
-
-static unsigned long cma_bitmap_maxno(struct cma *cma)
-{
- return cma-count cma-order_per_bit;
-}
-
-static unsigned long cma_bitmap_pages_to_bits(struct cma *cma,
- unsigned long pages)
-{
- return ALIGN(pages, 1 cma-order_per_bit) cma-order_per_bit;
-}
-
-static void clear_cma_bitmap(struct cma *cma, unsigned long pfn, int count)
-{
- unsigned long bitmapno, nr_bits;
-
- bitmapno = (pfn - cma-base_pfn) cma-order_per_bit;
- nr_bits = cma_bitmap_pages_to_bits(cma, count);
-
- mutex_lock(cma-lock);
- bitmap_clear(cma-bitmap, bitmapno, nr_bits);
- mutex_unlock(cma-lock);
-}
-
-static int __init cma_activate_area(struct cma *cma)
-{
- int bitmap_maxno = cma_bitmap_maxno(cma);
- int bitmap_size = BITS_TO_LONGS(bitmap_maxno) * sizeof(long);
- unsigned long base_pfn = cma-base_pfn, pfn = base_pfn;
- unsigned i = cma-count pageblock_order;
- struct zone *zone;
-
- pr_debug(%s()\n, __func__);
-
- cma-bitmap = kzalloc(bitmap_size, GFP_KERNEL);
- if (!cma-bitmap)
- return -ENOMEM;
-
- WARN_ON_ONCE(!pfn_valid(pfn));
- zone = page_zone(pfn_to_page(pfn));
-
- do {
- unsigned j;
- base_pfn = pfn;
- for (j = pageblock_nr_pages; j; --j, pfn++) {
- WARN_ON_ONCE(!pfn_valid(pfn));
- /*
- *
Re: [PATCH v2 08/10] mm, cma: clean-up cma allocation error path
On Thu, Jun 12, 2014 at 12:21:45PM +0900, Joonsoo Kim wrote: We can remove one call sites for clear_cma_bitmap() if we first call it before checking error number. Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com Acked-by: Minchan Kim minc...@kernel.org -- Kind regards, Minchan Kim ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 09/10] mm, cma: move output param to the end of param list
On Thu, Jun 12, 2014 at 12:21:46PM +0900, Joonsoo Kim wrote:
Conventionally, we put output param to the end of param list.
cma_declare_contiguous() doesn't look like that, so change it.
If you says Conventionally, I'd like to suggest one more thing.
Conventionally, we put 'base' ahead 'size' but dma_contiguous_reserve_area
is opposite.
Additionally, move down cma_areas reference code to the position
where it is really needed.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c
b/arch/powerpc/kvm/book3s_hv_builtin.c
index 28ec226..97613ea 100644
--- a/arch/powerpc/kvm/book3s_hv_builtin.c
+++ b/arch/powerpc/kvm/book3s_hv_builtin.c
@@ -184,7 +184,7 @@ void __init kvm_cma_reserve(void)
align_size = max(kvm_rma_pages PAGE_SHIFT, align_size);
cma_declare_contiguous(selected_size, 0, 0, align_size,
- KVM_CMA_CHUNK_ORDER - PAGE_SHIFT, kvm_cma, false);
+ KVM_CMA_CHUNK_ORDER - PAGE_SHIFT, false, kvm_cma);
}
}
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index f177f73..bfd4553 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -149,7 +149,7 @@ int __init dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base,
{
int ret;
- ret = cma_declare_contiguous(size, base, limit, 0, 0, res_cma, fixed);
+ ret = cma_declare_contiguous(size, base, limit, 0, 0, fixed, res_cma);
if (ret)
return ret;
diff --git a/include/linux/cma.h b/include/linux/cma.h
index e38efe9..e53eead 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -6,7 +6,7 @@ struct cma;
extern int __init cma_declare_contiguous(phys_addr_t size,
phys_addr_t base, phys_addr_t limit,
phys_addr_t alignment, int order_per_bit,
- struct cma **res_cma, bool fixed);
+ bool fixed, struct cma **res_cma);
extern struct page *cma_alloc(struct cma *cma, int count, unsigned int
align);
extern bool cma_release(struct cma *cma, struct page *pages, int count);
#endif
diff --git a/mm/cma.c b/mm/cma.c
index 01a0713..22a5b23 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -142,8 +142,8 @@ core_initcall(cma_init_reserved_areas);
* @limit: End address of the reserved memory (optional, 0 for any).
* @alignment: Alignment for the contiguous memory area, should be power of 2
* @order_per_bit: Order of pages represented by one bit on bitmap.
- * @res_cma: Pointer to store the created cma region.
* @fixed: hint about where to place the reserved area
+ * @res_cma: Pointer to store the created cma region.
*
* This function reserves memory from early allocator. It should be
* called by arch specific code once the early allocator (memblock or
bootmem)
@@ -156,9 +156,9 @@ core_initcall(cma_init_reserved_areas);
int __init cma_declare_contiguous(phys_addr_t size,
phys_addr_t base, phys_addr_t limit,
phys_addr_t alignment, int order_per_bit,
- struct cma **res_cma, bool fixed)
+ bool fixed, struct cma **res_cma)
{
- struct cma *cma = cma_areas[cma_area_count];
+ struct cma *cma;
int ret = 0;
pr_debug(%s(size %lx, base %08lx, limit %08lx alignment %08lx)\n,
@@ -214,6 +214,7 @@ int __init cma_declare_contiguous(phys_addr_t size,
* Each reserved area must be initialised later, when more kernel
* subsystems (like slab allocator) are available.
*/
+ cma = cma_areas[cma_area_count];
cma-base_pfn = PFN_DOWN(base);
cma-count = size PAGE_SHIFT;
cma-order_per_bit = order_per_bit;
--
1.7.9.5
--
Kind regards,
Minchan Kim
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 05/10] DMA, CMA: support arbitrary bitmap granularity
On 06/12/2014 03:08 PM, Minchan Kim wrote:
On Thu, Jun 12, 2014 at 12:21:42PM +0900, Joonsoo Kim wrote:
ppc kvm's cma region management requires arbitrary bitmap granularity,
since they want to reserve very large memory and manage this region
with bitmap that one bit for several pages to reduce management overheads.
So support arbitrary bitmap granularity for following generalization.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
Acked-by: Minchan Kim minc...@kernel.org
Just a nit below.
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index bc4c171..9bc9340 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -38,6 +38,7 @@ struct cma {
unsigned long base_pfn;
unsigned long count;
unsigned long *bitmap;
+int order_per_bit; /* Order of pages represented by one bit */
struct mutexlock;
};
@@ -157,9 +158,38 @@ void __init dma_contiguous_reserve(phys_addr_t limit)
static DEFINE_MUTEX(cma_mutex);
+static unsigned long cma_bitmap_aligned_mask(struct cma *cma, int
align_order)
+{
+return (1 (align_order cma-order_per_bit)) - 1;
+}
+
+static unsigned long cma_bitmap_maxno(struct cma *cma)
+{
+return cma-count cma-order_per_bit;
+}
+
+static unsigned long cma_bitmap_pages_to_bits(struct cma *cma,
+unsigned long pages)
+{
+return ALIGN(pages, 1 cma-order_per_bit) cma-order_per_bit;
+}
+
+static void clear_cma_bitmap(struct cma *cma, unsigned long pfn, int count)
+{
+unsigned long bitmapno, nr_bits;
+
+bitmapno = (pfn - cma-base_pfn) cma-order_per_bit;
+nr_bits = cma_bitmap_pages_to_bits(cma, count);
+
+mutex_lock(cma-lock);
+bitmap_clear(cma-bitmap, bitmapno, nr_bits);
+mutex_unlock(cma-lock);
+}
+
static int __init cma_activate_area(struct cma *cma)
{
-int bitmap_size = BITS_TO_LONGS(cma-count) * sizeof(long);
+int bitmap_maxno = cma_bitmap_maxno(cma);
+int bitmap_size = BITS_TO_LONGS(bitmap_maxno) * sizeof(long);
unsigned long base_pfn = cma-base_pfn, pfn = base_pfn;
unsigned i = cma-count pageblock_order;
struct zone *zone;
@@ -221,6 +251,7 @@ core_initcall(cma_init_reserved_areas);
* @base: Base address of the reserved area optional, use 0 for any
* @limit: End address of the reserved memory (optional, 0 for any).
* @alignment: Alignment for the contiguous memory area, should be power of
2
+ * @order_per_bit: Order of pages represented by one bit on bitmap.
* @res_cma: Pointer to store the created cma region.
* @fixed: hint about where to place the reserved area
*
@@ -235,7 +266,7 @@ core_initcall(cma_init_reserved_areas);
*/
static int __init __dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base, phys_addr_t limit,
-phys_addr_t alignment,
+phys_addr_t alignment, int order_per_bit,
struct cma **res_cma, bool fixed)
{
struct cma *cma = cma_areas[cma_area_count];
@@ -269,6 +300,8 @@ static int __init
__dma_contiguous_reserve_area(phys_addr_t size,
base = ALIGN(base, alignment);
size = ALIGN(size, alignment);
limit = ~(alignment - 1);
+/* size should be aligned with order_per_bit */
+BUG_ON(!IS_ALIGNED(size PAGE_SHIFT, 1 order_per_bit));
/* Reserve memory */
if (base fixed) {
@@ -294,6 +327,7 @@ static int __init
__dma_contiguous_reserve_area(phys_addr_t size,
*/
cma-base_pfn = PFN_DOWN(base);
cma-count = size PAGE_SHIFT;
+cma-order_per_bit = order_per_bit;
*res_cma = cma;
cma_area_count++;
@@ -313,7 +347,7 @@ int __init dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base,
{
int ret;
-ret = __dma_contiguous_reserve_area(size, base, limit, 0,
+ret = __dma_contiguous_reserve_area(size, base, limit, 0, 0,
res_cma, fixed);
if (ret)
return ret;
@@ -324,13 +358,6 @@ int __init dma_contiguous_reserve_area(phys_addr_t
size, phys_addr_t base,
return 0;
}
-static void clear_cma_bitmap(struct cma *cma, unsigned long pfn, int count)
-{
-mutex_lock(cma-lock);
-bitmap_clear(cma-bitmap, pfn - cma-base_pfn, count);
-mutex_unlock(cma-lock);
-}
-
/**
* dma_alloc_from_contiguous() - allocate pages from contiguous area
* @dev: Pointer to device for which the allocation is performed.
@@ -345,7 +372,8 @@ static void clear_cma_bitmap(struct cma *cma, unsigned
long pfn, int count)
static struct page *__dma_alloc_from_contiguous(struct cma *cma, int count,
unsigned int align)
{
-unsigned long mask, pfn, pageno, start = 0;
+unsigned long mask, pfn, start = 0;
+unsigned long bitmap_maxno, bitmapno, nr_bits;
Re: [PATCH v2 05/10] DMA, CMA: support arbitrary bitmap granularity
On Thu, Jun 12, 2014 at 04:08:11PM +0900, Minchan Kim wrote:
On Thu, Jun 12, 2014 at 12:21:42PM +0900, Joonsoo Kim wrote:
ppc kvm's cma region management requires arbitrary bitmap granularity,
since they want to reserve very large memory and manage this region
with bitmap that one bit for several pages to reduce management overheads.
So support arbitrary bitmap granularity for following generalization.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
Acked-by: Minchan Kim minc...@kernel.org
Thanks.
[snip...]
/**
* dma_alloc_from_contiguous() - allocate pages from contiguous area
* @dev: Pointer to device for which the allocation is performed.
@@ -345,7 +372,8 @@ static void clear_cma_bitmap(struct cma *cma, unsigned
long pfn, int count)
static struct page *__dma_alloc_from_contiguous(struct cma *cma, int count,
unsigned int align)
{
- unsigned long mask, pfn, pageno, start = 0;
+ unsigned long mask, pfn, start = 0;
+ unsigned long bitmap_maxno, bitmapno, nr_bits;
Just Nit: bitmap_maxno, bitmap_no or something consistent.
I know you love consistent when I read description in first patch
in this patchset. ;-)
Yeah, I will fix it. :)
Thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 06/10] CMA: generalize CMA reserved area management functionality
On Thu, Jun 12, 2014 at 04:13:11PM +0900, Minchan Kim wrote: On Thu, Jun 12, 2014 at 12:21:43PM +0900, Joonsoo Kim wrote: Currently, there are two users on CMA functionality, one is the DMA subsystem and the other is the kvm on powerpc. They have their own code to manage CMA reserved area even if they looks really similar. From my guess, it is caused by some needs on bitmap management. Kvm side wants to maintain bitmap not for 1 page, but for more size. Eventually it use bitmap where one bit represents 64 pages. When I implement CMA related patches, I should change those two places to apply my change and it seem to be painful to me. I want to change this situation and reduce future code management overhead through this patch. This change could also help developer who want to use CMA in their new feature development, since they can use CMA easily without copying pasting this reserved area management code. In previous patches, we have prepared some features to generalize CMA reserved area management and now it's time to do it. This patch moves core functions to mm/cma.c and change DMA APIs to use these functions. There is no functional change in DMA APIs. v2: There is no big change from v1 in mm/cma.c. Mostly renaming. Acked-by: Michal Nazarewicz min...@mina86.com Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com Acutally, I want to remove bool return of cma_release but it's not a out of scope in this patchset. Acked-by: Minchan Kim minc...@kernel.org diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig index 00e13ce..4eac559 100644 --- a/drivers/base/Kconfig +++ b/drivers/base/Kconfig @@ -283,16 +283,6 @@ config CMA_ALIGNMENT If unsure, leave the default value 8. -config CMA_AREAS - int Maximum count of the CMA device-private areas - default 7 - help - CMA allows to create CMA areas for particular devices. This parameter - sets the maximum number of such device private CMA areas in the - system. - - If unsure, leave the default value 7. - endif endmenu diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c index 9bc9340..f177f73 100644 --- a/drivers/base/dma-contiguous.c +++ b/drivers/base/dma-contiguous.c @@ -24,25 +24,10 @@ #include linux/memblock.h #include linux/err.h -#include linux/mm.h -#include linux/mutex.h -#include linux/page-isolation.h #include linux/sizes.h -#include linux/slab.h -#include linux/swap.h -#include linux/mm_types.h #include linux/dma-contiguous.h #include linux/log2.h Should we remain log2.h in here? We should remove it. I will fix it. Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 09/10] mm, cma: move output param to the end of param list
On Thu, Jun 12, 2014 at 04:19:31PM +0900, Minchan Kim wrote: On Thu, Jun 12, 2014 at 12:21:46PM +0900, Joonsoo Kim wrote: Conventionally, we put output param to the end of param list. cma_declare_contiguous() doesn't look like that, so change it. If you says Conventionally, I'd like to suggest one more thing. Conventionally, we put 'base' ahead 'size' but dma_contiguous_reserve_area is opposite. Okay. I will do it. :) Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 10/10] mm, cma: use spinlock instead of mutex
On Thu, Jun 12, 2014 at 12:21:47PM +0900, Joonsoo Kim wrote:
Currently, we should take the mutex for manipulating bitmap.
This job may be really simple and short so we don't need to sleep
if contended. So I change it to spinlock.
I'm not sure it would be good always.
Maybe you remember we discussed about similar stuff about bitmap
searching in vmap friend internally, which was really painful
when it was fragmented. So, at least we need number if you really want
and I hope the number from ARM machine most popular platform for CMA
at the moment.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
diff --git a/mm/cma.c b/mm/cma.c
index 22a5b23..3085e8c 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -27,6 +27,7 @@
#include linux/memblock.h
#include linux/err.h
#include linux/mm.h
+#include linux/spinlock.h
#include linux/mutex.h
#include linux/sizes.h
#include linux/slab.h
@@ -36,7 +37,7 @@ struct cma {
unsigned long count;
unsigned long *bitmap;
int order_per_bit; /* Order of pages represented by one bit */
- struct mutexlock;
+ spinlock_t lock;
};
/*
@@ -72,9 +73,9 @@ static void clear_cma_bitmap(struct cma *cma, unsigned long
pfn, int count)
bitmapno = (pfn - cma-base_pfn) cma-order_per_bit;
nr_bits = cma_bitmap_pages_to_bits(cma, count);
- mutex_lock(cma-lock);
+ spin_lock(cma-lock);
bitmap_clear(cma-bitmap, bitmapno, nr_bits);
- mutex_unlock(cma-lock);
+ spin_unlock(cma-lock);
}
static int __init cma_activate_area(struct cma *cma)
@@ -112,7 +113,7 @@ static int __init cma_activate_area(struct cma *cma)
init_cma_reserved_pageblock(pfn_to_page(base_pfn));
} while (--i);
- mutex_init(cma-lock);
+ spin_lock_init(cma-lock);
return 0;
err:
@@ -261,11 +262,11 @@ struct page *cma_alloc(struct cma *cma, int count,
unsigned int align)
nr_bits = cma_bitmap_pages_to_bits(cma, count);
for (;;) {
- mutex_lock(cma-lock);
+ spin_lock(cma-lock);
bitmapno = bitmap_find_next_zero_area(cma-bitmap,
bitmap_maxno, start, nr_bits, mask);
if (bitmapno = bitmap_maxno) {
- mutex_unlock(cma-lock);
+ spin_unlock(cma-lock);
break;
}
bitmap_set(cma-bitmap, bitmapno, nr_bits);
@@ -274,7 +275,7 @@ struct page *cma_alloc(struct cma *cma, int count,
unsigned int align)
* our exclusive use. If the migration fails we will take the
* lock again and unmark it.
*/
- mutex_unlock(cma-lock);
+ spin_unlock(cma-lock);
pfn = cma-base_pfn + (bitmapno cma-order_per_bit);
mutex_lock(cma_mutex);
--
1.7.9.5
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a
--
Kind regards,
Minchan Kim
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 10/10] mm, cma: use spinlock instead of mutex
On Thu, Jun 12, 2014 at 04:40:29PM +0900, Minchan Kim wrote: On Thu, Jun 12, 2014 at 12:21:47PM +0900, Joonsoo Kim wrote: Currently, we should take the mutex for manipulating bitmap. This job may be really simple and short so we don't need to sleep if contended. So I change it to spinlock. I'm not sure it would be good always. Maybe you remember we discussed about similar stuff about bitmap searching in vmap friend internally, which was really painful when it was fragmented. So, at least we need number if you really want and I hope the number from ARM machine most popular platform for CMA at the moment. Good Point!! Agreed. I will drop this one in next spin and re-submit in separate patchset after some testing. Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: Avoid circular dependency with zImage.%
Dne 12.6.2014 04:07, Mike Qiu napsal(a): This v2 patch is good, Tested-by: Mike Qiu qiud...@linux.vnet.ibm.com Thanks. In kbuild.git it goes. Michal ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/4] KVM: PPC: Book3S PR: Fix ABIv2 issues
binutils knows that a branch to a function descriptor is actually a branch to the function text. By removing the explicit branch to dot symbols, we maintain both ABIv1 and ABIv2 compatibility. Signed-off-by: Anton Blanchard an...@samba.org --- Index: b/arch/powerpc/kvm/book3s_interrupts.S === --- a/arch/powerpc/kvm/book3s_interrupts.S +++ b/arch/powerpc/kvm/book3s_interrupts.S @@ -25,11 +25,9 @@ #include asm/exception-64s.h #if defined(CONFIG_PPC_BOOK3S_64) -#define FUNC(name) GLUE(.,name) #define GET_SHADOW_VCPU(reg)addi reg, r13, PACA_SVCPU #elif defined(CONFIG_PPC_BOOK3S_32) -#define FUNC(name) name #define GET_SHADOW_VCPU(reg) lwz reg, (THREAD + THREAD_KVM_SVCPU)(r2) #endif /* CONFIG_PPC_BOOK3S_XX */ @@ -93,7 +91,7 @@ kvm_start_entry: kvm_start_lightweight: /* Copy registers into shadow vcpu so we can access them in real mode */ GET_SHADOW_VCPU(r3) - bl FUNC(kvmppc_copy_to_svcpu) + bl kvmppc_copy_to_svcpu nop REST_GPR(4, r1) @@ -131,7 +129,7 @@ after_sprg3_load: PPC_LL r4, VCPU_SHADOW_MSR(r4) /* get shadow_msr */ /* Jump to segment patching handler and into our guest */ - bl FUNC(kvmppc_entry_trampoline) + bl kvmppc_entry_trampoline nop /* @@ -164,7 +162,7 @@ after_sprg3_load: /* On 64-bit, interrupts are still off at this point */ GET_SHADOW_VCPU(r4) - bl FUNC(kvmppc_copy_from_svcpu) + bl kvmppc_copy_from_svcpu nop #ifdef CONFIG_PPC_BOOK3S_64 @@ -203,7 +201,7 @@ after_sprg3_load: /* Restore r3 (kvm_run) and r4 (vcpu) */ REST_2GPRS(3, r1) - bl FUNC(kvmppc_handle_exit_pr) + bl kvmppc_handle_exit_pr /* If RESUME_GUEST, get back in the loop */ cmpwi r3, RESUME_GUEST Index: b/arch/powerpc/kvm/book3s_rmhandlers.S === --- a/arch/powerpc/kvm/book3s_rmhandlers.S +++ b/arch/powerpc/kvm/book3s_rmhandlers.S @@ -34,13 +34,7 @@ * * / -#if defined(CONFIG_PPC_BOOK3S_64) - -#define FUNC(name) GLUE(.,name) - -#elif defined(CONFIG_PPC_BOOK3S_32) - -#define FUNC(name) name +#ifdef CONFIG_PPC_BOOK3S_32 .macro INTERRUPT_TRAMPOLINE intno ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 01/10] DMA, CMA: clean-up log message
On 06/12/2014 11:21 AM, Joonsoo Kim wrote:
We don't need explicit 'CMA:' prefix, since we already define prefix
'cma:' in pr_fmt. So remove it.
And, some logs print function name and others doesn't. This looks
bad to me, so I unify log format to print function name consistently.
Lastly, I add one more debug log on cma_activate_area().
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
Reviewed-by: Zhang Yanfei zhangyan...@cn.fujitsu.com
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 83969f8..bd0bb81 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -144,7 +144,7 @@ void __init dma_contiguous_reserve(phys_addr_t limit)
}
if (selected_size !dma_contiguous_default_area) {
- pr_debug(%s: reserving %ld MiB for global area\n, __func__,
+ pr_debug(%s(): reserving %ld MiB for global area\n, __func__,
(unsigned long)selected_size / SZ_1M);
dma_contiguous_reserve_area(selected_size, selected_base,
@@ -163,8 +163,9 @@ static int __init cma_activate_area(struct cma *cma)
unsigned i = cma-count pageblock_order;
struct zone *zone;
- cma-bitmap = kzalloc(bitmap_size, GFP_KERNEL);
+ pr_debug(%s()\n, __func__);
+ cma-bitmap = kzalloc(bitmap_size, GFP_KERNEL);
if (!cma-bitmap)
return -ENOMEM;
@@ -234,7 +235,8 @@ int __init dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base,
/* Sanity checks */
if (cma_area_count == ARRAY_SIZE(cma_areas)) {
- pr_err(Not enough slots for CMA reserved regions!\n);
+ pr_err(%s(): Not enough slots for CMA reserved regions!\n,
+ __func__);
return -ENOSPC;
}
@@ -274,14 +276,15 @@ int __init dma_contiguous_reserve_area(phys_addr_t
size, phys_addr_t base,
*res_cma = cma;
cma_area_count++;
- pr_info(CMA: reserved %ld MiB at %08lx\n, (unsigned long)size / SZ_1M,
- (unsigned long)base);
+ pr_info(%s(): reserved %ld MiB at %08lx\n,
+ __func__, (unsigned long)size / SZ_1M, (unsigned long)base);
/* Architecture specific contiguous memory fixup. */
dma_contiguous_early_fixup(base, size);
return 0;
err:
- pr_err(CMA: failed to reserve %ld MiB\n, (unsigned long)size / SZ_1M);
+ pr_err(%s(): failed to reserve %ld MiB\n,
+ __func__, (unsigned long)size / SZ_1M);
return ret;
}
--
Thanks.
Zhang Yanfei
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/4] KVM: PPC: Book3S HV: Fix ABIv2 issues
binutils knows that a branch to a function descriptor is actually a branch to the function text. By removing the explicit branch to dot symbols, we maintain both ABIv1 and ABIv2 compatibility. Signed-off-by: Anton Blanchard an...@samba.org --- Index: b/arch/powerpc/kvm/book3s_hv_rmhandlers.S === --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S @@ -675,9 +675,9 @@ END_FTR_SECTION_IFCLR(CPU_FTR_TM) mr r31, r4 addir3, r31, VCPU_FPRS_TM - bl .load_fp_state + bl load_fp_state addir3, r31, VCPU_VRS_TM - bl .load_vr_state + bl load_vr_state mr r4, r31 lwz r7, VCPU_VRSAVE_TM(r4) mtspr SPRN_VRSAVE, r7 @@ -1421,9 +1421,9 @@ END_FTR_SECTION_IFCLR(CPU_FTR_TM) /* Save FP/VSX. */ addir3, r9, VCPU_FPRS_TM - bl .store_fp_state + bl store_fp_state addir3, r9, VCPU_VRS_TM - bl .store_vr_state + bl store_vr_state mfspr r6, SPRN_VRSAVE stw r6, VCPU_VRSAVE_TM(r9) 1: @@ -2421,11 +2421,11 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX) mtmsrd r8 isync addir3,r3,VCPU_FPRS - bl .store_fp_state + bl store_fp_state #ifdef CONFIG_ALTIVEC BEGIN_FTR_SECTION addir3,r31,VCPU_VRS - bl .store_vr_state + bl store_vr_state END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC) #endif mfspr r6,SPRN_VRSAVE @@ -2457,11 +2457,11 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX) mtmsrd r8 isync addir3,r4,VCPU_FPRS - bl .load_fp_state + bl load_fp_state #ifdef CONFIG_ALTIVEC BEGIN_FTR_SECTION addir3,r31,VCPU_VRS - bl .load_vr_state + bl load_vr_state END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC) #endif lwz r7,VCPU_VRSAVE(r31) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/4] KVM: PPC: Book3S HV: Fix ABIv2 indirect branch issue
To establish addressability quickly, ABIv2 requires the target address of the function being called to be in r12. Signed-off-by: Anton Blanchard an...@samba.org --- Index: b/arch/powerpc/kvm/book3s_hv_rmhandlers.S === --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S @@ -1920,8 +1920,8 @@ hcall_try_real_mode: lwaxr3,r3,r4 cmpwi r3,0 beq guest_exit_cont - add r3,r3,r4 - mtctr r3 + add r12,r3,r4 + mtctr r12 mr r3,r9 /* get vcpu pointer */ ld r4,VCPU_GPR(R4)(r9) bctrl ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/4] KVM: PPC: Assembly functions exported to modules need _GLOBAL_TOC()
Both kvmppc_hv_entry_trampoline and kvmppc_entry_trampoline are assembly functions that are exported to modules and also require a valid r2. As such we need to use _GLOBAL_TOC so we provide a global entry point that establishes the TOC (r2). Signed-off-by: Anton Blanchard an...@samba.org --- Index: b/arch/powerpc/kvm/book3s_hv_rmhandlers.S === --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S @@ -51,7 +51,7 @@ * * LR = return address to continue at after eventually re-enabling MMU */ -_GLOBAL(kvmppc_hv_entry_trampoline) +_GLOBAL_TOC(kvmppc_hv_entry_trampoline) mflrr0 std r0, PPC_LR_STKOFF(r1) stdur1, -112(r1) Index: b/arch/powerpc/kvm/book3s_rmhandlers.S === --- a/arch/powerpc/kvm/book3s_rmhandlers.S +++ b/arch/powerpc/kvm/book3s_rmhandlers.S @@ -140,7 +140,7 @@ kvmppc_handler_skip_ins: * On entry, r4 contains the guest shadow MSR * MSR.EE has to be 0 when calling this function */ -_GLOBAL(kvmppc_entry_trampoline) +_GLOBAL_TOC(kvmppc_entry_trampoline) mfmsr r5 LOAD_REG_ADDR(r7, kvmppc_handler_trampoline_enter) toreal(r7) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc, kexec: Fix Processor X is stuck issue during kexec from ST mode
Hi Joel,
On 06/12/2014 12:09 PM, Joel Stanley wrote:
Hi Srivatsa,
On Sat, Jun 7, 2014 at 7:16 AM, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
And with the following hunk added (which I had forgotten earlier), it worked
just
fine on powernv :-)
How are the patches coming along?
I'm still waiting to test this patch series on a PowerVM box, and unfortunately
there are some machine issues to debug first :-( So that's why this is taking
time... :-(
I just hung a machine here while attempting to kexec. It appears to
have onlined all of the secondary threads, and then hung here:
kexec: Waking offline cpu 1.
kvm: enabling virtualization on CPU1
kexec: Waking offline cpu 2.
kvm: enabling virtualization on CPU2
kexec: Waking offline cpu 3.
kvm: enabling virtualization on CPU3
kexec: Waking offline cpu 5.
kvm: enabling virtualization on CPU5
[...]
kvm: enabling virtualization on CPU63
kexec: waiting for cpu 1 (physical 1) to enter OPAL
kexec: waiting for cpu 2 (physical 2) to enter OPAL
kexec: waiting for cpu 3 (physical 3) to enter OPAL
I'm running benh's next branch as of thismorning, and SMT was off.
Oh! This looks like a different hang than the one I tried to fix. My patch
(powerpc, kexec: Fix Processor X is stuck issue during kexec from ST mode)
which is already in benh's next branch was aimed at fixing the CPU is stuck
issue which was observed during the second kernel boot. If the first kernel
itself is hanging in the down-path, then it looks like a different problem
altogether.
Could you please post your latest patches a series? I will test them here.
The 4 patches that I proposed in this thread are aimed at making the above
solution more elegant, by not having to actually online the secondary threads
while doing kexec. I don't think it will solve the hang that you are seeing.
In any case, I'll provide the consolidated patch below if you want to give it
a try.
By the way, I have a few questions regarding the hang you observed: is it
always reproducible with SMT=off? And if SMT was 8 (i.e, all CPUs in the system
were online) and then you did a kexec, do you still see the hang?
Regards,
Srivatsa S. Bhat
---
diff --git a/arch/powerpc/include/asm/kexec.h b/arch/powerpc/include/asm/kexec.h
index 16d7e33..2a31b52 100644
--- a/arch/powerpc/include/asm/kexec.h
+++ b/arch/powerpc/include/asm/kexec.h
@@ -68,6 +68,7 @@ static inline void crash_setup_regs(struct pt_regs *newregs,
ppc_save_regs(newregs);
}
+extern bool kexec_cpu_wake(void);
extern void kexec_smp_wait(void); /* get and clear naca physid, wait for
master to copy new code to 0 */
extern int crashing_cpu;
diff --git a/arch/powerpc/include/asm/machdep.h
b/arch/powerpc/include/asm/machdep.h
index f92b0b5..39f721d 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -255,6 +255,16 @@ struct machdep_calls {
void (*machine_shutdown)(void);
#ifdef CONFIG_KEXEC
+#if (defined CONFIG_PPC64) (defined CONFIG_PPC_BOOK3S)
+
+ /*
+* The pseries and powernv book3s platforms have a special requirement
+* that soft-offline CPUs have to be woken up before kexec, to avoid
+* CPUs getting stuck. This callback prepares the system for the
+* impending wakeup of the offline CPUs.
+*/
+ void (*kexec_wake_prepare)(void);
+#endif
void (*kexec_cpu_down)(int crash_shutdown, int secondary);
/* Called to do what every setup is needed on image and the
diff --git a/arch/powerpc/kernel/machine_kexec_64.c
b/arch/powerpc/kernel/machine_kexec_64.c
index 879b3aa..84e91293 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -182,6 +182,14 @@ static void kexec_smp_down(void *arg)
/* NOTREACHED */
}
+bool kexec_cpu_wake(void)
+{
+ kexec_smp_down(NULL);
+
+ /* NOTREACHED */
+ return true;
+}
+
static void kexec_prepare_cpus_wait(int wait_state)
{
int my_cpu, i, notified=-1;
@@ -202,7 +210,7 @@ static void kexec_prepare_cpus_wait(int wait_state)
* these possible-but-not-online-but-should-be CPUs and chaperone them
* into kexec_smp_wait().
*/
- for_each_online_cpu(i) {
+ for_each_present_cpu(i) {
if (i == my_cpu)
continue;
@@ -228,16 +236,22 @@ static void kexec_prepare_cpus_wait(int wait_state)
* threads as offline -- and again, these CPUs will be stuck.
*
* So, we online all CPUs that should be running, including secondary threads.
+ *
+ * TODO: Update this comment
*/
static void wake_offline_cpus(void)
{
int cpu = 0;
+ if (ppc_md.kexec_wake_prepare)
+ ppc_md.kexec_wake_prepare();
+
for_each_present_cpu(cpu) {
if (!cpu_online(cpu)) {
Re: [PATCH v2 02/10] DMA, CMA: fix possible memory leak
On 06/12/2014 02:02 PM, Joonsoo Kim wrote:
On Thu, Jun 12, 2014 at 02:25:43PM +0900, Minchan Kim wrote:
On Thu, Jun 12, 2014 at 12:21:39PM +0900, Joonsoo Kim wrote:
We should free memory for bitmap when we find zone mis-match,
otherwise this memory will leak.
Then, -stable stuff?
I don't think so. This is just possible leak candidate, so we don't
need to push this to stable tree.
Additionally, I copy code comment from ppc kvm's cma code to notify
why we need to check zone mis-match.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index bd0bb81..fb0cdce 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -177,14 +177,24 @@ static int __init cma_activate_area(struct cma *cma)
base_pfn = pfn;
for (j = pageblock_nr_pages; j; --j, pfn++) {
WARN_ON_ONCE(!pfn_valid(pfn));
+ /*
+* alloc_contig_range requires the pfn range
+* specified to be in the same zone. Make this
+* simple by forcing the entire CMA resv range
+* to be in the same zone.
+*/
if (page_zone(pfn_to_page(pfn)) != zone)
- return -EINVAL;
+ goto err;
At a first glance, I thought it would be better to handle such error
before activating.
So when I see the registration code(ie, dma_contiguous_revere_area),
I realized it is impossible because we didn't set up zone yet. :(
If so, when we detect to fail here, it would be better to report more
meaningful error message like what was successful zone and what is
new zone and failed pfn number?
What I want to do in early phase of this patchset is to make cma code
on DMA APIs similar to ppc kvm's cma code. ppc kvm's cma code already
has this error handling logic, so I make this patch.
If we think that we need more things, we can do that on general cma code
after merging this patchset.
Yeah, I also like the idea. After all, this patchset aims to a general CMA
management, we could improve more after this patchset. So
Acked-by: Zhang Yanfei zhangyan...@cn.fujitsu.com
--
Thanks.
Zhang Yanfei
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc, xmon: Enable hardware instruction breakpoint support on POWER8
On 06/04/2014 02:18 PM, Anshuman Khandual wrote:
On 06/03/2014 11:33 AM, Anshuman Khandual wrote:
On 05/30/2014 07:12 PM, Aneesh Kumar K.V wrote:
Anshuman Khandual khand...@linux.vnet.ibm.com writes:
This patch enables support for hardware instruction breakpoints on
POWER8 with
the help of a new register called CIABR (Completed Instruction Address
Breakpoint
Register). With this patch, single hardware instruction breakpoint can
be added
and cleared during any active xmon debug session. This hardware based
instruction
breakpoint mechanism works correctly along with the existing TRAP based
instruction
breakpoints available on xmon. Example usage as follows.
(A) Start xmon:
$echo x /proc/sysrq-trigger
SysRq : Entering xmon
cpu 0x0: Vector: 0 at [c01f6c67f960]
pc: c0072078: .sysrq_handle_xmon+0x58/0x60
lr: c0072078: .sysrq_handle_xmon+0x58/0x60
sp: c01f6c67fac0
msr: 90009032
current = 0xc01f6e709ac0
paca= 0xcfffa000 softe: 0irq_happened: 0x00
pid = 3250, comm = bash
enter ? for help
0:mon b
typeaddress
(B) Set the breakpoint:
0:mon ls .power_pmu_add
.power_pmu_add: c0078f50
0:mon bi c0078f50
0:mon b
typeaddress
1 inst c0078f50 .power_pmu_add+0x0/0x2e0
0:mon ls .perf_event_interrupt
.perf_event_interrupt: c007aee0
0:mon bi c007aee0
One instruction breakpoint possible with CIABR
0:mon x
(C) Run the workload (with the breakpoint):
$./perf record ls
cpu 0x2: Vector: d00 (Single Step) at [c01f718133a0]
pc: c0078f54: .power_pmu_add+0x4/0x2e0
lr: c0155be0: .event_sched_in+0x90/0x1d0
sp: c01f71813620
msr: 900040109032
current = 0xc01f6ce3
paca= 0xcfffa600 softe: 0irq_happened: 0x01
pid = 3270, comm = ls
std r22,-80(r1)
enter ? for help
(D) Clear the breakpoint:
2:mon bc
All breakpoints cleared
2:mon x
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.002 MB perf.data (~66 samples) ]
(E) Run the workload again (without any breakpoints):
$./perf record ls
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.001 MB perf.data (~61 samples) ]
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
---
arch/powerpc/xmon/xmon.c | 62
1 file changed, 58 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 3fd1d9a..f74ec83 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -48,6 +48,7 @@
#ifdef CONFIG_PPC64
#include asm/hvcall.h
#include asm/paca.h
+#include asm/plpar_wrappers.h
#endif
#include nonstdio.h
@@ -89,6 +90,7 @@ struct bpt {
/* Bits in bpt.enabled */
#define BP_IABR_TE 1 /* IABR translation enabled */
#define BP_IABR 2
+#define BP_CIABR4
#define BP_TRAP 8
#define BP_DABR 0x10
@@ -97,6 +99,7 @@ static struct bpt bpts[NBPTS];
static struct bpt dabr;
static struct bpt *iabr;
static unsigned bpinstr = 0x7fe8; /* trap */
+static bool ciabr_used = false; /* CIABR instruction breakpoint
*/
#define BP_NUM(bp) ((bp) - bpts + 1)
@@ -269,6 +272,34 @@ static inline void cinval(void *p)
asm volatile (dcbi 0,%0; icbi 0,%0 : : r (p));
}
+static void write_ciabr(unsigned long ciabr)
+{
+if (cpu_has_feature(CPU_FTR_HVMODE)) {
+mtspr(SPRN_CIABR, ciabr);
+return;
+}
+
+#ifdef CONFIG_PPC64
+plapr_set_ciabr(ciabr);
+#endif
+}
+
+static void set_ciabr(unsigned long addr)
+{
+addr = ~CIABR_PRIV;
+if (cpu_has_feature(CPU_FTR_HVMODE))
+addr |= CIABR_PRIV_HYPER;
+else
+addr |= CIABR_PRIV_SUPER;
+write_ciabr(addr);
+}
+
+static void clear_ciabr(void)
+{
+if (cpu_has_feature(CPU_FTR_ARCH_207S))
+write_ciabr(0);
+}
+
/*
* Disable surveillance (the service processor watchdog function)
* while we are in xmon.
@@ -764,6 +795,9 @@ static void insert_cpu_bpts(void)
if (iabr cpu_has_feature(CPU_FTR_IABR))
mtspr(SPRN_IABR, iabr-address
| (iabr-enabled (BP_IABR|BP_IABR_TE)));
+
+if (iabr cpu_has_feature(CPU_FTR_ARCH_207S))
+set_ciabr(iabr-address);
}
static void remove_bpts(void)
@@ -791,6 +825,7 @@ static void remove_cpu_bpts(void)
hw_breakpoint_disable();
if (cpu_has_feature(CPU_FTR_IABR))
mtspr(SPRN_IABR, 0);
+clear_ciabr();
}
/* Command interpreting routine */
@@ -1124,7 +1159,7 @@ static char *breakpoint_help_string =
b addr [cnt] set breakpoint at given instr addr\n
Re: [PATCH v2 05/10] DMA, CMA: support arbitrary bitmap granularity
On 06/12/2014 11:21 AM, Joonsoo Kim wrote:
ppc kvm's cma region management requires arbitrary bitmap granularity,
since they want to reserve very large memory and manage this region
with bitmap that one bit for several pages to reduce management overheads.
So support arbitrary bitmap granularity for following generalization.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
Acked-by: Zhang Yanfei zhangyan...@cn.fujitsu.com
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index bc4c171..9bc9340 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -38,6 +38,7 @@ struct cma {
unsigned long base_pfn;
unsigned long count;
unsigned long *bitmap;
+ int order_per_bit; /* Order of pages represented by one bit */
struct mutexlock;
};
@@ -157,9 +158,38 @@ void __init dma_contiguous_reserve(phys_addr_t limit)
static DEFINE_MUTEX(cma_mutex);
+static unsigned long cma_bitmap_aligned_mask(struct cma *cma, int
align_order)
+{
+ return (1 (align_order cma-order_per_bit)) - 1;
+}
+
+static unsigned long cma_bitmap_maxno(struct cma *cma)
+{
+ return cma-count cma-order_per_bit;
+}
+
+static unsigned long cma_bitmap_pages_to_bits(struct cma *cma,
+ unsigned long pages)
+{
+ return ALIGN(pages, 1 cma-order_per_bit) cma-order_per_bit;
+}
+
+static void clear_cma_bitmap(struct cma *cma, unsigned long pfn, int count)
+{
+ unsigned long bitmapno, nr_bits;
+
+ bitmapno = (pfn - cma-base_pfn) cma-order_per_bit;
+ nr_bits = cma_bitmap_pages_to_bits(cma, count);
+
+ mutex_lock(cma-lock);
+ bitmap_clear(cma-bitmap, bitmapno, nr_bits);
+ mutex_unlock(cma-lock);
+}
+
static int __init cma_activate_area(struct cma *cma)
{
- int bitmap_size = BITS_TO_LONGS(cma-count) * sizeof(long);
+ int bitmap_maxno = cma_bitmap_maxno(cma);
+ int bitmap_size = BITS_TO_LONGS(bitmap_maxno) * sizeof(long);
unsigned long base_pfn = cma-base_pfn, pfn = base_pfn;
unsigned i = cma-count pageblock_order;
struct zone *zone;
@@ -221,6 +251,7 @@ core_initcall(cma_init_reserved_areas);
* @base: Base address of the reserved area optional, use 0 for any
* @limit: End address of the reserved memory (optional, 0 for any).
* @alignment: Alignment for the contiguous memory area, should be power of 2
+ * @order_per_bit: Order of pages represented by one bit on bitmap.
* @res_cma: Pointer to store the created cma region.
* @fixed: hint about where to place the reserved area
*
@@ -235,7 +266,7 @@ core_initcall(cma_init_reserved_areas);
*/
static int __init __dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base, phys_addr_t limit,
- phys_addr_t alignment,
+ phys_addr_t alignment, int order_per_bit,
struct cma **res_cma, bool fixed)
{
struct cma *cma = cma_areas[cma_area_count];
@@ -269,6 +300,8 @@ static int __init
__dma_contiguous_reserve_area(phys_addr_t size,
base = ALIGN(base, alignment);
size = ALIGN(size, alignment);
limit = ~(alignment - 1);
+ /* size should be aligned with order_per_bit */
+ BUG_ON(!IS_ALIGNED(size PAGE_SHIFT, 1 order_per_bit));
/* Reserve memory */
if (base fixed) {
@@ -294,6 +327,7 @@ static int __init
__dma_contiguous_reserve_area(phys_addr_t size,
*/
cma-base_pfn = PFN_DOWN(base);
cma-count = size PAGE_SHIFT;
+ cma-order_per_bit = order_per_bit;
*res_cma = cma;
cma_area_count++;
@@ -313,7 +347,7 @@ int __init dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base,
{
int ret;
- ret = __dma_contiguous_reserve_area(size, base, limit, 0,
+ ret = __dma_contiguous_reserve_area(size, base, limit, 0, 0,
res_cma, fixed);
if (ret)
return ret;
@@ -324,13 +358,6 @@ int __init dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base,
return 0;
}
-static void clear_cma_bitmap(struct cma *cma, unsigned long pfn, int count)
-{
- mutex_lock(cma-lock);
- bitmap_clear(cma-bitmap, pfn - cma-base_pfn, count);
- mutex_unlock(cma-lock);
-}
-
/**
* dma_alloc_from_contiguous() - allocate pages from contiguous area
* @dev: Pointer to device for which the allocation is performed.
@@ -345,7 +372,8 @@ static void clear_cma_bitmap(struct cma *cma, unsigned
long pfn, int count)
static struct page *__dma_alloc_from_contiguous(struct cma *cma, int count,
unsigned int align)
{
- unsigned long mask, pfn, pageno, start = 0;
+ unsigned long mask, pfn, start = 0;
+ unsigned long bitmap_maxno, bitmapno, nr_bits;
struct page
Re: [PATCH v2 06/10] CMA: generalize CMA reserved area management functionality
On 06/12/2014 11:21 AM, Joonsoo Kim wrote:
Currently, there are two users on CMA functionality, one is the DMA
subsystem and the other is the kvm on powerpc. They have their own code
to manage CMA reserved area even if they looks really similar.
From my guess, it is caused by some needs on bitmap management. Kvm side
wants to maintain bitmap not for 1 page, but for more size. Eventually it
use bitmap where one bit represents 64 pages.
When I implement CMA related patches, I should change those two places
to apply my change and it seem to be painful to me. I want to change
this situation and reduce future code management overhead through
this patch.
This change could also help developer who want to use CMA in their
new feature development, since they can use CMA easily without
copying pasting this reserved area management code.
In previous patches, we have prepared some features to generalize
CMA reserved area management and now it's time to do it. This patch
moves core functions to mm/cma.c and change DMA APIs to use
these functions.
There is no functional change in DMA APIs.
v2: There is no big change from v1 in mm/cma.c. Mostly renaming.
Acked-by: Michal Nazarewicz min...@mina86.com
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
Acked-by: Zhang Yanfei zhangyan...@cn.fujitsu.com
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 00e13ce..4eac559 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -283,16 +283,6 @@ config CMA_ALIGNMENT
If unsure, leave the default value 8.
-config CMA_AREAS
- int Maximum count of the CMA device-private areas
- default 7
- help
- CMA allows to create CMA areas for particular devices. This parameter
- sets the maximum number of such device private CMA areas in the
- system.
-
- If unsure, leave the default value 7.
-
endif
endmenu
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 9bc9340..f177f73 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -24,25 +24,10 @@
#include linux/memblock.h
#include linux/err.h
-#include linux/mm.h
-#include linux/mutex.h
-#include linux/page-isolation.h
#include linux/sizes.h
-#include linux/slab.h
-#include linux/swap.h
-#include linux/mm_types.h
#include linux/dma-contiguous.h
#include linux/log2.h
-
-struct cma {
- unsigned long base_pfn;
- unsigned long count;
- unsigned long *bitmap;
- int order_per_bit; /* Order of pages represented by one bit */
- struct mutexlock;
-};
-
-struct cma *dma_contiguous_default_area;
+#include linux/cma.h
#ifdef CONFIG_CMA_SIZE_MBYTES
#define CMA_SIZE_MBYTES CONFIG_CMA_SIZE_MBYTES
@@ -50,6 +35,8 @@ struct cma *dma_contiguous_default_area;
#define CMA_SIZE_MBYTES 0
#endif
+struct cma *dma_contiguous_default_area;
+
/*
* Default global CMA area size can be defined in kernel's .config.
* This is useful mainly for distro maintainers to create a kernel
@@ -156,199 +143,13 @@ void __init dma_contiguous_reserve(phys_addr_t limit)
}
}
-static DEFINE_MUTEX(cma_mutex);
-
-static unsigned long cma_bitmap_aligned_mask(struct cma *cma, int
align_order)
-{
- return (1 (align_order cma-order_per_bit)) - 1;
-}
-
-static unsigned long cma_bitmap_maxno(struct cma *cma)
-{
- return cma-count cma-order_per_bit;
-}
-
-static unsigned long cma_bitmap_pages_to_bits(struct cma *cma,
- unsigned long pages)
-{
- return ALIGN(pages, 1 cma-order_per_bit) cma-order_per_bit;
-}
-
-static void clear_cma_bitmap(struct cma *cma, unsigned long pfn, int count)
-{
- unsigned long bitmapno, nr_bits;
-
- bitmapno = (pfn - cma-base_pfn) cma-order_per_bit;
- nr_bits = cma_bitmap_pages_to_bits(cma, count);
-
- mutex_lock(cma-lock);
- bitmap_clear(cma-bitmap, bitmapno, nr_bits);
- mutex_unlock(cma-lock);
-}
-
-static int __init cma_activate_area(struct cma *cma)
-{
- int bitmap_maxno = cma_bitmap_maxno(cma);
- int bitmap_size = BITS_TO_LONGS(bitmap_maxno) * sizeof(long);
- unsigned long base_pfn = cma-base_pfn, pfn = base_pfn;
- unsigned i = cma-count pageblock_order;
- struct zone *zone;
-
- pr_debug(%s()\n, __func__);
-
- cma-bitmap = kzalloc(bitmap_size, GFP_KERNEL);
- if (!cma-bitmap)
- return -ENOMEM;
-
- WARN_ON_ONCE(!pfn_valid(pfn));
- zone = page_zone(pfn_to_page(pfn));
-
- do {
- unsigned j;
- base_pfn = pfn;
- for (j = pageblock_nr_pages; j; --j, pfn++) {
- WARN_ON_ONCE(!pfn_valid(pfn));
- /*
- * alloc_contig_range requires the pfn range
- * specified to be in the same zone. Make this
- * simple by forcing
Re: [PATCH v2 08/10] mm, cma: clean-up cma allocation error path
On 06/12/2014 11:21 AM, Joonsoo Kim wrote:
We can remove one call sites for clear_cma_bitmap() if we first
call it before checking error number.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
Reviewed-by: Zhang Yanfei zhangyan...@cn.fujitsu.com
diff --git a/mm/cma.c b/mm/cma.c
index 1e1b017..01a0713 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -282,11 +282,12 @@ struct page *cma_alloc(struct cma *cma, int count,
unsigned int align)
if (ret == 0) {
page = pfn_to_page(pfn);
break;
- } else if (ret != -EBUSY) {
- clear_cma_bitmap(cma, pfn, count);
- break;
}
+
clear_cma_bitmap(cma, pfn, count);
+ if (ret != -EBUSY)
+ break;
+
pr_debug(%s(): memory range at %p is busy, retrying\n,
__func__, pfn_to_page(pfn));
/* try again with a bit different memory target */
--
Thanks.
Zhang Yanfei
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 01/10] DMA, CMA: clean-up log message
Joonsoo Kim iamjoonsoo@lge.com writes:
We don't need explicit 'CMA:' prefix, since we already define prefix
'cma:' in pr_fmt. So remove it.
And, some logs print function name and others doesn't. This looks
bad to me, so I unify log format to print function name consistently.
Lastly, I add one more debug log on cma_activate_area().
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 83969f8..bd0bb81 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -144,7 +144,7 @@ void __init dma_contiguous_reserve(phys_addr_t limit)
}
if (selected_size !dma_contiguous_default_area) {
- pr_debug(%s: reserving %ld MiB for global area\n, __func__,
+ pr_debug(%s(): reserving %ld MiB for global area\n, __func__,
(unsigned long)selected_size / SZ_1M);
On Thu, Jun 12, 2014 at 10:11:19AM +0530, Aneesh Kumar K.V wrote:
Do we need to do function(), or just function:. I have seen the later
usage in other parts of the kernel.
On Thu, Jun 12 2014, Joonsoo Kim iamjoonsoo@lge.com wrote:
I also haven't seen this format in other kernel code, but, in cma, they use
this format as following.
function(arg1, arg2, ...): some message
If we all dislike this format, we can change it after merging this
patchset. Until then, it seems better to me to leave it as is.
I used “function(arg1, arg2, …)” at the *beginning* of functions when
the arguments passed to the function were included in the message. In
all other cases I left it at just “function:” (or just no additional
prefix). IMO that's a reasonable strategy.
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +--m...@google.com--xmpp:min...@jabber.org--ooO--(_)--Ooo--
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 01/10] DMA, CMA: clean-up log message
On Thu, Jun 12 2014, Joonsoo Kim iamjoonsoo@lge.com wrote:
We don't need explicit 'CMA:' prefix, since we already define prefix
'cma:' in pr_fmt. So remove it.
And, some logs print function name and others doesn't. This looks
bad to me, so I unify log format to print function name consistently.
Lastly, I add one more debug log on cma_activate_area().
I don't particularly care what format of logs you choose, so:
Acked-by: Michal Nazarewicz min...@mina86.com
even though I'd go without empty “()”.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 83969f8..bd0bb81 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -144,7 +144,7 @@ void __init dma_contiguous_reserve(phys_addr_t limit)
}
if (selected_size !dma_contiguous_default_area) {
- pr_debug(%s: reserving %ld MiB for global area\n, __func__,
+ pr_debug(%s(): reserving %ld MiB for global area\n, __func__,
(unsigned long)selected_size / SZ_1M);
dma_contiguous_reserve_area(selected_size, selected_base,
@@ -163,8 +163,9 @@ static int __init cma_activate_area(struct cma *cma)
unsigned i = cma-count pageblock_order;
struct zone *zone;
- cma-bitmap = kzalloc(bitmap_size, GFP_KERNEL);
+ pr_debug(%s()\n, __func__);
+ cma-bitmap = kzalloc(bitmap_size, GFP_KERNEL);
if (!cma-bitmap)
return -ENOMEM;
@@ -234,7 +235,8 @@ int __init dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base,
/* Sanity checks */
if (cma_area_count == ARRAY_SIZE(cma_areas)) {
- pr_err(Not enough slots for CMA reserved regions!\n);
+ pr_err(%s(): Not enough slots for CMA reserved regions!\n,
+ __func__);
return -ENOSPC;
}
@@ -274,14 +276,15 @@ int __init dma_contiguous_reserve_area(phys_addr_t
size, phys_addr_t base,
*res_cma = cma;
cma_area_count++;
- pr_info(CMA: reserved %ld MiB at %08lx\n, (unsigned long)size / SZ_1M,
- (unsigned long)base);
+ pr_info(%s(): reserved %ld MiB at %08lx\n,
+ __func__, (unsigned long)size / SZ_1M, (unsigned long)base);
/* Architecture specific contiguous memory fixup. */
dma_contiguous_early_fixup(base, size);
return 0;
err:
- pr_err(CMA: failed to reserve %ld MiB\n, (unsigned long)size / SZ_1M);
+ pr_err(%s(): failed to reserve %ld MiB\n,
+ __func__, (unsigned long)size / SZ_1M);
return ret;
}
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +--m...@google.com--xmpp:min...@jabber.org--ooO--(_)--Ooo--
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V3 0/3] Add new PowerPC specific ELF core notes
On 05/23/2014 08:45 PM, Anshuman Khandual wrote: This patch series adds five new ELF core note sections which can be used with existing ptrace request PTRACE_GETREGSET/SETREGSET for accessing various transactional memory and miscellaneous register sets on PowerPC platform. Please find a test program exploiting these new ELF core note types on a POWER8 system. RFC: https://lkml.org/lkml/2014/4/1/292 V1: https://lkml.org/lkml/2014/4/2/43 V2: https://lkml.org/lkml/2014/5/5/88 Changes in V3 = (1) Added two new error paths in every TM related get/set functions when regset support is not present on the system (ENODEV) or when the process does not have any transaction active (ENODATA) in the context (2) Installed the active hooks for all the newly added regset core note types Changes in V2 = (1) Removed all the power specific ptrace requests corresponding to new NT_PPC_* elf core note types. Now all the register sets can be accessed from ptrace through PTRACE_GETREGSET/PTRACE_SETREGSET using the individual NT_PPC* core note type instead (2) Fixed couple of attribute values for REGSET_TM_CGPR register set (3) Renamed flush_tmreg_to_thread as flush_tmregs_to_thread (4) Fixed 32 bit checkpointed GPR support (5) Changed commit messages accordingly Outstanding Issues == (1) Running DSCR register value inside a transaction does not seem to be saved at thread.dscr when the process stops for ptrace examination. Hey Ben, Any updates on this patch series ? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 02/10] DMA, CMA: fix possible memory leak
On Thu, Jun 12 2014, Joonsoo Kim iamjoonsoo@lge.com wrote:
We should free memory for bitmap when we find zone mis-match,
otherwise this memory will leak.
Additionally, I copy code comment from ppc kvm's cma code to notify
why we need to check zone mis-match.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
Reviewed-by: Michal Nazarewicz min...@mina86.com
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index bd0bb81..fb0cdce 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -177,14 +177,24 @@ static int __init cma_activate_area(struct cma *cma)
base_pfn = pfn;
for (j = pageblock_nr_pages; j; --j, pfn++) {
WARN_ON_ONCE(!pfn_valid(pfn));
+ /*
+ * alloc_contig_range requires the pfn range
+ * specified to be in the same zone. Make this
+ * simple by forcing the entire CMA resv range
+ * to be in the same zone.
+ */
if (page_zone(pfn_to_page(pfn)) != zone)
- return -EINVAL;
+ goto err;
}
init_cma_reserved_pageblock(pfn_to_page(base_pfn));
} while (--i);
mutex_init(cma-lock);
return 0;
+
+err:
+ kfree(cma-bitmap);
+ return -EINVAL;
}
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +--m...@google.com--xmpp:min...@jabber.org--ooO--(_)--Ooo--
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 01/10] DMA, CMA: clean-up log message
On Thu, Jun 12 2014, Michal Nazarewicz min...@mina86.com wrote: I used “function(arg1, arg2, …)” at the *beginning* of functions when the arguments passed to the function were included in the message. In all other cases I left it at just “function:” (or just no additional prefix). IMO that's a reasonable strategy. At closer inspection, I realised drivers/base/dma-contiguous.c is Marek's code, but the above I think is still reasonable thing to do, so I'd rather standardise on having “function(…)” only at the beginning of a function. Just my 0.02 CHF. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +--m...@google.com--xmpp:min...@jabber.org--ooO--(_)--Ooo-- ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 03/10] DMA, CMA: separate core cma management codes from DMA APIs
On Thu, Jun 12 2014, Joonsoo Kim iamjoonsoo@lge.com wrote: To prepare future generalization work on cma area management code, we need to separate core cma management codes from DMA APIs. We will extend these core functions to cover requirements of ppc kvm's cma area management functionality in following patches. This separation helps us not to touch DMA APIs while extending core functions. Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com Acked-by: Michal Nazarewicz min...@mina86.com -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +--m...@google.com--xmpp:min...@jabber.org--ooO--(_)--Ooo-- ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 04/10] DMA, CMA: support alignment constraint on cma region
On Thu, Jun 12 2014, Joonsoo Kim iamjoonsoo@lge.com wrote:
ppc kvm's cma area management needs alignment constraint on
I've noticed it earlier and cannot seem to get to terms with this. It
should IMO be PPC, KVM and CMA since those are acronyms. But if you
have strong feelings, it's not a big issue.
cma region. So support it to prepare generalization of cma area
management functionality.
Additionally, add some comments which tell us why alignment
constraint is needed on cma region.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
Acked-by: Michal Nazarewicz min...@mina86.com
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 8a44c82..bc4c171 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -219,6 +220,7 @@ core_initcall(cma_init_reserved_areas);
* @size: Size of the reserved area (in bytes),
* @base: Base address of the reserved area optional, use 0 for any
* @limit: End address of the reserved memory (optional, 0 for any).
+ * @alignment: Alignment for the contiguous memory area, should be
power of 2
“must be power of 2 or zero”.
* @res_cma: Pointer to store the created cma region.
* @fixed: hint about where to place the reserved area
*
@@ -233,15 +235,15 @@ core_initcall(cma_init_reserved_areas);
*/
static int __init __dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base, phys_addr_t limit,
+ phys_addr_t alignment,
struct cma **res_cma, bool fixed)
{
struct cma *cma = cma_areas[cma_area_count];
- phys_addr_t alignment;
int ret = 0;
- pr_debug(%s(size %lx, base %08lx, limit %08lx)\n, __func__,
- (unsigned long)size, (unsigned long)base,
- (unsigned long)limit);
+ pr_debug(%s(size %lx, base %08lx, limit %08lx align_order %08lx)\n,
+ __func__, (unsigned long)size, (unsigned long)base,
+ (unsigned long)limit, (unsigned long)alignment);
Nit: Align with the rest of the arguments, i.e.:
+ pr_debug(%s(size %lx, base %08lx, limit %08lx align_order %08lx)\n,
+__func__, (unsigned long)size, (unsigned long)base,
+(unsigned long)limit, (unsigned long)alignment);
/* Sanity checks */
if (cma_area_count == ARRAY_SIZE(cma_areas)) {
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +--m...@google.com--xmpp:min...@jabber.org--ooO--(_)--Ooo--
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 05/10] DMA, CMA: support arbitrary bitmap granularity
On Thu, Jun 12 2014, Joonsoo Kim iamjoonsoo@lge.com wrote:
ppc kvm's cma region management requires arbitrary bitmap granularity,
since they want to reserve very large memory and manage this region
with bitmap that one bit for several pages to reduce management overheads.
So support arbitrary bitmap granularity for following generalization.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
Acked-by: Michal Nazarewicz min...@mina86.com
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index bc4c171..9bc9340 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -38,6 +38,7 @@ struct cma {
unsigned long base_pfn;
unsigned long count;
Have you considered replacing count with maxno?
unsigned long *bitmap;
+ int order_per_bit; /* Order of pages represented by one bit */
I'd make it unsigned.
struct mutexlock;
};
+static void clear_cma_bitmap(struct cma *cma, unsigned long pfn, int
count)
For consistency cma_clear_bitmap would make more sense I think. On the
other hand, you're just moving stuff around so perhaps renaming the
function at this point is not worth it any more.
+{
+ unsigned long bitmapno, nr_bits;
+
+ bitmapno = (pfn - cma-base_pfn) cma-order_per_bit;
+ nr_bits = cma_bitmap_pages_to_bits(cma, count);
+
+ mutex_lock(cma-lock);
+ bitmap_clear(cma-bitmap, bitmapno, nr_bits);
+ mutex_unlock(cma-lock);
+}
+
static int __init cma_activate_area(struct cma *cma)
{
- int bitmap_size = BITS_TO_LONGS(cma-count) * sizeof(long);
+ int bitmap_maxno = cma_bitmap_maxno(cma);
+ int bitmap_size = BITS_TO_LONGS(bitmap_maxno) * sizeof(long);
unsigned long base_pfn = cma-base_pfn, pfn = base_pfn;
unsigned i = cma-count pageblock_order;
struct zone *zone;
bitmap_maxno is never used again, perhaps:
+ int bitmap_size = BITS_TO_LONGS(cma_bitmap_maxno(cma)) * sizeof(long);
instead? Up to you.
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +--m...@google.com--xmpp:min...@jabber.org--ooO--(_)--Ooo--
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 08/10] mm, cma: clean-up cma allocation error path
On Thu, Jun 12 2014, Joonsoo Kim iamjoonsoo@lge.com wrote:
We can remove one call sites for clear_cma_bitmap() if we first
call it before checking error number.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
Reviewed-by: Michal Nazarewicz min...@mina86.com
diff --git a/mm/cma.c b/mm/cma.c
index 1e1b017..01a0713 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -282,11 +282,12 @@ struct page *cma_alloc(struct cma *cma, int count,
unsigned int align)
if (ret == 0) {
page = pfn_to_page(pfn);
break;
- } else if (ret != -EBUSY) {
- clear_cma_bitmap(cma, pfn, count);
- break;
}
+
clear_cma_bitmap(cma, pfn, count);
+ if (ret != -EBUSY)
+ break;
+
pr_debug(%s(): memory range at %p is busy, retrying\n,
__func__, pfn_to_page(pfn));
/* try again with a bit different memory target */
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +--m...@google.com--xmpp:min...@jabber.org--ooO--(_)--Ooo--
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 09/10] mm, cma: move output param to the end of param list
On Thu, Jun 12 2014, Joonsoo Kim iamjoonsoo@lge.com wrote:
Conventionally, we put output param to the end of param list.
cma_declare_contiguous() doesn't look like that, so change it.
Perhaps the function should be changed to return an error-pointer?
Additionally, move down cma_areas reference code to the position
where it is really needed.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
Acked-by: Michal Nazarewicz min...@mina86.com
diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c
b/arch/powerpc/kvm/book3s_hv_builtin.c
index 28ec226..97613ea 100644
--- a/arch/powerpc/kvm/book3s_hv_builtin.c
+++ b/arch/powerpc/kvm/book3s_hv_builtin.c
@@ -184,7 +184,7 @@ void __init kvm_cma_reserve(void)
align_size = max(kvm_rma_pages PAGE_SHIFT, align_size);
cma_declare_contiguous(selected_size, 0, 0, align_size,
- KVM_CMA_CHUNK_ORDER - PAGE_SHIFT, kvm_cma, false);
+ KVM_CMA_CHUNK_ORDER - PAGE_SHIFT, false, kvm_cma);
}
}
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index f177f73..bfd4553 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -149,7 +149,7 @@ int __init dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base,
{
int ret;
- ret = cma_declare_contiguous(size, base, limit, 0, 0, res_cma, fixed);
+ ret = cma_declare_contiguous(size, base, limit, 0, 0, fixed, res_cma);
if (ret)
return ret;
diff --git a/include/linux/cma.h b/include/linux/cma.h
index e38efe9..e53eead 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -6,7 +6,7 @@ struct cma;
extern int __init cma_declare_contiguous(phys_addr_t size,
phys_addr_t base, phys_addr_t limit,
phys_addr_t alignment, int order_per_bit,
- struct cma **res_cma, bool fixed);
+ bool fixed, struct cma **res_cma);
extern struct page *cma_alloc(struct cma *cma, int count, unsigned int
align);
extern bool cma_release(struct cma *cma, struct page *pages, int count);
#endif
diff --git a/mm/cma.c b/mm/cma.c
index 01a0713..22a5b23 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -142,8 +142,8 @@ core_initcall(cma_init_reserved_areas);
* @limit: End address of the reserved memory (optional, 0 for any).
* @alignment: Alignment for the contiguous memory area, should be power of 2
* @order_per_bit: Order of pages represented by one bit on bitmap.
- * @res_cma: Pointer to store the created cma region.
* @fixed: hint about where to place the reserved area
+ * @res_cma: Pointer to store the created cma region.
*
* This function reserves memory from early allocator. It should be
* called by arch specific code once the early allocator (memblock or
bootmem)
@@ -156,9 +156,9 @@ core_initcall(cma_init_reserved_areas);
int __init cma_declare_contiguous(phys_addr_t size,
phys_addr_t base, phys_addr_t limit,
phys_addr_t alignment, int order_per_bit,
- struct cma **res_cma, bool fixed)
+ bool fixed, struct cma **res_cma)
{
- struct cma *cma = cma_areas[cma_area_count];
+ struct cma *cma;
int ret = 0;
pr_debug(%s(size %lx, base %08lx, limit %08lx alignment %08lx)\n,
@@ -214,6 +214,7 @@ int __init cma_declare_contiguous(phys_addr_t size,
* Each reserved area must be initialised later, when more kernel
* subsystems (like slab allocator) are available.
*/
+ cma = cma_areas[cma_area_count];
cma-base_pfn = PFN_DOWN(base);
cma-count = size PAGE_SHIFT;
cma-order_per_bit = order_per_bit;
--
1.7.9.5
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +--m...@google.com--xmpp:min...@jabber.org--ooO--(_)--Ooo--
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Kernel build issues after yesterdays merge by Linus
Hi Christoph,
This is under Ubuntu Utopic Unicorn on a Power 8 system while simply
trying to build with the Ubuntu standard kernel config. It could be
that these issues come about because we do not have an rc1 yet but I
wanted to give some early notice. Also this is a new arch to me so I
may not be aware of how things work.
1. Bad relocation while building:
root@rd-power8:/rdhome/clameter/linux# make
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CALLscripts/checksyscalls.sh
CHK include/generated/compile.h
SKIPPED include/generated/compile.h
CALLarch/powerpc/kernel/systbl_chk.sh
CALLarch/powerpc/kernel/prom_init_check.sh
CHK kernel/config_data.h
CALLarch/powerpc/relocs_check.pl
WARNING: 1 bad relocations
c0cc7df0 R_PPC64_ADDR64__crc_TOC.
The TOC symbol export is special and I think we might need to get our
script to ignore it.
2. make install fails
root@rd-power8:/rdhome/clameter/linux# make install
sh -x /rdhome/clameter/linux/arch/powerpc/boot/install.sh 3.15.0+
vmlinux System.map /boot arch/powerpc/boot/zImage.pseries
arch/powerpc/boot/zImage.epapr
+ set -e
+ [ -x /home/clameter/bin/installkernel ]
+ [ -x /sbin/installkernel ]
+ exec /sbin/installkernel 3.15.0+ vmlinux System.map /boot
arch/powerpc/boot/zImage.pseries arch/powerpc/boot/zImage.epapr
Usage: installkernel version image System.map directory
/rdhome/clameter/linux/arch/powerpc/boot/Makefile:393: recipe for target
'install' failed
make[1]: *** [install] Error 1
/rdhome/clameter/linux/arch/powerpc/Makefile:294: recipe for target
'install' failed
make: *** [install] Error 2
Shows how much we use make install :) Below is a quick hack to get you going
but we should look at either fixing the Ubuntu installkernel to handle
extra optional args, or stop passing them from the ppc64 kernel
install.sh script.
Anton
--
diff --git a/arch/powerpc/boot/install.sh b/arch/powerpc/boot/install.sh
index b6a256b..e096e5a 100644
--- a/arch/powerpc/boot/install.sh
+++ b/arch/powerpc/boot/install.sh
@@ -23,8 +23,8 @@ set -e
# User may have a custom install script
-if [ -x ~/bin/${INSTALLKERNEL} ]; then exec ~/bin/${INSTALLKERNEL} $@; fi
-if [ -x /sbin/${INSTALLKERNEL} ]; then exec /sbin/${INSTALLKERNEL} $@; fi
+if [ -x ~/bin/${INSTALLKERNEL} ]; then exec ~/bin/${INSTALLKERNEL} $1 $2 $3
$4; fi
+if [ -x /sbin/${INSTALLKERNEL} ]; then exec /sbin/${INSTALLKERNEL} $1 $2 $3
$4; fi
# Default install
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
On Mon, May 12, 2014 at 03:57:34PM +1000, Benjamin Herrenschmidt wrote: This shuffles code around in exceptions-64s.S in order to allow an allmodconfig build to succeed. The main problems were: - We have a fixed hole from 0x7000 to 0x8000 for use by FW, under some circumstances the code before that would grow too big and hit the . = 0x7000 - The various attempts at making space in there would trigger cases where short conditional branches from assembly would no longer be able to reach their target. This is especially nasty when these branches reside in alternate feature sections which are appended at the end of each .o file This fixes it by essentially moving all the second level exception handlers to after the hole and moving a couple of functions near the hole itself so they sit at reachable distance of both the first level handlers (before the hole) and the alternate feature sections (end of file). In the long run, if we start hitting this again, we'll probably have to split the file in two, probably at the hole location, to keep the alt sections used by the first level handlers close to them, and move everything else further away. But for now, this will do. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org Hi Ben, what happened with this patch ? Thanks, Guenter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: power and percpu: Could we move the paca into the percpu area?
Actually, from gcc/config/rs6000.h: /* 1 for registers that have pervasive standard uses and are not available for the register allocator. [snip] So cr5, which is number 73, is never used by gcc. Not available for RA is not the same thing at all as not used by GCC. For example, GPR1 and XER[CA] are also fixed regs. But, indeed, it does look like GCC doesn't use it. It seems to me that some ABI forbade userland (or non-libraries or whatever) from using it. I'll see what I can find out. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Kernel build issues after yesterdays merge by Linus
From: Anton Blanchard
...
diff --git a/arch/powerpc/boot/install.sh b/arch/powerpc/boot/install.sh
index b6a256b..e096e5a 100644
--- a/arch/powerpc/boot/install.sh
+++ b/arch/powerpc/boot/install.sh
@@ -23,8 +23,8 @@ set -e
# User may have a custom install script
-if [ -x ~/bin/${INSTALLKERNEL} ]; then exec ~/bin/${INSTALLKERNEL} $@; fi
-if [ -x /sbin/${INSTALLKERNEL} ]; then exec /sbin/${INSTALLKERNEL} $@; fi
+if [ -x ~/bin/${INSTALLKERNEL} ]; then exec ~/bin/${INSTALLKERNEL} $1 $2 $3
$4; fi
+if [ -x /sbin/${INSTALLKERNEL} ]; then exec /sbin/${INSTALLKERNEL} $1 $2 $3
$4; fi
You probably want to enclose the $1 in as:
+if [ -x /sbin/${INSTALLKERNEL} ]; then exec /sbin/${INSTALLKERNEL} $1 $2
$3 $4; fi
David
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] KVM: PPC: e500mc: Relax tlb invalidation condition on vcpu schedule
On vcpu schedule, the condition checked for tlb pollution is too tight.
The tlb entries of one vcpu are polluted when a different vcpu from the
same partition runs in-between. Relax the current tlb invalidation
condition taking into account the lpid.
Signed-off-by: Mihai Caraman mihai.caraman at freescale.com
Cc: Scott Wood scottwood at freescale.com
---
arch/powerpc/kvm/e500mc.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
index 17e4562..2e0cd69 100644
--- a/arch/powerpc/kvm/e500mc.c
+++ b/arch/powerpc/kvm/e500mc.c
@@ -111,10 +111,12 @@ void kvmppc_mmu_msr_notify(struct kvm_vcpu *vcpu, u32
old_msr)
}
static DEFINE_PER_CPU(struct kvm_vcpu *, last_vcpu_on_cpu);
+static DEFINE_PER_CPU(int, last_lpid_on_cpu);
static void kvmppc_core_vcpu_load_e500mc(struct kvm_vcpu *vcpu, int cpu)
{
struct kvmppc_vcpu_e500 *vcpu_e500 = to_e500(vcpu);
+ bool update_last = false, inval_tlb = false;
kvmppc_booke_vcpu_load(vcpu, cpu);
@@ -140,12 +142,24 @@ static void kvmppc_core_vcpu_load_e500mc(struct kvm_vcpu
*vcpu, int cpu)
mtspr(SPRN_GDEAR, vcpu-arch.shared-dar);
mtspr(SPRN_GESR, vcpu-arch.shared-esr);
- if (vcpu-arch.oldpir != mfspr(SPRN_PIR) ||
- __get_cpu_var(last_vcpu_on_cpu) != vcpu) {
- kvmppc_e500_tlbil_all(vcpu_e500);
+ if (vcpu-arch.oldpir != mfspr(SPRN_PIR)) {
+ /* tlb entries deprecated */
+ inval_tlb = update_last = true;
+ } else if (__get_cpu_var(last_vcpu_on_cpu) != vcpu) {
+ update_last = true;
+ /* tlb entries polluted */
+ inval_tlb = __get_cpu_var(last_lpid_on_cpu) ==
+ vcpu-kvm-arch.lpid;
+ }
+
+ if (update_last) {
__get_cpu_var(last_vcpu_on_cpu) = vcpu;
+ __get_cpu_var(last_lpid_on_cpu) = vcpu-kvm-arch.lpid;
}
+ if (inval_tlb)
+ kvmppc_e500_tlbil_all(vcpu_e500);
+
kvmppc_load_guest_fp(vcpu);
}
--
1.7.11.7
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4 v3] KVM: PPC: Alow kvmppc_get_last_inst() to fail
On 06/02/2014 05:50 PM, Mihai Caraman wrote:
On book3e, guest last instruction is read on the exit path using load
external pid (lwepx) dedicated instruction. This load operation may fail
due to TLB eviction and execute-but-not-read entries.
This patch lay down the path for an alternative solution to read the guest
last instruction, by allowing kvmppc_get_lat_inst() function to fail.
Architecture specific implmentations of kvmppc_load_last_inst() may read
last guest instruction and instruct the emulation layer to re-execute the
guest in case of failure.
Make kvmppc_get_last_inst() definition common between architectures.
Signed-off-by: Mihai Caraman mihai.cara...@freescale.com
---
v3:
- these changes compile on book3s, please validate the functionality and
do the necessary adaptations!
- rework patch description
- add common definition for kvmppc_get_last_inst()
- check return values in book3s code
v2:
- integrated kvmppc_get_last_inst() in book3s code and checked build
- addressed cosmetic feedback
arch/powerpc/include/asm/kvm_book3s.h| 28 ++--
arch/powerpc/include/asm/kvm_booke.h | 7 +-
arch/powerpc/include/asm/kvm_ppc.h | 16 +
arch/powerpc/kvm/book3s_64_mmu_hv.c | 16 ++---
arch/powerpc/kvm/book3s_paired_singles.c | 38 ++
arch/powerpc/kvm/book3s_pr.c | 116 +--
arch/powerpc/kvm/booke.c | 3 +
arch/powerpc/kvm/e500_mmu_host.c | 5 ++
arch/powerpc/kvm/emulate.c | 18 +++--
arch/powerpc/kvm/powerpc.c | 10 ++-
10 files changed, 142 insertions(+), 115 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s.h
b/arch/powerpc/include/asm/kvm_book3s.h
index f52f656..3409572 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -274,30 +274,14 @@ static inline bool kvmppc_need_byteswap(struct kvm_vcpu
*vcpu)
return (kvmppc_get_msr(vcpu) MSR_LE) != (MSR_KERNEL MSR_LE);
}
-static inline u32 kvmppc_get_last_inst_internal(struct kvm_vcpu *vcpu, ulong pc)
+static inline int kvmppc_load_last_inst(struct kvm_vcpu *vcpu, bool prev,
Please make prev an enum :)
+u32 *inst)
{
- /* Load the instruction manually if it failed to do so in the
-* exit path */
- if (vcpu-arch.last_inst == KVM_INST_FETCH_FAILED)
- kvmppc_ld(vcpu, pc, sizeof(u32), vcpu-arch.last_inst, false);
+ ulong pc = kvmppc_get_pc(vcpu);
- return kvmppc_need_byteswap(vcpu) ? swab32(vcpu-arch.last_inst) :
- vcpu-arch.last_inst;
-}
-
-static inline u32 kvmppc_get_last_inst(struct kvm_vcpu *vcpu)
-{
- return kvmppc_get_last_inst_internal(vcpu, kvmppc_get_pc(vcpu));
-}
-
-/*
- * Like kvmppc_get_last_inst(), but for fetching a sc instruction.
- * Because the sc instruction sets SRR0 to point to the following
- * instruction, we have to fetch from pc - 4.
- */
-static inline u32 kvmppc_get_last_sc(struct kvm_vcpu *vcpu)
-{
- return kvmppc_get_last_inst_internal(vcpu, kvmppc_get_pc(vcpu) - 4);
+ if (prev)
+ pc -= 4;
+ return kvmppc_ld(vcpu, pc, sizeof(u32), vcpu-arch.last_inst, false);
}
In this case we're already in the slow path. Can we move this into a .c
file instead? That would unify it with booke and ...
static inline ulong kvmppc_get_fault_dar(struct kvm_vcpu *vcpu)
diff --git a/arch/powerpc/include/asm/kvm_booke.h
b/arch/powerpc/include/asm/kvm_booke.h
index c7aed61..1e28371 100644
--- a/arch/powerpc/include/asm/kvm_booke.h
+++ b/arch/powerpc/include/asm/kvm_booke.h
@@ -33,6 +33,8 @@
#define KVMPPC_INST_EHPRIV_DEBUG (KVMPPC_INST_EHPRIV | \
(EHPRIV_OC_DEBUG EHPRIV_OC_SHIFT))
+extern int kvmppc_load_last_inst(struct kvm_vcpu *vcpu, bool prev, u32 *inst);
... allow us to move this to a common header file :).
+
static inline void kvmppc_set_gpr(struct kvm_vcpu *vcpu, int num, ulong val)
{
vcpu-arch.gpr[num] = val;
@@ -69,11 +71,6 @@ static inline bool kvmppc_need_byteswap(struct kvm_vcpu
*vcpu)
return false;
}
-static inline u32 kvmppc_get_last_inst(struct kvm_vcpu *vcpu)
-{
- return vcpu-arch.last_inst;
-}
-
static inline void kvmppc_set_ctr(struct kvm_vcpu *vcpu, ulong val)
{
vcpu-arch.ctr = val;
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index 4a7cc45..619be2f 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -234,6 +234,22 @@ struct kvmppc_ops {
extern struct kvmppc_ops *kvmppc_hv_ops;
extern struct kvmppc_ops *kvmppc_pr_ops;
+static inline int kvmppc_get_last_inst(struct kvm_vcpu *vcpu, bool prev,
+ u32 *inst)
+{
+ int ret = EMULATE_DONE;
+
+ /* Load the instruction manually if it failed to do so in the
+* exit
Re: [PATCH 4/4 v3] KVM: PPC: Bookehv: Get vcpu's last instruction for emulation
On 06/02/2014 05:50 PM, Mihai Caraman wrote:
On book3e, KVM uses load external pid (lwepx) dedicated instruction to read
guest last instruction on the exit path. lwepx exceptions (DTLB_MISS, DSI
and LRAT), generated by loading a guest address, needs to be handled by KVM.
These exceptions are generated in a substituted guest translation context
(EPLC[EGS] = 1) from host context (MSR[GS] = 0).
Currently, KVM hooks only interrupts generated from guest context (MSR[GS] = 1),
doing minimal checks on the fast path to avoid host performance degradation.
lwepx exceptions originate from host state (MSR[GS] = 0) which implies
additional checks in DO_KVM macro (beside the current MSR[GS] = 1) by looking
at the Exception Syndrome Register (ESR[EPID]) and the External PID Load Context
Register (EPLC[EGS]). Doing this on each Data TLB miss exception is obvious
too intrusive for the host.
Read guest last instruction from kvmppc_load_last_inst() by searching for the
physical address and kmap it. This address the TODO for TLB eviction and
execute-but-not-read entries, and allow us to get rid of lwepx until we are
able to handle failures.
A simple stress benchmark shows a 1% sys performance degradation compared with
previous approach (lwepx without failure handling):
time for i in `seq 1 1`; do /bin/echo /dev/null; done
real0m 8.85s
user0m 4.34s
sys 0m 4.48s
vs
real0m 8.84s
user0m 4.36s
sys 0m 4.44s
An alternative solution, to handle lwepx exceptions in KVM, is to temporary
highjack the interrupt vector from host. Some cores share host IVOR registers
between hardware threads, which is the case of FSL e6500, which impose
additional
synchronization logic for this solution to work. This optimized solution can
be developed later on top of this patch.
Signed-off-by: Mihai Caraman mihai.cara...@freescale.com
---
v3:
- reworked patch description
- use unaltered kmap addr for kunmap
- get last instruction before beeing preempted
v2:
- reworked patch description
- used pr_* functions
- addressed cosmetic feedback
arch/powerpc/kvm/booke.c | 32
arch/powerpc/kvm/bookehv_interrupts.S | 37 --
arch/powerpc/kvm/e500_mmu_host.c | 93 +++
3 files changed, 134 insertions(+), 28 deletions(-)
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 34a42b9..4ef52a8 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -880,6 +880,8 @@ int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu
*vcpu,
int r = RESUME_HOST;
int s;
int idx;
+ u32 last_inst = KVM_INST_FETCH_FAILED;
+ enum emulation_result emulated = EMULATE_DONE;
/* update before a new last_exit_type is rewritten */
kvmppc_update_timing_stats(vcpu);
@@ -887,6 +889,15 @@ int kvmppc_handle_exit(struct kvm_run *run, struct
kvm_vcpu *vcpu,
/* restart interrupts if they were meant for the host */
kvmppc_restart_interrupt(vcpu, exit_nr);
+ /*
+* get last instruction before beeing preempted
+* TODO: for e6500 check also BOOKE_INTERRUPT_LRAT_ERROR ESR_DATA
+*/
+ if (exit_nr == BOOKE_INTERRUPT_DATA_STORAGE ||
+ exit_nr == BOOKE_INTERRUPT_DTLB_MISS ||
+ exit_nr == BOOKE_INTERRUPT_HV_PRIV)
Please make this a switch() - that's easier to read.
+ emulated = kvmppc_get_last_inst(vcpu, false, last_inst);
+
local_irq_enable();
trace_kvm_exit(exit_nr, vcpu);
@@ -895,6 +906,26 @@ int kvmppc_handle_exit(struct kvm_run *run, struct
kvm_vcpu *vcpu,
run-exit_reason = KVM_EXIT_UNKNOWN;
run-ready_for_interrupt_injection = 1;
+ switch (emulated) {
+ case EMULATE_AGAIN:
+ r = RESUME_GUEST;
+ goto out;
+
+ case EMULATE_FAIL:
+ pr_debug(%s: emulation at %lx failed (%08x)\n,
+ __func__, vcpu-arch.pc, last_inst);
+ /* For debugging, encode the failing instruction and
+* report it to userspace. */
+ run-hw.hardware_exit_reason = ~0ULL 32;
+ run-hw.hardware_exit_reason |= last_inst;
+ kvmppc_core_queue_program(vcpu, ESR_PIL);
+ r = RESUME_HOST;
+ goto out;
+
+ default:
+ break;
+ }
I think you can just put this into a function.
Scott, I think the patch overall looks quite good. Can you please check
as well and if you agree give it your reviewed-by? Mike, when Scott
gives you a reviewed-by, please include it for the next version.
Alex
+
switch (exit_nr) {
case BOOKE_INTERRUPT_MACHINE_CHECK:
printk(MACHINE CHECK: %lx\n, mfspr(SPRN_MCSR));
@@ -1184,6 +1215,7 @@ int kvmppc_handle_exit(struct kvm_run *run, struct
kvm_vcpu *vcpu,
BUG();
}
+out:
/*
* To avoid clobbering exit_reason, only check
Re: [PATCH] KVM: PPC: e500mc: Relax tlb invalidation condition on vcpu schedule
On 06/12/2014 04:00 PM, Mihai Caraman wrote:
On vcpu schedule, the condition checked for tlb pollution is too tight.
The tlb entries of one vcpu are polluted when a different vcpu from the
same partition runs in-between. Relax the current tlb invalidation
condition taking into account the lpid.
Signed-off-by: Mihai Caraman mihai.caraman at freescale.com
Your mailer is broken? :)
This really should be an @.
I think this should work. Scott, please ack.
Alex
Cc: Scott Wood scottwood at freescale.com
---
arch/powerpc/kvm/e500mc.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
index 17e4562..2e0cd69 100644
--- a/arch/powerpc/kvm/e500mc.c
+++ b/arch/powerpc/kvm/e500mc.c
@@ -111,10 +111,12 @@ void kvmppc_mmu_msr_notify(struct kvm_vcpu *vcpu, u32
old_msr)
}
static DEFINE_PER_CPU(struct kvm_vcpu *, last_vcpu_on_cpu);
+static DEFINE_PER_CPU(int, last_lpid_on_cpu);
static void kvmppc_core_vcpu_load_e500mc(struct kvm_vcpu *vcpu, int cpu)
{
struct kvmppc_vcpu_e500 *vcpu_e500 = to_e500(vcpu);
+ bool update_last = false, inval_tlb = false;
kvmppc_booke_vcpu_load(vcpu, cpu);
@@ -140,12 +142,24 @@ static void kvmppc_core_vcpu_load_e500mc(struct kvm_vcpu *vcpu, int cpu)
mtspr(SPRN_GDEAR, vcpu-arch.shared-dar);
mtspr(SPRN_GESR, vcpu-arch.shared-esr);
- if (vcpu-arch.oldpir != mfspr(SPRN_PIR) ||
- __get_cpu_var(last_vcpu_on_cpu) != vcpu) {
- kvmppc_e500_tlbil_all(vcpu_e500);
+ if (vcpu-arch.oldpir != mfspr(SPRN_PIR)) {
+ /* tlb entries deprecated */
+ inval_tlb = update_last = true;
+ } else if (__get_cpu_var(last_vcpu_on_cpu) != vcpu) {
+ update_last = true;
+ /* tlb entries polluted */
+ inval_tlb = __get_cpu_var(last_lpid_on_cpu) ==
+ vcpu-kvm-arch.lpid;
+ }
+
+ if (update_last) {
__get_cpu_var(last_vcpu_on_cpu) = vcpu;
+ __get_cpu_var(last_lpid_on_cpu) = vcpu-kvm-arch.lpid;
}
+ if (inval_tlb)
+ kvmppc_e500_tlbil_all(vcpu_e500);
+
kvmppc_load_guest_fp(vcpu);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add AT_HWCAP2 to indicate V.CRYPTO category support
The precedent we have used is that features that refer to ISA Categories include _HAS_ following the PPC_FEATURE[2]. So GLIBC specifies in hwcap.h: /* Feature definitions in AT_HWCAP2. */ #define PPC_FEATURE2_ARCH_2_07 0x8000 /* ISA 2.07 */ #define PPC_FEATURE2_HAS_HTM 0x4000 /* Hardware Transactional Memory */ #define PPC_FEATURE2_HAS_DSCR 0x2000 /* Data Stream Control Register */ #define PPC_FEATURE2_HAS_EBB 0x1000 /* Event Base Branching */ #define PPC_FEATURE2_HAS_ISEL 0x0800 /* Integer Select */ #define PPC_FEATURE2_HAS_TAR 0x0400 /* Target Address Register */ This was carried from the original AT_HWCAP defines. $ grep _HAS_ ./sysdeps/powerpc/bits/hwcap.h #define PPC_FEATURE_HAS_ALTIVEC 0x1000 /* SIMD/Vector Unit. */ #define PPC_FEATURE_HAS_FPU 0x0800 /* Floating Point Unit. */ #define PPC_FEATURE_HAS_MMU 0x0400 /* Memory Management Unit. */ #define PPC_FEATURE_HAS_4xxMAC 0x0200 /* 4xx Multiply Accumulator. */ #define PPC_FEATURE_HAS_SPE 0x0080 /* Signal Processing ext. */ #define PPC_FEATURE_HAS_EFP_SINGLE 0x0040 /* SPE Float. */ #define PPC_FEATURE_HAS_EFP_DOUBLE 0x0020 /* SPE Double. */ #define PPC_FEATURE_HAS_DFP 0x0400 /* Decimal FP Unit */ #define PPC_FEATURE_HAS_VSX 0x0080 /* P7 Vector Extension. */ So could we agree on PPC_FEATURE2_HAS_VEC_CRYPTO or the shorter PPC_FEATURE2_HAS_VCRYPTO? Steven J. Munroe Linux on Power Toolchain Architect IBM Corporation, Linux Technology Center From: Benjamin Herrenschmidt b...@kernel.crashing.org To: linuxppc-...@ozlabs.org Cc: Steve Munroe/Rochester/IBM@IBMUS, Hanns-Joachim Uhl hannsj_...@de.ibm.com, Diane Brent/Poughkeepsie/IBM@IBMUS, Jeffrey Scheel/Rochester/IBM@IBMUS, Adhemerval Zanella azane...@linux.vnet.ibm.com Date: 06/10/2014 12:05 AM Subject:[PATCH] powerpc: Add AT_HWCAP2 to indicate V.CRYPTO category support The Vector Crypto category instructions are supported by current POWER8 chips, advertise them to userspace using a specific bit to properly differentiate with chips of the same architecture level that might not have them. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org CC: sta...@vger.kernel.org [v3.10+] -- diff --git a/arch/powerpc/include/uapi/asm/cputable.h b/arch/powerpc/include/uapi/asm/cputable.h index 5b76579..de2c0e4 100644 --- a/arch/powerpc/include/uapi/asm/cputable.h +++ b/arch/powerpc/include/uapi/asm/cputable.h @@ -41,5 +41,6 @@ #define PPC_FEATURE2_EBB0x1000 #define PPC_FEATURE2_ISEL 0x0800 #define PPC_FEATURE2_TAR0x0400 +#define PPC_FEATURE2_VEC_CRYPTO 0x0200 #endif /* _UAPI__ASM_POWERPC_CPUTABLE_H */ diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c index c1faade..11da04a 100644 --- a/arch/powerpc/kernel/cputable.c +++ b/arch/powerpc/kernel/cputable.c @@ -109,7 +109,8 @@ extern void __restore_cpu_e6500(void); PPC_FEATURE_PSERIES_PERFMON_COMPAT) #define COMMON_USER2_POWER8 (PPC_FEATURE2_ARCH_2_07 | \ PPC_FEATURE2_HTM_COMP | PPC_FEATURE2_DSCR | \ - PPC_FEATURE2_ISEL | PPC_FEATURE2_TAR) + PPC_FEATURE2_ISEL | PPC_FEATURE2_TAR | \ + PPC_FEATURE2_VEC_CRYPTO) #define COMMON_USER_PA6T(COMMON_USER_PPC64 | PPC_FEATURE_PA6T |\ PPC_FEATURE_TRUE_LE | \ PPC_FEATURE_HAS_ALTIVEC_COMP) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Device Tree Binding for DSA on P1023RDB
The QORIQ P1023RDB has an option to populate the Marvell 88E6165
Ethernet switch. We populated this device and was able to initialize
it as a basic switch in U-Boot. However, the switch driver was not
loaded upon kernel bootup. DSA kernel config was enabled for the
88E6165. The following patch was applied:
http://patchwork.ozlabs.org/patch/230257/
The switch is attached to phy address 0x3 via dtsec2. My dts
file is as below. Would appreciate any feedback on whether the DSA
is correctly structured in the dts.
Pannir
/*
* P1023 RDB Device Tree Source
*
* Copyright 2013 Freescale Semiconductor Inc.
*
* Author: Roy Zang tie-fei.z...@freescale.com
* Chunhe Lan chunhe@freescale.com
*
* Redistribution and use in source and binary forms, with or
without
* modification, are permitted provided that the following
conditions are met:
* * Redistributions of source code must retain the above
copyright
* notice, this list of conditions and the following
disclaimer.
* * Redistributions in binary form must reproduce the above
copyright
* notice, this list of conditions and the following
disclaimer in the
* documentation and/or other materials provided with the
distribution.
* * Neither the name of Freescale Semiconductor nor the
* names of its contributors may be used to endorse or promote
products
* derived from this software without specific prior written
permission.
*
*
* ALTERNATIVELY, this software may be distributed under the terms
of the
* GNU General Public License ("GPL") as published by the Free
Software
* Foundation, either version 2 of that License or (at your option)
any
* later version.
*
* THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS''
AND ANY
* EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED
* WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE
FOR ANY
* DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES
* (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
OR SERVICES;
* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
USE OF THIS
* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
/include/ "fsl/p1023si-pre.dtsi"
/ {
model = "fsl,P1023";
compatible = "fsl,P1023RDB";
#address-cells = 2;
#size-cells = 2;
interrupt-parent = mpic;
aliases {
ethernet0 = enet0;
ethernet1 = enet1;
};
memory {
device_type = "memory";
};
qportals: qman-portals@ff00 {
ranges = 0x0 0xf 0xff00 0x20;
};
bportals: bman-portals@ff20 {
ranges = 0x0 0xf 0xff20 0x20;
};
soc: soc@ff60 {
ranges = 0x0 0x0 0xff60 0x20;
i2c@3000 {
eeprom@53 {
compatible = "at24,24c04";
reg = 0x53;
};
rtc@6f {
compatible = "microchip,mcp7941x";
reg = 0x6f;
};
};
usb@22000 {
dr_mode = "host";
phy_type = "ulpi";
};
fman0: fman@10 {
enet0: ethernet@e {
phy-handle = phy0;
phy-connection-type = "rgmii";
};
enet1: ethernet@e2000 {
phy-handle = phy1;
phy-connection-type = "rgmii";
};
mdio0: mdio@e1120 {
phy0: ethernet-phy@1 {
reg = 0x01;
};
phy1: ethernet-phy@2 {
reg = 0x03;
};
};
};
};
lbc: localbus@ff605000 {
reg = 0 0xff605000 0 0x1000;
/* NOR Flash */
ranges = 0x0 0x0 0x0 0xec00 0x0400;
nor@0,0 {
#address-cells = 1;
#size-cells = 1;
compatible = "cfi-flash";
reg = 0x0 0x0 0x0400;
bank-width = 2;
device-width = 1;
partition@0 {
label = "ramdisk";
reg = 0x 0x0300;
};
partition@300 {
label = "kernel";
reg = 0x0300 0x00ee;
};
partiton@3ee {
label = "dtb";
reg = 0x03ee 0x0002;
};
partition@3f0 {
label = "firmware";
reg = 0x03f0 0x0008;
read-only;
};
partition@3f8 {
label = "u-boot";
reg = 0x03f8 0x0008;
read-only;
};
};
};
pci0: pcie@ff60a000 {
reg = 0 0xff60a000 0 0x1000;
ranges = 0x200 0x0
Re: Device Tree Binding for DSA on P1023RDB
On Thu, 2014-06-12 at 23:36 +0800, Pannirselvam Kanagaratnam wrote:
The QORIQ P1023RDB has an option to populate the Marvell 88E6165
Ethernet switch. We populated this device and was able to initialize
it as a basic switch in U-Boot. However, the switch driver was not
loaded upon kernel bootup. DSA kernel config was enabled for the
88E6165. The following patch was applied:
http://patchwork.ozlabs.org/patch/230257/
The switch is attached to phy address 0x3 via dtsec2. My dts file is
as below. Would appreciate any feedback on whether the DSA is
correctly structured in the dts.
If you have a dtsec driver you're not working with an upstream kernel
(or you've ported a lot of SDK code to it)... What tree are you working
with? Are there prerequisites to the above patch that you might be
missing?
The above patch is a platform driver and you put the node in the
toplevel device tree node. Have you added marvell,dsa to the list of
compatible strings that get probed (of_device_ids in corenet_generic.c
or an equivalent list in your SDK kernel)?
dsa@0 {
compatible = marvell,dsa;
#address-cells = 2;
#size-cells = 0;
interrupts = 3;
This interrupts property needs to be four cells rather than one, if MPIC
is the parent -- assuming you have #interrupt-cells = 4 and not some
old device tree with #interrupt-cells = 2, but in any case you need
more than one cell.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: power and percpu: Could we move the paca into the percpu area?
On Thu, 2014-06-12 at 07:26 -0500, Segher Boessenkool wrote: But, indeed, it does look like GCC doesn't use it. It seems to me that some ABI forbade userland (or non-libraries or whatever) from using it. I'll see what I can find out. I can still use -ffixed-cr5 for safety no ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
On Thu, 2014-06-12 at 05:26 -0700, Guenter Roeck wrote: what happened with this patch ? Well it breaks with that binutils version of yours ... I'm trying to fix it in a better way but it's a mess... still working on it. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add AT_HWCAP2 to indicate V.CRYPTO category support
On Thu, 2014-06-12 at 10:13 -0500, Steve Munroe wrote: The precedent we have used is that features that refer to ISA Categories include _HAS_ following the PPC_FEATURE[2]. So GLIBC specifies in hwcap.h: /* Feature definitions in AT_HWCAP2. */ #define PPC_FEATURE2_ARCH_2_07 0x8000 /* ISA 2.07 */ #define PPC_FEATURE2_HAS_HTM 0x4000 /* Hardware Transactional Memory */ #define PPC_FEATURE2_HAS_DSCR 0x2000 /* Data Stream Control Register */ #define PPC_FEATURE2_HAS_EBB 0x1000 /* Event Base Branching */ #define PPC_FEATURE2_HAS_ISEL 0x0800 /* Integer Select */ #define PPC_FEATURE2_HAS_TAR 0x0400 /* Target Address Register */ This was carried from the original AT_HWCAP defines. Off, they don't have the HAS in the kernel definitions... $ grep _HAS_ ./sysdeps/powerpc/bits/hwcap.h #define PPC_FEATURE_HAS_ALTIVEC0x1000 /* SIMD/Vector Unit. */ #define PPC_FEATURE_HAS_FPU0x0800 /* Floating Point Unit. */ #define PPC_FEATURE_HAS_MMU0x0400 /* Memory Management Unit. */ #define PPC_FEATURE_HAS_4xxMAC0x0200 /* 4xx Multiply Accumulator. */ #define PPC_FEATURE_HAS_SPE0x0080 /* Signal Processing ext. */ #define PPC_FEATURE_HAS_EFP_SINGLE 0x0040 /* SPE Float. */ #define PPC_FEATURE_HAS_EFP_DOUBLE 0x0020 /* SPE Double. */ #define PPC_FEATURE_HAS_DFP0x0400 /* Decimal FP Unit */ #define PPC_FEATURE_HAS_VSX0x0080 /* P7 Vector Extension. */ So could we agree on PPC_FEATURE2_HAS_VEC_CRYPTO or the shorter PPC_FEATURE2_HAS_VCRYPTO? Well, I made it consistent with the other HWCAP2 bits exposed by the kernel which seem to differ from the glibc versions :-( In any case, I've merged it but I can do a follow up patch that adds the _HAS_ everywhere, hopefully nobody in userspace use the kernel definition and they use the glibc one instead. In that case, go for VCRYPTO. Cheers, Ben. Steven J. Munroe Linux on Power Toolchain Architect IBM Corporation, Linux Technology Center Inactive hide details for Benjamin Herrenschmidt ---06/10/2014 12:05:07 AM---The Vector Crypto category instructions are supporBenjamin Herrenschmidt ---06/10/2014 12:05:07 AM---The Vector Crypto category instructions are supported by current POWER8 chips, advertise them to use From: Benjamin Herrenschmidt b...@kernel.crashing.org To: linuxppc-...@ozlabs.org Cc: Steve Munroe/Rochester/IBM@IBMUS, Hanns-Joachim Uhl hannsj_...@de.ibm.com, Diane Brent/Poughkeepsie/IBM@IBMUS, Jeffrey Scheel/Rochester/IBM@IBMUS, Adhemerval Zanella azane...@linux.vnet.ibm.com Date: 06/10/2014 12:05 AM Subject: [PATCH] powerpc: Add AT_HWCAP2 to indicate V.CRYPTO category support __ The Vector Crypto category instructions are supported by current POWER8 chips, advertise them to userspace using a specific bit to properly differentiate with chips of the same architecture level that might not have them. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org CC: sta...@vger.kernel.org [v3.10+] -- diff --git a/arch/powerpc/include/uapi/asm/cputable.h b/arch/powerpc/include/uapi/asm/cputable.h index 5b76579..de2c0e4 100644 --- a/arch/powerpc/include/uapi/asm/cputable.h +++ b/arch/powerpc/include/uapi/asm/cputable.h @@ -41,5 +41,6 @@ #define PPC_FEATURE2_EBB 0x1000 #define PPC_FEATURE2_ISEL 0x0800 #define PPC_FEATURE2_TAR 0x0400 +#define PPC_FEATURE2_VEC_CRYPTO 0x0200 #endif /* _UAPI__ASM_POWERPC_CPUTABLE_H */ diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c index c1faade..11da04a 100644 --- a/arch/powerpc/kernel/cputable.c +++ b/arch/powerpc/kernel/cputable.c @@ -109,7 +109,8 @@ extern void __restore_cpu_e6500(void); PPC_FEATURE_PSERIES_PERFMON_COMPAT) #define COMMON_USER2_POWER8 (PPC_FEATURE2_ARCH_2_07 | \ PPC_FEATURE2_HTM_COMP | PPC_FEATURE2_DSCR | \ - PPC_FEATURE2_ISEL | PPC_FEATURE2_TAR) + PPC_FEATURE2_ISEL | PPC_FEATURE2_TAR | \ + PPC_FEATURE2_VEC_CRYPTO) #define COMMON_USER_PA6T (COMMON_USER_PPC64 | PPC_FEATURE_PA6T |\ PPC_FEATURE_TRUE_LE | \ PPC_FEATURE_HAS_ALTIVEC_COMP) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: power and percpu: Could we move the paca into the percpu area?
On Fri, Jun 13, 2014 at 07:57:08AM +1000, Benjamin Herrenschmidt wrote: On Thu, 2014-06-12 at 07:26 -0500, Segher Boessenkool wrote: But, indeed, it does look like GCC doesn't use it. It seems to me that some ABI forbade userland (or non-libraries or whatever) from using it. I'll see what I can find out. I can still use -ffixed-cr5 for safety no ? Yes, definitely, and in fact you have to if GCC changes to not have cr5 fixed by default (which may or may not happen). It will be good documentation in either case :-) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
On 06/12/2014 02:57 PM, Benjamin Herrenschmidt wrote: On Thu, 2014-06-12 at 05:26 -0700, Guenter Roeck wrote: what happened with this patch ? Well it breaks with that binutils version of yours ... I'm trying to fix it in a better way but it's a mess... still working on it. I updated my binutils since then, though, and the other problem I encountered (with the changed ABI) has been fixed. As it is, I'd prefer to have the patch applied, but I can understand if you don't want to apply it in case others hit the problem I had. Guenter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git next branch
Hi Linus ! Here are the remaining bits I was mentioning earlier. Mostly bug fixes and new selftests from Michael (yay !). He also removed the WSP platform and A2 core support which were dead before release, so less clutter. One little feature I snuck in is the doorbell IPI support for non-virtualized P8 which speeds up IPIs significantly between threads of a core. Cheers, Ben. The following changes since commit dfb945473ae8528fd885607b6fa843c676745e0c: Merge git://www.linux-watchdog.org/linux-watchdog (2014-06-10 19:16:36 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next for you to fetch changes up to ad718622ab6d500c870772b1b8dda46fa2195e6d: powerpc/book3s: Fix some ABIv2 issues in machine check code (2014-06-12 09:41:33 +1000) Anton Blanchard (4): powernv: Fix permissions on sysparam sysfs entries crypto/nx: disable NX on little endian builds powerpc/powernv: Reduce panic timeout from 180s to 10s powerpc/book3s: Fix some ABIv2 issues in machine check code Benjamin Herrenschmidt (1): powerpc: Add AT_HWCAP2 to indicate V.CRYPTO category support Dan Carpenter (2): powerpc/cpm: Remove duplicate FCC_GFMR_TTX define powerpc/spufs: Remove duplicate SPUFS_CNTL_MAP_SIZE define Gavin Shan (5): powerpc/eeh: Clear frozen state for child PE powerpc/eeh: Report frozen parent PE prior to child PE powerpc/powernv: Don't escalate non-existing frozen PE powerpc/powernv: Fix killed EEH event powerpc/eeh: Dump PE location code Guo Chao (1): powerpc/powernv: Fix endianness problems in EEH Joel Stanley (1): powerpc/powernv: Fix reading of OPAL msglog Kees Cook (1): powerpc/xmon: avoid format string leaking to printk Mahesh Salgaonkar (4): powerpc/book3s: Fix machine check handling for unhandled errors powerpc/book3s: Add stack overflow check in machine check handler. powerpc/book3s: Increment the mce counter during machine_check_early call. powerpc/book3s: Fix guest MC delivery mechanism to avoid soft lockups in guest. Michael Ellerman (6): powerpc: Remove platforms/wsp and associated pieces powerpc/perf: Ensure all EBB register state is cleared on fork() selftests/powerpc: Fix instruction loop for ABIv2 (LE) selftests/powerpc: Put the test in a separate process group selftests/powerpc: Add support for skipping tests selftests/powerpc: Add tests of PMU EBBs Michael Neuling (3): powerpc: Don't setup CPUs with bad status powerpc/cpuidle: Only clear LPCR decrementer wakeup bit on fast sleep entry powerpc/powernv: Enable POWER8 doorbell IPIs Paul Bolle (3): powerpc: Remove check for CONFIG_SERIAL_TEXT_DEBUG powerpc: fix typo 'CONFIG_PPC_CPU' powerpc: fix typo 'CONFIG_PMAC' Sam bobroff (1): powerpc: Correct DSCR during TM context switch Shreyas B. Prabhu (2): powerpc/powernv: Include asm/smp.h to fix UP build failure powerpc/powernv : Disable subcore for UP configs arch/powerpc/Kconfig.debug |5 - arch/powerpc/configs/chroma_defconfig | 307 -- arch/powerpc/include/asm/cpm2.h|1 - arch/powerpc/include/asm/eeh.h |1 + arch/powerpc/include/asm/eeh_event.h |2 +- arch/powerpc/include/asm/mmu-book3e.h |4 - arch/powerpc/include/asm/opal.h| 102 +- arch/powerpc/include/asm/reg_a2.h |9 - arch/powerpc/include/asm/switch_to.h |8 +- arch/powerpc/include/asm/wsp.h | 14 - arch/powerpc/include/uapi/asm/cputable.h |1 + arch/powerpc/kernel/Makefile |1 - arch/powerpc/kernel/cpu_setup_a2.S | 120 --- arch/powerpc/kernel/cpu_setup_power.S |2 + arch/powerpc/kernel/cputable.c | 41 +- arch/powerpc/kernel/eeh.c | 38 +- arch/powerpc/kernel/eeh_driver.c | 24 +- arch/powerpc/kernel/eeh_event.c| 21 +- arch/powerpc/kernel/eeh_pe.c | 60 ++ arch/powerpc/kernel/entry_64.S |6 - arch/powerpc/kernel/exceptions-64e.S | 16 - arch/powerpc/kernel/exceptions-64s.S | 64 +- arch/powerpc/kernel/head_40x.S | 19 - arch/powerpc/kernel/process.c |8 +- arch/powerpc/kernel/setup-common.c |2 +- arch/powerpc/kernel/time.c |2 +- arch/powerpc/kernel/traps.c|2 + arch/powerpc/kernel/udbg.c |2 - arch/powerpc/kernel/udbg_16550.c | 11 - arch/powerpc/kvm/book3s_hv_ras.c
Re: [git pull] Please pull powerpc.git next branch
On Fri, 2014-06-13 at 10:55 +1000, Benjamin Herrenschmidt wrote: Hi Linus ! Sending a copy via IBM just in case gmail has an issue with pull requests :-) If it goes through fine I'll stop doing it. Cheers, Ben. Here are the remaining bits I was mentioning earlier. Mostly bug fixes and new selftests from Michael (yay !). He also removed the WSP platform and A2 core support which were dead before release, so less clutter. One little feature I snuck in is the doorbell IPI support for non-virtualized P8 which speeds up IPIs significantly between threads of a core. Cheers, Ben. The following changes since commit dfb945473ae8528fd885607b6fa843c676745e0c: Merge git://www.linux-watchdog.org/linux-watchdog (2014-06-10 19:16:36 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next for you to fetch changes up to ad718622ab6d500c870772b1b8dda46fa2195e6d: powerpc/book3s: Fix some ABIv2 issues in machine check code (2014-06-12 09:41:33 +1000) Anton Blanchard (4): powernv: Fix permissions on sysparam sysfs entries crypto/nx: disable NX on little endian builds powerpc/powernv: Reduce panic timeout from 180s to 10s powerpc/book3s: Fix some ABIv2 issues in machine check code Benjamin Herrenschmidt (1): powerpc: Add AT_HWCAP2 to indicate V.CRYPTO category support Dan Carpenter (2): powerpc/cpm: Remove duplicate FCC_GFMR_TTX define powerpc/spufs: Remove duplicate SPUFS_CNTL_MAP_SIZE define Gavin Shan (5): powerpc/eeh: Clear frozen state for child PE powerpc/eeh: Report frozen parent PE prior to child PE powerpc/powernv: Don't escalate non-existing frozen PE powerpc/powernv: Fix killed EEH event powerpc/eeh: Dump PE location code Guo Chao (1): powerpc/powernv: Fix endianness problems in EEH Joel Stanley (1): powerpc/powernv: Fix reading of OPAL msglog Kees Cook (1): powerpc/xmon: avoid format string leaking to printk Mahesh Salgaonkar (4): powerpc/book3s: Fix machine check handling for unhandled errors powerpc/book3s: Add stack overflow check in machine check handler. powerpc/book3s: Increment the mce counter during machine_check_early call. powerpc/book3s: Fix guest MC delivery mechanism to avoid soft lockups in guest. Michael Ellerman (6): powerpc: Remove platforms/wsp and associated pieces powerpc/perf: Ensure all EBB register state is cleared on fork() selftests/powerpc: Fix instruction loop for ABIv2 (LE) selftests/powerpc: Put the test in a separate process group selftests/powerpc: Add support for skipping tests selftests/powerpc: Add tests of PMU EBBs Michael Neuling (3): powerpc: Don't setup CPUs with bad status powerpc/cpuidle: Only clear LPCR decrementer wakeup bit on fast sleep entry powerpc/powernv: Enable POWER8 doorbell IPIs Paul Bolle (3): powerpc: Remove check for CONFIG_SERIAL_TEXT_DEBUG powerpc: fix typo 'CONFIG_PPC_CPU' powerpc: fix typo 'CONFIG_PMAC' Sam bobroff (1): powerpc: Correct DSCR during TM context switch Shreyas B. Prabhu (2): powerpc/powernv: Include asm/smp.h to fix UP build failure powerpc/powernv : Disable subcore for UP configs arch/powerpc/Kconfig.debug |5 - arch/powerpc/configs/chroma_defconfig | 307 -- arch/powerpc/include/asm/cpm2.h|1 - arch/powerpc/include/asm/eeh.h |1 + arch/powerpc/include/asm/eeh_event.h |2 +- arch/powerpc/include/asm/mmu-book3e.h |4 - arch/powerpc/include/asm/opal.h| 102 +- arch/powerpc/include/asm/reg_a2.h |9 - arch/powerpc/include/asm/switch_to.h |8 +- arch/powerpc/include/asm/wsp.h | 14 - arch/powerpc/include/uapi/asm/cputable.h |1 + arch/powerpc/kernel/Makefile |1 - arch/powerpc/kernel/cpu_setup_a2.S | 120 --- arch/powerpc/kernel/cpu_setup_power.S |2 + arch/powerpc/kernel/cputable.c | 41 +- arch/powerpc/kernel/eeh.c | 38 +- arch/powerpc/kernel/eeh_driver.c | 24 +- arch/powerpc/kernel/eeh_event.c| 21 +- arch/powerpc/kernel/eeh_pe.c | 60 ++ arch/powerpc/kernel/entry_64.S |6 - arch/powerpc/kernel/exceptions-64e.S | 16 - arch/powerpc/kernel/exceptions-64s.S | 64 +- arch/powerpc/kernel/head_40x.S | 19 - arch/powerpc/kernel/process.c |8 +- arch/powerpc/kernel/setup-common.c
RE: Kernel build issues after yesterdays merge by Linus
Goobledieguy due to missing Mime header. On Thu, 12 Jun 2014, David Laight wrote: RnJvbTogQW50b24gQmxhbmNoYXJkDQouLi4NCj4gZGlmZiAtLWdpdCBhL2FyY2gvcG93ZXJwYy9i b290L2luc3RhbGwuc2ggYi9hcmNoL3Bvd2VycGMvYm9vdC9pbnN0YWxsLnNoDQo+IGluZGV4IGI2 YTI1NmIuLmUwOTZlNWEgMTAwNjQ0DQo+IC0tLSBhL2FyY2gvcG93ZXJwYy9ib290L2luc3RhbGwu c2gNCj4gKysrIGIvYXJjaC9wb3dlcnBjL2Jvb3QvaW5zdGFsbC5zaA0KPiBAQCAtMjMsOCArMjMs OCBAQCBzZXQgLWUNCj4gDQo+ICAjIFVzZXIgbWF5IGhhdmUgYSBjdXN0b20gaW5zdGFsbCBzY3Jp cHQNCj4gDQo+IC1pZiBbIC14IH4vYmluLyR7SU5TVEFMTEtFUk5FTH0gXTsgdGhlbiBleGVjIH4v YmluLyR7SU5TVEFMTEtFUk5FTH0gIiRAIjsgZmkNCj4gLWlmIFsgLXggL3NiaW4vJHtJTlNUQUxM S0VSTkVMfSBdOyB0aGVuIGV4ZWMgL3NiaW4vJHtJTlNUQUxMS0VSTkVMfSAiJEAiOyBmaQ0KPiAr aWYgWyAteCB+L2Jpbi8ke0lOU1RBTExLRVJORUx9IF07IHRoZW4gZXhlYyB+L2Jpbi8ke0lOU1RB TExLRVJORUx9ICQxICQyICQzICQ0OyBmaQ0KPiAraWYgWyAteCAvc2Jpbi8ke0lOU1RBTExLRVJO RUx9IF07IHRoZW4gZXhlYyAvc2Jpbi8ke0lOU1RBTExLRVJORUx9ICQxICQyICQzICQ0OyBmaQ0K DQpZb3UgcHJvYmFibHkgd2FudCB0byBlbmNsb3NlIHRoZSAkMSBpbiAiIGFzOg0KDQo+ICtpZiBb IC14IC9zYmluLyR7SU5TVEFMTEtFUk5FTH0gXTsgdGhlbiBleGVjIC9zYmluLyR7SU5TVEFMTEtF Uk5FTH0gIiQxIiAiJDIiICIkMyIgIiQ0IjsgZmkNCg0KCURhdmlkDQoNCg== ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [RFC][PATCH v1] ASoC: fsl_ssi: Add DAI master mode support for SSI on i.MX series
On Thu, Dec 12, 2013 at 4:44 AM, Nicolin Chen
guangyu.c...@freescale.com wrote:
+static int fsl_ssi_set_dai_sysclk(struct snd_soc_dai *cpu_dai,
+ int clk_id, unsigned int freq, int dir)
+{
+ struct fsl_ssi_private *ssi_private =
snd_soc_dai_get_drvdata(cpu_dai);
+ struct ccsr_ssi __iomem *ssi = ssi_private-ssi;
+ int synchronous = ssi_private-cpu_dai_drv.symmetric_rates, ret;
+ u32 pm = 999, div2, psr, stccr, mask, afreq, factor, i;
+ unsigned long flags, clkrate, baudrate, tmprate;
+ u64 sub, savesub = 10;
+
+ /* Don't apply it to any non-baudclk circumstance */
+ if (IS_ERR(ssi_private-baudclk))
+ return -EINVAL;
+
+ /* It should be already enough to divide clock by setting pm alone */
+ psr = 0;
+ div2 = 0;
+
+ factor = (div2 + 1) * (7 * psr + 1) * 2;
+
+ for (i = 0; i 255; i++) {
+ /* The bclk rate must be smaller than 1/5 sysclk rate */
+ if (factor * (i + 1) 5)
+ continue;
+
+ tmprate = freq * factor * (i + 2);
+ clkrate = clk_round_rate(ssi_private-baudclk, tmprate);
+
+ do_div(clkrate, factor);
This do_div() call causes this warning on PowerPC:
CC sound/soc/fsl/fsl_ssi.o
sound/soc/fsl/fsl_ssi.c: In function 'fsl_ssi_set_bclk':
sound/soc/fsl/fsl_ssi.c:593:3: warning: comparison of distinct pointer
types lacks a cast
sound/soc/fsl/fsl_ssi.c:593:3: warning: right shift count = width of type
sound/soc/fsl/fsl_ssi.c:593:3: warning: passing argument 1 of
'__div64_32' from incompatible pointer type
include/asm-generic/div64.h:35:17: note: expected 'uint64_t *' but
argument is of type 'long unsigned int *'
The comments in do_div() say that clkrate should be 64-bits. Changing
clkrate to a u64 does fix this problem, but I'm wondering if anyone
else has seen this. This code has been around for months.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [RFC][PATCH v1] ASoC: fsl_ssi: Add DAI master mode support for SSI on i.MX series
Sir,
On Thu, Jun 12, 2014 at 10:24:55PM -0500, Timur Tabi wrote:
On Thu, Dec 12, 2013 at 4:44 AM, Nicolin Chen
guangyu.c...@freescale.com wrote:
+static int fsl_ssi_set_dai_sysclk(struct snd_soc_dai *cpu_dai,
+ int clk_id, unsigned int freq, int dir)
+{
+ struct fsl_ssi_private *ssi_private =
snd_soc_dai_get_drvdata(cpu_dai);
+ struct ccsr_ssi __iomem *ssi = ssi_private-ssi;
+ int synchronous = ssi_private-cpu_dai_drv.symmetric_rates, ret;
+ u32 pm = 999, div2, psr, stccr, mask, afreq, factor, i;
+ unsigned long flags, clkrate, baudrate, tmprate;
+ u64 sub, savesub = 10;
+
+ /* Don't apply it to any non-baudclk circumstance */
+ if (IS_ERR(ssi_private-baudclk))
+ return -EINVAL;
+
+ /* It should be already enough to divide clock by setting pm alone
*/
+ psr = 0;
+ div2 = 0;
+
+ factor = (div2 + 1) * (7 * psr + 1) * 2;
+
+ for (i = 0; i 255; i++) {
+ /* The bclk rate must be smaller than 1/5 sysclk rate */
+ if (factor * (i + 1) 5)
+ continue;
+
+ tmprate = freq * factor * (i + 2);
+ clkrate = clk_round_rate(ssi_private-baudclk, tmprate);
+
+ do_div(clkrate, factor);
This do_div() call causes this warning on PowerPC:
CC sound/soc/fsl/fsl_ssi.o
sound/soc/fsl/fsl_ssi.c: In function 'fsl_ssi_set_bclk':
sound/soc/fsl/fsl_ssi.c:593:3: warning: comparison of distinct pointer
types lacks a cast
sound/soc/fsl/fsl_ssi.c:593:3: warning: right shift count = width of type
sound/soc/fsl/fsl_ssi.c:593:3: warning: passing argument 1 of
'__div64_32' from incompatible pointer type
include/asm-generic/div64.h:35:17: note: expected 'uint64_t *' but
argument is of type 'long unsigned int *'
The comments in do_div() say that clkrate should be 64-bits. Changing
clkrate to a u64 does fix this problem, but I'm wondering if anyone
else has seen this. This code has been around for months.
It compiles well with my ARM cross compiler. I guess it might be related
to the compiler's version? But we should fix it anyway. Would you mind if
I submit a patch? Or you do it directly?
Thank you,
Nicolin
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [RFC][PATCH v1] ASoC: fsl_ssi: Add DAI master mode support for SSI on i.MX series
On Thu, Jun 12, 2014 at 10:21 PM, Nicolin Chen guangyu.c...@freescale.com wrote: It compiles well with my ARM cross compiler. I guess it might be related to the compiler's version? But we should fix it anyway. Would you mind if I submit a patch? Or you do it directly? I just submitted a patch, but I can't test the code since I don't have any boards that configure the SSI into master mode, so this function is never called. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [RFC][PATCH v1] ASoC: fsl_ssi: Add DAI master mode support for SSI on i.MX series
On Thu, Jun 12, 2014 at 10:44:48PM -0500, Timur Tabi wrote: On Thu, Jun 12, 2014 at 10:21 PM, Nicolin Chen guangyu.c...@freescale.com wrote: It compiles well with my ARM cross compiler. I guess it might be related to the compiler's version? But we should fix it anyway. Would you mind if I submit a patch? Or you do it directly? I just submitted a patch, but I can't test the code since I don't have any boards that configure the SSI into master mode, so this function is never called. I just tested it with i.MX platform. It still works. Thank you, Nicolin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Kernel build issues after yesterdays merge by Linus
On Thu, Jun 12, 2014 at 10:09:12PM +1000, Anton Blanchard wrote:
The TOC symbol export is special and I think we might need to get our
script to ignore it.
Try this (untested) patch. If it's good I'll send it to Ben.
diff --git a/arch/powerpc/relocs_check.pl b/arch/powerpc/relocs_check.pl
index 3f46e8b..34e3f25 100755
--- a/arch/powerpc/relocs_check.pl
+++ b/arch/powerpc/relocs_check.pl
@@ -45,6 +45,9 @@ while (FD) {
/\bR_PPC_ADDR16_HA\b/ or /\bR_PPC_RELATIVE\b/ or
/\bR_PPC_NONE\b/);
+ # The TOC is special so let's ignore it.
+ next if (/__crc_TOC\./);
+
# If we see this type of relocation it's an idication that
# we /may/ be using an old version of binutils.
if (/R_PPC64_UADDR64/) {
snip
Shows how much we use make install :) Below is a quick hack to get you going
but we should look at either fixing the Ubuntu installkernel to handle
extra optional args, or stop passing them from the ppc64 kernel
install.sh script.
It seems like passign the zImage files is probably wrong. How about:
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index ccc25ed..146d898 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -390,7 +390,7 @@ $(obj)/zImage.initrd: $(addprefix $(obj)/,
$(initrd-y))
@rm -f $@; ln $ $@
install: $(CONFIGURE) $(addprefix $(obj)/, $(image-y))
- sh -x $(srctree)/$(src)/install.sh $(KERNELRELEASE) vmlinux
System.map $(INSTALL_PATH) $^
+ sh -x $(srctree)/$(src)/install.sh $(KERNELRELEASE) vmlinux
System.map $(INSTALL_PATH)
# anything not in $(targets)
clean-files += $(image-) $(initrd-) cuImage.* dtbImage.* treeImage.* \
pgpB9qeLlAzXL.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
