Le 07/04/2021 à 17:38, Laurent Dufour a écrit :
When a CPU is hot added, the CPU ids are taken from the available mask from
the lower possible set. If that set of values was previously used for CPU
attached to a different node, this seems to application like if these CPUs
have migrated from
Signed-off-by: Laurent Dufour
---
arch/powerpc/platforms/pseries/hotplug-cpu.c | 52 ++--
1 file changed, 47 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c
b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index ec478f8a98ff..cddf6d2db786
Le 07/04/2021 à 16:55, Nathan Lynch a écrit :
Laurent Dufour writes:
Changes since V2, addressing Nathan's comments:
- Remove the retry feature
- Reduce the number of local variables (removing 'i')
I was more interested in not having two variables for NUMA nodes in the
function named
the cpu_add_remove_lock protecting the added CPU mask.
Changes since V1 (no functional changes):
- update the test's output in the commit's description
- node_recorded_ids_map should be static
Signed-off-by: Laurent Dufour
---
arch/powerpc/platforms/pseries/hotplug-cpu.c | 51 ++--
1
Thanks Nathan for reviewing this.
Le 02/04/2021 à 15:34, Nathan Lynch a écrit :
Hi Laurent,
Laurent Dufour writes:
When a CPU is hot added, the CPU ids are taken from the available mask from
the lower possible set. If that set of values was previously used for CPU
attached to a different
ode. Thanks!
Cc: Andrei Vagin
Cc: Andy Lutomirski
Cc: Benjamin Herrenschmidt
Cc: Christophe Leroy
Cc: Laurent Dufour
Cc: Michael Ellerman
Cc: Paul Mackerras
Cc: linuxppc-...@lists.ozlabs.org
Cc: sta...@vger.kernel.org # v5.11
[1]: https://github.com/checkpoint-restore/criu/issues/1417
Signed-
the commit 511157ab641e is ABI
regression as no other userspace got broken, but I'd really appreciate
if it gets backported to v5.11 after v5.12 is released, so as not
to complicate already non-simple CRIU-vdso code. Thanks!
Cc: Andrei Vagin
Cc: Andy Lutomirski
Cc: Benjamin Herrenschmidt
Cc: Christophe
44 45 46 47
Changes since V1 (no functional changes):
- update the test's output in the commit's description
- node_recorded_ids_map should be static
Signed-off-by: Laurent Dufour
---
arch/powerpc/platforms/pseries/hotplug-cpu.c | 83 ++--
1 file changed, 76 insertions(+), 7
cpus: 24 25 26 27 28 29 30 31
node 2 cpus: 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
Signed-off-by: Laurent Dufour
---
arch/powerpc/platforms/pseries/hotplug-cpu.c | 83 ++--
1 file changed, 76 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/hotplug
It is better to rely on the API provided by the MM layer instead of
directly manipulating the mm_users field.
Signed-off-by: Laurent Dufour
---
drivers/misc/cxl/fault.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/cxl/fault.c b/drivers/misc/cxl/fault.c
index
-by: Laurent Dufour
---
arch/powerpc/include/asm/hvcall.h| 1 +
arch/powerpc/platforms/pseries/lparcfg.c | 2 ++
arch/powerpc/platforms/pseries/pseries.h | 1 +
arch/powerpc/platforms/pseries/setup.c | 8
4 files changed, 12 insertions(+)
diff --git a/arch/powerpc/include/asm
Le 05/03/2021 à 12:43, Michael Ellerman a écrit :
Laurent Dufour writes:
Le 05/03/2021 à 07:23, Michael Ellerman a écrit :
Laurent Dufour writes:
This is helpful to read the security flavor from inside the LPAR.
We already have /sys/kernel/debug/powerpc/security_features
Le 05/03/2021 à 07:23, Michael Ellerman a écrit :
Laurent Dufour writes:
This is helpful to read the security flavor from inside the LPAR.
We already have /sys/kernel/debug/powerpc/security_features.
Is that not sufficient?
Not really, it only reports that security mitigation
Speculative execution controls to mitigate user-to-kernel and
user-to-user side-channel attacks
Signed-off-by: Laurent Dufour
---
arch/powerpc/include/asm/hvcall.h| 1 +
arch/powerpc/platforms/pseries/lparcfg.c | 2 ++
arch/powerpc/platforms/pseries/pseries.h | 1 +
arch/powerpc
Le 12/01/2021 à 17:57, Peter Zijlstra a écrit :
On Tue, Jan 12, 2021 at 04:47:17PM +0100, Laurent Dufour wrote:
Le 12/01/2021 à 12:43, Vinayak Menon a écrit :
Possibility of race against other PTE modifiers
1) Fork - We have seen a case of SPF racing with fork marking PTEs RO
Le 12/01/2021 à 12:43, Vinayak Menon a écrit :
On 1/5/2021 9:07 PM, Peter Zijlstra wrote:
On Mon, Dec 21, 2020 at 08:16:11PM -0800, Linus Torvalds wrote:
So I think the basic rule is that "if you hold mmap_sem for writing,
you're always safe". And that really should be considered the
Le 14/12/2020 à 03:03, Joel Fernandes a écrit :
On Tue, Jul 07, 2020 at 01:31:37PM +0800, Chinwen Chang wrote:
[..]
Hi Laurent,
We merged SPF v11 and some patches from v12 into our platforms. After
several experiments, we observed SPF has obvious improvements on the
launch time of
Le 12/12/2020 à 16:04, Souptick Joarder a écrit :
On Fri, Dec 11, 2020 at 8:32 PM Laurent Dufour wrote:
On PowerPC, when dymically removing memory from a system we can see in the
console a
lot of messages like this:
[ 186.575389] Offlined Pages 4096
Is it specific to PowerPC
it to DEBUG to not flood the console.
Signed-off-by: Laurent Dufour
---
mm/memory_hotplug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index b44d4c7ba73b..c47a53a16782 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
f memory and LMB size is 256MB, this leads to 4096
messages to be displayed on the console. These messages are not really
helpful for the end user, so moving them to the DEBUG level.
Signed-off-by: Laurent Dufour
---
arch/powerpc/platforms/pseries/hotplug-memory.c | 12 ++--
1 fi
Le 03/12/2020 à 19:25, Greg KH a écrit :
On Thu, Dec 03, 2020 at 11:15:14AM +0100, Laurent Dufour wrote:
This patch applies to 5.9 and earlier kernels only.
Since 5.10, this has been fortunately fixed by the commit
e5e179aa3a39 ("pseries/drmem: don't cache node id in drmem_lmb struct&quo
ue, simply set that flag earlier in dlpar_add_lmb().
Note, this code has been rewrote in 5.10 and thus this fix has no meaning
since this version.
Signed-off-by: Laurent Dufour
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Nathan Lynch
Cc: Scott Cheloha
Cc
Le 03/11/2020 à 22:08, Dmitry Safonov a écrit :
Hi Laurent, Christophe, Michael, all,
On 11/3/20 5:11 PM, Laurent Dufour wrote:
Le 23/10/2020 à 14:28, Christophe Leroy a écrit :
[..]
That seems like it would work for CRIU and make sense in general?
Sorry for the late answer, yes this would
ables from arch/powerpc/kernel/vdso.c.
Fixes: 83d3f0e90c6c ("powerpc/mm: tracking vDSO remap")
Signed-off-by: Laurent Dufour
Reported-by: Thomas Gleixner
Suggested-by: Christophe Leroy
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
---
arch/powerpc/include/as
Le 23/10/2020 à 14:28, Christophe Leroy a écrit :
Hi Laurent
Le 07/05/2019 à 18:35, Laurent Dufour a écrit :
Le 01/05/2019 à 12:32, Michael Ellerman a écrit :
Laurent Dufour writes:
Le 23/04/2019 à 18:04, Dave Hansen a écrit :
On 4/23/19 4:16 AM, Laurent Dufour wrote:
...
There are 2
Le 28/10/2020 à 12:11, Christopher Lameter a écrit :
On Tue, 27 Oct 2020, Laurent Dufour wrote:
The issue is that object is not NULL while page is NULL which is odd but
may happen if the cache flush happened after loading object but before
loading page. Thus checking for the page pointer
ular case, so check for page before calling node_match() here.
Fixes: 6159d0f5c03e ("mm/slub.c: page is always non-NULL in node_match()")
Signed-off-by: Laurent Dufour
Acked-by: Vlastimil Babka
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Joonsoo Kim
Cc: Andrew Morton
particular case, so check for page before calling node_match() here.
Fixes: 6159d0f5c03e ("mm/slub.c: page is always non-NULL in node_match()")
Signed-off-by: Laurent Dufour
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: David Rientjes
Cc: Joonsoo Kim
Cc: Andrew Morton
Cc: sta...@vg
Le 27/10/2020 à 16:03, Michal Hocko a écrit :
On Tue 27-10-20 15:39:46, Laurent Dufour wrote:
Le 27/10/2020 à 15:24, Michal Hocko a écrit :
[Cc Vlastimil]
On Tue 27-10-20 15:09:26, Laurent Dufour wrote:
While doing memory hot-unplug operation on a PowerPC VM running 1024 CPUs
with 11TB
Le 27/10/2020 à 15:24, Michal Hocko a écrit :
[Cc Vlastimil]
On Tue 27-10-20 15:09:26, Laurent Dufour wrote:
While doing memory hot-unplug operation on a PowerPC VM running 1024 CPUs
with 11TB of ram, I hit the following panic:
BUG: Kernel NULL pointer dereference on read at 0x0007
Le 17/09/2020 à 01:37, Andrew Morton a écrit :
On Wed, 16 Sep 2020 18:09:55 +0200 Laurent Dufour wrote:
It's up to the maintainer what they want, but as it is, this patch is
not going to end up in stable kernel release (which it looks like is the
right thing to do...)
Thanks a lot Greg
Le 16/09/2020 à 09:52, David Hildenbrand a écrit :
On 16.09.20 09:47, Laurent Dufour wrote:
Le 16/09/2020 à 09:40, Greg Kroah-Hartman a écrit :
On Wed, Sep 16, 2020 at 09:29:22AM +0200, Laurent Dufour wrote:
Le 16/09/2020 à 08:33, Greg Kroah-Hartman a écrit :
On Tue, Sep 15, 2020 at 03:26
Le 16/09/2020 à 09:40, Greg Kroah-Hartman a écrit :
On Wed, Sep 16, 2020 at 09:29:22AM +0200, Laurent Dufour wrote:
Le 16/09/2020 à 08:33, Greg Kroah-Hartman a écrit :
On Tue, Sep 15, 2020 at 03:26:24PM +0200, Laurent Dufour wrote:
The memmap_context enum is used to detect whether a memory
Le 16/09/2020 à 08:33, Greg Kroah-Hartman a écrit :
On Tue, Sep 15, 2020 at 03:26:24PM +0200, Laurent Dufour wrote:
The memmap_context enum is used to detect whether a memory operation is due
to a hot-add operation or happening at boot time.
Make it general to the hotplug operation and rename
-off-by: Laurent Dufour
---
arch/ia64/mm/init.c| 6 +++---
include/linux/mm.h | 2 +-
include/linux/mmzone.h | 11 ---
mm/memory_hotplug.c| 2 +-
mm/page_alloc.c| 10 +-
5 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/arch/ia64/mm/init.c b
-by: Laurent Dufour
---
arch/ia64/mm/init.c| 6 +++---
include/linux/mm.h | 2 +-
include/linux/mmzone.h | 11 ---
mm/memory_hotplug.c| 2 +-
mm/page_alloc.c| 10 +-
5 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/arch/ia64/mm/init.c b/arch
dev=memdimm6,id=dimm6,slot=6 \
Fixes: 4fbce633910e ("mm/memory_hotplug.c: make register_mem_sect_under_node()
a callback of walk_memory_range()")
Signed-off-by: Laurent Dufour
Reviewed-by: David Hildenbrand
Cc: sta...@vger.kernel.org
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wyso
of memory blocks managed could be high, the messages are
rate limited.
As a consequence, link_mem_sections() has no status to report anymore.
Signed-off-by: Laurent Dufour
Acked-by: Michal Hocko
Acked-by: David Hildenbrand
Cc: Greg Kroah-Hartman
---
drivers/base/node.c | 33
Greg's comment
Laurent Dufour (3):
mm: replace memmap_context by memplug_context
mm: don't rely on system state to detect hot-plug operations
mm: don't panic when links can't be created in sysfs
arch/ia64/mm/init.c| 6 +--
drivers/base/node.c| 98
Le 15/09/2020 à 09:23, David Hildenbrand a écrit :
On 14.09.20 18:50, Laurent Dufour wrote:
At boot time, or when doing memory hot-add operations, if the links in
sysfs can't be created, the system is still able to run, so just report the
error in the kernel log rather than BUG_ON
Le 14/09/2020 à 19:15, David Hildenbrand a écrit :
arch/ia64/mm/init.c | 4 +--
drivers/base/node.c | 86
include/linux/node.h | 11 +++---
mm/memory_hotplug.c | 5 +--
4 files changed, 68 insertions(+), 38 deletions(-)
diff --git
Le 14/09/2020 à 19:10, David Hildenbrand a écrit :
On 14.09.20 18:50, Laurent Dufour wrote:
The memmap_context is used to detect whether a memory operation is due to a
hot-add operation or happening at boot time.
Make it general to the hotplug operation and rename it at memplug_context
-by: Laurent Dufour
---
arch/ia64/mm/init.c| 6 +++---
include/linux/mm.h | 2 +-
include/linux/mmzone.h | 11 ---
mm/memory_hotplug.c| 2 +-
mm/page_alloc.c| 10 +-
5 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/arch/ia64/mm/init.c b/arch
of this series.
The patch 3 is addressing the point b.
Thanks,
Laurent
Since v1:
- change context enum's name from Michal's comment
- use 2 callbacks in link_mem_sections from David's comment
- use dev_err_ratelimited from Greg's comment
Laurent Dufour (3):
mm: replace memmap_context by mempl
of memory blocks managed could be high, the messages are
rate limited.
As a consequence, link_mem_sections() has no status to report anymore.
Signed-off-by: Laurent Dufour
Acked-by: Michal Hocko
Cc: David Hildenbrand
Cc: Greg Kroah-Hartman
---
drivers/base/node.c | 33
dev=memdimm6,id=dimm6,slot=6 \
Fixes: 4fbce633910e ("mm/memory_hotplug.c: make register_mem_sect_under_node()
a callback of walk_memory_range()")
Signed-off-by: Laurent Dufour
Reviewed-by: David Hildenbrand
Cc: sta...@vger.kernel.org
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wyso
Le 14/09/2020 à 10:31, David Hildenbrand a écrit :
static int register_mem_sect_under_node_hotplug(struct memory_block *mem_blk,
void *arg)
{
const int nid = *(int *)arg;
int ret;
/* Hotplugged memory has no holes and
Le 14/09/2020 à 10:49, Michal Hocko a écrit :
On Fri 11-09-20 15:48:29, Laurent Dufour wrote:
The memmap_context is used to detect whether a memory operation is due to a
hot-add operation or happening at boot time.
Makes it general to the hotplug operation, renaming it at memplug_context
Le 14/09/2020 à 10:19, Oscar Salvador a écrit :
On Mon, Sep 14, 2020 at 09:57:46AM +0200, David Hildenbrand wrote:
/* register memory section under specified node if it spans that node */
+struct rmsun_args {
+ int nid;
+ enum memplug_context context;
+};
Uhmf, that is a not so
Le 14/09/2020 à 09:57, David Hildenbrand a écrit :
On 11.09.20 15:48, Laurent Dufour wrote:
In register_mem_sect_under_node() the system_state’s value is checked to
detect whether the operation the call is made during boot time or during an
hot-plug operation. Unfortunately, that check against
ling whether the
operation is due to a hot-plug operation.
Fixes: 4fbce633910e ("mm/memory_hotplug.c: make register_mem_sect_under_node()
a callback of walk_memory_range()")
Signed-off-by: Laurent Dufour
Cc: sta...@vger.kernel.org
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Cc:
Le 11/09/2020 à 16:01, Greg Kroah-Hartman a écrit :
On Fri, Sep 11, 2020 at 03:48:31PM +0200, Laurent Dufour wrote:
At boot time, or when doing memory hot-add operations, if the links in
sysfs can't be created, the system is still able to run, so just report the
error in the kernel log.
Since
() has no status to report anymore.
Signed-off-by: Laurent Dufour
Cc: David Hildenbrand
---
drivers/base/node.c | 25 +
include/linux/node.h | 17 -
mm/memory_hotplug.c | 5 ++---
3 files changed, 27 insertions(+), 20 deletions(-)
diff --git a/drivers
Le 11/09/2020 à 16:59, David Hildenbrand a écrit :
struct page *start;
struct memmap_init_callback_data args;
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index 375515803cd8..cd2bd21d3a4d 100644
--- a/include/linux/memory_hotplug.h
by this patch
Suggested-by: David Hildenbrand
Signed-off-by: Laurent Dufour
---
arch/ia64/mm/init.c| 6 +++---
include/linux/memory_hotplug.h | 9 +
include/linux/mm.h | 2 +-
include/linux/mmzone.h | 4
mm/memory_hotplug.c| 2 +-
mm
of this series.
The patch 3 is addressing the point b.
Laurent Dufour (3):
mm: replace memmap_context by memplug_context
mm: don't rely on system state to detect hot-plug operations
mm: don't panic when links can't be created in sysfs
arch/ia64/mm/init.c| 6 ++---
driv
Le 10/09/2020 à 13:12, Michal Hocko a écrit :
On Thu 10-09-20 09:51:39, Laurent Dufour wrote:
Le 10/09/2020 à 09:23, Michal Hocko a écrit :
On Wed 09-09-20 18:07:15, Laurent Dufour wrote:
Le 09/09/2020 à 12:59, Michal Hocko a écrit :
On Wed 09-09-20 11:21:58, Laurent Dufour wrote
Le 10/09/2020 à 14:00, David Hildenbrand a écrit :
On 10.09.20 13:35, Laurent Dufour wrote:
Le 10/09/2020 à 13:12, Michal Hocko a écrit :
On Thu 10-09-20 09:51:39, Laurent Dufour wrote:
Le 10/09/2020 à 09:23, Michal Hocko a écrit :
On Wed 09-09-20 18:07:15, Laurent Dufour wrote:
Le 09/09
Le 10/09/2020 à 14:03, Oscar Salvador a écrit :
On Thu, Sep 10, 2020 at 01:35:32PM +0200, Laurent Dufour wrote:
That points has been raised by David, quoting him here:
IIRC, ACPI can hotadd memory while SCHEDULING, this patch would break that.
Ccing Oscar, I think he mentioned recently
Le 10/09/2020 à 09:23, Michal Hocko a écrit :
On Wed 09-09-20 18:07:15, Laurent Dufour wrote:
Le 09/09/2020 à 12:59, Michal Hocko a écrit :
On Wed 09-09-20 11:21:58, Laurent Dufour wrote:
[...]
For the point a, using the enum allows to know in
register_mem_sect_under_node() if the link
Le 09/09/2020 à 12:59, Michal Hocko a écrit :
On Wed 09-09-20 11:21:58, Laurent Dufour wrote:
Le 09/09/2020 à 11:09, Michal Hocko a écrit :
On Wed 09-09-20 09:48:59, Laurent Dufour wrote:
Le 09/09/2020 à 09:40, Michal Hocko a écrit :
[...]
In
that case, the system is able to boot but later
Le 09/09/2020 à 11:24, David Hildenbrand a écrit :
I am not sure an enum is going to make the existing situation less
messy. Sure we somehow have to distinguish boot init and runtime hotplug
because they have different constrains. I am arguing that a) we should
have a consistent way to check for
Le 09/09/2020 à 11:09, Michal Hocko a écrit :
On Wed 09-09-20 09:48:59, Laurent Dufour wrote:
Le 09/09/2020 à 09:40, Michal Hocko a écrit :
[reposting because the malformed cc list confused my email client]
On Tue 08-09-20 19:08:35, Laurent Dufour wrote:
In register_mem_sect_under_node
Le 09/09/2020 à 09:40, Michal Hocko a écrit :
[reposting because the malformed cc list confused my email client]
On Tue 08-09-20 19:08:35, Laurent Dufour wrote:
In register_mem_sect_under_node() the system_state’s value is checked to
detect whether the operation the call is made during boot
Le 03/09/2020 à 23:35, Andrew Morton a écrit :
On Wed, 2 Sep 2020 11:09:11 +0200 Laurent Dufour wrote:
register_mem_sect_under_nodem() is checking the memory block's node id only
if the system state is "SYSTEM_BOOTING". On PowerPC, the memory blocks are
registered while the sy
king done for states
prior to SYSTEM_RUNNING.
Signed-off-by: Laurent Dufour
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Cc: Andrew Morton
Fixes: 4fbce633910e ("mm/memory_hotplug.c: make register_mem_sect_under_node()
a callback of walk_memory_range()")
---
drivers/b
a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Laurent-Dufour/powerpc-drmem-Don-t-compute-the-NUMA-node-for-each-LMB/20200805-173213
base: https://git.kernel.org/pub/scm/linux
starting large guests
Code has meaning only if CONFIG_MEMORY_HOTPLUG is set, otherwise the nid
field is not present in the drmem_lmb structure.
Signed-off-by: Laurent Dufour
---
arch/powerpc/mm/drmem.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git
starting large guests
Signed-off-by: Laurent Dufour
---
arch/powerpc/mm/drmem.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/drmem.c b/arch/powerpc/mm/drmem.c
index b2eeea39684c..3819c523c65b 100644
--- a/arch/powerpc/mm/drmem.c
+++ b
Le 23/07/2020 à 14:32, Laurent Dufour a écrit :
Le 23/07/2020 à 05:36, Bharata B Rao a écrit :
On Tue, Jul 21, 2020 at 12:42:02PM +0200, Laurent Dufour wrote:
When a secure memslot is dropped, all the pages backed in the secure device
(aka really backed by secure memory by the Ultravisor
Le 23/07/2020 à 05:36, Bharata B Rao a écrit :
On Tue, Jul 21, 2020 at 12:42:02PM +0200, Laurent Dufour wrote:
When a secure memslot is dropped, all the pages backed in the secure device
(aka really backed by secure memory by the Ultravisor) should be paged out
to a normal page. Previously
Le 21/07/2020 à 23:37, Ram Pai a écrit :
On Tue, Jul 21, 2020 at 12:42:02PM +0200, Laurent Dufour wrote:
When a secure memslot is dropped, all the pages backed in the secure device
(aka really backed by secure memory by the Ultravisor) should be paged out
to a normal page. Previously
uce a wrapper which call that
function with the lock held.
There is no functional change.
Cc: Ram Pai
Cc: Bharata B Rao
Cc: Paul Mackerras
Signed-off-by: Laurent Dufour
---
arch/powerpc/kvm/book3s_hv_uvmem.c | 166 -
1 file changed, 90 insertions(+), 76 deletions(-)
d
e.
Cc: Ram Pai
Cc: Bharata B Rao
Cc: Paul Mackerras
Signed-off-by: Laurent Dufour
---
arch/powerpc/kvm/book3s_hv_uvmem.c | 54 --
1 file changed, 37 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c
b/arch/powerpc/kvm/book3s_hv_uvmem.c
V4 series
- Address Bharata's comment to use mmap_read_*lock().
Laurent Dufour (2):
KVM: PPC: Book3S HV: move kvmppc_svm_page_out up
KVM: PPC: Book3S HV: rework secure mem slot dropping
arch/powerpc/kvm/book3s_hv_uvmem.c | 220 +
1 file changed, 127 insertions(+), 93
Le 08/07/2020 à 13:25, Bharata B Rao a écrit :
On Fri, Jul 03, 2020 at 05:59:14PM +0200, Laurent Dufour wrote:
When a secure memslot is dropped, all the pages backed in the secure device
(aka really backed by secure memory by the Ultravisor) should be paged out
to a normal page. Previously
, 2019 at 10:44:47AM +0200, Laurent Dufour wrote:
Le 14/06/2019 à 10:37, Laurent Dufour a écrit :
Please find attached the script I run to get these numbers.
This would be nice if you could give it a try on your victim node and share the
result.
Sounds that the Intel mail fitering system doesn't
of the memslot is not interfering on the page out process.
This series applies on top of the Ram's one titled:
"PATCH v3 0/4] Migrate non-migrated pages of a SVM."
https://lore.kernel.org/linuxppc-dev/1592606622-29884-1-git-send-email-linux...@us.ibm.com/#r
Laurent Dufour (2):
KVM: PPC: Book3
e.
Cc: Ram Pai
Cc: Bharata B Rao
Cc: Paul Mackerras
Signed-off-by: Laurent Dufour
---
arch/powerpc/kvm/book3s_hv_uvmem.c | 54 --
1 file changed, 37 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c
b/arch/powerpc/kvm/book3s_hv_uvmem.c
uce a wrapper which call that
function with the lock held.
There is no functional change.
Cc: Ram Pai
Cc: Bharata B Rao
Cc: Paul Mackerras
Signed-off-by: Laurent Dufour
---
arch/powerpc/kvm/book3s_hv_uvmem.c | 166 -
1 file changed, 90 insertions(+), 76 deletions(-)
d
c: Laurent Dufour
Cc: Michael Ellerman
Reviewed-by: Thiago Jung Bauermann
Reviewed-by: Laurent Dufour
Signed-off-by: Satheesh Rajendran
---
V2:
Added reviewed by Thiago.
Dropped align argument as per Michael suggest.
Modified commit msg.
V1:
http://patchwork.ozlabs.org/project/linuxppc
]
[0.00] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
which is not necessary, let's remove it.
Reviewed-by: Laurent Dufour
Cc: linux-kernel@vger.kernel.org
Cc: Thiago Jung Bauermann
Cc: Ram Pai
Cc: Sukadev Bhattiprolu
Cc: Laurent Dufour
Signed-off-by: Satheesh Rajendran
Le 27/05/2020 à 06:16, Paul Mackerras a écrit :
On Wed, May 20, 2020 at 07:43:08PM +0200, Laurent Dufour wrote:
The commit 8c47b6ff29e3 ("KVM: PPC: Book3S HV: Check caller of H_SVM_*
Hcalls") added checks of secure bit of SRR1 to filter out the Hcall
reserved to the Ultravisor
Paul, could you please take that patch?
Le 16/04/2020 à 18:27, Laurent Dufour a écrit :
The newly introduced ibm,secure-memory nodes supersede the
ibm,uv-firmware's property secure-memory-ranges.
Firmware will no more expose the secure-memory-ranges property so first
read the new one
in that case.
Fixes: 8c47b6ff29e3 ("KVM: PPC: Book3S HV: Check caller of H_SVM_* Hcalls")
Signed-off-by: Laurent Dufour
---
arch/powerpc/kvm/book3s_hv.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_
Le 20/05/2020 à 19:32, Greg Kurz a écrit :
On Wed, 20 May 2020 18:51:10 +0200
Laurent Dufour wrote:
The commit 8c47b6ff29e3 ("KVM: PPC: Book3S HV: Check caller of H_SVM_*
Hcalls") added checks of secure bit of SRR1 to filter out the Hcall
reserved to the Ultravisor.
However,
in that case.
Fixes: 8c47b6ff29e3 ("KVM: PPC: Book3S HV: Check caller of H_SVM_* Hcalls")
Signed-off-by: Laurent Dufour
---
arch/powerpc/kvm/book3s_hv.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_
Le 19/05/2020 à 15:10, Michel Lespinasse a écrit :
On Mon, May 18, 2020 at 03:45:22PM +0200, Laurent Dufour wrote:
Le 24/04/2020 à 03:39, Michel Lespinasse a écrit :
Rename the mmap_sem field to mmap_lock. Any new uses of this lock
should now go through the new mmap locking api. The mmap_lock
Le 24/04/2020 à 03:39, Michel Lespinasse a écrit :
Rename the mmap_sem field to mmap_lock. Any new uses of this lock
should now go through the new mmap locking api. The mmap_lock is
still implemented as a rwsem, though this could change in the future.
Signed-off-by: Michel Lespinasse
---
).mmap_sem in the
MMAP_LOCK_INITIALIZER macro,
Reviewed-by: Laurent Dufour
---
arch/x86/kernel/tboot.c| 2 +-
drivers/firmware/efi/efi.c | 2 +-
include/linux/mmap_lock.h | 3 +++
mm/init-mm.c | 2 +-
4 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch
Le 22/04/2020 à 02:14, Michel Lespinasse a écrit :
Add API for nested write locks and convert the few call sites doing that.
Signed-off-by: Michel Lespinasse
Reviewed-by: Daniel Jordan
Reviewed-by: Laurent Dufour
---
arch/um/include/asm/mmu_context.h | 3 ++-
include/linux/mmap_lock.h
-by: Michel Lespinasse
Reviewed-by: Daniel Jordan
Reviewed-by: Laurent Dufour
---
arch/mips/mm/fault.c | 10 +-
arch/riscv/mm/pageattr.c | 4 ++--
arch/x86/kvm/mmu/paging_tmpl.h | 8
drivers/android/binder_alloc.c | 4 ++--
fs/proc/base.c | 6
Le 22/04/2020 à 02:14, Michel Lespinasse a écrit :
This use is converted manually ahead of the next patch in the series,
as it requires including a new header which the automated conversion
would miss.
Signed-off-by: Michel Lespinasse
Reviewed-by: Daniel Jordan
Reviewed-by: Laurent Dufour
of any other rwsems.
- In the future, it may be a starting point for replacing the rwsem
implementation with a different one, such as range locks.
Signed-off-by: Michel Lespinasse
Reviewed-by: Daniel Jordan
Reviewed-by: Davidlohr Bueso
Reviewed-by: Laurent Dufour
---
include/linux/mm.h
Reviewed-by: Laurent Dufour
---
include/linux/mmu_notifier.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index 736f6918335e..2f462710a1a4 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux
Read TLB Block Invalidate
Characteristics")
Reported-by: Stephen Rothwell
Signed-off-by: Laurent Dufour
---
arch/powerpc/platforms/pseries/lpar.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/lpar.c
b/arch/powerpc/platforms/pseries/lpar.
s's buffer format
- Introduce #define instead of using direct numerical values
- Function reading the characteristics is now directly called from
pSeries_setup_arch()
- The characteristics are now stored in a dedciated table static to lpar.c
Laurent Dufour (2):
powperc/mm: read TLB Block
pages and hugetlb, the assumption is made that the page size is
equal to the base page size. For THP the page size is assumed to be 16M.
Fixes: ba2dd8a26baa ("powerpc/pseries/mm: call H_BLOCK_REMOVE")
Signed-off-by: Laurent Dufour
---
arch/powerpc/platforms/pseries/lpar.c | 23 ++
the mmu_psize_def because this is specific to
the pseries platform.
A new init function, pseries_lpar_read_hblkrm_characteristics() is added to
read the characteristics. It is called from pSeries_setup_arch().
Fixes: ba2dd8a26baa ("powerpc/pseries/mm: call H_BLOCK_REMOVE")
Signed-off-b
Le 18/09/2019 à 15:42, Michael Ellerman a écrit :
Hi Laurent,
Comments below ...
Hi Michael,
Thanks for your review.
One comment below (at the end).
Laurent Dufour writes:
The PAPR document specifies the TLB Block Invalidate Characteristics which
tells for each couple segment base page
1 - 100 of 1353 matches
Mail list logo
