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 Kardashe
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
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 painf
igned-off-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 10064
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
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
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
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 see
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/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 remov
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 c
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
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
-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
;last online CPU' 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 +
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
^--- s/eturning/returning/;
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
;last online CPU' 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
n on memoryless 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/arc
oking 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,sock
00611.pdf
[2] https://lists.gnu.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/plat
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
being 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 insert
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 this
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 UNISOLA
b() since we're validating all 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/platf
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
aniel 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 1
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 for
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-o
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
elper 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/ps
ting
that the operation we're doing (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/ho
f comments explaining 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 cha
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 for
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
in_common_depth to primary_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
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])
111916.243569-1-aneesh.ku...@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
le CPU add/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-c
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
ctionality")
Fixes: b015f6bc9547 ("powerpc/pseries: Add cpu DLPAR 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-cp
better of without 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/arc
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:
FORM2
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
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
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/ho
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
ng decremented each time a lmb 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/
ady validated 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/ho
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
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
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 -
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 ker
_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
Tested-by: Laurent Vivier
Thanks,
Laurent
FIG_MEMORY_HOTPLUG_DEFAULT_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 hotplu
On 08/01/2017 11:05 AM, Nathan Fontenot wrote:
On 08/01/2017 04:59 AM, Michael Ellerman wrote:
Daniel Henrique Barboza writes:
Commit 943db62c316c ("powerpc/pseries: Revert 'Auto-online
hotplugged memory'") reverted the auto-online feature for pseries due
to problems w
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_o
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 exampl
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
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
pseries,cap-cfpc=broken,cap-sbbc=broken,cap-ibs=broken,cap-ccf-
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 Pow
ng it up in
the QEMU
mailing list in [1] and follow 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
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 th
67 matches
Mail list logo
