Emil Medve writes:
> Currently bootmem is just a wrapper around memblock. This gets rid of
> the wrapper code just as other ARHC(es) did: x86, arm, etc.
>
> For now only cover !NUMA systems/builds
>
> Signed-off-by: Emil Medve
> ---
>
> v2: Acknowledge that NUMA systems/builds are not covered by
From: Diana Craciun
Updated the device trees according to the corenet-cf
binding definition.
Signed-off-by: Diana Craciun
---
v2:
Added missing p5040
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/p4080
On 05/06/2014 07:57 PM, Scott Wood wrote:
On Tue, 2014-05-06 at 17:56 +0300, Diana Craciun wrote:
From: Diana Craciun
Updated the device trees according to the corenet-cf
binding definition.
Signed-off-by: Diana Craciun
---
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 2 +-
arch/powerpc/
On Sun, May 04, 2014 at 10:56:08PM +0530, Aneesh Kumar K.V wrote:
> With debug option "sleep inside atomic section checking" enabled we get
> the below WARN_ON during a PR KVM boot. This is because upstream now
> have PREEMPT_COUNT enabled even if we have preempt disabled. Fix the
> warning by addi
From: Tang Yuantian
Basically, this patch does the following:
1. Move the codes of parsing boot parameters from setup-common.c
to driver. In this way, code reader can know directly that
there are boot parameters that can change the timeout.
2. Make boot parameter 'booke_wdt_period' effectiv
On Tue, 2014-05-06 at 00:54 -0500, Emil Medve wrote:
> Hello Scott,
>
>
> On 05/05/2014 06:25 PM, Scott Wood wrote:
> > On Sat, 2014-05-03 at 05:02 -0500, Emil Medve wrote:
> >> Hello Scott,
> >>
> >>
> >> On 04/21/2014 05:11 PM, Scott Wood wrote:
> >>> On Fri, 2014-04-18 at 07:21 -0500, Shruti K
On Tue, 2014-05-06 at 19:16 -0500, Emil Medve wrote:
> Hello Scott,
>
>
> On 05/06/2014 04:49 PM, Scott Wood wrote:
> > On Tue, 2014-05-06 at 13:48 -0500, Emil Medve wrote:
> >> Currently bootmem is just a wrapper around memblock. This gets rid of
> >> the wrapper code just as other ARHC(es) did:
Hello Scott,
On 05/06/2014 04:49 PM, Scott Wood wrote:
> On Tue, 2014-05-06 at 13:48 -0500, Emil Medve wrote:
>> Currently bootmem is just a wrapper around memblock. This gets rid of
>> the wrapper code just as other ARHC(es) did: x86, arm, etc.
>>
>> For now only cover !NUMA systems/builds
>>
>>
On Tue, 2014-05-06 at 16:49 -0500, Scott Wood wrote:
> On Tue, 2014-05-06 at 13:48 -0500, Emil Medve wrote:
> > Currently bootmem is just a wrapper around memblock. This gets rid of
> > the wrapper code just as other ARHC(es) did: x86, arm, etc.
> >
> > For now only cover !NUMA systems/builds
> >
On Tue, 2014-05-06 at 13:48 -0500, Emil Medve wrote:
> Currently bootmem is just a wrapper around memblock. This gets rid of
> the wrapper code just as other ARHC(es) did: x86, arm, etc.
>
> For now only cover !NUMA systems/builds
>
> Signed-off-by: Emil Medve
> ---
>
> v2: Acknowledge that NUM
On Tue, 2014-05-06 at 21:38 +0530, Aneesh Kumar K.V wrote:
> >> I updated the commit message as below. Let me know if this is ok.
> >>
> >> KVM: PPC: BOOK3S: HV: THP support for guest
> >
> > This has nothing to do with THP.
>
> THP support in guest depend on KVM advertising MPSS feature. We
Signed-off-by: Emil Medve
---
v2: Rebased and updated due to upstream changes since v1
arch/powerpc/include/asm/io.h | 2 +-
arch/powerpc/include/asm/page.h| 2 +-
arch/powerpc/include/asm/pgalloc-32.h | 2 +-
arch/powerpc/include/asm/rtas.h| 3 ++-
arch/powerpc/ke
Currently bootmem is just a wrapper around memblock. This gets rid of
the wrapper code just as other ARHC(es) did: x86, arm, etc.
For now only cover !NUMA systems/builds
Signed-off-by: Emil Medve
---
v2: Acknowledge that NUMA systems/builds are not covered by this patch
arch/powerpc/Kconfig
Unify the low/highmem code path from do_init_bootmem() by using (the)
lowmem related variables/parameters even when the low/highmem split
is not needed (64-bit) or configured. In such cases the "lowmem"
variables/parameters continue to observe the definition by referring
to memory directly mapped b
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Friday, May 02, 2014 12:55 PM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-...@vger.kernel.org; k...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org
> Subject: Re: [PATCH v2 3/4] KVM: PPC: Alow kvmppc_get_last_ins
On recent IBM Power CPUs, while the hashed page table is looked up using
the page size from the segmentation hardware (i.e. the SLB), it is
possible to have the HPT entry indicate a larger page size. Thus for
example it is possible to put a 16MB page in a 64kB segment, but since
the hash lookup is
On Tue, 2014-05-06 at 17:56 +0300, Diana Craciun wrote:
> From: Diana Craciun
>
> Updated the device trees according to the corenet-cf
> binding definition.
>
> Signed-off-by: Diana Craciun
> ---
> arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 2 +-
> arch/powerpc/boot/dts/fsl/p3041si-post.dts
On 05/06/2014 06:08 PM, Aneesh Kumar K.V wrote:
Alexander Graf writes:
On 05/06/2014 05:06 PM, Aneesh Kumar K.V wrote:
Alexander Graf writes:
On 05/06/2014 11:26 AM, Benjamin Herrenschmidt wrote:
On Tue, 2014-05-06 at 11:12 +0200, Alexander Graf wrote:
.
I updated the commit messa
Alexander Graf writes:
> On 05/06/2014 05:06 PM, Aneesh Kumar K.V wrote:
>> Alexander Graf writes:
>>
>>> On 05/06/2014 11:26 AM, Benjamin Herrenschmidt wrote:
On Tue, 2014-05-06 at 11:12 +0200, Alexander Graf wrote:
>> .
>>
>>
>> I updated the commit message as below. Let me know
Today when KVM tries to reserve memory for the hash page table it
allocates from the normal page allocator first. If that fails it
falls back to CMA's reserved region. One of the side effects of
this is that we could end up exhausting the page allocator and
get linux into OOM conditions while we st
On 05/06/2014 05:48 PM, mihai.cara...@freescale.com wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Sunday, May 04, 2014 1:14 AM
To: Caraman Mihai Claudiu-B02008
Cc: kvm-...@vger.kernel.org; k...@vger.kernel.org; linuxppc-
d...@lists.ozlabs.org
Subject: Re: [PA
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Sunday, May 04, 2014 1:14 AM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-...@vger.kernel.org; k...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org
> Subject: Re: [PATCH v2 1/4] KVM: PPC: e500mc: Revert "add load
On 05/06/2014 05:06 PM, Aneesh Kumar K.V wrote:
Alexander Graf writes:
On 05/06/2014 11:26 AM, Benjamin Herrenschmidt wrote:
On Tue, 2014-05-06 at 11:12 +0200, Alexander Graf wrote:
.
I updated the commit message as below. Let me know if this is ok.
KVM: PPC: BOOK3S: HV: THP sup
Alexander Graf writes:
> On 05/06/2014 11:26 AM, Benjamin Herrenschmidt wrote:
>> On Tue, 2014-05-06 at 11:12 +0200, Alexander Graf wrote:
>>
.
I updated the commit message as below. Let me know if this is ok.
KVM: PPC: BOOK3S: HV: THP support for guest
On recent IBM Power CP
From: Diana Craciun
Updated the device trees according to the corenet-cf
binding definition.
Signed-off-by: Diana Craciun
---
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 2 +-
arch/powerpc
Although it's optional IBM POWER cpus always had DAR value set on
alignment interrupt. So don't try to compute these values.
Signed-off-by: Aneesh Kumar K.V
---
* Changes from V4
* Update comments around using fault_dar
arch/powerpc/include/asm/disassemble.h | 34 +
arc
Paul Mackerras writes:
> On Mon, May 05, 2014 at 08:17:00PM +0530, Aneesh Kumar K.V wrote:
>> Alexander Graf writes:
>>
>> > On 05/04/2014 07:30 PM, Aneesh Kumar K.V wrote:
>> >> Signed-off-by: Aneesh Kumar K.V
>> >
>> > No patch description, no proper explanations anywhere why you're doing
>
On 05/06/2014 04:20 PM, Aneesh Kumar K.V wrote:
Alexander Graf writes:
On 06.05.14 09:19, Benjamin Herrenschmidt wrote:
On Tue, 2014-05-06 at 09:05 +0200, Alexander Graf wrote:
On 06.05.14 02:06, Benjamin Herrenschmidt wrote:
On Mon, 2014-05-05 at 17:16 +0200, Alexander Graf wrote:
Isn't t
Alexander Graf writes:
> On 05/04/2014 07:30 PM, Aneesh Kumar K.V wrote:
>> Signed-off-by: Aneesh Kumar K.V
>> static inline unsigned long hpte_page_size(unsigned long h, unsigned long
>> l)
>> {
>> +int size, a_size;
>> +/* Look at the 8 bit LP value */
>> +unsigned
On 05/06/2014 04:12 PM, Aneesh Kumar K.V wrote:
Alexander Graf writes:
On 06.05.14 02:41, Paul Mackerras wrote:
On Mon, May 05, 2014 at 01:19:30PM +0200, Alexander Graf wrote:
On 05/04/2014 07:21 PM, Aneesh Kumar K.V wrote:
+#ifdef CONFIG_PPC_BOOK3S_64
+ return vcpu->arch.fault_dar;
Alexander Graf writes:
> On 06.05.14 09:19, Benjamin Herrenschmidt wrote:
>> On Tue, 2014-05-06 at 09:05 +0200, Alexander Graf wrote:
>>> On 06.05.14 02:06, Benjamin Herrenschmidt wrote:
On Mon, 2014-05-05 at 17:16 +0200, Alexander Graf wrote:
> Isn't this a greater problem? We should st
Alexander Graf writes:
> On 06.05.14 02:41, Paul Mackerras wrote:
>> On Mon, May 05, 2014 at 01:19:30PM +0200, Alexander Graf wrote:
>>> On 05/04/2014 07:21 PM, Aneesh Kumar K.V wrote:
+#ifdef CONFIG_PPC_BOOK3S_64
+ return vcpu->arch.fault_dar;
>>> How about PA6T and G5s?
>> G5 sets DA
Alexander Graf writes:
> On 06.05.14 02:41, Paul Mackerras wrote:
>> On Mon, May 05, 2014 at 01:19:30PM +0200, Alexander Graf wrote:
>>> On 05/04/2014 07:21 PM, Aneesh Kumar K.V wrote:
+#ifdef CONFIG_PPC_BOOK3S_64
+ return vcpu->arch.fault_dar;
>>> How about PA6T and G5s?
>> G5 sets DA
On Tue, May 6, 2014 at 2:04 PM, Geert Uytterhoeven wrote:
> JFYI, when comparing v3.15-rc4[1] to v3.15-rc3[3], the summaries are:
> - build errors: +7/-1
+ /scratch/kisskb/src/arch/powerpc/include/asm/fixmap.h: error:
overflow in enumeration values CC drivers/hwmon/smsc47m192.o:
=> 51:
* Rusty Russell wrote:
> Ingo Molnar writes:
> > * Madhavan Srinivasan wrote:
> >
> >> Performance data for different FAULT_AROUND_ORDER values from 4 socket
> >> Power7 system (128 Threads and 128GB memory). perf stat with repeat of 5
> >> is used to get the stddev values. Test ran in v3.14 k
On 05/06/2014 11:26 AM, Benjamin Herrenschmidt wrote:
On Tue, 2014-05-06 at 11:12 +0200, Alexander Graf wrote:
So if I understand this patch correctly, it simply introduces logic to
handle page sizes other than 4k, 64k, 16M by analyzing the actual page
size field in the HPTE. Mind to explain wh
On Tue, 2014-05-06 at 11:12 +0200, Alexander Graf wrote:
> So if I understand this patch correctly, it simply introduces logic to
> handle page sizes other than 4k, 64k, 16M by analyzing the actual page
> size field in the HPTE. Mind to explain why exactly that enables us to
> use THP?
>
> What
On 05/04/2014 07:30 PM, Aneesh Kumar K.V wrote:
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/kvm_book3s_64.h | 146 ++-
arch/powerpc/kvm/book3s_hv.c | 7 ++
2 files changed, 130 insertions(+), 23 deletions(-)
diff --git a/arch/powerp
"Linuxppc-dev"
wrote on 2014/05/06 08:28:42:
>
.
>
> > That said,
> > I don't object to having a way to label a PHY as attached via TBI if
> > that's useful. I'm giving a mild, non-nacking (given the history)
> > objection to using device_type for that (given other history).
>
> Person
On 06.05.14 09:19, Benjamin Herrenschmidt wrote:
On Tue, 2014-05-06 at 09:05 +0200, Alexander Graf wrote:
On 06.05.14 02:06, Benjamin Herrenschmidt wrote:
On Mon, 2014-05-05 at 17:16 +0200, Alexander Graf wrote:
Isn't this a greater problem? We should start swapping before we hit
the point wh
On Tue, 2014-05-06 at 09:05 +0200, Alexander Graf wrote:
> On 06.05.14 02:06, Benjamin Herrenschmidt wrote:
> > On Mon, 2014-05-05 at 17:16 +0200, Alexander Graf wrote:
> >> Isn't this a greater problem? We should start swapping before we hit
> >> the point where non movable kernel allocation fails
On Tue, 2014-05-06 at 08:56 +0200, Alexander Graf wrote:
> > For the error injection, I guess I have to put the logic token
> management
> > into QEMU and error injection request will be handled by QEMU and
> then
> > routed to host kernel via additional syscall as we did for pSeries.
>
> Yes, sta
On 06.05.14 02:06, Benjamin Herrenschmidt wrote:
On Mon, 2014-05-05 at 17:16 +0200, Alexander Graf wrote:
Isn't this a greater problem? We should start swapping before we hit
the point where non movable kernel allocation fails, no?
Possibly but the fact remains, this can be avoided by making s
43 matches
Mail list logo