* Re: [PATCH v2] cpuidle/pseries: Fixup CEDE0 latency only for POWER10 onwards
From: Gautham R Shenoy @ 2021-04-29 11:10 UTC (permalink / raw)
To: Michael Ellerman
Cc: Gautham R. Shenoy, Michal Suchanek, linux-pm, Aneesh Kumar K.V,
Daniel Lezcano, Rafael J. Wysocki, joedecke,
Vaidyanathan Srinivasan, linuxppc-dev
In-Reply-To: <87r1it9zxy.fsf@mpe.ellerman.id.au>
Hello Michael,
On Thu, Apr 29, 2021 at 07:56:25PM +1000, Michael Ellerman wrote:
> "Gautham R. Shenoy" <ego@linux.vnet.ibm.com> writes:
> > From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
> >
> > Commit d947fb4c965c ("cpuidle: pseries: Fixup exit latency for
> > CEDE(0)") sets the exit latency of CEDE(0) based on the latency values
> > of the Extended CEDE states advertised by the platform
> >
> > On POWER9 LPARs, the firmwares advertise a very low value of 2us for
> > CEDE1 exit latency on a Dedicated LPAR. The latency advertized by the
> > PHYP hypervisor corresponds to the latency required to wakeup from the
> > underlying hardware idle state. However the wakeup latency from the
> > LPAR perspective should include
> >
> > 1. The time taken to transition the CPU from the Hypervisor into the
> > LPAR post wakeup from platform idle state
> >
> > 2. Time taken to send the IPI from the source CPU (waker) to the idle
> > target CPU (wakee).
> >
> > 1. can be measured via timer idle test, where we queue a timer, say
> > for 1ms, and enter the CEDE state. When the timer fires, in the timer
> > handler we compute how much extra timer over the expected 1ms have we
> > consumed. On a a POWER9 LPAR the numbers are
> >
> > CEDE latency measured using a timer (numbers in ns)
> > N Min Median Avg 90%ile 99%ile Max Stddev
> > 400 2601 5677 5668.74 5917 6413 9299 455.01
> >
> > 1. and 2. combined can be determined by an IPI latency test where we
> > send an IPI to an idle CPU and in the handler compute the time
> > difference between when the IPI was sent and when the handler ran. We
> > see the following numbers on POWER9 LPAR.
> >
> > CEDE latency measured using an IPI (numbers in ns)
> > N Min Median Avg 90%ile 99%ile Max Stddev
> > 400 711 7564 7369.43 8559 9514 9698 1200.01
> >
> > Suppose, we consider the 99th percentile latency value measured using
> > the IPI to be the wakeup latency, the value would be 9.5us This is in
> > the ballpark of the default value of 10us.
> >
> > Hence, use the exit latency of CEDE(0) based on the latency values
> > advertized by platform only from POWER10 onwards. The values
> ^^^^^^^
> > advertized on POWER10 platforms is more realistic and informed by the
> > latency measurements. For earlier platforms stick to the default value
> > of 10us.
>
> ...
>
> > diff --git a/drivers/cpuidle/cpuidle-pseries.c b/drivers/cpuidle/cpuidle-pseries.c
> > index a2b5c6f..7207467 100644
> > --- a/drivers/cpuidle/cpuidle-pseries.c
> > +++ b/drivers/cpuidle/cpuidle-pseries.c
> > @@ -419,7 +419,8 @@ static int pseries_idle_probe(void)
> > cpuidle_state_table = shared_states;
> > max_idle_state = ARRAY_SIZE(shared_states);
> > } else {
> > - fixup_cede0_latency();
> > + if (pvr_version_is(PVR_POWER10))
> > + fixup_cede0_latency();
>
> A PVR check like that tests for *only* Power10, not Power10 and onwards
> as you say in the change log.
Right. The accurate thing would be to check not do the fix up for
!(PVR_POWER4 || PVR_POWER4p || POWER_POWER5 || PVR_POWER5p || PVR_POWER6 || PVR_POWER7
|| PVR_POWER8 || PVR_POWER9)
But that was a bit mouthful. I will go with your suggestion (from
private correspondence)
if (cpu_has_feature(CPU_FTR_ARCH_31) || pvr_version_is(PVR_POWER10))
fixup_cede0_latency();
since it will allow the fixup for Processors suporting ISA 3.1
(POWER10 and above) and also on POWER10 CPUs running in compat mode.
>
> The other question is what should happen on a Power10 LPAR that's
> running in Power9 compat mode. I assume in that case we *do* want to use
> the firmware provided values, because they're tied to the underlying
> CPU, not the compat mode?
>
Yes, the firmware provided values are tied to the underlying CPU. Not
the compat mode.
> In which case a check for !PVR_POWER9 would seem to achieve what we
> want?
>
> cheers
--
Thanks and Regards
gautham.
^ permalink raw reply
* Re: [PATCH v3] pseries/drmem: update LMBs after LPM
From: Laurent Dufour @ 2021-04-29 11:31 UTC (permalink / raw)
To: Aneesh Kumar K.V, mpe, benh, paulus
Cc: nathanl, Tyrel Datwyler, linuxppc-dev, linux-kernel
In-Reply-To: <87fsz95qso.fsf@linux.ibm.com>
Le 29/04/2021 à 12:27, Aneesh Kumar K.V a écrit :
> Laurent Dufour <ldufour@linux.ibm.com> writes:
>
>> After a LPM, the device tree node ibm,dynamic-reconfiguration-memory may be
>> updated by the hypervisor in the case the NUMA topology of the LPAR's
>> memory is updated.
>>
>> This is caught by the kernel, but the memory's node is updated because
>> there is no way to move a memory block between nodes.
>>
>> If later a memory block is added or removed, drmem_update_dt() is called
>> and it is overwriting the DT node to match the added or removed LMB. But
>> the LMB's associativity node has not been updated after the DT node update
>> and thus the node is overwritten by the Linux's topology instead of the
>> hypervisor one.
>>
>> Introduce a hook called when the ibm,dynamic-reconfiguration-memory node is
>> updated to force an update of the LMB's associativity.
>>
>> Cc: Tyrel Datwyler <tyreld@linux.ibm.com>
>> Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
>> ---
>>
>> V3:
>> - Check rd->dn->name instead of rd->dn->full_name
>> V2:
>> - Take Tyrel's idea to rely on OF_RECONFIG_UPDATE_PROPERTY instead of
>> introducing a new hook mechanism.
>> ---
>> arch/powerpc/include/asm/drmem.h | 1 +
>> arch/powerpc/mm/drmem.c | 35 +++++++++++++++++++
>> .../platforms/pseries/hotplug-memory.c | 4 +++
>> 3 files changed, 40 insertions(+)
>>
>> diff --git a/arch/powerpc/include/asm/drmem.h b/arch/powerpc/include/asm/drmem.h
>> index bf2402fed3e0..4265d5e95c2c 100644
>> --- a/arch/powerpc/include/asm/drmem.h
>> +++ b/arch/powerpc/include/asm/drmem.h
>> @@ -111,6 +111,7 @@ int drmem_update_dt(void);
>> int __init
>> walk_drmem_lmbs_early(unsigned long node, void *data,
>> int (*func)(struct drmem_lmb *, const __be32 **, void *));
>> +void drmem_update_lmbs(struct property *prop);
>> #endif
>>
>> static inline void invalidate_lmb_associativity_index(struct drmem_lmb *lmb)
>> diff --git a/arch/powerpc/mm/drmem.c b/arch/powerpc/mm/drmem.c
>> index 9af3832c9d8d..f0a6633132af 100644
>> --- a/arch/powerpc/mm/drmem.c
>> +++ b/arch/powerpc/mm/drmem.c
>> @@ -307,6 +307,41 @@ int __init walk_drmem_lmbs_early(unsigned long node, void *data,
>> return ret;
>> }
>>
>> +/*
>> + * Update the LMB associativity index.
>> + */
>> +static int update_lmb(struct drmem_lmb *updated_lmb,
>> + __maybe_unused const __be32 **usm,
>> + __maybe_unused void *data)
>> +{
>> + struct drmem_lmb *lmb;
>> +
>> + /*
>> + * Brut force there may be better way to fetch the LMB
>> + */
>> + for_each_drmem_lmb(lmb) {
>> + if (lmb->drc_index != updated_lmb->drc_index)
>> + continue;
>> +
>> + lmb->aa_index = updated_lmb->aa_index;
>> + break;
>> + }
>> + return 0;
>> +}
>> +
>> +/*
>> + * Update the LMB associativity index.
>> + *
>> + * This needs to be called when the hypervisor is updating the
>> + * dynamic-reconfiguration-memory node property.
>> + */
>> +void drmem_update_lmbs(struct property *prop)
>> +{
>> + if (!strcmp(prop->name, "ibm,dynamic-memory"))
>> + __walk_drmem_v1_lmbs(prop->value, NULL, NULL, update_lmb);
>> + else if (!strcmp(prop->name, "ibm,dynamic-memory-v2"))
>> + __walk_drmem_v2_lmbs(prop->value, NULL, NULL, update_lmb);
>> +}
>> #endif
>>
>> static int init_drmem_lmb_size(struct device_node *dn)
>> diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
>> index 8377f1f7c78e..672ffbee2e78 100644
>> --- a/arch/powerpc/platforms/pseries/hotplug-memory.c
>> +++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
>> @@ -949,6 +949,10 @@ static int pseries_memory_notifier(struct notifier_block *nb,
>> case OF_RECONFIG_DETACH_NODE:
>> err = pseries_remove_mem_node(rd->dn);
>> break;
>> + case OF_RECONFIG_UPDATE_PROPERTY:
>> + if (!strcmp(rd->dn->name,
>> + "ibm,dynamic-reconfiguration-memory"))
>> + drmem_update_lmbs(rd->prop);
>> }
>> return notifier_from_errno(err);
>
> How will this interact with DLPAR memory? When we dlpar memory,
> ibm,configure-connector is used to fetch the new associativity details
> and set drmem_lmb->aa_index correctly there. Once that is done kernel
> then call drmem_update_dt() which will result in the above notifier
> callback?
When a memory DLPAR operation is done, the in memory DT property
"ibm,dynamic-memory" or "ibm,dynamic-memory-v2" (if existing) have to be updated
to reflect the added/removed memory part. This is done by calling drmem_update_dt().
This patch is addressing the case where the hypervisor has updated the DT
property mentioned above. In that case, the LMB tree should be updated so the
aa_index fields are matching the DT one. This way the next time a memory DLPAR
operation is done the DT properties "ibm,dynamic-memory" or
"ibm,dynamic-memory-v2" will be rebuilt correctly.
> IIUC, the call back then will update drmem_lmb->aa_index again?
drmem_update_dt() is not updating drmem_lmb->aa_index, that's the oppposite, it
is rebuilding the in memory DT property "ibm,dynamic-memory" or
"ibm,dynamic-memory-v2" based on the data stored in the LMB tree.
Laurent.
^ permalink raw reply
* Re: [PATCH v3] pseries/drmem: update LMBs after LPM
From: Laurent Dufour @ 2021-04-29 11:35 UTC (permalink / raw)
To: Aneesh Kumar K.V, mpe, benh, paulus
Cc: nathanl, Tyrel Datwyler, linuxppc-dev, linux-kernel
In-Reply-To: <e3fcd8b6-6d43-85ed-7036-42430aad4979@linux.ibm.com>
Le 29/04/2021 à 13:31, Laurent Dufour a écrit :
> Le 29/04/2021 à 12:27, Aneesh Kumar K.V a écrit :
>> Laurent Dufour <ldufour@linux.ibm.com> writes:
>>
>>> After a LPM, the device tree node ibm,dynamic-reconfiguration-memory may be
>>> updated by the hypervisor in the case the NUMA topology of the LPAR's
>>> memory is updated.
>>>
>>> This is caught by the kernel, but the memory's node is updated because
>>> there is no way to move a memory block between nodes.
>>>
>>> If later a memory block is added or removed, drmem_update_dt() is called
>>> and it is overwriting the DT node to match the added or removed LMB. But
>>> the LMB's associativity node has not been updated after the DT node update
>>> and thus the node is overwritten by the Linux's topology instead of the
>>> hypervisor one.
>>>
>>> Introduce a hook called when the ibm,dynamic-reconfiguration-memory node is
>>> updated to force an update of the LMB's associativity.
>>>
>>> Cc: Tyrel Datwyler <tyreld@linux.ibm.com>
>>> Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
>>> ---
>>>
>>> V3:
>>> - Check rd->dn->name instead of rd->dn->full_name
>>> V2:
>>> - Take Tyrel's idea to rely on OF_RECONFIG_UPDATE_PROPERTY instead of
>>> introducing a new hook mechanism.
>>> ---
>>> arch/powerpc/include/asm/drmem.h | 1 +
>>> arch/powerpc/mm/drmem.c | 35 +++++++++++++++++++
>>> .../platforms/pseries/hotplug-memory.c | 4 +++
>>> 3 files changed, 40 insertions(+)
>>>
>>> diff --git a/arch/powerpc/include/asm/drmem.h b/arch/powerpc/include/asm/drmem.h
>>> index bf2402fed3e0..4265d5e95c2c 100644
>>> --- a/arch/powerpc/include/asm/drmem.h
>>> +++ b/arch/powerpc/include/asm/drmem.h
>>> @@ -111,6 +111,7 @@ int drmem_update_dt(void);
>>> int __init
>>> walk_drmem_lmbs_early(unsigned long node, void *data,
>>> int (*func)(struct drmem_lmb *, const __be32 **, void *));
>>> +void drmem_update_lmbs(struct property *prop);
>>> #endif
>>> static inline void invalidate_lmb_associativity_index(struct drmem_lmb *lmb)
>>> diff --git a/arch/powerpc/mm/drmem.c b/arch/powerpc/mm/drmem.c
>>> index 9af3832c9d8d..f0a6633132af 100644
>>> --- a/arch/powerpc/mm/drmem.c
>>> +++ b/arch/powerpc/mm/drmem.c
>>> @@ -307,6 +307,41 @@ int __init walk_drmem_lmbs_early(unsigned long node,
>>> void *data,
>>> return ret;
>>> }
>>> +/*
>>> + * Update the LMB associativity index.
>>> + */
>>> +static int update_lmb(struct drmem_lmb *updated_lmb,
>>> + __maybe_unused const __be32 **usm,
>>> + __maybe_unused void *data)
>>> +{
>>> + struct drmem_lmb *lmb;
>>> +
>>> + /*
>>> + * Brut force there may be better way to fetch the LMB
>>> + */
>>> + for_each_drmem_lmb(lmb) {
>>> + if (lmb->drc_index != updated_lmb->drc_index)
>>> + continue;
>>> +
>>> + lmb->aa_index = updated_lmb->aa_index;
>>> + break;
>>> + }
>>> + return 0;
>>> +}
>>> +
>>> +/*
>>> + * Update the LMB associativity index.
>>> + *
>>> + * This needs to be called when the hypervisor is updating the
>>> + * dynamic-reconfiguration-memory node property.
>>> + */
>>> +void drmem_update_lmbs(struct property *prop)
>>> +{
>>> + if (!strcmp(prop->name, "ibm,dynamic-memory"))
>>> + __walk_drmem_v1_lmbs(prop->value, NULL, NULL, update_lmb);
>>> + else if (!strcmp(prop->name, "ibm,dynamic-memory-v2"))
>>> + __walk_drmem_v2_lmbs(prop->value, NULL, NULL, update_lmb);
>>> +}
>>> #endif
>>> static int init_drmem_lmb_size(struct device_node *dn)
>>> diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c
>>> b/arch/powerpc/platforms/pseries/hotplug-memory.c
>>> index 8377f1f7c78e..672ffbee2e78 100644
>>> --- a/arch/powerpc/platforms/pseries/hotplug-memory.c
>>> +++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
>>> @@ -949,6 +949,10 @@ static int pseries_memory_notifier(struct notifier_block
>>> *nb,
>>> case OF_RECONFIG_DETACH_NODE:
>>> err = pseries_remove_mem_node(rd->dn);
>>> break;
>>> + case OF_RECONFIG_UPDATE_PROPERTY:
>>> + if (!strcmp(rd->dn->name,
>>> + "ibm,dynamic-reconfiguration-memory"))
>>> + drmem_update_lmbs(rd->prop);
>>> }
>>> return notifier_from_errno(err);
>>
>> How will this interact with DLPAR memory? When we dlpar memory,
>> ibm,configure-connector is used to fetch the new associativity details
>> and set drmem_lmb->aa_index correctly there. Once that is done kernel
>> then call drmem_update_dt() which will result in the above notifier
>> callback?
>
> When a memory DLPAR operation is done, the in memory DT property
> "ibm,dynamic-memory" or "ibm,dynamic-memory-v2" (if existing) have to be updated
> to reflect the added/removed memory part. This is done by calling
> drmem_update_dt().
>
> This patch is addressing the case where the hypervisor has updated the DT
> property mentioned above. In that case, the LMB tree should be updated so the
> aa_index fields are matching the DT one. This way the next time a memory DLPAR
> operation is done the DT properties "ibm,dynamic-memory" or
> "ibm,dynamic-memory-v2" will be rebuilt correctly.
>
>> IIUC, the call back then will update drmem_lmb->aa_index again?
Oh I missed what you pointed out.
Please ignore my previous answer, I need to double check code.
> drmem_update_dt() is not updating drmem_lmb->aa_index, that's the oppposite, it
> is rebuilding the in memory DT property "ibm,dynamic-memory" or
> "ibm,dynamic-memory-v2" based on the data stored in the LMB tree.
>
> Laurent.
^ permalink raw reply
* [PATCH v3] cpuidle/pseries: Fixup CEDE0 latency only for POWER10 onwards
From: Gautham R. Shenoy @ 2021-04-29 12:06 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Michael Ellerman,
Aneesh Kumar K.V, Vaidyanathan Srinivasan
Cc: Gautham R. Shenoy, linux-pm, joedecke, Michal Suchanek,
linuxppc-dev
From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
Commit d947fb4c965c ("cpuidle: pseries: Fixup exit latency for
CEDE(0)") sets the exit latency of CEDE(0) based on the latency values
of the Extended CEDE states advertised by the platform
On POWER9 LPARs, the firmwares advertise a very low value of 2us for
CEDE1 exit latency on a Dedicated LPAR. The latency advertized by the
PHYP hypervisor corresponds to the latency required to wakeup from the
underlying hardware idle state. However the wakeup latency from the
LPAR perspective should include
1. The time taken to transition the CPU from the Hypervisor into the
LPAR post wakeup from platform idle state
2. Time taken to send the IPI from the source CPU (waker) to the idle
target CPU (wakee).
1. can be measured via timer idle test, where we queue a timer, say
for 1ms, and enter the CEDE state. When the timer fires, in the timer
handler we compute how much extra timer over the expected 1ms have we
consumed. On a a POWER9 LPAR the numbers are
CEDE latency measured using a timer (numbers in ns)
N Min Median Avg 90%ile 99%ile Max Stddev
400 2601 5677 5668.74 5917 6413 9299 455.01
1. and 2. combined can be determined by an IPI latency test where we
send an IPI to an idle CPU and in the handler compute the time
difference between when the IPI was sent and when the handler ran. We
see the following numbers on POWER9 LPAR.
CEDE latency measured using an IPI (numbers in ns)
N Min Median Avg 90%ile 99%ile Max Stddev
400 711 7564 7369.43 8559 9514 9698 1200.01
Suppose, we consider the 99th percentile latency value measured using
the IPI to be the wakeup latency, the value would be 9.5us This is in
the ballpark of the default value of 10us.
Hence, use the exit latency of CEDE(0) based on the latency values
advertized by platform only from POWER10 onwards. The values
advertized on POWER10 platforms is more realistic and informed by the
latency measurements. For earlier platforms stick to the default value
of 10us. The fix was suggested by Michael Ellerman.
Reported-by: Enrico Joedecke <joedecke@de.ibm.com>
Fixes: commit d947fb4c965c ("cpuidle: pseries: Fixup exit latency for
CEDE(0)")
Cc: Michal Suchanek <msuchanek@suse.de>
Cc: Vaidyanathan Srinivasan <svaidy@linux.ibm.com>
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
---
v2-->v3: Modify the condition to preclude only the platforms prior to
POWER10 from using the firmware provided values.
drivers/cpuidle/cpuidle-pseries.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/cpuidle/cpuidle-pseries.c b/drivers/cpuidle/cpuidle-pseries.c
index a2b5c6f..694d71e 100644
--- a/drivers/cpuidle/cpuidle-pseries.c
+++ b/drivers/cpuidle/cpuidle-pseries.c
@@ -349,6 +349,15 @@ static void __init fixup_cede0_latency(void)
u64 min_latency_us;
int i;
+ /*
+ * Use firmware provided latency values on POWER10 onwards and
+ * also on POWER10 running in POWER9-compat mode. On platforms
+ * prior to POWER10, we cannot rely on the firmware provided
+ * values, so we go with the conservative default value.
+ */
+ if (!cpu_has_feature(CPU_FTR_ARCH_31) && !pvr_version_is(PVR_POWER10))
+ return;
+
min_latency_us = dedicated_states[1].exit_latency; // CEDE latency
if (parse_cede_parameters())
--
1.9.4
^ permalink raw reply related
* Re: [PATCH v3] pseries/drmem: update LMBs after LPM
From: Laurent Dufour @ 2021-04-29 12:38 UTC (permalink / raw)
To: Aneesh Kumar K.V, mpe, benh, paulus
Cc: nathanl, Tyrel Datwyler, linuxppc-dev, linux-kernel
In-Reply-To: <87fsz95qso.fsf@linux.ibm.com>
Le 29/04/2021 à 12:27, Aneesh Kumar K.V a écrit :
> Laurent Dufour <ldufour@linux.ibm.com> writes:
>
>> After a LPM, the device tree node ibm,dynamic-reconfiguration-memory may be
>> updated by the hypervisor in the case the NUMA topology of the LPAR's
>> memory is updated.
>>
>> This is caught by the kernel, but the memory's node is updated because
>> there is no way to move a memory block between nodes.
>>
>> If later a memory block is added or removed, drmem_update_dt() is called
>> and it is overwriting the DT node to match the added or removed LMB. But
>> the LMB's associativity node has not been updated after the DT node update
>> and thus the node is overwritten by the Linux's topology instead of the
>> hypervisor one.
>>
>> Introduce a hook called when the ibm,dynamic-reconfiguration-memory node is
>> updated to force an update of the LMB's associativity.
>>
>> Cc: Tyrel Datwyler <tyreld@linux.ibm.com>
>> Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
>> ---
>>
>> V3:
>> - Check rd->dn->name instead of rd->dn->full_name
>> V2:
>> - Take Tyrel's idea to rely on OF_RECONFIG_UPDATE_PROPERTY instead of
>> introducing a new hook mechanism.
>> ---
>> arch/powerpc/include/asm/drmem.h | 1 +
>> arch/powerpc/mm/drmem.c | 35 +++++++++++++++++++
>> .../platforms/pseries/hotplug-memory.c | 4 +++
>> 3 files changed, 40 insertions(+)
>>
>> diff --git a/arch/powerpc/include/asm/drmem.h b/arch/powerpc/include/asm/drmem.h
>> index bf2402fed3e0..4265d5e95c2c 100644
>> --- a/arch/powerpc/include/asm/drmem.h
>> +++ b/arch/powerpc/include/asm/drmem.h
>> @@ -111,6 +111,7 @@ int drmem_update_dt(void);
>> int __init
>> walk_drmem_lmbs_early(unsigned long node, void *data,
>> int (*func)(struct drmem_lmb *, const __be32 **, void *));
>> +void drmem_update_lmbs(struct property *prop);
>> #endif
>>
>> static inline void invalidate_lmb_associativity_index(struct drmem_lmb *lmb)
>> diff --git a/arch/powerpc/mm/drmem.c b/arch/powerpc/mm/drmem.c
>> index 9af3832c9d8d..f0a6633132af 100644
>> --- a/arch/powerpc/mm/drmem.c
>> +++ b/arch/powerpc/mm/drmem.c
>> @@ -307,6 +307,41 @@ int __init walk_drmem_lmbs_early(unsigned long node, void *data,
>> return ret;
>> }
>>
>> +/*
>> + * Update the LMB associativity index.
>> + */
>> +static int update_lmb(struct drmem_lmb *updated_lmb,
>> + __maybe_unused const __be32 **usm,
>> + __maybe_unused void *data)
>> +{
>> + struct drmem_lmb *lmb;
>> +
>> + /*
>> + * Brut force there may be better way to fetch the LMB
>> + */
>> + for_each_drmem_lmb(lmb) {
>> + if (lmb->drc_index != updated_lmb->drc_index)
>> + continue;
>> +
>> + lmb->aa_index = updated_lmb->aa_index;
>> + break;
>> + }
>> + return 0;
>> +}
>> +
>> +/*
>> + * Update the LMB associativity index.
>> + *
>> + * This needs to be called when the hypervisor is updating the
>> + * dynamic-reconfiguration-memory node property.
>> + */
>> +void drmem_update_lmbs(struct property *prop)
>> +{
>> + if (!strcmp(prop->name, "ibm,dynamic-memory"))
>> + __walk_drmem_v1_lmbs(prop->value, NULL, NULL, update_lmb);
>> + else if (!strcmp(prop->name, "ibm,dynamic-memory-v2"))
>> + __walk_drmem_v2_lmbs(prop->value, NULL, NULL, update_lmb);
>> +}
>> #endif
>>
>> static int init_drmem_lmb_size(struct device_node *dn)
>> diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
>> index 8377f1f7c78e..672ffbee2e78 100644
>> --- a/arch/powerpc/platforms/pseries/hotplug-memory.c
>> +++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
>> @@ -949,6 +949,10 @@ static int pseries_memory_notifier(struct notifier_block *nb,
>> case OF_RECONFIG_DETACH_NODE:
>> err = pseries_remove_mem_node(rd->dn);
>> break;
>> + case OF_RECONFIG_UPDATE_PROPERTY:
>> + if (!strcmp(rd->dn->name,
>> + "ibm,dynamic-reconfiguration-memory"))
>> + drmem_update_lmbs(rd->prop);
>> }
>> return notifier_from_errno(err);
>
> How will this interact with DLPAR memory? When we dlpar memory,
> ibm,configure-connector is used to fetch the new associativity details
> and set drmem_lmb->aa_index correctly there. Once that is done kernel
> then call drmem_update_dt() which will result in the above notifier
> callback?
>
> IIUC, the call back then will update drmem_lmb->aa_index again?
Thanks for pointing this Aneesh,
You're right I missed that callback and it was quite invisible during my test
because the value set back in the aa_index was the same.
When dmrem_update_dt() is called, there is no need to update the LMB back and
the DT modify notifier should be ignored.
As DLPAR operations are serialized (by lock_device_hotplug()), I'm proposing to
rely on a boolean static variable to do skip this notification, like this:
diff --git a/arch/powerpc/mm/drmem.c b/arch/powerpc/mm/drmem.c
index f0a6633132af..3c0130720086 100644
--- a/arch/powerpc/mm/drmem.c
+++ b/arch/powerpc/mm/drmem.c
@@ -18,6 +18,7 @@ static int n_root_addr_cells, n_root_size_cells;
static struct drmem_lmb_info __drmem_info;
struct drmem_lmb_info *drmem_info = &__drmem_info;
+static bool in_drmem_update;
u64 drmem_lmb_memory_max(void)
{
@@ -178,6 +179,11 @@ int drmem_update_dt(void)
if (!memory)
return -1;
+ /*
+ * Set in_drmem_update to prevent the notifier callback to process the
+ * DT property back since the change is coming from the LMB tree.
+ */
+ in_drmem_update = true;
prop = of_find_property(memory, "ibm,dynamic-memory", NULL);
if (prop) {
rc = drmem_update_dt_v1(memory, prop);
@@ -186,6 +192,7 @@ int drmem_update_dt(void)
if (prop)
rc = drmem_update_dt_v2(memory, prop);
}
+ in_drmem_update = false;
of_node_put(memory);
return rc;
@@ -337,6 +344,12 @@ static int update_lmb(struct drmem_lmb *updated_lmb,
*/
void drmem_update_lmbs(struct property *prop)
{
+ /*
+ * Don't update the LMBs If called from the update done in
+ * drmem_update_dt().
+ */
+ if (in_drmem_update)
+ return;
if (!strcmp(prop->name, "ibm,dynamic-memory"))
__walk_drmem_v1_lmbs(prop->value, NULL, NULL, update_lmb);
else if (!strcmp(prop->name, "ibm,dynamic-memory-v2"))
Any concern with this option?
Laurent.
^ permalink raw reply related
* Re: [PATCH kernel v2] powerpc/iommu: Annotate nested lock for lockdep
From: Michael Ellerman @ 2021-04-29 14:01 UTC (permalink / raw)
To: linuxppc-dev, Alexey Kardashevskiy; +Cc: Frederic Barrat, kvm-ppc
In-Reply-To: <20210301063653.51003-1-aik@ozlabs.ru>
On Mon, 1 Mar 2021 17:36:53 +1100, Alexey Kardashevskiy wrote:
> The IOMMU table is divided into pools for concurrent mappings and each
> pool has a separate spinlock. When taking the ownership of an IOMMU group
> to pass through a device to a VM, we lock these spinlocks which triggers
> a false negative warning in lockdep (below).
>
> This fixes it by annotating the large pool's spinlock as a nest lock
> which makes lockdep not complaining when locking nested locks if
> the nest lock is locked already.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/iommu: Annotate nested lock for lockdep
https://git.kernel.org/powerpc/c/cc7130bf119add37f36238343a593b71ef6ecc1e
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/perf: Fix sampled instruction type for larx/stcx
From: Michael Ellerman @ 2021-04-29 14:01 UTC (permalink / raw)
To: mpe, Athira Rajeev; +Cc: maddy, linuxppc-dev
In-Reply-To: <1614858937-1485-1-git-send-email-atrajeev@linux.vnet.ibm.com>
On Thu, 4 Mar 2021 06:55:37 -0500, Athira Rajeev wrote:
> Sampled Instruction Event Register (SIER) field [46:48]
> identifies the sampled instruction type. ISA v3.1 says value
> of 0b111 for this field as reserved, but in POWER10 it denotes
> LARX/STCX type which will hopefully be fixed in ISA v3.1 update.
>
> Patch fixes the functions to handle type value 7 for
> CPU_FTR_ARCH_31.
Applied to powerpc/next.
[1/1] powerpc/perf: Fix sampled instruction type for larx/stcx
https://git.kernel.org/powerpc/c/b4ded42268ee3d703da208278342b9901abe145a
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/perf: Fix the threshold event selection for memory events in power10
From: Michael Ellerman @ 2021-04-29 14:01 UTC (permalink / raw)
To: mpe, Athira Rajeev; +Cc: maddy, linuxppc-dev
In-Reply-To: <1614840015-1535-1-git-send-email-atrajeev@linux.vnet.ibm.com>
On Thu, 4 Mar 2021 01:40:15 -0500, Athira Rajeev wrote:
> Memory events (mem-loads and mem-stores) currently use the threshold
> event selection as issue to finish. Power10 supports issue to complete
> as part of thresholding which is more appropriate for mem-loads and
> mem-stores. Hence fix the event code for memory events to use issue
> to complete.
Applied to powerpc/next.
[1/1] powerpc/perf: Fix the threshold event selection for memory events in power10
https://git.kernel.org/powerpc/c/66d9b7492887d34c711bc05b36c22438acba51b4
cheers
^ permalink raw reply
* Re: [PATCH kernel 0/2] powerpc/iommu: Stop crashing the host when VM is terminated
From: Michael Ellerman @ 2021-04-29 14:01 UTC (permalink / raw)
To: linuxppc-dev, Alexey Kardashevskiy; +Cc: kvm-ppc, David Gibson
In-Reply-To: <20210216033307.69863-1-aik@ozlabs.ru>
On Tue, 16 Feb 2021 14:33:05 +1100, Alexey Kardashevskiy wrote:
> Killing a VM on a host under memory pressure kills a host which is
> annoying. 1/2 reduces the chances, 2/2 eliminates panic() on
> ioda2.
>
>
> This is based on sha1
> f40ddce88593 Linus Torvalds "Linux 5.11".
>
> [...]
Applied to powerpc/next.
[1/2] powerpc/iommu: Allocate it_map by vmalloc
https://git.kernel.org/powerpc/c/7f1fa82d79947dfabb4046e1d787da9db2bc1c20
[2/2] powerpc/iommu: Do not immediately panic when failed IOMMU table allocation
https://git.kernel.org/powerpc/c/4be518d838809e21354f32087aa9c26efc50b410
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/52xx: Fix an invalid ASM expression ('addi' used instead of 'add')
From: Michael Ellerman @ 2021-04-29 14:01 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Christophe Leroy,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cb4cec9131c8577803367f1699209a7e104cec2a.1619025821.git.christophe.leroy@csgroup.eu>
On Wed, 21 Apr 2021 17:24:03 +0000 (UTC), Christophe Leroy wrote:
> AS arch/powerpc/platforms/52xx/lite5200_sleep.o
> arch/powerpc/platforms/52xx/lite5200_sleep.S: Assembler messages:
> arch/powerpc/platforms/52xx/lite5200_sleep.S:184: Warning: invalid register expression
>
> In the following code, 'addi' is wrong, has to be 'add'
>
> /* local udelay in sram is needed */
> udelay: /* r11 - tb_ticks_per_usec, r12 - usecs, overwrites r13 */
> mullw r12, r12, r11
> mftb r13 /* start */
> addi r12, r13, r12 /* end */
Applied to powerpc/next.
[1/1] powerpc/52xx: Fix an invalid ASM expression ('addi' used instead of 'add')
https://git.kernel.org/powerpc/c/8a87a507714386efc39c3ae6fa24d4f79846b522
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/kasan: Fix shadow start address with modules
From: Michael Ellerman @ 2021-04-29 14:01 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Christophe Leroy,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <c68163065163f303f5af1e4bbdd9f1ce69f0543e.1619260465.git.christophe.leroy@csgroup.eu>
On Sat, 24 Apr 2021 10:34:43 +0000 (UTC), Christophe Leroy wrote:
> Modules are now located before kernel, KASAN area has to
> be extended accordingly.
Applied to powerpc/next.
[1/1] powerpc/kasan: Fix shadow start address with modules
https://git.kernel.org/powerpc/c/30c400886bad4ac1801516683b71d7714bc2b1b1
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/signal32: Fix erroneous SIGSEGV on RT signal return
From: Michael Ellerman @ 2021-04-29 14:01 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Christophe Leroy,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <a29aadc54c93bcbf069a83615fa102ca0f59c3ae.1619185912.git.christophe.leroy@csgroup.eu>
On Fri, 23 Apr 2021 13:52:10 +0000 (UTC), Christophe Leroy wrote:
> Return of user_read_access_begin() is tested the wrong way,
> leading to a SIGSEGV when the user address is valid and likely
> an Oops when the user address is bad.
>
> Fix the test.
Applied to powerpc/next.
[1/1] powerpc/signal32: Fix erroneous SIGSEGV on RT signal return
https://git.kernel.org/powerpc/c/5256426247837feb8703625bda7fcfc824af04cf
cheers
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc/64: Fix the definition of the fixmap area
From: Michael Ellerman @ 2021-04-29 14:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Christophe Leroy, Michael Ellerman,
chris.packham, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <0d51620eacf036d683d1a3c41328f69adb601dc0.1618925560.git.christophe.leroy@csgroup.eu>
On Tue, 20 Apr 2021 13:32:48 +0000 (UTC), Christophe Leroy wrote:
> At the time being, the fixmap area is defined at the top of
> the address space or just below KASAN.
>
> This definition is not valid for PPC64.
>
> For PPC64, use the top of the I/O space.
>
> [...]
Applied to powerpc/next.
[1/2] powerpc/64: Fix the definition of the fixmap area
https://git.kernel.org/powerpc/c/9ccba66d4d2aff9a3909aa77d57ea8b7cc166f3c
[2/2] powerpc/legacy_serial: Use early_ioremap()
https://git.kernel.org/powerpc/c/0bd3f9e953bd3636e73d296e9bed11a25c09c118
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/44x: fix spelling mistake in Kconfig "varients" -> "variants"
From: Michael Ellerman @ 2021-04-29 14:01 UTC (permalink / raw)
To: Colin King, Benjamin Herrenschmidt, linuxppc-dev,
Michael Ellerman, Christophe Leroy, Paul Mackerras
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20201216113608.11812-1-colin.king@canonical.com>
On Wed, 16 Dec 2020 11:36:08 +0000, Colin King wrote:
> There is a spelling mistake in the Kconfig help text. Fix it.
Applied to powerpc/next.
[1/1] powerpc/44x: fix spelling mistake in Kconfig "varients" -> "variants"
https://git.kernel.org/powerpc/c/ee6b25fa7c037e42cc5f3b5c024b2a779edab6dd
cheers
^ permalink raw reply
* Re: [PATCH] selftests/powerpc: Add uaccess flush test
From: Michael Ellerman @ 2021-04-29 14:01 UTC (permalink / raw)
To: Daniel Axtens, linuxppc-dev; +Cc: Thadeu Lima de Souza Cascardo
In-Reply-To: <20210225061949.1213404-1-dja@axtens.net>
On Thu, 25 Feb 2021 17:19:49 +1100, Daniel Axtens wrote:
> Also based on the RFI and entry flush tests, it counts the L1D misses
> by doing a syscall that does user access: uname, in this case.
Applied to powerpc/next.
[1/1] selftests/powerpc: Add uaccess flush test
https://git.kernel.org/powerpc/c/da650ada100956b0f00aa4fe9ce33103378ce9ca
cheers
^ permalink raw reply
* Re: [PATCH 1/1] powerpc/kernel/iommu: Align size for IOMMU_PAGE_SIZE() to save TCEs
From: Michael Ellerman @ 2021-04-29 14:01 UTC (permalink / raw)
To: Alexey Kardashevskiy, Benjamin Herrenschmidt, Nicolin Chen,
Leonardo Bras, Michael Ellerman, Niklas Schnelle, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20210318174414.684630-1-leobras.c@gmail.com>
On Thu, 18 Mar 2021 14:44:14 -0300, Leonardo Bras wrote:
> Currently both iommu_alloc_coherent() and iommu_free_coherent() align the
> desired allocation size to PAGE_SIZE, and gets system pages and IOMMU
> mappings (TCEs) for that value.
>
> When IOMMU_PAGE_SIZE < PAGE_SIZE, this behavior may cause unnecessary
> TCEs to be created for mapping the whole system page.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/kernel/iommu: Align size for IOMMU_PAGE_SIZE() to save TCEs
https://git.kernel.org/powerpc/c/3c0468d4451eb6b4f6604370639f163f9637a479
cheers
^ permalink raw reply
* Re: [PATCH 1/1] powerpc/kernel/iommu: Use largepool as a last resort when !largealloc
From: Michael Ellerman @ 2021-04-29 14:01 UTC (permalink / raw)
To: Alexey Kardashevskiy, Benjamin Herrenschmidt, Nicolin Chen,
Leonardo Bras, Michael Ellerman, Niklas Schnelle, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20210318174414.684630-2-leobras.c@gmail.com>
On Thu, 18 Mar 2021 14:44:17 -0300, Leonardo Bras wrote:
> As of today, doing iommu_range_alloc() only for !largealloc (npages <= 15)
> will only be able to use 3/4 of the available pages, given pages on
> largepool not being available for !largealloc.
>
> This could mean some drivers not being able to fully use all the available
> pages for the DMA window.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/kernel/iommu: Use largepool as a last resort when !largealloc
https://git.kernel.org/powerpc/c/fc5590fd56c9608f317729b59a56dad2a75d633f
cheers
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/fadump: Fix sparse warnings
From: Michael Ellerman @ 2021-04-29 14:01 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: hbathini
In-Reply-To: <20210421125402.1955013-1-mpe@ellerman.id.au>
On Wed, 21 Apr 2021 22:54:01 +1000, Michael Ellerman wrote:
> Sparse says:
> arch/powerpc/kernel/fadump.c:48:16: warning: symbol 'fadump_kobj' was not declared. Should it be static?
> arch/powerpc/kernel/fadump.c:55:27: warning: symbol 'crash_mrange_info' was not declared. Should it be static?
> arch/powerpc/kernel/fadump.c:61:27: warning: symbol 'reserved_mrange_info' was not declared. Should it be static?
> arch/powerpc/kernel/fadump.c:83:12: warning: symbol 'fadump_cma_init' was not declared. Should it be static?
>
> And indeed none of them are used outside this file, they can all be made
> static. Also fadump_kobj needs to be moved inside the ifdef where it's
> used.
Applied to powerpc/next.
[1/2] powerpc/fadump: Fix sparse warnings
https://git.kernel.org/powerpc/c/2e341f56a16a71f240c87ec69711aad0d95a704c
[2/2] powerpc/powernv: Fix type of opal_mpipl_query_tag() addr argument
https://git.kernel.org/powerpc/c/d936f8182e1bd18f5e9e6c5e8d8b69261200ca96
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/64s: Add FA_DUMP to defconfig
From: Michael Ellerman @ 2021-04-29 14:01 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20210420042209.1641634-1-mpe@ellerman.id.au>
On Tue, 20 Apr 2021 14:22:09 +1000, Michael Ellerman wrote:
> FA_DUMP (Firmware Assisted Dump) is a powerpc only feature that should
> be enabled in our defconfig to get some build / test coverage.
Applied to powerpc/next.
[1/1] powerpc/64s: Add FA_DUMP to defconfig
https://git.kernel.org/powerpc/c/7d946276570755d6b53d29bd100271f18cb8bf95
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/configs: Add IBMVNIC to some 64-bit configs
From: Michael Ellerman @ 2021-04-29 14:01 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20210302020954.2980046-1-mpe@ellerman.id.au>
On Tue, 2 Mar 2021 13:09:54 +1100, Michael Ellerman wrote:
> This is an IBM specific driver that we should enable to get some
> build/boot testing.
Applied to powerpc/next.
[1/1] powerpc/configs: Add IBMVNIC to some 64-bit configs
https://git.kernel.org/powerpc/c/421a7483878cf3f356ebb871effe81997a45dda7
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/kvm: Fix build error when PPC_MEM_KEYS/PPC_PSERIES=n
From: Michael Ellerman @ 2021-04-29 14:01 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20210425115831.2818434-1-mpe@ellerman.id.au>
On Sun, 25 Apr 2021 21:58:31 +1000, Michael Ellerman wrote:
> lkp reported a randconfig failure:
>
> In file included from arch/powerpc/include/asm/book3s/64/pkeys.h:6,
> from arch/powerpc/kvm/book3s_64_mmu_host.c:15:
> arch/powerpc/include/asm/book3s/64/hash-pkey.h: In function 'hash__vmflag_to_pte_pkey_bits':
> >> arch/powerpc/include/asm/book3s/64/hash-pkey.h:10:23: error: 'VM_PKEY_BIT0' undeclared
> 10 | return (((vm_flags & VM_PKEY_BIT0) ? H_PTE_PKEY_BIT0 : 0x0UL) |
> | ^~~~~~~~~~~~
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/kvm: Fix build error when PPC_MEM_KEYS/PPC_PSERIES=n
https://git.kernel.org/powerpc/c/ee1bc694fbaec1a662770703fc34a74abf418938
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: Avoid clang uninitialized warning in __get_user_size_allowed
From: Michael Ellerman @ 2021-04-29 14:01 UTC (permalink / raw)
To: Michael Ellerman, Nathan Chancellor
Cc: clang-built-linux, Nick Desaulniers, linuxppc-dev, linux-kernel,
Paul Mackerras
In-Reply-To: <20210426203518.981550-1-nathan@kernel.org>
On Mon, 26 Apr 2021 13:35:18 -0700, Nathan Chancellor wrote:
> Commit 9975f852ce1b ("powerpc/uaccess: Remove calls to __get_user_bad()
> and __put_user_bad()") switch to BUILD_BUG() in the default case, which
> leaves x uninitialized. This will not be an issue because the build will
> be broken in that case but clang does static analysis before it realizes
> the default case will be done so it warns about x being uninitialized
> (trimmed for brevity):
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: Avoid clang uninitialized warning in __get_user_size_allowed
https://git.kernel.org/powerpc/c/f9cd5f91a897ea0c45d0059ceeb091cee78c6ebe
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/64s: Fix mm_cpumask memory ordering comment
From: Michael Ellerman @ 2021-04-29 14:01 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <20210421151733.212858-1-npiggin@gmail.com>
On Thu, 22 Apr 2021 01:17:32 +1000, Nicholas Piggin wrote:
> The memory ordering comment no longer applies, because mm_ctx_id is
> no longer used anywhere. At best always been difficult to follow.
>
> It's better to consider the load on which the slbmte depends on, which
> the MMU depends on before it can start loading TLBs, rather than a
> store which may or may not have a subsequent dependency chain to the
> slbmte.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/64s: Fix mm_cpumask memory ordering comment
https://git.kernel.org/powerpc/c/0f197ddce403af33aa7f15af55644549778a9988
cheers
^ permalink raw reply
* Re: [PATCH v3] powerpc: make ALTIVEC select PPC_FPU
From: Michael Ellerman @ 2021-04-29 14:01 UTC (permalink / raw)
To: linux-kernel, Randy Dunlap; +Cc: linuxppc-dev, kernel test robot
In-Reply-To: <20210421210647.20836-1-rdunlap@infradead.org>
On Wed, 21 Apr 2021 14:06:47 -0700, Randy Dunlap wrote:
> On a kernel config with ALTIVEC=y and PPC_FPU not set/enabled,
> there are build errors:
>
> drivers/cpufreq/pmac32-cpufreq.c:262:2: error: implicit declaration of function 'enable_kernel_fp' [-Werror,-Wimplicit-function-declaration]
> enable_kernel_fp();
> ../arch/powerpc/lib/sstep.c: In function 'do_vec_load':
> ../arch/powerpc/lib/sstep.c:637:3: error: implicit declaration of function 'put_vr' [-Werror=implicit-function-declaration]
> 637 | put_vr(rn, &u.v);
> | ^~~~~~
> ../arch/powerpc/lib/sstep.c: In function 'do_vec_store':
> ../arch/powerpc/lib/sstep.c:660:3: error: implicit declaration of function 'get_vr'; did you mean 'get_oc'? [-Werror=implicit-function-declaration]
> 660 | get_vr(rn, &u.v);
> | ^~~~~~
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: make ALTIVEC select PPC_FPU
https://git.kernel.org/powerpc/c/389586333c0229a4fbc5c1a7f89148d141293682
cheers
^ permalink raw reply
* Re: [PATCH v3 0/4] powerpc/selftests: Add Power10 2nd DAWR selftests
From: Michael Ellerman @ 2021-04-29 14:01 UTC (permalink / raw)
To: mpe, Ravi Bangoria; +Cc: linuxppc-dev, mikey, shuah, linux-kselftest, dja
In-Reply-To: <20210412112218.128183-1-ravi.bangoria@linux.ibm.com>
On Mon, 12 Apr 2021 16:52:14 +0530, Ravi Bangoria wrote:
> Power10 introduced 2nd watchpoint (DAWR). ISA 3.1, Book 3S, Ch 9 -
> 'Debug Facilities' covers the feature in detail. Kernel patches to
> enable the 2nd DAWR are already in[1], including kvm enablement[2].
> These patches adds selftests for 2nd DAWR.
>
> [1]: https://git.kernel.org/torvalds/c/deb2bd9bcc8428d4b65b6ba640ba8b57c1b20b17
> [2]: https://git.kernel.org/torvalds/c/bd1de1a0e6eff4bde5ceae969673b85b8446fd6a
>
> [...]
Applied to powerpc/next.
[1/4] powerpc/selftests/ptrace-hwbreak: Add testcases for 2nd DAWR
https://git.kernel.org/powerpc/c/dae4ff8031b49af4721101d6298fc14cb9c16a4c
[2/4] powerpc/selftests/perf-hwbreak: Coalesce event creation code
https://git.kernel.org/powerpc/c/c9cb0afb4eaa03801322f48dad4093979ff45e88
[3/4] powerpc/selftests/perf-hwbreak: Add testcases for 2nd DAWR
https://git.kernel.org/powerpc/c/c65c64cc7bbd273121edf96a7a5a0269038ab454
[4/4] powerpc/selftests: Add selftest to test concurrent perf/ptrace events
https://git.kernel.org/powerpc/c/290f7d8ce2b1eea5413bb120e0d9d610675b7fba
cheers
^ 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