* Re: [RFC PATCH] KVM: PPC: BOOK3S: HV: THP support for guest
From: Alexander Graf @ 2014-05-05 11:38 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: paulus, linuxppc-dev, kvm-ppc, kvm
In-Reply-To: <1399224616-25142-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On 05/04/2014 07:30 PM, Aneesh Kumar K.V wrote:
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
No patch description, no proper explanations anywhere why you're doing
what. All of that in a pretty sensitive piece of code. There's no way
this patch can go upstream in its current form.
Alex
^ permalink raw reply
* Re: [PATCH RFC 00/22] EEH Support for VFIO PCI devices on PowerKVM guest
From: Alexander Graf @ 2014-05-05 11:56 UTC (permalink / raw)
To: Gavin Shan; +Cc: kvm, aik, kvm-ppc, alex.williamson, qiudayu, linuxppc-dev
In-Reply-To: <1399253291-3975-1-git-send-email-gwshan@linux.vnet.ibm.com>
On 05/05/2014 03:27 AM, Gavin Shan wrote:
> The series of patches intends to support EEH for PCI devices, which have been
> passed through to PowerKVM based guest via VFIO. The implementation is
> straightforward based on the issues or problems we have to resolve to support
> EEH for PowerKVM based guest.
>
> - Emulation for EEH RTAS requests. Thanksfully, we already have infrastructure
> to emulate XICS. Without introducing new mechanism, we just extend that
> existing infrastructure to support EEH RTAS emulation. EEH RTAS requests
> initiated from guest are posted to host where the requests get handled or
> delivered to underly firmware for further handling. For that, the host kerenl
> has to maintain the PCI address (host domain/bus/slot/function to guest's
> PHB BUID/bus/slot/function) mapping via KVM VFIO device. The address mapping
> will be built when initializing VFIO device in QEMU and destroied when the
> VFIO device in QEMU is going to offline, or VM is destroy.
Do you also expose all those interfaces to user space? VFIO is as much
about user space device drivers as it is about device assignment.
I would like to first see an implementation that doesn't touch KVM
emulation code at all but instead routes everything through QEMU. As a
second step we can then accelerate performance critical paths inside of KVM.
That way we ensure that user space device drivers have all the power
over a device they need to drive it.
Alex
^ permalink raw reply
* Re: [PATCH] powerpc: move epapr paravirt init of power_save to an initcall
From: Tudor Laurentiu @ 2014-05-05 12:17 UTC (permalink / raw)
To: Alexander Graf
Cc: Scott Wood, Laurentiu.Tudor, linuxppc-dev@lists.ozlabs.org,
Stuart Yoder
In-Reply-To: <53615872.3010006@suse.de>
On 04/30/2014 11:09 PM, Alexander Graf wrote:
>
> On 30.04.14 22:03, Stuart Yoder wrote:
>>
>>> -----Original Message-----
>>> From: Alexander Graf [mailto:agraf@suse.de]
>>> Sent: Wednesday, April 30, 2014 2:56 PM
>>> To: Yoder Stuart-B08248; benh@kernel.crashing.org; Wood Scott-B07421
>>> Cc: linuxppc-dev@lists.ozlabs.org
>>> Subject: Re: [PATCH] powerpc: move epapr paravirt init of power_save to
>>> an initcall
>>>
>>>
>>> On 30.04.14 21:54, Stuart Yoder wrote:
>>>> From: Stuart Yoder <stuart.yoder@freescale.com>
>>>>
>>>> some restructuring of epapr paravirt init resulted in
>>>> ppc_md.power_save being set, and then overwritten to
>>>> NULL during machine_init. This patch splits the
>>>> initialization of ppc_md.power_save out into a postcore
>>>> init call.
>>>>
>>>> Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com>
>>>> ---
>>>> arch/powerpc/kernel/epapr_paravirt.c | 25
>>>> ++++++++++++++++++++-----
>>>> 1 file changed, 20 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/arch/powerpc/kernel/epapr_paravirt.c
>>> b/arch/powerpc/kernel/epapr_paravirt.c
>>>> index 6300c13..c49b69c 100644
>>>> --- a/arch/powerpc/kernel/epapr_paravirt.c
>>>> +++ b/arch/powerpc/kernel/epapr_paravirt.c
>>>> @@ -52,11 +52,6 @@ static int __init early_init_dt_scan_epapr(unsigned
>>> long node,
>>>> #endif
>>>> }
>>>>
>>>> -#if !defined(CONFIG_64BIT) || defined(CONFIG_PPC_BOOK3E_64)
>>>> - if (of_get_flat_dt_prop(node, "has-idle", NULL))
>>>> - ppc_md.power_save = epapr_ev_idle;
>>>> -#endif
>>>> -
>>>> epapr_paravirt_enabled = true;
>>>>
>>>> return 1;
>>>> @@ -69,3 +64,23 @@ int __init epapr_paravirt_early_init(void)
>>>> return 0;
>>>> }
>>>>
>>>> +static int __init epapr_idle_init_dt_scan(unsigned long node,
>>>> + const char *uname,
>>>> + int depth, void *data)
>>>> +{
>>>> +#if !defined(CONFIG_64BIT) || defined(CONFIG_PPC_BOOK3E_64)
>>>> + if (of_get_flat_dt_prop(node, "has-idle", NULL))
>>>> + ppc_md.power_save = epapr_ev_idle;
>>>> +#endif
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static int __init epapr_idle_init(void)
>>>> +{
>>>> + if (epapr_paravirt_enabled)
>>>> + of_scan_flat_dt(epapr_idle_init_dt_scan, NULL);
>>> Doesn't this scan all nodes? We only want to match on
>>> /hypervisor/has-idle, no?
>> I cut/pasted from the approach the existing code in that file
>> took, but yes you're right we just need the one property.
>> Let me respin that to look at the hypervisor node only.
>
> Yeah, the same commit that introduced the breakage on has-idle also
> removed the explicit check for /hypervisor.
>
> Laurentiu, was this change on purpose?
>
Alex,
IIRC, at that time i had to switch from the normal "of" functions to a
completely different api that's available in early init stage. This
early "of" api is pretty limited (e.g. doesn't have a way to address a
specific node) and i had to use that function that scans the whole tree.
---
Best Regards, Laurentiu
^ permalink raw reply
* Re: [PATCH] powerpc: move epapr paravirt init of power_save to an initcall
From: Alexander Graf @ 2014-05-05 12:21 UTC (permalink / raw)
To: Tudor Laurentiu
Cc: Scott Wood, Laurentiu.Tudor, linuxppc-dev@lists.ozlabs.org,
Stuart Yoder
In-Reply-To: <5367815F.5010509@freescale.com>
On 05/05/2014 02:17 PM, Tudor Laurentiu wrote:
> On 04/30/2014 11:09 PM, Alexander Graf wrote:
>>
>> On 30.04.14 22:03, Stuart Yoder wrote:
>>>
>>>> -----Original Message-----
>>>> From: Alexander Graf [mailto:agraf@suse.de]
>>>> Sent: Wednesday, April 30, 2014 2:56 PM
>>>> To: Yoder Stuart-B08248; benh@kernel.crashing.org; Wood Scott-B07421
>>>> Cc: linuxppc-dev@lists.ozlabs.org
>>>> Subject: Re: [PATCH] powerpc: move epapr paravirt init of
>>>> power_save to
>>>> an initcall
>>>>
>>>>
>>>> On 30.04.14 21:54, Stuart Yoder wrote:
>>>>> From: Stuart Yoder <stuart.yoder@freescale.com>
>>>>>
>>>>> some restructuring of epapr paravirt init resulted in
>>>>> ppc_md.power_save being set, and then overwritten to
>>>>> NULL during machine_init. This patch splits the
>>>>> initialization of ppc_md.power_save out into a postcore
>>>>> init call.
>>>>>
>>>>> Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com>
>>>>> ---
>>>>> arch/powerpc/kernel/epapr_paravirt.c | 25
>>>>> ++++++++++++++++++++-----
>>>>> 1 file changed, 20 insertions(+), 5 deletions(-)
>>>>>
>>>>> diff --git a/arch/powerpc/kernel/epapr_paravirt.c
>>>> b/arch/powerpc/kernel/epapr_paravirt.c
>>>>> index 6300c13..c49b69c 100644
>>>>> --- a/arch/powerpc/kernel/epapr_paravirt.c
>>>>> +++ b/arch/powerpc/kernel/epapr_paravirt.c
>>>>> @@ -52,11 +52,6 @@ static int __init
>>>>> early_init_dt_scan_epapr(unsigned
>>>> long node,
>>>>> #endif
>>>>> }
>>>>>
>>>>> -#if !defined(CONFIG_64BIT) || defined(CONFIG_PPC_BOOK3E_64)
>>>>> - if (of_get_flat_dt_prop(node, "has-idle", NULL))
>>>>> - ppc_md.power_save = epapr_ev_idle;
>>>>> -#endif
>>>>> -
>>>>> epapr_paravirt_enabled = true;
>>>>>
>>>>> return 1;
>>>>> @@ -69,3 +64,23 @@ int __init epapr_paravirt_early_init(void)
>>>>> return 0;
>>>>> }
>>>>>
>>>>> +static int __init epapr_idle_init_dt_scan(unsigned long node,
>>>>> + const char *uname,
>>>>> + int depth, void *data)
>>>>> +{
>>>>> +#if !defined(CONFIG_64BIT) || defined(CONFIG_PPC_BOOK3E_64)
>>>>> + if (of_get_flat_dt_prop(node, "has-idle", NULL))
>>>>> + ppc_md.power_save = epapr_ev_idle;
>>>>> +#endif
>>>>> + return 0;
>>>>> +}
>>>>> +
>>>>> +static int __init epapr_idle_init(void)
>>>>> +{
>>>>> + if (epapr_paravirt_enabled)
>>>>> + of_scan_flat_dt(epapr_idle_init_dt_scan, NULL);
>>>> Doesn't this scan all nodes? We only want to match on
>>>> /hypervisor/has-idle, no?
>>> I cut/pasted from the approach the existing code in that file
>>> took, but yes you're right we just need the one property.
>>> Let me respin that to look at the hypervisor node only.
>>
>> Yeah, the same commit that introduced the breakage on has-idle also
>> removed the explicit check for /hypervisor.
>>
>> Laurentiu, was this change on purpose?
>>
>
> Alex,
>
> IIRC, at that time i had to switch from the normal "of" functions to a
> completely different api that's available in early init stage. This
> early "of" api is pretty limited (e.g. doesn't have a way to address a
> specific node) and i had to use that function that scans the whole tree.
Ok, so it is an accident. Could you please post a patch that checks that
the node we're looking at is called "hypervisor"? The simple API should
give you enough information for that at least. Maybe you could even
check that the parent node is the root node.
Alex
^ permalink raw reply
* Re: [PATCH] powerpc: move epapr paravirt init of power_save to an initcall
From: Tudor Laurentiu @ 2014-05-05 12:35 UTC (permalink / raw)
To: Alexander Graf
Cc: Scott Wood, Laurentiu.Tudor, linuxppc-dev@lists.ozlabs.org,
Stuart Yoder
In-Reply-To: <53678236.7060206@suse.de>
On 05/05/2014 03:21 PM, Alexander Graf wrote:
> On 05/05/2014 02:17 PM, Tudor Laurentiu wrote:
>> On 04/30/2014 11:09 PM, Alexander Graf wrote:
>>>
>>> On 30.04.14 22:03, Stuart Yoder wrote:
>>>>
>>>>> -----Original Message-----
>>>>> From: Alexander Graf [mailto:agraf@suse.de]
>>>>> Sent: Wednesday, April 30, 2014 2:56 PM
>>>>> To: Yoder Stuart-B08248; benh@kernel.crashing.org; Wood Scott-B07421
>>>>> Cc: linuxppc-dev@lists.ozlabs.org
>>>>> Subject: Re: [PATCH] powerpc: move epapr paravirt init of
>>>>> power_save to
>>>>> an initcall
>>>>>
>>>>>
>>>>> On 30.04.14 21:54, Stuart Yoder wrote:
>>>>>> From: Stuart Yoder <stuart.yoder@freescale.com>
>>>>>>
>>>>>> some restructuring of epapr paravirt init resulted in
>>>>>> ppc_md.power_save being set, and then overwritten to
>>>>>> NULL during machine_init. This patch splits the
>>>>>> initialization of ppc_md.power_save out into a postcore
>>>>>> init call.
>>>>>>
>>>>>> Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com>
>>>>>> ---
>>>>>> arch/powerpc/kernel/epapr_paravirt.c | 25
>>>>>> ++++++++++++++++++++-----
>>>>>> 1 file changed, 20 insertions(+), 5 deletions(-)
>>>>>>
>>>>>> diff --git a/arch/powerpc/kernel/epapr_paravirt.c
>>>>> b/arch/powerpc/kernel/epapr_paravirt.c
>>>>>> index 6300c13..c49b69c 100644
>>>>>> --- a/arch/powerpc/kernel/epapr_paravirt.c
>>>>>> +++ b/arch/powerpc/kernel/epapr_paravirt.c
>>>>>> @@ -52,11 +52,6 @@ static int __init
>>>>>> early_init_dt_scan_epapr(unsigned
>>>>> long node,
>>>>>> #endif
>>>>>> }
>>>>>>
>>>>>> -#if !defined(CONFIG_64BIT) || defined(CONFIG_PPC_BOOK3E_64)
>>>>>> - if (of_get_flat_dt_prop(node, "has-idle", NULL))
>>>>>> - ppc_md.power_save = epapr_ev_idle;
>>>>>> -#endif
>>>>>> -
>>>>>> epapr_paravirt_enabled = true;
>>>>>>
>>>>>> return 1;
>>>>>> @@ -69,3 +64,23 @@ int __init epapr_paravirt_early_init(void)
>>>>>> return 0;
>>>>>> }
>>>>>>
>>>>>> +static int __init epapr_idle_init_dt_scan(unsigned long node,
>>>>>> + const char *uname,
>>>>>> + int depth, void *data)
>>>>>> +{
>>>>>> +#if !defined(CONFIG_64BIT) || defined(CONFIG_PPC_BOOK3E_64)
>>>>>> + if (of_get_flat_dt_prop(node, "has-idle", NULL))
>>>>>> + ppc_md.power_save = epapr_ev_idle;
>>>>>> +#endif
>>>>>> + return 0;
>>>>>> +}
>>>>>> +
>>>>>> +static int __init epapr_idle_init(void)
>>>>>> +{
>>>>>> + if (epapr_paravirt_enabled)
>>>>>> + of_scan_flat_dt(epapr_idle_init_dt_scan, NULL);
>>>>> Doesn't this scan all nodes? We only want to match on
>>>>> /hypervisor/has-idle, no?
>>>> I cut/pasted from the approach the existing code in that file
>>>> took, but yes you're right we just need the one property.
>>>> Let me respin that to look at the hypervisor node only.
>>>
>>> Yeah, the same commit that introduced the breakage on has-idle also
>>> removed the explicit check for /hypervisor.
>>>
>>> Laurentiu, was this change on purpose?
>>>
>>
>> Alex,
>>
>> IIRC, at that time i had to switch from the normal "of" functions to a
>> completely different api that's available in early init stage. This
>> early "of" api is pretty limited (e.g. doesn't have a way to address a
>> specific node) and i had to use that function that scans the whole tree.
>
> Ok, so it is an accident. Could you please post a patch that checks that
> the node we're looking at is called "hypervisor"? The simple API should
> give you enough information for that at least. Maybe you could even
> check that the parent node is the root node.
>
Just had a quick look and it looks that that early fdt api was improved
with a function that allows specifying a starting path for the scan
(of_scan_flat_dt_by_path() added in commit
57d74bcf3072b65bde5aa540cedc976a75c48e5c). So i think we can simply use
that instead.
---
Best Regards, Laurentiu
^ permalink raw reply
* Re: [PATCH] powerpc: memcpy optimization for 64bit LE
From: Philippe Bergheaud @ 2014-05-05 12:56 UTC (permalink / raw)
To: Anton Blanchard; +Cc: paulus, linuxppc-dev
In-Reply-To: <20140430091054.4de84c9b@kryten>
Anton Blanchard wrote:
> Unaligned stores take alignment exceptions on POWER7 running in little-endian.
> This is a dumb little-endian base memcpy that prevents unaligned stores.
> Once booted the feature fixup code switches over to the VMX copy loops
> (which are already endian safe).
>
> The question is what we do before that switch over. The base 64bit
> memcpy takes alignment exceptions on POWER7 so we can't use it as is.
> Fixing the causes of alignment exception would slow it down, because
> we'd need to ensure all loads and stores are aligned either through
> rotate tricks or bytewise loads and stores. Either would be bad for
> all other 64bit platforms.
>
> [ I simplified the loop a bit - Anton ]
Got it.
The 3 instructions that you have removed were modifying r5 for no reason,
as the last instruction was always resetting r5 to its initial value.
Philippe
^ permalink raw reply
* Re: [PATCH RFC 00/22] EEH Support for VFIO PCI devices on PowerKVM guest
From: Alex Williamson @ 2014-05-05 14:00 UTC (permalink / raw)
To: Alexander Graf; +Cc: kvm, aik, Gavin Shan, kvm-ppc, qiudayu, linuxppc-dev
In-Reply-To: <53677C6C.8060508@suse.de>
On Mon, 2014-05-05 at 13:56 +0200, Alexander Graf wrote:
> On 05/05/2014 03:27 AM, Gavin Shan wrote:
> > The series of patches intends to support EEH for PCI devices, which have been
> > passed through to PowerKVM based guest via VFIO. The implementation is
> > straightforward based on the issues or problems we have to resolve to support
> > EEH for PowerKVM based guest.
> >
> > - Emulation for EEH RTAS requests. Thanksfully, we already have infrastructure
> > to emulate XICS. Without introducing new mechanism, we just extend that
> > existing infrastructure to support EEH RTAS emulation. EEH RTAS requests
> > initiated from guest are posted to host where the requests get handled or
> > delivered to underly firmware for further handling. For that, the host kerenl
> > has to maintain the PCI address (host domain/bus/slot/function to guest's
> > PHB BUID/bus/slot/function) mapping via KVM VFIO device. The address mapping
> > will be built when initializing VFIO device in QEMU and destroied when the
> > VFIO device in QEMU is going to offline, or VM is destroy.
>
> Do you also expose all those interfaces to user space? VFIO is as much
> about user space device drivers as it is about device assignment.
>
> I would like to first see an implementation that doesn't touch KVM
> emulation code at all but instead routes everything through QEMU. As a
> second step we can then accelerate performance critical paths inside of KVM.
>
> That way we ensure that user space device drivers have all the power
> over a device they need to drive it.
+1
^ permalink raw reply
* Re: [PATCH V4] POWERPC: BOOK3S: KVM: Use the saved dar value and generic make_dsisr
From: Aneesh Kumar K.V @ 2014-05-05 14:26 UTC (permalink / raw)
To: Alexander Graf; +Cc: paulus, linuxppc-dev, kvm-ppc, kvm
In-Reply-To: <536773C2.1070502@suse.de>
Alexander Graf <agraf@suse.de> writes:
> On 05/04/2014 07:21 PM, Aneesh Kumar K.V wrote:
>> 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 <aneesh.kumar@linux.vnet.ibm.com>
>> ---
>> Changes from V3:
>> * Use make_dsisr instead of checking feature flag to decide whether to use
>> saved dsisr or not
>>
....
>> ulong kvmppc_alignment_dar(struct kvm_vcpu *vcpu, unsigned int inst)
>> {
>> +#ifdef CONFIG_PPC_BOOK3S_64
>> + return vcpu->arch.fault_dar;
>
> How about PA6T and G5s?
>
>
Paul mentioned that BOOK3S always had DAR value set on alignment
interrupt. And the patch is to enable/collect correct DAR value when
running with Little Endian PR guest. Now to limit the impact and to
enable Little Endian PR guest, I ended up doing the conditional code
only for book3s 64 for which we know for sure that we set DAR value.
-aneesh
^ permalink raw reply
* Re: [PATCH] KVM: PPC: BOOK3S: HV: Don't try to allocate from kernel page allocator for hash page table.
From: Aneesh Kumar K.V @ 2014-05-05 14:35 UTC (permalink / raw)
To: Alexander Graf; +Cc: paulus, linuxppc-dev, kvm-ppc, kvm
In-Reply-To: <53677558.50900@suse.de>
Alexander Graf <agraf@suse.de> writes:
> On 05/04/2014 07:25 PM, Aneesh Kumar K.V wrote:
>> We reserve 5% of total ram for CMA allocation and not using that can
>> result in us running out of numa node memory with specific
>> configuration. One caveat is we may not have node local hpt with pinned
>> vcpu configuration. But currently libvirt also pins the vcpu to cpuset
>> after creating hash page table.
>
> I don't understand the problem. Can you please elaborate?
>
>
Lets take a system with 100GB RAM. We reserve around 5GB for htab
allocation. Now if we use rest of available memory for hugetlbfs
(because we want all the guest to be backed by huge pages), we would
end up in a situation where we have a few GB of free RAM and 5GB of CMA
reserve area. Now if we allow hash page table allocation to consume the
free space, we would end up hitting page allocation failure for other
non movable kernel allocation even though we still have 5GB CMA reserve
space free.
-aneesh
^ permalink raw reply
* Re: [PATCH V4] POWERPC: BOOK3S: KVM: Use the saved dar value and generic make_dsisr
From: Alexander Graf @ 2014-05-05 14:43 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: kvm, linuxppc-dev, kvm-ppc, paulus, olofj
In-Reply-To: <87tx949u9d.fsf@linux.vnet.ibm.com>
On 05/05/2014 04:26 PM, Aneesh Kumar K.V wrote:
> Alexander Graf <agraf@suse.de> writes:
>
>> On 05/04/2014 07:21 PM, Aneesh Kumar K.V wrote:
>>> 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 <aneesh.kumar@linux.vnet.ibm.com>
>>> ---
>>> Changes from V3:
>>> * Use make_dsisr instead of checking feature flag to decide whether to use
>>> saved dsisr or not
>>>
> ....
>
>>> ulong kvmppc_alignment_dar(struct kvm_vcpu *vcpu, unsigned int inst)
>>> {
>>> +#ifdef CONFIG_PPC_BOOK3S_64
>>> + return vcpu->arch.fault_dar;
>> How about PA6T and G5s?
>>
>>
> Paul mentioned that BOOK3S always had DAR value set on alignment
> interrupt. And the patch is to enable/collect correct DAR value when
> running with Little Endian PR guest. Now to limit the impact and to
> enable Little Endian PR guest, I ended up doing the conditional code
> only for book3s 64 for which we know for sure that we set DAR value.
Yes, and I'm asking whether we know that this statement holds true for
PA6T and G5 chips which I wouldn't consider IBM POWER. Since the G5 is
at least developed by IBM, I'd assume its semantics here are similar to
POWER4, but for PA6T I wouldn't be so sure.
Alex
^ permalink raw reply
* Re: [RFC PATCH] KVM: PPC: BOOK3S: HV: THP support for guest
From: Aneesh Kumar K.V @ 2014-05-05 14:47 UTC (permalink / raw)
To: Alexander Graf; +Cc: paulus, linuxppc-dev, kvm-ppc, kvm
In-Reply-To: <53677834.5010808@suse.de>
Alexander Graf <agraf@suse.de> writes:
> On 05/04/2014 07:30 PM, Aneesh Kumar K.V wrote:
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>
> No patch description, no proper explanations anywhere why you're doing
> what. All of that in a pretty sensitive piece of code. There's no way
> this patch can go upstream in its current form.
>
Sorry about being vague. Will add a better commit message. The goal is
to export MPSS support to guest if the host support the same. MPSS
support is exported via penc encoding in "ibm,segment-page-sizes". The
actual format can be found at htab_dt_scan_page_sizes. When the guest
memory is backed by hugetlbfs we expose the penc encoding the host
support to guest via kvmppc_add_seg_page_size.
Now the challenge to THP support is to make sure that our henter,
hremove etc decode base page size and actual page size correctly
from the hash table entry values. Most of the changes is to do that.
Rest of the stuff is already handled by kvm.
NOTE: It is much easier to read the code after applying the patch rather
than reading the diff. I have added comments around each steps in the
code.
-aneesh
^ permalink raw reply
* Re: [PATCH V4] POWERPC: BOOK3S: KVM: Use the saved dar value and generic make_dsisr
From: Aneesh Kumar K.V @ 2014-05-05 14:50 UTC (permalink / raw)
To: Alexander Graf; +Cc: kvm, linuxppc-dev, kvm-ppc, paulus, olofj
In-Reply-To: <5367A39D.9080709@suse.de>
Alexander Graf <agraf@suse.de> writes:
> On 05/05/2014 04:26 PM, Aneesh Kumar K.V wrote:
>> Alexander Graf <agraf@suse.de> writes:
>>
>>> On 05/04/2014 07:21 PM, Aneesh Kumar K.V wrote:
>>>> 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 <aneesh.kumar@linux.vnet.ibm.com>
>>>> ---
>>>> Changes from V3:
>>>> * Use make_dsisr instead of checking feature flag to decide whether to use
>>>> saved dsisr or not
>>>>
>> ....
>>
>>>> ulong kvmppc_alignment_dar(struct kvm_vcpu *vcpu, unsigned int inst)
>>>> {
>>>> +#ifdef CONFIG_PPC_BOOK3S_64
>>>> + return vcpu->arch.fault_dar;
>>> How about PA6T and G5s?
>>>
>>>
>> Paul mentioned that BOOK3S always had DAR value set on alignment
>> interrupt. And the patch is to enable/collect correct DAR value when
>> running with Little Endian PR guest. Now to limit the impact and to
>> enable Little Endian PR guest, I ended up doing the conditional code
>> only for book3s 64 for which we know for sure that we set DAR value.
>
> Yes, and I'm asking whether we know that this statement holds true for
> PA6T and G5 chips which I wouldn't consider IBM POWER. Since the G5 is
> at least developed by IBM, I'd assume its semantics here are similar to
> POWER4, but for PA6T I wouldn't be so sure.
I will have to defer to Paul on that question. But that should not
prevent this patch from going upstream right ?
-aneesh
^ permalink raw reply
* Re: [PATCH V4] POWERPC: BOOK3S: KVM: Use the saved dar value and generic make_dsisr
From: Olof Johansson @ 2014-05-05 14:54 UTC (permalink / raw)
To: Alexander Graf
Cc: kvm, kvm-ppc, Paul Mackerras, Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <5367A39D.9080709@suse.de>
[-- Attachment #1: Type: text/plain, Size: 1866 bytes --]
2014-05-05 7:43 GMT-07:00 Alexander Graf <agraf@suse.de>:
> On 05/05/2014 04:26 PM, Aneesh Kumar K.V wrote:
>
>> Alexander Graf <agraf@suse.de> writes:
>>
>> On 05/04/2014 07:21 PM, Aneesh Kumar K.V wrote:
>>>
>>>> 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 <aneesh.kumar@linux.vnet.ibm.com>
>>>> ---
>>>> Changes from V3:
>>>> * Use make_dsisr instead of checking feature flag to decide whether to
>>>> use
>>>> saved dsisr or not
>>>>
>>>> ....
>>
>> ulong kvmppc_alignment_dar(struct kvm_vcpu *vcpu, unsigned int inst)
>>>> {
>>>> +#ifdef CONFIG_PPC_BOOK3S_64
>>>> + return vcpu->arch.fault_dar;
>>>>
>>> How about PA6T and G5s?
>>>
>>>
>>> Paul mentioned that BOOK3S always had DAR value set on alignment
>> interrupt. And the patch is to enable/collect correct DAR value when
>> running with Little Endian PR guest. Now to limit the impact and to
>> enable Little Endian PR guest, I ended up doing the conditional code
>> only for book3s 64 for which we know for sure that we set DAR value.
>>
>
> Yes, and I'm asking whether we know that this statement holds true for
> PA6T and G5 chips which I wouldn't consider IBM POWER. Since the G5 is at
> least developed by IBM, I'd assume its semantics here are similar to
> POWER4, but for PA6T I wouldn't be so sure.
>
>
Thanks for looking out for us, obviously IBM doesn't (based on the reply a
minute ago).
In the end, since there's been no work to enable KVM on PA6T, I'm not too
worried. I guess it's one more thing to sort out (and check for) whenever
someone does that.
I definitely don't have cycles to deal with that myself at this time. I can
help find hardware for someone who wants to, but even then I'm guessing the
interest is pretty limited.
-Olof
[-- Attachment #2: Type: text/html, Size: 3115 bytes --]
^ permalink raw reply
* Re: [PATCH V4] POWERPC: BOOK3S: KVM: Use the saved dar value and generic make_dsisr
From: Olof Johansson @ 2014-05-05 14:57 UTC (permalink / raw)
To: Alexander Graf
Cc: kvm, kvm-ppc, Paul Mackerras, Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <5367A39D.9080709@suse.de>
[Now without HTML email -- it's what you get for cc:ing me at work
instead of my upstream email :)]
2014-05-05 7:43 GMT-07:00 Alexander Graf <agraf@suse.de>:
>
> On 05/05/2014 04:26 PM, Aneesh Kumar K.V wrote:
>>
>> Alexander Graf <agraf@suse.de> writes:
>>
>>> On 05/04/2014 07:21 PM, Aneesh Kumar K.V wrote:
>>>>
>>>> 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 <aneesh.kumar@linux.vnet.ibm.com>
>>>> ---
>>>> Changes from V3:
>>>> * Use make_dsisr instead of checking feature flag to decide whether to=
use
>>>> saved dsisr or not
>>>>
>> ....
>>
>>>> ulong kvmppc_alignment_dar(struct kvm_vcpu *vcpu, unsigned int inst=
)
>>>> {
>>>> +#ifdef CONFIG_PPC_BOOK3S_64
>>>> + return vcpu->arch.fault_dar;
>>>
>>> How about PA6T and G5s?
>>>
>>>
>> Paul mentioned that BOOK3S always had DAR value set on alignment
>> interrupt. And the patch is to enable/collect correct DAR value when
>> running with Little Endian PR guest. Now to limit the impact and to
>> enable Little Endian PR guest, I ended up doing the conditional code
>> only for book3s 64 for which we know for sure that we set DAR value.
>
>
> Yes, and I'm asking whether we know that this statement holds true for PA=
6T and G5 chips which I wouldn't consider IBM POWER. Since the G5 is at lea=
st developed by IBM, I'd assume its semantics here are similar to POWER4, b=
ut for PA6T I wouldn't be so sure.
>
Thanks for looking out for us, obviously IBM doesn't (based on the
reply a minute ago).
In the end, since there's been no work to enable KVM on PA6T, I'm not
too worried. I guess it's one more thing to sort out (and check for)
whenever someone does that.
I definitely don't have cycles to deal with that myself at this time.
I can help find hardware for someone who wants to, but even then I'm
guessing the interest is pretty limited.
-Olof
^ permalink raw reply
* Re: [PATCH V4] POWERPC: BOOK3S: KVM: Use the saved dar value and generic make_dsisr
From: Aneesh Kumar K.V @ 2014-05-05 15:03 UTC (permalink / raw)
To: Olof Johansson, Alexander Graf; +Cc: Paul Mackerras, linuxppc-dev, kvm-ppc, kvm
In-Reply-To: <CALiw-2G2LL55WfZpDTrGr198W4uokcoZn5JxYNVYHbt4Bu_DhA@mail.gmail.com>
Olof Johansson <olofj@google.com> writes:
> 2014-05-05 7:43 GMT-07:00 Alexander Graf <agraf@suse.de>:
>
>> On 05/05/2014 04:26 PM, Aneesh Kumar K.V wrote:
>>
>>> Alexander Graf <agraf@suse.de> writes:
>>>
>>> On 05/04/2014 07:21 PM, Aneesh Kumar K.V wrote:
>>>>
>>>>> 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 <aneesh.kumar@linux.vnet.ibm.com>
>>>>> ---
>>>>> Changes from V3:
>>>>> * Use make_dsisr instead of checking feature flag to decide whether to
>>>>> use
>>>>> saved dsisr or not
>>>>>
>>>>> ....
>>>
>>> ulong kvmppc_alignment_dar(struct kvm_vcpu *vcpu, unsigned int inst)
>>>>> {
>>>>> +#ifdef CONFIG_PPC_BOOK3S_64
>>>>> + return vcpu->arch.fault_dar;
>>>>>
>>>> How about PA6T and G5s?
>>>>
>>>>
>>>> Paul mentioned that BOOK3S always had DAR value set on alignment
>>> interrupt. And the patch is to enable/collect correct DAR value when
>>> running with Little Endian PR guest. Now to limit the impact and to
>>> enable Little Endian PR guest, I ended up doing the conditional code
>>> only for book3s 64 for which we know for sure that we set DAR value.
>>>
>>
>> Yes, and I'm asking whether we know that this statement holds true for
>> PA6T and G5 chips which I wouldn't consider IBM POWER. Since the G5 is at
>> least developed by IBM, I'd assume its semantics here are similar to
>> POWER4, but for PA6T I wouldn't be so sure.
>>
>>
> Thanks for looking out for us, obviously IBM doesn't (based on the reply a
> minute ago).
The reason I deferred the question to Paul is really because I don't
know enough about PA6T and G5 to comment. I intentionally restricted the
changes to BOOK3S_64 because I wanted to make sure I don't break
anything else. It is in no way to hint that others don't care.
-aneesh
^ permalink raw reply
* Re: [PATCH V4] POWERPC: BOOK3S: KVM: Use the saved dar value and generic make_dsisr
From: Olof Johansson @ 2014-05-05 15:06 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: kvm, Alexander Graf, kvm-ppc, Paul Mackerras, linuxppc-dev
In-Reply-To: <87d2fs9sk0.fsf@linux.vnet.ibm.com>
2014-05-05 8:03 GMT-07:00 Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>:
> Olof Johansson <olofj@google.com> writes:
>
>> 2014-05-05 7:43 GMT-07:00 Alexander Graf <agraf@suse.de>:
>>
>>> On 05/05/2014 04:26 PM, Aneesh Kumar K.V wrote:
>>>
>>>> Alexander Graf <agraf@suse.de> writes:
>>>>
>>>> On 05/04/2014 07:21 PM, Aneesh Kumar K.V wrote:
>>>>>
>>>>>> 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 <aneesh.kumar@linux.vnet.ibm.com>
>>>>>> ---
>>>>>> Changes from V3:
>>>>>> * Use make_dsisr instead of checking feature flag to decide whether to
>>>>>> use
>>>>>> saved dsisr or not
>>>>>>
>>>>>> ....
>>>>
>>>> ulong kvmppc_alignment_dar(struct kvm_vcpu *vcpu, unsigned int inst)
>>>>>> {
>>>>>> +#ifdef CONFIG_PPC_BOOK3S_64
>>>>>> + return vcpu->arch.fault_dar;
>>>>>>
>>>>> How about PA6T and G5s?
>>>>>
>>>>>
>>>>> Paul mentioned that BOOK3S always had DAR value set on alignment
>>>> interrupt. And the patch is to enable/collect correct DAR value when
>>>> running with Little Endian PR guest. Now to limit the impact and to
>>>> enable Little Endian PR guest, I ended up doing the conditional code
>>>> only for book3s 64 for which we know for sure that we set DAR value.
>>>>
>>>
>>> Yes, and I'm asking whether we know that this statement holds true for
>>> PA6T and G5 chips which I wouldn't consider IBM POWER. Since the G5 is at
>>> least developed by IBM, I'd assume its semantics here are similar to
>>> POWER4, but for PA6T I wouldn't be so sure.
>>>
>>>
>> Thanks for looking out for us, obviously IBM doesn't (based on the reply a
>> minute ago).
>
> The reason I deferred the question to Paul is really because I don't
> know enough about PA6T and G5 to comment. I intentionally restricted the
> changes to BOOK3S_64 because I wanted to make sure I don't break
> anything else. It is in no way to hint that others don't care.
Ah, I see -- the disconnect is that you don't think PA6T and 970 are
64-bit book3s CPUs. They are.
-Olof
^ permalink raw reply
* Re: [PATCH V4] POWERPC: BOOK3S: KVM: Use the saved dar value and generic make_dsisr
From: Alexander Graf @ 2014-05-05 15:09 UTC (permalink / raw)
To: Olof Johansson
Cc: kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, Paul Mackerras,
Aneesh Kumar K.V, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CALiw-2E222RXHK0drwaygb62hXT8F8KCG_AJ7OGKgNfL+Vj8dg@mail.gmail.com>
> Am 05.05.2014 um 16:57 schrieb Olof Johansson <olofj@google.com>:
>=20
> [Now without HTML email -- it's what you get for cc:ing me at work
> instead of my upstream email :)]
>=20
> 2014-05-05 7:43 GMT-07:00 Alexander Graf <agraf@suse.de>:
>>=20
>>> On 05/05/2014 04:26 PM, Aneesh Kumar K.V wrote:
>>>=20
>>> Alexander Graf <agraf@suse.de> writes:
>>>=20
>>>>> On 05/04/2014 07:21 PM, Aneesh Kumar K.V wrote:
>>>>>=20
>>>>> Although it's optional IBM POWER cpus always had DAR value set on
>>>>> alignment interrupt. So don't try to compute these values.
>>>>>=20
>>>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>>>>> ---
>>>>> Changes from V3:
>>>>> * Use make_dsisr instead of checking feature flag to decide whether to=
use
>>>>> saved dsisr or not
>>> ....
>>>=20
>>>>> ulong kvmppc_alignment_dar(struct kvm_vcpu *vcpu, unsigned int inst)=
>>>>> {
>>>>> +#ifdef CONFIG_PPC_BOOK3S_64
>>>>> + return vcpu->arch.fault_dar;
>>>>=20
>>>> How about PA6T and G5s?
>>> Paul mentioned that BOOK3S always had DAR value set on alignment
>>> interrupt. And the patch is to enable/collect correct DAR value when
>>> running with Little Endian PR guest. Now to limit the impact and to
>>> enable Little Endian PR guest, I ended up doing the conditional code
>>> only for book3s 64 for which we know for sure that we set DAR value.
>>=20
>>=20
>> Yes, and I'm asking whether we know that this statement holds true for PA=
6T and G5 chips which I wouldn't consider IBM POWER. Since the G5 is at leas=
t developed by IBM, I'd assume its semantics here are similar to POWER4, but=
for PA6T I wouldn't be so sure.
>=20
> Thanks for looking out for us, obviously IBM doesn't (based on the
> reply a minute ago).
>=20
> In the end, since there's been no work to enable KVM on PA6T, I'm not
> too worried. I guess it's one more thing to sort out (and check for)
> whenever someone does that.
>=20
> I definitely don't have cycles to deal with that myself at this time.
> I can help find hardware for someone who wants to, but even then I'm
> guessing the interest is pretty limited.
I know of at least 1 person who successfully runs PR KVM on a PA6T, so it's n=
either neglected nor non-working.
If you can get me access to a pa6t system I can easily check whether alignme=
nt interrupts generate dar and dsisr properly :).
Alex
^ permalink raw reply
* Re: [PATCH V4] POWERPC: BOOK3S: KVM: Use the saved dar value and generic make_dsisr
From: Alexander Graf @ 2014-05-05 15:10 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: kvm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
kvm-ppc@vger.kernel.org, paulus@samba.org, olofj@google.com
In-Reply-To: <87fvko9t4d.fsf@linux.vnet.ibm.com>
> Am 05.05.2014 um 16:50 schrieb "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet=
.ibm.com>:
>=20
> Alexander Graf <agraf@suse.de> writes:
>=20
>>> On 05/05/2014 04:26 PM, Aneesh Kumar K.V wrote:
>>> Alexander Graf <agraf@suse.de> writes:
>>>=20
>>>>> On 05/04/2014 07:21 PM, Aneesh Kumar K.V wrote:
>>>>> Although it's optional IBM POWER cpus always had DAR value set on
>>>>> alignment interrupt. So don't try to compute these values.
>>>>>=20
>>>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>>>>> ---
>>>>> Changes from V3:
>>>>> * Use make_dsisr instead of checking feature flag to decide whether to=
use
>>>>> saved dsisr or not
>>> ....
>>>=20
>>>>> ulong kvmppc_alignment_dar(struct kvm_vcpu *vcpu, unsigned int inst)=
>>>>> {
>>>>> +#ifdef CONFIG_PPC_BOOK3S_64
>>>>> + return vcpu->arch.fault_dar;
>>>> How about PA6T and G5s?
>>> Paul mentioned that BOOK3S always had DAR value set on alignment
>>> interrupt. And the patch is to enable/collect correct DAR value when
>>> running with Little Endian PR guest. Now to limit the impact and to
>>> enable Little Endian PR guest, I ended up doing the conditional code
>>> only for book3s 64 for which we know for sure that we set DAR value.
>>=20
>> Yes, and I'm asking whether we know that this statement holds true for=20=
>> PA6T and G5 chips which I wouldn't consider IBM POWER. Since the G5 is=20=
>> at least developed by IBM, I'd assume its semantics here are similar to=20=
>> POWER4, but for PA6T I wouldn't be so sure.
>=20
> I will have to defer to Paul on that question. But that should not
> prevent this patch from going upstream right ?
Regressions are big no-gos.
Alex
>=20
> -aneesh
>=20
^ permalink raw reply
* Re: [PATCH] KVM: PPC: BOOK3S: HV: Don't try to allocate from kernel page allocator for hash page table.
From: Alexander Graf @ 2014-05-05 15:16 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: paulus@samba.org, linuxppc-dev@lists.ozlabs.org,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
In-Reply-To: <87r4489ttk.fsf@linux.vnet.ibm.com>
> Am 05.05.2014 um 16:35 schrieb "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet=
.ibm.com>:
>=20
> Alexander Graf <agraf@suse.de> writes:
>=20
>>> On 05/04/2014 07:25 PM, Aneesh Kumar K.V wrote:
>>> We reserve 5% of total ram for CMA allocation and not using that can
>>> result in us running out of numa node memory with specific
>>> configuration. One caveat is we may not have node local hpt with pinned
>>> vcpu configuration. But currently libvirt also pins the vcpu to cpuset
>>> after creating hash page table.
>>=20
>> I don't understand the problem. Can you please elaborate?
>=20
> Lets take a system with 100GB RAM. We reserve around 5GB for htab
> allocation. Now if we use rest of available memory for hugetlbfs
> (because we want all the guest to be backed by huge pages), we would
> end up in a situation where we have a few GB of free RAM and 5GB of CMA
> reserve area. Now if we allow hash page table allocation to consume the
> free space, we would end up hitting page allocation failure for other
> non movable kernel allocation even though we still have 5GB CMA reserve
> space free.
Isn't this a greater problem? We should start swapping before we hit the poi=
nt where non movable kernel allocation fails, no?
The fact that KVM uses a good number of normal kernel pages is maybe subopti=
mal, but shouldn't be a critical problem.
Alex
>=20
> -aneesh
>=20
^ permalink raw reply
* Re: [PATCH] KVM: PPC: BOOK3S: HV: Don't try to allocate from kernel page allocator for hash page table.
From: Aneesh Kumar K.V @ 2014-05-05 15:40 UTC (permalink / raw)
To: Alexander Graf
Cc: paulus@samba.org, linuxppc-dev@lists.ozlabs.org,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
In-Reply-To: <20FFDF8F-1A3D-4719-B492-1E4B70F9D1B4@suse.de>
Alexander Graf <agraf@suse.de> writes:
>> Am 05.05.2014 um 16:35 schrieb "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>:
>>
>> Alexander Graf <agraf@suse.de> writes:
>>
>>>> On 05/04/2014 07:25 PM, Aneesh Kumar K.V wrote:
>>>> We reserve 5% of total ram for CMA allocation and not using that can
>>>> result in us running out of numa node memory with specific
>>>> configuration. One caveat is we may not have node local hpt with pinned
>>>> vcpu configuration. But currently libvirt also pins the vcpu to cpuset
>>>> after creating hash page table.
>>>
>>> I don't understand the problem. Can you please elaborate?
>>
>> Lets take a system with 100GB RAM. We reserve around 5GB for htab
>> allocation. Now if we use rest of available memory for hugetlbfs
>> (because we want all the guest to be backed by huge pages), we would
>> end up in a situation where we have a few GB of free RAM and 5GB of CMA
>> reserve area. Now if we allow hash page table allocation to consume the
>> free space, we would end up hitting page allocation failure for other
>> non movable kernel allocation even though we still have 5GB CMA reserve
>> space free.
>
> Isn't this a greater problem? We should start swapping before we hit
> the point where non movable kernel allocation fails, no?
But there is nothing much to swap. Because most of the memory is
reserved for guest RAM via hugetlbfs.
>
> The fact that KVM uses a good number of normal kernel pages is maybe
> suboptimal, but shouldn't be a critical problem.
Yes. But then in this case we could do better isn't it ? We already have
a large part of guest RAM kept aside for htab allocation which cannot be
used for non movable allocation. And we ignore that reserve space and
use other areas for hash page table allocation with the current code.
We actually hit this case in one of the test box.
KVM guest htab at c000001e50000000 (order 30), LPID 1
libvirtd invoked oom-killer: gfp_mask=0x2000d0, order=0,oom_score_adj=0
libvirtd cpuset=/ mems_allowed=0,16
CPU: 72 PID: 20044 Comm: libvirtd Not tainted 3.10.23-1401.pkvm2_1.4.ppc64 #1
Call Trace:
[c000001e3b63f150] [c000000000017330] .show_stack+0x130/0x200(unreliable)
[c000001e3b63f220] [c00000000087a888] .dump_stack+0x28/0x3c
[c000001e3b63f290] [c000000000876a4c] .dump_header+0xbc/0x228
[c000001e3b63f360] [c0000000001dd838].oom_kill_process+0x318/0x4c0
[c000001e3b63f440] [c0000000001de258] .out_of_memory+0x518/0x550
[c000001e3b63f520] [c0000000001e5aac].__alloc_pages_nodemask+0xb3c/0xbf0
[c000001e3b63f700] [c000000000243580] .new_slab+0x440/0x490
[c000001e3b63f7a0] [c0000000008781fc] .__slab_alloc+0x17c/0x618
[c000001e3b63f8d0] [c0000000002467fc].kmem_cache_alloc_node_trace+0xcc/0x300
[c000001e3b63f990] [c00000000010f62c].alloc_fair_sched_group+0xfc/0x200
[c000001e3b63fa60] [c000000000104f00].sched_create_group+0x50/0xe0
[c000001e3b63fae0] [c000000000104fc0].cpu_cgroup_css_alloc+0x30/0x80
[c000001e3b63fb60] [c0000000001513ec] .cgroup_mkdir+0x2bc/0x6e0
[c000001e3b63fc50] [c000000000275aec] .vfs_mkdir+0x14c/0x220
[c000001e3b63fcf0] [c00000000027a734] .SyS_mkdirat+0x94/0x110
[c000001e3b63fdb0] [c00000000027a7e4] .SyS_mkdir+0x34/0x50
[c000001e3b63fe30] [c000000000009f54] syscall_exit+0x0/0x98
Node 0 DMA free:23424kB min:23424kB low:29248kB high:35136kB
active_anon:0kB inactive_anon:128kB active_file:256kB inactive_file:384kB
unevictable:9536kB isolated(anon):0kB isolated(file):0kB present:67108864kB
managed:65931776kB mlocked:9536kB dirty:64kB writeback:0kB mapped:5376kB
shmem:0kB slab_reclaimable:23616kB slab_unreclaimable:1237056kB
kernel_stack:18256kB pagetables:1088kB unstable:0kB bounce:0kB free_cma:0kB
writeback_tmp:0kB pages_scanned:78 all_unreclaimable? yes
lowmem_reserve[]: 0 0 0
Node 16 DMA free:5787008kB min:21376kB low:26688kB high:32064kB
active_anon:1984kB inactive_anon:2112kB active_file:896kB inactive_file:64kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:67108864kB
managed:60060032kB mlocked:0kB dirty:128kB writeback:3712kB mapped:0kB
shmem:0kB slab_reclaimable:23424kB slab_unreclaimable:826048kB
kernel_stack:576kB pagetables:1408kB unstable:0kB bounce:0kB free_cma:5767040kB
writeback_tmp:0kB pages_scanned:756 all_unreclaimable? yes
^ permalink raw reply
* [PATCH v3] powerpc/fsl: Added binding for Freescale CoreNet coherency fabric (CCF)
From: Diana Craciun @ 2014-05-05 15:58 UTC (permalink / raw)
To: linuxppc-dev; +Cc: scottwood, devicetree, Diana Craciun
From: Diana Craciun <Diana.Craciun@freescale.com>
The CoreNet coherency fabric is a fabric-oriented, conectivity
infrastructure that enables the implementation of coherent, multicore
systems. The CCF acts as a central interconnect for cores,
platform-level caches, memory subsystem, peripheral devices and I/O host
bridges in the system.
Signed-off-by: Diana Craciun <Diana.Craciun@freescale.com>
---
v3:
- added port ID mapping
- removed fsl,corenetx-cf
.../devicetree/bindings/powerpc/fsl/ccf.txt | 42 ++++++++++++++++++++++
.../devicetree/bindings/powerpc/fsl/cpus.txt | 8 +++++
.../devicetree/bindings/powerpc/fsl/pamu.txt | 8 +++++
3 files changed, 58 insertions(+)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/ccf.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/ccf.txt b/Documentation/devicetree/bindings/powerpc/fsl/ccf.txt
new file mode 100644
index 0000000..1263c29
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/ccf.txt
@@ -0,0 +1,42 @@
+Freescale CoreNet Coherency Fabric(CCF) Device Tree Binding
+
+DESCRIPTION
+
+The CoreNet coherency fabric is a fabric-oriented, connectivity infrastructure
+that enables the implementation of coherent, multicore systems.
+
+Required properties:
+
+- compatible : <string>
+ fsl,corenet1-cf - CoreNet coherency fabric version 1. Example chips: T4240,
+ B4860
+ fsl,corenet2-cf - CoreNet coherency fabric version 2. Example chips: P5020,
+ P4080, P3041, P2041
+ fsl,corenet-cf - It is used to represent the common registers between
+ CCF version 1 and CCF version 2. This compatible is retained for
+ compatibility reasons as it was already used for both CCF version 1 chips
+ and CCF version 2 chips.
+
+- reg : <prop-encoded-array>
+ A standard property. Represents the CCF registers.
+
+- interrupts : <prop-encoded-array>
+ Interrupt mapping for CCF error interrupt.
+
+- fsl,ccf-num-csdids: <u32>
+ Specifies the number of Coherency Subdomain ID Port Mapping
+ Registers that are supported by the CCF.
+
+- fsl,ccf-num-snoopids: <u32>
+ Specifies the number of Snoop ID Port Mapping Registers that
+ are supported by CCF.
+
+Example:
+
+ corenet-cf@18000 {
+ compatible = "fsl,corenet2-cf", "fsl,corenet-cf";
+ reg = <0x18000 0x1000>;
+ interrupts = <16 2 1 31>;
+ fsl,ccf-num-csdids = <32>;
+ fsl,ccf-num-snoopids = <32>;
+ };
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt b/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt
index 922c30a..09dbc5f 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt
@@ -20,3 +20,11 @@ PROPERTIES
a property named fsl,eref-[CAT], where [CAT] is the abbreviated category
name with all uppercase letters converted to lowercase, indicates that
the category is supported by the implementation.
+
+ - fsl,portid-mapping : <u32>
+ The Coherency Subdomain ID Port Mapping Registers and Snoop ID Port Mapping
+ registers which are part of the CoreNet Coherency fabric (CCF) provide a
+ CoreNet Coherency Subdomain ID/CoreNet Snoop ID to cpu mapping functions.
+ Certain bits from these registers should be set if the coresponding CPU
+ should be snooped. This property defines a bitmask which selects the bit that
+ should be set if this cpu should be snooped.
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt b/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt
index 1f5e329..827c637 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt
@@ -26,6 +26,13 @@ Required properties:
A standard property.
- #size-cells : <u32>
A standard property.
+- fsl,portid-mapping : <u32>
+ The Coherency Subdomain ID Port Mapping Registers and Snoop ID Port Mapping
+ registers which are part of the CoreNet Coherency fabric (CCF) provide a
+ CoreNet Coherency Subdomain ID/CoreNet Snoop ID to pamu mapping functions.
+ Certain bits from these registers should be set if PAMUs should be snooped.
+ This property defines a bitmask which selects the bits that should be set
+ if PAMUs should be snooped.
Optional properties:
- reg : <prop-encoded-array>
@@ -88,6 +95,7 @@ Example:
compatible = "fsl,pamu-v1.0", "fsl,pamu";
reg = <0x20000 0x5000>;
ranges = <0 0x20000 0x5000>;
+ fsl,portid-mapping = <0xf80000>;
#address-cells = <1>;
#size-cells = <1>;
interrupts = <
--
1.7.11.7
^ permalink raw reply related
* [PATCH v2] powerpc/fsl: Updated device trees for platforms with corenet version 2
From: Diana Craciun @ 2014-05-05 16:04 UTC (permalink / raw)
To: linuxppc-dev; +Cc: scottwood, Diana Craciun
From: Diana Craciun <Diana.Craciun@freescale.com>
Updated the device trees according to the corenet-cf
binding definition.
Signed-off-by: Diana Craciun <Diana.Craciun@freescale.com>
---
arch/powerpc/boot/dts/b4860emu.dts | 7 ++++++-
arch/powerpc/boot/dts/fsl/b4420si-post.dtsi | 4 ----
arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi | 2 ++
arch/powerpc/boot/dts/fsl/b4860si-post.dtsi | 4 ----
arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi | 4 ++++
arch/powerpc/boot/dts/fsl/b4si-post.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 3 ++-
arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi | 12 ++++++++++++
arch/powerpc/boot/dts/t4240emu.dts | 15 ++++++++++++++-
9 files changed, 42 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/boot/dts/b4860emu.dts b/arch/powerpc/boot/dts/b4860emu.dts
index 7290021..85646b4 100644
--- a/arch/powerpc/boot/dts/b4860emu.dts
+++ b/arch/powerpc/boot/dts/b4860emu.dts
@@ -61,21 +61,25 @@
device_type = "cpu";
reg = <0 1>;
next-level-cache = <&L2>;
+ fsl,portid-mapping = <0x80000000>;
};
cpu1: PowerPC,e6500@2 {
device_type = "cpu";
reg = <2 3>;
next-level-cache = <&L2>;
+ fsl,portid-mapping = <0x80000000>;
};
cpu2: PowerPC,e6500@4 {
device_type = "cpu";
reg = <4 5>;
next-level-cache = <&L2>;
+ fsl,portid-mapping = <0x80000000>;
};
cpu3: PowerPC,e6500@6 {
device_type = "cpu";
reg = <6 7>;
next-level-cache = <&L2>;
+ fsl,portid-mapping = <0x80000000>;
};
};
};
@@ -157,7 +161,7 @@
};
corenet-cf@18000 {
- compatible = "fsl,b4-corenet-cf";
+ compatible = "fsl,corenet2-cf", "fsl,corenet-cf";
reg = <0x18000 0x1000>;
interrupts = <16 2 1 0>;
fsl,ccf-num-csdids = <32>;
@@ -167,6 +171,7 @@
iommu@20000 {
compatible = "fsl,pamu-v1.0", "fsl,pamu";
reg = <0x20000 0x4000>;
+ fsl,portid-mapping = <0x8000>;
#address-cells = <1>;
#size-cells = <1>;
interrupts = <
diff --git a/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi b/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
index 60566f99..d678944 100644
--- a/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
@@ -76,10 +76,6 @@
compatible = "fsl,b4420-l3-cache-controller", "cache";
};
- corenet-cf@18000 {
- compatible = "fsl,b4420-corenet-cf";
- };
-
guts: global-utilities@e0000 {
compatible = "fsl,b4420-device-config", "fsl,qoriq-device-config-2.0";
};
diff --git a/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi b/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
index 2419731..338af7e 100644
--- a/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
@@ -66,12 +66,14 @@
reg = <0 1>;
clocks = <&mux0>;
next-level-cache = <&L2>;
+ fsl,portid-mapping = <0x80000000>;
};
cpu1: PowerPC,e6500@2 {
device_type = "cpu";
reg = <2 3>;
clocks = <&mux0>;
next-level-cache = <&L2>;
+ fsl,portid-mapping = <0x80000000>;
};
};
};
diff --git a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
index cbc354b..582381d 100644
--- a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
@@ -120,10 +120,6 @@
compatible = "fsl,b4860-l3-cache-controller", "cache";
};
- corenet-cf@18000 {
- compatible = "fsl,b4860-corenet-cf";
- };
-
guts: global-utilities@e0000 {
compatible = "fsl,b4860-device-config", "fsl,qoriq-device-config-2.0";
};
diff --git a/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi b/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
index 142ac86..1948f73 100644
--- a/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
@@ -66,24 +66,28 @@
reg = <0 1>;
clocks = <&mux0>;
next-level-cache = <&L2>;
+ fsl,portid-mapping = <0x80000000>;
};
cpu1: PowerPC,e6500@2 {
device_type = "cpu";
reg = <2 3>;
clocks = <&mux0>;
next-level-cache = <&L2>;
+ fsl,portid-mapping = <0x80000000>;
};
cpu2: PowerPC,e6500@4 {
device_type = "cpu";
reg = <4 5>;
clocks = <&mux0>;
next-level-cache = <&L2>;
+ fsl,portid-mapping = <0x80000000>;
};
cpu3: PowerPC,e6500@6 {
device_type = "cpu";
reg = <6 7>;
clocks = <&mux0>;
next-level-cache = <&L2>;
+ fsl,portid-mapping = <0x80000000>;
};
};
};
diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
index 4f6e482..1a54ba7 100644
--- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
@@ -158,7 +158,7 @@
};
corenet-cf@18000 {
- compatible = "fsl,b4-corenet-cf";
+ compatible = "fsl,corenet2-cf", "fsl,corenet-cf";
reg = <0x18000 0x1000>;
interrupts = <16 2 1 0>;
fsl,ccf-num-csdids = <32>;
@@ -168,6 +168,7 @@
iommu@20000 {
compatible = "fsl,pamu-v1.0", "fsl,pamu";
reg = <0x20000 0x4000>;
+ fsl,portid-mapping = <0x8000>;
#address-cells = <1>;
#size-cells = <1>;
interrupts = <
diff --git a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
index f99d74f..793669b 100644
--- a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
@@ -343,7 +343,7 @@
};
corenet-cf@18000 {
- compatible = "fsl,corenet-cf";
+ compatible = "fsl,corenet2-cf", "fsl,corenet-cf";
reg = <0x18000 0x1000>;
interrupts = <16 2 1 31>;
fsl,ccf-num-csdids = <32>;
@@ -353,6 +353,7 @@
iommu@20000 {
compatible = "fsl,pamu-v1.0", "fsl,pamu";
reg = <0x20000 0x6000>;
+ fsl,portid-mapping = <0x8000>;
interrupts = <
24 2 0 0
16 2 1 30>;
diff --git a/arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi b/arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi
index 0b8ccc5..d2f157e 100644
--- a/arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi
@@ -69,72 +69,84 @@
reg = <0 1>;
clocks = <&mux0>;
next-level-cache = <&L2_1>;
+ fsl,portid-mapping = <0x80000000>;
};
cpu1: PowerPC,e6500@2 {
device_type = "cpu";
reg = <2 3>;
clocks = <&mux0>;
next-level-cache = <&L2_1>;
+ fsl,portid-mapping = <0x80000000>;
};
cpu2: PowerPC,e6500@4 {
device_type = "cpu";
reg = <4 5>;
clocks = <&mux0>;
next-level-cache = <&L2_1>;
+ fsl,portid-mapping = <0x80000000>;
};
cpu3: PowerPC,e6500@6 {
device_type = "cpu";
reg = <6 7>;
clocks = <&mux0>;
next-level-cache = <&L2_1>;
+ fsl,portid-mapping = <0x80000000>;
};
cpu4: PowerPC,e6500@8 {
device_type = "cpu";
reg = <8 9>;
clocks = <&mux1>;
next-level-cache = <&L2_2>;
+ fsl,portid-mapping = <0x40000000>;
};
cpu5: PowerPC,e6500@10 {
device_type = "cpu";
reg = <10 11>;
clocks = <&mux1>;
next-level-cache = <&L2_2>;
+ fsl,portid-mapping = <0x40000000>;
};
cpu6: PowerPC,e6500@12 {
device_type = "cpu";
reg = <12 13>;
clocks = <&mux1>;
next-level-cache = <&L2_2>;
+ fsl,portid-mapping = <0x40000000>;
};
cpu7: PowerPC,e6500@14 {
device_type = "cpu";
reg = <14 15>;
clocks = <&mux1>;
next-level-cache = <&L2_2>;
+ fsl,portid-mapping = <0x40000000>;
};
cpu8: PowerPC,e6500@16 {
device_type = "cpu";
reg = <16 17>;
clocks = <&mux2>;
next-level-cache = <&L2_3>;
+ fsl,portid-mapping = <0x20000000>;
};
cpu9: PowerPC,e6500@18 {
device_type = "cpu";
reg = <18 19>;
clocks = <&mux2>;
next-level-cache = <&L2_3>;
+ fsl,portid-mapping = <0x20000000>;
};
cpu10: PowerPC,e6500@20 {
device_type = "cpu";
reg = <20 21>;
clocks = <&mux2>;
next-level-cache = <&L2_3>;
+ fsl,portid-mapping = <0x20000000>;
};
cpu11: PowerPC,e6500@22 {
device_type = "cpu";
reg = <22 23>;
clocks = <&mux2>;
next-level-cache = <&L2_3>;
+ fsl,portid-mapping = <0x20000000>;
};
};
};
diff --git a/arch/powerpc/boot/dts/t4240emu.dts b/arch/powerpc/boot/dts/t4240emu.dts
index ee24ab3..bc12127a 100644
--- a/arch/powerpc/boot/dts/t4240emu.dts
+++ b/arch/powerpc/boot/dts/t4240emu.dts
@@ -60,63 +60,75 @@
device_type = "cpu";
reg = <0 1>;
next-level-cache = <&L2_1>;
+ fsl,portid-mapping = <0x80000000>;
};
cpu1: PowerPC,e6500@2 {
device_type = "cpu";
reg = <2 3>;
next-level-cache = <&L2_1>;
+ fsl,portid-mapping = <0x80000000>;
};
cpu2: PowerPC,e6500@4 {
device_type = "cpu";
reg = <4 5>;
next-level-cache = <&L2_1>;
+ fsl,portid-mapping = <0x80000000>;
};
cpu3: PowerPC,e6500@6 {
device_type = "cpu";
reg = <6 7>;
next-level-cache = <&L2_1>;
+ fsl,portid-mapping = <0x80000000>;
};
cpu4: PowerPC,e6500@8 {
device_type = "cpu";
reg = <8 9>;
next-level-cache = <&L2_2>;
+ fsl,portid-mapping = <0x40000000>;
};
cpu5: PowerPC,e6500@10 {
device_type = "cpu";
reg = <10 11>;
next-level-cache = <&L2_2>;
+ fsl,portid-mapping = <0x40000000>;
};
cpu6: PowerPC,e6500@12 {
device_type = "cpu";
reg = <12 13>;
next-level-cache = <&L2_2>;
+ fsl,portid-mapping = <0x40000000>;
};
cpu7: PowerPC,e6500@14 {
device_type = "cpu";
reg = <14 15>;
next-level-cache = <&L2_2>;
+ fsl,portid-mapping = <0x40000000>;
};
cpu8: PowerPC,e6500@16 {
device_type = "cpu";
reg = <16 17>;
next-level-cache = <&L2_3>;
+ fsl,portid-mapping = <0x20000000>;
};
cpu9: PowerPC,e6500@18 {
device_type = "cpu";
reg = <18 19>;
next-level-cache = <&L2_3>;
+ fsl,portid-mapping = <0x20000000>;
};
cpu10: PowerPC,e6500@20 {
device_type = "cpu";
reg = <20 21>;
next-level-cache = <&L2_3>;
+ fsl,portid-mapping = <0x20000000>;
};
cpu11: PowerPC,e6500@22 {
device_type = "cpu";
reg = <22 23>;
next-level-cache = <&L2_3>;
+ fsl,portid-mapping = <0x20000000>;
};
};
};
@@ -213,7 +225,7 @@
};
corenet-cf@18000 {
- compatible = "fsl,corenet-cf";
+ compatible = "fsl,corenet2-cf", "fsl,corenet-cf";
reg = <0x18000 0x1000>;
interrupts = <16 2 1 31>;
fsl,ccf-num-csdids = <32>;
@@ -223,6 +235,7 @@
iommu@20000 {
compatible = "fsl,pamu-v1.0", "fsl,pamu";
reg = <0x20000 0x6000>;
+ fsl,portid-mapping = <0x8000>;
interrupts = <
24 2 0 0
16 2 1 30>;
--
1.7.11.7
^ permalink raw reply related
* RE: [PATCH] powerpc: Fix comment around arch specific definition of RECLAIM_DISTANCE
From: Motohiro Kosaki @ 2014-05-05 16:29 UTC (permalink / raw)
To: Preeti U Murthy, linuxppc-dev@lists.ozlabs.org
Cc: anton@samba.org, Motohiro Kosaki JP
In-Reply-To: <20140505051713.7744.47492.stgit@preeti>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBQcmVldGkgVSBNdXJ0aHkgW21h
aWx0bzpwcmVldGlAbGludXgudm5ldC5pYm0uY29tXQ0KPiBTZW50OiBNb25kYXksIE1heSAwNSwg
MjAxNCAxOjE3IEFNDQo+IFRvOiBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZw0KPiBDYzog
YmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnOyBhbnRvbkBzYW1iYS5vcmc7IE1vdG9oaXJvIEtvc2Fr
aSBKUA0KPiBTdWJqZWN0OiBbUEFUQ0hdIHBvd2VycGM6IEZpeCBjb21tZW50IGFyb3VuZCBhcmNo
IHNwZWNpZmljIGRlZmluaXRpb24gb2YgUkVDTEFJTV9ESVNUQU5DRQ0KPiANCj4gQ29tbWl0IDMy
ZTQ1ZmY0M2VhZjVjMTdmIGNoYW5nZWQgdGhlIGRlZmF1bHQgdmFsdWUgb2YgUkVDTEFJTV9ESVNU
QU5DRSB0byAzMC4gSG93ZXZlciB0aGUgY29tbWVudCBhcm91bmQgYXJjaCBzcGVjaWZjDQo+IGRl
ZmluaXRpb24gb2YgUkVDTEFJTV9ESVNUQU5DRSBpcyBub3QgdXBkYXRlZCB0byByZWZsZWN0IHRo
ZSBzYW1lLiBDb3JyZWN0IHRoZSB2YWx1ZSBtZW50aW9uZWQgaW4gdGhlIGNvbW1lbnQuDQo+IA0K
PiBTaWduZWQtb2ZmLWJ5OiBQcmVldGkgVSBNdXJ0aHkgPHByZWV0aUBsaW51eC52bmV0LmlibS5j
b20+DQo+IENjOiBBbnRvbiBCbGFuY2hhcmQgPGFudG9uQHNhbWJhLm9yZz4NCj4gQ2M6IEJlbmph
bWluIEhlcnJlbnNjaG1pZHQgPGJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZz4NCj4gQ2M6IEtPU0FL
SSBNb3RvaGlybyA8a29zYWtpLm1vdG9oaXJvQGpwLmZ1aml0c3UuY29tPg0KDQpBY2tlZC1ieTog
S09TQUtJIE1vdG9oaXJvIDxLb3Nha2kubW90b2hpcm9AanAuZnVqaXRzdS5jb20+DQoNCg==
^ permalink raw reply
* [PATCH v2] powerpc/mpc85xx: Remove P1023 RDS support
From: Lijun Pan @ 2014-05-05 18:23 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Lijun Pan, Emilian.Medve
P1023RDS is no longer supported/manufactured by Freescale while P1023RDB is.
Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com>
---
arch/powerpc/boot/dts/p1023rds.dts | 219 ---------------------
arch/powerpc/configs/mpc85xx_defconfig | 1 -
arch/powerpc/configs/mpc85xx_smp_defconfig | 1 -
arch/powerpc/platforms/85xx/Kconfig | 6 +-
arch/powerpc/platforms/85xx/Makefile | 2 +-
.../platforms/85xx/{p1023_rds.c => p1023_rdb.c} | 36 +---
6 files changed, 10 insertions(+), 255 deletions(-)
delete mode 100644 arch/powerpc/boot/dts/p1023rds.dts
rename arch/powerpc/platforms/85xx/{p1023_rds.c => p1023_rdb.c} (75%)
diff --git a/arch/powerpc/boot/dts/p1023rds.dts b/arch/powerpc/boot/dts/p1023rds.dts
deleted file mode 100644
index beb6cb1..0000000
--- a/arch/powerpc/boot/dts/p1023rds.dts
+++ /dev/null
@@ -1,219 +0,0 @@
-/*
- * P1023 RDS Device Tree Source
- *
- * Copyright 2010-2011 Freescale Semiconductor Inc.
- *
- * Author: Roy Zang <tie-fei.zang@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,P1023RDS";
- #address-cells = <2>;
- #size-cells = <2>;
- interrupt-parent = <&mpic>;
-
- memory {
- device_type = "memory";
- };
-
- soc: soc@ff600000 {
- ranges = <0x0 0x0 0xff600000 0x200000>;
-
- i2c@3000 {
- rtc@68 {
- compatible = "dallas,ds1374";
- reg = <0x68>;
- };
- };
-
- spi@7000 {
- fsl_dataflash@0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "atmel,at45db081d";
- reg = <0>;
- spi-max-frequency = <40000000>; /* input clock */
- partition@u-boot {
- /* 512KB for u-boot Bootloader Image */
- label = "u-boot-spi";
- reg = <0x00000000 0x00080000>;
- read-only;
- };
- partition@dtb {
- /* 512KB for DTB Image */
- label = "dtb-spi";
- reg = <0x00080000 0x00080000>;
- read-only;
- };
- };
- };
-
- usb@22000 {
- dr_mode = "host";
- phy_type = "ulpi";
- };
- };
-
- lbc: localbus@ff605000 {
- reg = <0 0xff605000 0 0x1000>;
-
- /* NOR Flash, BCSR */
- ranges = <0x0 0x0 0x0 0xee000000 0x02000000
- 0x1 0x0 0x0 0xe0000000 0x00008000>;
-
- nor@0,0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "cfi-flash";
- reg = <0x0 0x0 0x02000000>;
- bank-width = <2>;
- device-width = <1>;
- partition@0 {
- label = "ramdisk";
- reg = <0x00000000 0x01c00000>;
- };
- partition@1c00000 {
- label = "kernel";
- reg = <0x01c00000 0x002e0000>;
- };
- partiton@1ee0000 {
- label = "dtb";
- reg = <0x01ee0000 0x00020000>;
- };
- partition@1f00000 {
- label = "firmware";
- reg = <0x01f00000 0x00080000>;
- read-only;
- };
- partition@1f80000 {
- label = "u-boot";
- reg = <0x01f80000 0x00080000>;
- read-only;
- };
- };
-
- fpga@1,0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "fsl,p1023rds-fpga";
- reg = <1 0 0x8000>;
- ranges = <0 1 0 0x8000>;
-
- bcsr@20 {
- compatible = "fsl,p1023rds-bcsr";
- reg = <0x20 0x20>;
- };
- };
- };
-
- pci0: pcie@ff60a000 {
- reg = <0 0xff60a000 0 0x1000>;
- ranges = <0x2000000 0x0 0xc0000000 0 0xc0000000 0x0 0x20000000
- 0x1000000 0x0 0x00000000 0 0xffc20000 0x0 0x10000>;
- pcie@0 {
- /* IRQ[0:3] are pulled up on board, set to active-low */
- interrupt-map-mask = <0xf800 0 0 7>;
- interrupt-map = <
- /* IDSEL 0x0 */
- 0000 0 0 1 &mpic 0 1 0 0
- 0000 0 0 2 &mpic 1 1 0 0
- 0000 0 0 3 &mpic 2 1 0 0
- 0000 0 0 4 &mpic 3 1 0 0
- >;
- ranges = <0x2000000 0x0 0xc0000000
- 0x2000000 0x0 0xc0000000
- 0x0 0x20000000
-
- 0x1000000 0x0 0x0
- 0x1000000 0x0 0x0
- 0x0 0x100000>;
- };
- };
-
- board_pci1: pci1: pcie@ff609000 {
- reg = <0 0xff609000 0 0x1000>;
- ranges = <0x2000000 0x0 0xa0000000 0 0xa0000000 0x0 0x20000000
- 0x1000000 0x0 0x00000000 0 0xffc10000 0x0 0x10000>;
- pcie@0 {
- /*
- * IRQ[4:6] only for PCIe, set to active-high,
- * IRQ[7] is pulled up on board, set to active-low
- */
- interrupt-map-mask = <0xf800 0 0 7>;
- interrupt-map = <
- /* IDSEL 0x0 */
- 0000 0 0 1 &mpic 4 2 0 0
- 0000 0 0 2 &mpic 5 2 0 0
- 0000 0 0 3 &mpic 6 2 0 0
- 0000 0 0 4 &mpic 7 1 0 0
- >;
- ranges = <0x2000000 0x0 0xa0000000
- 0x2000000 0x0 0xa0000000
- 0x0 0x20000000
-
- 0x1000000 0x0 0x0
- 0x1000000 0x0 0x0
- 0x0 0x100000>;
- };
- };
-
- pci2: pcie@ff60b000 {
- reg = <0 0xff60b000 0 0x1000>;
- ranges = <0x2000000 0x0 0x80000000 0 0x80000000 0x0 0x20000000
- 0x1000000 0x0 0x00000000 0 0xffc00000 0x0 0x10000>;
- pcie@0 {
- /*
- * IRQ[8:10] are pulled up on board, set to active-low
- * IRQ[11] only for PCIe, set to active-high,
- */
- interrupt-map-mask = <0xf800 0 0 7>;
- interrupt-map = <
- /* IDSEL 0x0 */
- 0000 0 0 1 &mpic 8 1 0 0
- 0000 0 0 2 &mpic 9 1 0 0
- 0000 0 0 3 &mpic 10 1 0 0
- 0000 0 0 4 &mpic 11 2 0 0
- >;
- ranges = <0x2000000 0x0 0x80000000
- 0x2000000 0x0 0x80000000
- 0x0 0x20000000
-
- 0x1000000 0x0 0x0
- 0x1000000 0x0 0x0
- 0x0 0x100000>;
- };
- };
-};
-
-/include/ "fsl/p1023si-post.dtsi"
diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig
index 19f0fbe..55765c8 100644
--- a/arch/powerpc/configs/mpc85xx_defconfig
+++ b/arch/powerpc/configs/mpc85xx_defconfig
@@ -32,7 +32,6 @@ CONFIG_P1010_RDB=y
CONFIG_P1022_DS=y
CONFIG_P1022_RDK=y
CONFIG_P1023_RDB=y
-CONFIG_P1023_RDS=y
CONFIG_SOCRATES=y
CONFIG_KSI8560=y
CONFIG_XES_MPC85xx=y
diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig
index 062312e..5c6ecdc 100644
--- a/arch/powerpc/configs/mpc85xx_smp_defconfig
+++ b/arch/powerpc/configs/mpc85xx_smp_defconfig
@@ -35,7 +35,6 @@ CONFIG_P1010_RDB=y
CONFIG_P1022_DS=y
CONFIG_P1022_RDK=y
CONFIG_P1023_RDB=y
-CONFIG_P1023_RDS=y
CONFIG_SOCRATES=y
CONFIG_KSI8560=y
CONFIG_XES_MPC85xx=y
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index c17aae8..f049c2a 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -117,11 +117,11 @@ config P1022_RDK
This option enables support for the Freescale / iVeia P1022RDK
reference board.
-config P1023_RDS
- bool "Freescale P1023 RDS/RDB"
+config P1023_RDB
+ bool "Freescale P1023 RDB"
select DEFAULT_UIMAGE
help
- This option enables support for the P1023 RDS and RDB boards
+ This option enables support for the P1023 RDB board.
config TWR_P102x
bool "Freescale TWR-P102x"
diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
index 25cebe7..822103e 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -17,7 +17,7 @@ obj-$(CONFIG_MPC85xx_RDB) += mpc85xx_rdb.o
obj-$(CONFIG_P1010_RDB) += p1010rdb.o
obj-$(CONFIG_P1022_DS) += p1022_ds.o
obj-$(CONFIG_P1022_RDK) += p1022_rdk.o
-obj-$(CONFIG_P1023_RDS) += p1023_rds.o
+obj-$(CONFIG_P1023_RDB) += p1023_rdb.o
obj-$(CONFIG_TWR_P102x) += twr_p102x.o
obj-$(CONFIG_CORENET_GENERIC) += corenet_generic.o
obj-$(CONFIG_STX_GP3) += stx_gp3.o
diff --git a/arch/powerpc/platforms/85xx/p1023_rds.c b/arch/powerpc/platforms/85xx/p1023_rdb.c
similarity index 75%
rename from arch/powerpc/platforms/85xx/p1023_rds.c
rename to arch/powerpc/platforms/85xx/p1023_rdb.c
index 0e61400..d5b7509 100644
--- a/arch/powerpc/platforms/85xx/p1023_rds.c
+++ b/arch/powerpc/platforms/85xx/p1023_rdb.c
@@ -4,7 +4,7 @@
* Author: Roy Zang <tie-fei.zang@freescale.com>
*
* Description:
- * P1023 RDS Board Setup
+ * P1023 RDB Board Setup
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -41,12 +41,12 @@
* Setup the architecture
*
*/
-static void __init mpc85xx_rds_setup_arch(void)
+static void __init mpc85xx_rdb_setup_arch(void)
{
struct device_node *np;
if (ppc_md.progress)
- ppc_md.progress("p1023_rds_setup_arch()", 0);
+ ppc_md.progress("p1023_rdb_setup_arch()", 0);
/* Map BCSR area */
np = of_find_node_by_name(NULL, "bcsr");
@@ -85,10 +85,9 @@ static void __init mpc85xx_rds_setup_arch(void)
fsl_pci_assign_primary();
}
-machine_arch_initcall(p1023_rds, mpc85xx_common_publish_devices);
machine_arch_initcall(p1023_rdb, mpc85xx_common_publish_devices);
-static void __init mpc85xx_rds_pic_init(void)
+static void __init mpc85xx_rdb_pic_init(void)
{
struct mpic *mpic = mpic_alloc(NULL, 0, MPIC_BIG_ENDIAN |
MPIC_SINGLE_DEST_CPU,
@@ -99,14 +98,6 @@ static void __init mpc85xx_rds_pic_init(void)
mpic_init(mpic);
}
-static int __init p1023_rds_probe(void)
-{
- unsigned long root = of_get_flat_dt_root();
-
- return of_flat_dt_is_compatible(root, "fsl,P1023RDS");
-
-}
-
static int __init p1023_rdb_probe(void)
{
unsigned long root = of_get_flat_dt_root();
@@ -115,26 +106,11 @@ static int __init p1023_rdb_probe(void)
}
-define_machine(p1023_rds) {
- .name = "P1023 RDS",
- .probe = p1023_rds_probe,
- .setup_arch = mpc85xx_rds_setup_arch,
- .init_IRQ = mpc85xx_rds_pic_init,
- .get_irq = mpic_get_irq,
- .restart = fsl_rstcr_restart,
- .calibrate_decr = generic_calibrate_decr,
- .progress = udbg_progress,
-#ifdef CONFIG_PCI
- .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
- .pcibios_fixup_phb = fsl_pcibios_fixup_phb,
-#endif
-};
-
define_machine(p1023_rdb) {
.name = "P1023 RDB",
.probe = p1023_rdb_probe,
- .setup_arch = mpc85xx_rds_setup_arch,
- .init_IRQ = mpc85xx_rds_pic_init,
+ .setup_arch = mpc85xx_rdb_setup_arch,
+ .init_IRQ = mpc85xx_rdb_pic_init,
.get_irq = mpic_get_irq,
.restart = fsl_rstcr_restart,
.calibrate_decr = generic_calibrate_decr,
--
1.9.0
^ permalink raw reply related
* Re: [PATCH v2] powerpc/mpc85xx: Remove P1023 RDS support
From: Scott Wood @ 2014-05-05 19:04 UTC (permalink / raw)
To: Lijun Pan; +Cc: linuxppc-dev, Emilian.Medve
In-Reply-To: <1399314195-28616-1-git-send-email-Lijun.Pan@freescale.com>
On Mon, 2014-05-05 at 13:23 -0500, Lijun Pan wrote:
> P1023RDS is no longer supported/manufactured by Freescale while P1023RDB is.
>
> Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com>
> ---
> arch/powerpc/boot/dts/p1023rds.dts | 219 ---------------------
> arch/powerpc/configs/mpc85xx_defconfig | 1 -
> arch/powerpc/configs/mpc85xx_smp_defconfig | 1 -
> arch/powerpc/platforms/85xx/Kconfig | 6 +-
> arch/powerpc/platforms/85xx/Makefile | 2 +-
> .../platforms/85xx/{p1023_rds.c => p1023_rdb.c} | 36 +---
> 6 files changed, 10 insertions(+), 255 deletions(-)
> delete mode 100644 arch/powerpc/boot/dts/p1023rds.dts
> rename arch/powerpc/platforms/85xx/{p1023_rds.c => p1023_rdb.c} (75%)
What changed from v1?
If you want this patch merged, please respond to the comments on v1.
-Scott
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox