T_ONLINE=y after 943db62c316c, this patch
changes mm/Kconfig to make the MEMORY_HOTPLUG_DEFAULT_ONLINE config
unavailable for the PPC64 arch.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1476380
Fixes: 943db62c316c ("powerpc/pseries: Revert 'Auto-online hotplugged memory'")
Signed-off
On 08/01/2017 11:39 AM, Daniel Henrique Barboza wrote:
On 08/01/2017 11:05 AM, Nathan Fontenot wrote:
At this point I don't think we need this patch to disable auto online
for ppc64. I would be curious if this is still broken with the latest
mainline code though.
If the auto_online
On 08/01/2017 11:05 AM, Nathan Fontenot wrote:
On 08/01/2017 04:59 AM, Michael Ellerman wrote:
Daniel Henrique Barboza <danie...@linux.vnet.ibm.com> writes:
Commit 943db62c316c ("powerpc/pseries: Revert 'Auto-online
hotplugged memory'") reverted the auto-online feature
Unless you (Daniel) think there's some reason lmb_is_removable() is
incorrectly returning false. But most likely it's correct and there's
just an unmovable allocation in that range.
I am not educated enough to say that the current behavior is wrong. What I
can say is that in 4.11 and older
Hi,
This is a scenario I've been facing when working in early device
hotplugs in QEMU. When a device is added, a IRQ pulse is fired to warn
the guest of the event, then the kernel fetches it by calling
'check_exception' and handles it. If the hotplug is done too early
(before SLOF, for
Hi Ben,
On 08/29/2017 06:55 PM, Benjamin Herrenschmidt wrote:
On Tue, 2017-08-29 at 17:43 -0300, Daniel Henrique Barboza wrote:
Hi,
This is a scenario I've been facing when working in early device
hotplugs in QEMU. When a device is added, a IRQ pulse is fired to warn
the guest of the event
Hi,
I've stumbled in a LMB hot unplug problem when running a guest with
4.13+ kernel using QEMU 2.10. When trying to hot unplug a recently
hotplugged LMB this is what I got, using an upstream kernel:
---
QEMU cmd line: sudo ./qemu-system-ppc64 -name migrate_qemu -boot
strict=on
ET_LPID, lpid, 2, 0, 1);
} else {
asm volatile(PPC_TLBIE_5(%0,%1,2,0,0) : :
This patch fixes for me a VM migration crash on POWER9.
Same here.
Tested-by: Daniel Henrique Barboza <danie...@linux.vnet.ibm.com>
Tested-by: Laurent Vivier <lviv...@redhat.com>
Thanks,
Laurent
This patch fixed an issue I was experiencing with virsh start/destroy
of guests with mlx5 and GPU passthrough in a Power 9 server. I
believe it's a similar situation which Alexey described in the post
commit msg.
Tested-by: Daniel Henrique Barboza
On 7/12/19 5:20 AM, Alexey Kardashevskiy
when creating the distance table.
This of course has consequences for QEMU, so based on that, I've adapted
the QEMU implementation to not touch node 0.
Daniel
On 8/14/20 5:34 PM, Daniel Henrique Barboza wrote:
Hi,
This is a simple fix that I made while testing NUMA changes
I'm making in QEMU [1
...@linux.ibm.com/
Daniel Henrique Barboza (1):
powerpc/numa: do not skip node 0 when init lookup table
arch/powerpc/mm/numa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.26.2
: 10 160 160 160
1: 160 10 80 80
2: 160 80 10 80
3: 160 80 80 10
With this patch, this is the result:
$ numactl -H
(...)
node distances:
node 0 1 2 3
0: 10 80 80 80
1: 80 10 80 80
2: 80 80 10 80
3: 80 80 80 10
Signed-off-by: Daniel Henrique
Hello,
I didn't find an explanation about the 'double the distance' logic in
'git log' or anywhere in the kernel docs:
(arch/powerpc/mm/numa.c, __node_distance()):
for (i = 0; i < distance_ref_points_depth; i++) {
if (distance_lookup_table[a][i] == distance_lookup_table[b][i])
rimary_domain_index
powerpc/pseries: rename distance_ref_points_depth to max_domain_index
powerpc/pseries: Rename TYPE1_AFFINITY to FORM1_AFFINITY
powerpc/pseries: Consolidate DLPAR NUMA distance update
powerpc/pseries: Consolidate NUMA distance update during boot
powerpc/pseries: Add a help
On 6/17/21 8:11 AM, Aneesh Kumar K.V wrote:
Daniel Henrique Barboza writes:
On 6/17/21 4:46 AM, David Gibson wrote:
On Tue, Jun 15, 2021 at 12:35:17PM +0530, Aneesh Kumar K.V wrote:
David Gibson writes:
On Tue, Jun 15, 2021 at 11:27:50AM +0530, Aneesh Kumar K.V wrote:
David Gibson
On 6/17/21 4:46 AM, David Gibson wrote:
On Tue, Jun 15, 2021 at 12:35:17PM +0530, Aneesh Kumar K.V wrote:
David Gibson writes:
On Tue, Jun 15, 2021 at 11:27:50AM +0530, Aneesh Kumar K.V wrote:
David Gibson writes:
On Mon, Jun 14, 2021 at 10:10:03PM +0530, Aneesh Kumar K.V wrote:
adds another resource grouping named FORM2.
Signed-off-by: Daniel Henrique Barboza
Signed-off-by: Aneesh Kumar K.V
---
Documentation/powerpc/associativity.rst | 135
arch/powerpc/include/asm/firmware.h | 3 +-
arch/powerpc/include/asm/prom.h | 1
in the
previous step.
Signed-off-by: Daniel Henrique Barboza
---
arch/powerpc/platforms/pseries/hotplug-memory.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c
b/arch/powerpc/platforms/pseries/hotplug-memory.c
index
The function is counting reserved LMBs as available to be added, but
they aren't. This will cause the function to miscalculate the available
LMBs and can trigger errors later on when executing dlpar_add_lmb().
Signed-off-by: Daniel Henrique Barboza
---
arch/powerpc/platforms/pseries/hotplug
Hi,
These are a couple of cleanups for the dlpar_memory_add* functions
that are similar to those I did a month or so ago in
dlpar_memory_remove_by_count and dlpar_memory_remove_by_ic.
Daniel Henrique Barboza (3):
powerpc/pseries: skip reserved LMBs in dlpar_memory_add_by_count()
powerpc
reservation is removed, indicating
if there are still marked LMBs to be processed.
Signed-off-by: Daniel Henrique Barboza
---
arch/powerpc/platforms/pseries/hotplug-memory.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/pseries
On 6/22/21 9:07 AM, Aneesh Kumar K.V wrote:
Daniel Henrique Barboza writes:
On 6/17/21 1:51 PM, Aneesh Kumar K.V wrote:
PAPR interface currently supports two different ways of communicating resource
grouping details to the OS. These are referred to as Form 0 and Form 1
associativity
On 5/14/21 4:10 AM, YueHaibing wrote:
dlpar_memory_remove() is never used, so can be removed.
Signed-off-by: YueHaibing
---
Reviewed-by: Daniel Henrique Barboza
arch/powerpc/platforms/pseries/hotplug-memory.c | 4
1 file changed, 4 deletions(-)
diff --git a/arch/powerpc
On 5/3/21 10:02 PM, David Gibson wrote:
On Fri, Apr 30, 2021 at 09:09:16AM -0300, Daniel Henrique Barboza wrote:
dlpar_memory_remove_by_ic() validates the amount of LMBs to be removed
by checking !DRCONF_MEM_RESERVED, and in the following loop before
dlpar_remove_lmb() a check
On 5/3/21 10:02 PM, David Gibson wrote:
On Fri, Apr 30, 2021 at 09:09:16AM -0300, Daniel Henrique Barboza wrote:
dlpar_memory_remove_by_ic() validates the amount of LMBs to be removed
by checking !DRCONF_MEM_RESERVED, and in the following loop before
dlpar_remove_lmb() a check
the reasoning behind the differences
we have in this function in contrast to what it is done in its sister
function, dlpar_memory_remove_by_count().
Signed-off-by: Daniel Henrique Barboza
---
.../platforms/pseries/hotplug-memory.c| 28 +--
1 file changed, 19 insertions(+), 9
.
This change is done in dlpar_memory_remove_by_ic() only because, as of
today, only QEMU is using this code path for error recovery (via the
PSERIES_HP_ELOG_ID_DRC_IC event). phyp treats it as a no-op.
Reviewed-by: David Gibson
Signed-off-by: Daniel Henrique Barboza
---
arch/powerpc/platforms/pseries
(adding back LMBs or releasing DRCs) is
completed.
Signed-off-by: Daniel Henrique Barboza
---
arch/powerpc/platforms/pseries/hotplug-memory.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c
b/arch/powerpc/platforms
function too complex
to handle both cases
- (new) patch 3 and 4: minor enhancements
v1 link:
https://lore.kernel.org/linuxppc-dev/20210430120917.217951-1-danielhb...@gmail.com/
Daniel Henrique Barboza (4):
powerpc/pseries: Set UNISOLATE on dlpar_memory_remove_by_ic() error
powerpc/pseries
mory_remove_by_count()
to miscalculate the number of elegible LMBs for the removal, and can
make it error out later on instead of failing in the validation with the
'not enough LMBs to satisfy request' message.
Making a DRCONF_MEM_RESERVED check in lmb_is_removable() fixes all these
issues.
Signed-off-by: Dan
Henrique Barboza
---
.../platforms/pseries/hotplug-memory.c| 163 +++---
1 file changed, 67 insertions(+), 96 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c
b/arch/powerpc/platforms/pseries/hotplug-memory.c
index 4e6d162c3f1a..a031993725ca 100644
LMBs beforehand.
Signed-off-by: Daniel Henrique Barboza
---
arch/powerpc/platforms/pseries/hotplug-memory.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c
b/arch/powerpc/platforms/pseries/hotplug-memory.c
index
.
This change is done in dlpar_memory_remove_by_ic() only because, as of
today, only QEMU is using this code path for error recovery (via the
PSERIES_HP_ELOG_ID_DRC_IC event). phyp treats it as a no-op.
Signed-off-by: Daniel Henrique Barboza
---
arch/powerpc/platforms/pseries/hotplug-memory.c | 7 +++
1
Hi,
This is a follow-up of the work done in dlpar_cpu_remove() to
report CPU removal error by unisolating the DRC. This time I'm
doing it for LMBs. Patch 01 handles this.
Patches 2 and 3 are cleanups I consider worth posting.
Daniel Henrique Barboza (3):
powerpc/pseries: Set UNISOLATE
On 3/19/21 8:26 AM, Michael Ellerman wrote:
Daniel Henrique Barboza writes:
Ping
On 3/5/21 2:38 PM, Daniel Henrique Barboza wrote:
Of all the reasons that dlpar_cpu_remove() can fail, the 'last online
CPU' is one that can be caused directly by the user offlining CPUs
in a partition
Hey Daniel,
On 3/26/21 2:24 AM, Daniel Axtens wrote:
Hi Daniel,
Two small nitpicks:
This patch adds a 'last online' check in dlpar_cpu_offline() to catch
the 'last online CPU' offline error, eturning a more informative error
^---
the verification code from dlpar_cpu_remove() to
dlpar_cpu_offline(), while holding cpu_add_remove_lock
- reworded the commit message and code comment
v1 link:
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20210305173845.451158-1-danielhb...@gmail.com/
Daniel Henrique Barboza (1):
hotplug
U' offline error, returning a more informative error
message:
pseries-hotplug-cpu: Unable to remove last online CPU PowerPC,POWER9
[1] https://bugzilla.redhat.com/1911414
Signed-off-by: Daniel Henrique Barboza
---
arch/powerpc/platforms/pseries/hotplug-cpu.c | 14 ++
1 file c
-danielhb...@gmail.com/
Daniel Henrique Barboza (1):
hotplug-cpu.c: show 'last online CPU' error in dlpar_cpu_offline()
arch/powerpc/platforms/pseries/hotplug-cpu.c | 13 +
1 file changed, 13 insertions(+)
--
2.30.2
U' offline error, eturning a more informative error
message:
pseries-hotplug-cpu: Unable to remove last online CPU PowerPC,POWER9
[1] https://bugzilla.redhat.com/1911414
Signed-off-by: Daniel Henrique Barboza
---
arch/powerpc/platforms/pseries/hotplug-cpu.c | 13 +
1 file changed, 13
On 3/18/21 10:42 AM, Srikar Dronamraju wrote:
* Daniel Henrique Barboza [2021-03-17 10:00:34]:
Hello,
Patch 4bce545903fa ("powerpc/topology: Update topology_core_cpumask") introduced
a regression in both upstream and RHEL downstream kernels [1]. The assumption
made
in
Ping
On 3/5/21 2:38 PM, Daniel Henrique Barboza wrote:
Of all the reasons that dlpar_cpu_remove() can fail, the 'last online
CPU' is one that can be caused directly by the user offlining CPUs
in a partition/virtual machine that has hotplugged CPUs. Trying to
reclaim a hotplugged CPU can fail
On 3/18/21 4:28 AM, Cédric Le Goater wrote:
Also we've been using it for several years and I don't think we should
risk breaking anything by changing the value now.
I guess we can leave it that way. Please read the commit log of
the second patch (not tagged as a v2 ...).
But we should
Hello,
Patch 4bce545903fa ("powerpc/topology: Update topology_core_cpumask") introduced
a regression in both upstream and RHEL downstream kernels [1]. The assumption
made
in the commit:
"Further analysis shows that cpu_core_mask and cpu_cpu_mask for any CPU would be
equal on Power"
Doesn't
On 3/17/21 12:30 PM, Cédric Le Goater wrote:
On 3/17/21 2:00 PM, Daniel Henrique Barboza wrote:
Hello,
Patch 4bce545903fa ("powerpc/topology: Update topology_core_cpumask") introduced
a regression in both upstream and RHEL downstream kernels [1]. The assumption
made
in
On 3/9/21 12:33 PM, Cédric Le Goater wrote:
On 3/8/21 6:13 PM, Greg Kurz wrote:
On Wed, 3 Mar 2021 18:48:50 +0100
Cédric Le Goater wrote:
The 'chip_id' field of the XIVE CPU structure is used to choose a
target for a source located on the same chip when possible. This field
is assigned on
ibm,chip-id
in QEMU is matching the socket-id. After this patch,
topology_physical_package_id()
will now match the NUMA id of the CPU.
Reviewed-by: Daniel Henrique Barboza
Tested-by: Daniel Henrique Barboza
Cc: Nathan Lynch
Cc: Srikar Dronamraju
Cc: Vasant Hegde
Signed-off-by: Cédric L
On 3/15/21 1:16 PM, Cédric Le Goater wrote:
On 3/15/21 4:12 PM, Daniel Henrique Barboza wrote:
On 3/12/21 11:31 AM, Cédric Le Goater wrote:
Initial commit 15863ff3b8da ("powerpc: Make chip-id information
available to userspace") introduce a cpu_to_chip_id() routine for t
On 3/12/21 6:53 AM, Cédric Le Goater wrote:
On 3/12/21 2:55 AM, David Gibson wrote:
On Tue, 9 Mar 2021 18:26:35 +0100
Cédric Le Goater wrote:
On 3/9/21 6:08 PM, Daniel Henrique Barboza wrote:
On 3/9/21 12:33 PM, Cédric Le Goater wrote:
On 3/8/21 6:13 PM, Greg Kurz wrote:
On Wed, 3
by: Daniel Henrique Barboza
---
arch/powerpc/platforms/pseries/hotplug-cpu.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c
b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index 12cbffd3c2e3..134f393f09e1 100644
--- a/ar
this up, Srikar. For all patches:
Tested-by: Daniel Henrique Barboza
On 4/15/21 9:09 AM, Srikar Dronamraju wrote:
Daniel had reported that
QEMU is now unable to see requested topologies in a multi socket single
NUMA node configurations.
-smp 8,maxcpus=8,cores=2,threads=2,sockets=2
On 4/19/21 9:48 AM, Michael Ellerman wrote:
Daniel Henrique Barboza writes:
The RTAS set-indicator call, when attempting to UNISOLATE a DRC that is
already UNISOLATED or CONFIGURED, returns RTAS_OK and does nothing else
for both QEMU and phyp. This gives us an opportunity to use
done for this event
only because its the only CPU removal event QEMU uses, and there's no
need at this moment to add this mechanism for phyp only code.
Signed-off-by: Daniel Henrique Barboza
---
arch/powerpc/platforms/pseries/hotplug-cpu.c | 9 -
1 file changed, 8 insertions(+), 1
u.org/archive/html/qemu-devel/2021-02/msg06395.html
[3] https://github.com/danielhb/qemu/tree/unisolate_drc_callback_v1
Daniel Henrique Barboza (2):
dlpar.c: introduce dlpar_unisolate_drc()
hotplug-cpu.c: set UNISOLATE on dlpar_cpu_remove() failure
arch/powerpc/platforms/pseries/dlpar.c |
Next patch will execute a set-indicator call in hotplug-cpu.c.
Create a dlpar_unisolate_drc() helper to avoid spreading more
rtas_set_indicator() calls outside of dlpar.c.
Signed-off-by: Daniel Henrique Barboza
---
arch/powerpc/platforms/pseries/dlpar.c | 14 ++
arch/powerpc
Aneesh,
This series compiles with a configuration made with "pseries_le_defconfig"
but fails with a config based on an existing RHEL8 config.
The reason, which is hinted in the robot replies in patch 4, is that you defined
a "__vphn_get_associativity" inside a #ifdef CONFIG_PPC_SPLPAR guard but
val=255 -numa
dist,src=4,dst=2,val=255 -numa dist,src=4,dst=3,val=230 \
-object
memory-backend-file,id=memnvdimm1,prealloc=yes,mem-path=$PMEM_DISK,share=yes,size=${PMEM_SIZE}
\
-device
nvdimm,label-size=128K,memdev=memnvdimm1,id=nvdimm1,slot=4,uuid=72511b67-0b3b-42fd-8d1d-5be3cae8bcaa,node=4
Q
t it since it doesn't make sense
with the current codebase.
Reviewed-by: Daniel Henrique Barboza
Remove it to prevent confusion.
Signed-off-by: Nathan Lynch
---
arch/powerpc/platforms/pseries/hotplug-cpu.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/powerpc/platforms/pseri
this will not solve the crash for kernels with
panic_on_warn, but at least it will panic with a clearer message on those
and will not panic for everyone else.
Reviewed-by: Daniel Henrique Barboza
arch/powerpc/kernel/sysfs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch
/removals of the same CPU,
and no issues found with these new pseries_cpuhp* functions.
Code LGTM as well.
Reviewed-by: Daniel Henrique Barboza
Tested-by: Daniel Henrique Barboza
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c
b/arch/powerpc/platforms/pseries/hotplug-cpu.c
support for drc-info
property")
---
Tested with a QEMU pseries guest, no issues found.
Reviewed-by: Daniel Henrique Barboza
Tested-by: Daniel Henrique Barboza
arch/powerpc/platforms/pseries/hotplug-cpu.c | 218 +--
1 file changed, 2 insertions(+), 216 deletions(-
yless node 0")
Signed-off-by: Daniel Henrique Barboza
---
arch/powerpc/mm/numa.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 9d5f710d2c20..b9b7fefbb64b 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/
Hi,
I tried this series out with mainline QEMU built with Alexey's patch [1]
and I wasn't able to get it to work. I'm using a simple QEMU command line
booting a fedora36 guest in a Power9 boston host:
sudo ./qemu-system-ppc64 \
-M
it up from there.
[1]
https://patchwork.ozlabs.org/project/qemu-ppc/patch/20220608030153.1862335-1-...@ozlabs.ru/
Thanks,
Daniel
On 6/15/22 22:43, Daniel Henrique Barboza wrote:
Hi,
I tried this series out with mainline QEMU built with Alexey's patch [1]
and I wasn't able to get it to work
On 6/16/22 13:44, Tyrel Datwyler wrote:
On 6/15/22 18:43, Daniel Henrique Barboza wrote:
Hi,
I tried this series out with mainline QEMU built with Alexey's patch [1]
and I wasn't able to get it to work. I'm using a simple QEMU command line
booting a fedora36 guest in a Power9 boston host
ux.ibm.com/
Tested successfully with mainline QEMU plus Alexey's new h_watchdog patches in
https://patchwork.ozlabs.org/project/qemu-ppc/list/?series=305226.
All patches of this series:
Tested-by: Daniel Henrique Barboza
Thanks,
Daniel
Changes of note from PATCH v1:
- Trim down the lar
On 11/30/22 17:45, Crystal Wood wrote:
On Mon, 2022-11-28 at 14:36 +1000, Nicholas Piggin wrote:
BookE KVM is in a deep maintenance state, I'm not sure how much testing
it gets. I don't have a test setup, and it does not look like QEMU has
any HV architecture enabled. It hasn't been too
67 matches
Mail list logo
