/include/linux/damon.h
index 0bd5d6913a6c..72cf5ebd35fe 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -246,4 +246,17 @@ int damon_stop(struct damon_ctx **ctxs, int nr_ctxs);
#endif /* CONFIG_DAMON */
+#ifdef CONFIG_DAMON_VADDR
+
+/* Monitoring primitives for virtual memory
primitives for virtual memory address spaces */
+void damon_va_init(struct damon_ctx *ctx);
+void damon_va_update(struct damon_ctx *ctx);
+void damon_va_prepare_access_checks(struct damon_ctx *ctx);
+unsigned int damon_va_check_accesses(struct damon_ctx *ctx);
+bool damon_va_target_valid(void *t);
+void
On Wed, 31 Mar 2021 16:49:27 +0200 Michal Hocko wrote:
> > Thanks for the clarification! I have suspected this to be the case but
> > I am not really familiar with the interface to have any strong statement
> > here. Maybe we want to document this explicitly.
>
> Btw. Andrew the patch still
ge_protection() has no effect when there is no page table
> > > > entries associated with that virtual memory range (a newly mapped memory
> > > > range). As a result, later access to that memory range causes
> > > > allocating a
> > > > page table entry w
primitives for virtual memory address spaces */
+void damon_va_init(struct damon_ctx *ctx);
+void damon_va_update(struct damon_ctx *ctx);
+void damon_va_prepare_access_checks(struct damon_ctx *ctx);
+unsigned int damon_va_check_accesses(struct damon_ctx *ctx);
+bool damon_va_target_valid(void *t);
+void
From: SeongJae Park
On Thu, 18 Mar 2021 10:08:48 + sj38.p...@gmail.com wrote:
> From: SeongJae Park
>
> This commit introduces a reference implementation of the address space
> specific low level primitives for the virtual address space, so that
> users of DAMON can easily monitor the
> > > > However, change_protection() has no effect when there is no page table
> > > > entries associated with that virtual memory range (a newly mapped memory
> > > > range). As a result, later access to that memory range causes
> > > > allocating a
rotection() to clear write bit in
> > > page table entries (pte/pmd). So, later write to this virtual address
> > > range causes a page fault, which is then handled by userspace program.
> > > However, change_protection() has no effect when there is no page table
> > > entrie
it in
> > > page table entries (pte/pmd). So, later write to this virtual address
> > > range causes a page fault, which is then handled by userspace program.
> > > However, change_protection() has no effect when there is no page table
> > > entries associated
rotection() to clear write bit in
> > > page table entries (pte/pmd). So, later write to this virtual address
> > > range causes a page fault, which is then handled by userspace program.
> > > However, change_protection() has no effect when there is no page table
> > > entrie
this virtual address
> > range causes a page fault, which is then handled by userspace program.
> > However, change_protection() has no effect when there is no page table
> > entries associated with that virtual memory range (a newly mapped memory
> > range). As a result, later
this virtual address
> > range causes a page fault, which is then handled by userspace program.
> > However, change_protection() has no effect when there is no page table
> > entries associated with that virtual memory range (a newly mapped memory
> > range). As a res
e program.
> However, change_protection() has no effect when there is no page table
> entries associated with that virtual memory range (a newly mapped memory
> range). As a result, later access to that memory range causes allocating a
> page table entry with write bit still set (due to V
> However, change_protection() has no effect when there is no page table
> entries associated with that virtual memory range (a newly mapped memory
> range). As a result, later access to that memory range causes allocating a
> page table entry with write bit still set (due to VM_WRITE fl
associated with that virtual memory range (a newly mapped memory
range). As a result, later access to that memory range causes allocating a
page table entry with write bit still set (due to VM_WRITE flag in
vma->vm_flags).
Add checks for VM_UFFD_WP in vma->vm_flags when allocating new page table
/include/linux/damon.h
index 0bd5d6913a6c..72cf5ebd35fe 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -246,4 +246,17 @@ int damon_stop(struct damon_ctx **ctxs, int nr_ctxs);
#endif /* CONFIG_DAMON */
+#ifdef CONFIG_DAMON_VADDR
+
+/* Monitoring primitives for virtual memory
/include/linux/damon.h
index 0bd5d6913a6c..72cf5ebd35fe 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -246,4 +246,17 @@ int damon_stop(struct damon_ctx **ctxs, int nr_ctxs);
#endif /* CONFIG_DAMON */
+#ifdef CONFIG_DAMON_VADDR
+
+/* Monitoring primitives for virtual memory
On Wed, Jan 27, 2021 at 8:57 AM SeongJae Park wrote:
>
> On Thu, 24 Dec 2020 08:11:11 +0100 SeongJae Park wrote:
>
> > On Wed, 23 Dec 2020 14:54:02 -0800 Shakeel Butt wrote:
> >
> > > On Wed, Dec 23, 2020 at 8:47 AM SeongJae Park wrote:
> > > >
> > > [snip]
> > > > > [snip]
> > > > > > +
> > >
On Thu, 24 Dec 2020 08:11:11 +0100 SeongJae Park wrote:
> On Wed, 23 Dec 2020 14:54:02 -0800 Shakeel Butt wrote:
>
> > On Wed, Dec 23, 2020 at 8:47 AM SeongJae Park wrote:
> > >
> > [snip]
> > > > [snip]
> > > > > +
> > > > > +static bool damon_va_young(struct mm_struct *mm, unsigned long
From: Guo Ren
Fixup commit c2d1adfa9a24 "csky: Add memory layout 2.5G(user):1.5G
(kernel)". That patch broke the global bit in PTE.
C-SKY TLB's entry contain two pages:
vpn, vpn + 1 -> ppn0, ppn1
All PPN's attributes contain global bit and final global is PPN0.G
& PPN1.G. So we must keep
On Wed, 23 Dec 2020 14:54:02 -0800 Shakeel Butt wrote:
> On Wed, Dec 23, 2020 at 8:47 AM SeongJae Park wrote:
> >
> [snip]
> > > [snip]
> > > > +
> > > > +static bool damon_va_young(struct mm_struct *mm, unsigned long addr,
> > > > + unsigned long *page_sz)
> > > > +{
> >
On Wed, Dec 23, 2020 at 8:47 AM SeongJae Park wrote:
>
[snip]
> > [snip]
> > > +
> > > +static bool damon_va_young(struct mm_struct *mm, unsigned long addr,
> > > + unsigned long *page_sz)
> > > +{
> > > + pte_t *pte = NULL;
> > > + pmd_t *pmd = NULL;
> > > +
; ---
> > include/linux/damon.h | 13 +
> > mm/damon/Kconfig | 9 +
> > mm/damon/Makefile | 1 +
> > mm/damon/vaddr.c | 579 ++
> > 4 files changed, 602 insertions(+)
> > create mode 100644 mm/damon/vadd
files changed, 602 insertions(+)
> create mode 100644 mm/damon/vaddr.c
>
> diff --git a/include/linux/damon.h b/include/linux/damon.h
> index f446f8433599..39b4d6d3ddee 100644
> --- a/include/linux/damon.h
> +++ b/include/linux/damon.h
> @@ -274,4 +274,17 @@ int damon_stop(st
/linux/damon.h
index f446f8433599..39b4d6d3ddee 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -274,4 +274,17 @@ int damon_stop(struct damon_ctx **ctxs, int nr_ctxs);
#endif /* CONFIG_DAMON */
+#ifdef CONFIG_DAMON_VADDR
+
+/* Monitoring primitives for virtual memory address
nsertions(+)
> > create mode 100644 mm/damon/primitives.c
> >
> > diff --git a/include/linux/damon.h b/include/linux/damon.h
> > index b8562814751e..70cc4b54212e 100644
> > --- a/include/linux/damon.h
> > +++ b/include/linux/damon.h
> > @@ -238,4 +238,18 @@ i
/include/linux/damon.h
> index b8562814751e..70cc4b54212e 100644
> --- a/include/linux/damon.h
> +++ b/include/linux/damon.h
> @@ -238,4 +238,18 @@ int damon_stop(struct damon_ctx **ctxs, int nr_ctxs);
>
> #endif /* CONFIG_DAMON */
>
> +#ifdef CONFIG_DAMON_PRIMITIVES
/include/linux/damon.h
@@ -238,4 +238,18 @@ int damon_stop(struct damon_ctx **ctxs, int nr_ctxs);
#endif /* CONFIG_DAMON */
+#ifdef CONFIG_DAMON_PRIMITIVES
+
+/* Reference callback implementations for virtual memory */
+void damon_va_init_regions(struct damon_ctx *ctx);
+void
/include/linux/damon.h
@@ -237,4 +237,18 @@ int damon_stop(struct damon_ctx **ctxs, int nr_ctxs);
#endif /* CONFIG_DAMON */
+#ifdef CONFIG_DAMON_PRIMITIVES
+
+/* Reference callback implementations for virtual memory */
+void damon_va_init_regions(struct damon_ctx *ctx);
+void
(*aggregate_cb)(struct damon_ctx *context);
};
+/* Reference callback implementations for virtual memory */
+void kdamond_init_vm_regions(struct damon_ctx *ctx);
+void kdamond_update_vm_regions(struct damon_ctx *ctx);
+void kdamond_prepare_vm_access_checks(struct damon_ctx *ctx);
+unsigned int
(*aggregate_cb)(struct damon_ctx *context);
};
+/* Reference callback implementations for virtual memory */
+void kdamond_init_vm_regions(struct damon_ctx *ctx);
+void kdamond_update_vm_regions(struct damon_ctx *ctx);
+void kdamond_prepare_vm_access_checks(struct damon_ctx *ctx);
+unsigned int
On Tue, 28 Jul 2020 10:42:11 -0700 Shakeel Butt wrote:
> On Mon, Jul 27, 2020 at 2:03 AM SeongJae Park wrote:
> >
> > On Mon, 27 Jul 2020 00:34:54 -0700 Greg Thelen wrote:
> >
> > > SeongJae Park wrote:
> > >
> > > > From: SeongJae Park
> > > >
> > > > This commit introduces a reference
On Mon, Jul 27, 2020 at 2:03 AM SeongJae Park wrote:
>
> On Mon, 27 Jul 2020 00:34:54 -0700 Greg Thelen wrote:
>
> > SeongJae Park wrote:
> >
> > > From: SeongJae Park
> > >
> > > This commit introduces a reference implementation of the address space
> > > specific low level primitives for the
On Mon, 27 Jul 2020 00:34:54 -0700 Greg Thelen wrote:
> SeongJae Park wrote:
>
> > From: SeongJae Park
> >
> > This commit introduces a reference implementation of the address space
> > specific low level primitives for the virtual address space, so that
> > users of DAMON can easily monitor
e/linux/damon.h
> index 3c0b92a679e8..310d36d123b3 100644
> --- a/include/linux/damon.h
> +++ b/include/linux/damon.h
> @@ -144,6 +144,12 @@ struct damon_ctx {
> void (*aggregate_cb)(struct damon_ctx *context);
> };
>
> +/* Reference callback implementatio
On Fri, 17 Jul 2020 19:23:28 -0700 Shakeel Butt wrote:
> On Fri, Jul 17, 2020 at 9:24 AM SeongJae Park wrote:
> >
> > On Fri, 17 Jul 2020 08:17:09 -0700 Shakeel Butt wrote:
> >
> > > On Thu, Jul 16, 2020 at 11:54 PM SeongJae Park wrote:
> > > >
> > > > On Thu, 16 Jul 2020 17:46:54 -0700
On Fri, Jul 17, 2020 at 9:24 AM SeongJae Park wrote:
>
> On Fri, 17 Jul 2020 08:17:09 -0700 Shakeel Butt wrote:
>
> > On Thu, Jul 16, 2020 at 11:54 PM SeongJae Park wrote:
> > >
> > > On Thu, 16 Jul 2020 17:46:54 -0700 Shakeel Butt
> > > wrote:
> > >
> > > > On Mon, Jul 13, 2020 at 1:44 AM
On Fri, 17 Jul 2020 08:17:09 -0700 Shakeel Butt wrote:
> On Thu, Jul 16, 2020 at 11:54 PM SeongJae Park wrote:
> >
> > On Thu, 16 Jul 2020 17:46:54 -0700 Shakeel Butt wrote:
> >
> > > On Mon, Jul 13, 2020 at 1:44 AM SeongJae Park wrote:
> > > >
> > > > From: SeongJae Park
> > > >
> > > >
On Thu, Jul 16, 2020 at 11:54 PM SeongJae Park wrote:
>
> On Thu, 16 Jul 2020 17:46:54 -0700 Shakeel Butt wrote:
>
> > On Mon, Jul 13, 2020 at 1:44 AM SeongJae Park wrote:
> > >
> > > From: SeongJae Park
> > >
> > > This commit introduces a reference implementation of the address space
> > >
On Thu, 16 Jul 2020 17:46:54 -0700 Shakeel Butt wrote:
> On Mon, Jul 13, 2020 at 1:44 AM SeongJae Park wrote:
> >
> > From: SeongJae Park
> >
> > This commit introduces a reference implementation of the address space
> > specific low level primitives for the virtual address space, so that
> >
On Mon, Jul 13, 2020 at 1:44 AM SeongJae Park wrote:
>
> From: SeongJae Park
>
> This commit introduces a reference implementation of the address space
> specific low level primitives for the virtual address space, so that
> users of DAMON can easily monitor the data accesses on virtual address
..310d36d123b3 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -144,6 +144,12 @@ struct damon_ctx {
void (*aggregate_cb)(struct damon_ctx *context);
};
+/* Reference callback implementations for virtual memory */
+void kdamond_init_vm_regions(struct damon_ctx *ctx);
+void
+++ b/include/linux/damon.h
@@ -144,6 +144,12 @@ struct damon_ctx {
void (*aggregate_cb)(struct damon_ctx *context);
};
+/* Reference callback implementations for virtual memory */
+void kdamond_init_vm_regions(struct damon_ctx *ctx);
+void kdamond_update_vm_regions(struct damon_ctx *ctx
On 2020-06-15T18:19:19+02:00 SeongJae Park wrote:
> From: SeongJae Park
>
> This commit implements the four essential callbacks of DAMON,
> '->init_target_regions', '->update_target_regions',
> '->prepare_access_checks', and '->check_accesses' for virtual memo
From: SeongJae Park
This commit implements the four essential callbacks of DAMON,
'->init_target_regions', '->update_target_regions',
'->prepare_access_checks', and '->check_accesses' for virtual memory
address spaces. Those internally use PTE Accessed bit. Using these
callback
Popcorn Linux implements software-based distributed
shared memory by extending Linux's virtual memory subsystem,
and enables processes on different machines to observe a
common and coherent virtual address space. Coherency of virtual
memory pages of different hosts is ensured using a
reader
[ Upstream commit a8c715b4dd73c26a81a9cc8dc792aa715d8b4bb2 ]
As of today if userspace process tries to access a kernel virtual addres
(0x7000_ to 0x7_) such that a legit kernel mapping already
exists, that process hangs instead of being killed with SIGSEGV
Fix that by ensuring that
From: Eugeniy Paltsev
[ Upstream commit a8c715b4dd73c26a81a9cc8dc792aa715d8b4bb2 ]
As of today if userspace process tries to access a kernel virtual addres
(0x7000_ to 0x7_) such that a legit kernel mapping already
exists, that process hangs instead of being killed with SIGSEGV
Fix
Hi Andrew,
On Wed, 31 Jul 2019, a...@linux-foundation.org wrote:
> The patch titled
> Subject: riscv: kbuild: add virtual memory system selection
> has been added to the -mm tree. Its filename is
> riscv-kbuild-add-virtual-memory-system-selection.patch
>
> This
On Wed, 7 Aug 2019, Alexandre Ghiti wrote:
> And FYI my series and your patch are already in linux-next.
Yes, I agree with Christoph that it would be preferable not to break
randconfig/allyesconfig. So if you don't mind, could you respin the
RISC-V patch to drop the Sv48 portion, and simply
On Wed, 07 Aug 2019 08:12:30 PDT (-0700), Christoph Hellwig wrote:
On Wed, Aug 07, 2019 at 09:04:40AM +0200, Alexandre Ghiti wrote:
I took a look at how x86 deals with 5-level page table: it allows to handle
5-level and 4-level at runtime by folding the last page table level (cf
On Wed, Aug 07, 2019 at 09:04:40AM +0200, Alexandre Ghiti wrote:
> I took a look at how x86 deals with 5-level page table: it allows to handle
> 5-level and 4-level at runtime by folding the last page table level (cf
> Documentation/x86/x86_64/5level-paging.rst). So we might want to be able to
>
that distributions
(and kernel developers) need to support.
The expectation is that kernels that support multiple virtual memory
system modes at runtime will probably incur either a performance or a
memory layout penalty for doing so. So performance-sensitive embedded
applications will select only
gt; compile time one to not balloon the number of configs that distributions
> > (and kernel developers) need to support.
>
> The expectation is that kernels that support multiple virtual memory
> system modes at runtime will probably incur either a performance or a
> memory layo
On Fri, 2 Aug 2019, Christoph Hellwig wrote:
> On Fri, Jul 26, 2019 at 01:00:49PM -0700, Paul Walmsley wrote:
> >
> > The RISC-V specifications currently define three virtual memory
> > translation systems: Sv32, Sv39, and Sv48. Sv32 is currently specific
> > to 32
On Fri, Jul 26, 2019 at 01:00:49PM -0700, Paul Walmsley wrote:
>
> The RISC-V specifications currently define three virtual memory
> translation systems: Sv32, Sv39, and Sv48. Sv32 is currently specific
> to 32-bit systems; Sv39 and Sv48 are currently specific to 64-bit
> system
i, 26 Jul 2019 10:21:11 -0700
> Subject: [PATCH v2] riscv: kbuild: add virtual memory system selection
>
> The RISC-V specifications currently define three virtual memory
> translation systems: Sv32, Sv39, and Sv48. Sv32 is currently specific
> to 32-bit systems; Sv39 and Sv48 are curre
On Sun, 28 Jul 2019, Bin Meng wrote:
> The spec does not mention 40-bit physical addresses, but 56-bit.
Thanks, agreed. Updated patch below
- Paul
From: Paul Walmsley
Date: Fri, 26 Jul 2019 10:21:11 -0700
Subject: [PATCH v2] riscv: kbuild: add virtual memory system selection
The RIS
On Sat, Jul 27, 2019 at 4:00 AM Paul Walmsley wrote:
>
>
> The RISC-V specifications currently define three virtual memory
> translation systems: Sv32, Sv39, and Sv48. Sv32 is currently specific
> to 32-bit systems; Sv39 and Sv48 are currently specific to 64-bit
> systems.
The RISC-V specifications currently define three virtual memory
translation systems: Sv32, Sv39, and Sv48. Sv32 is currently specific
to 32-bit systems; Sv39 and Sv48 are currently specific to 64-bit
systems. The current kernel only supports Sv32 and Sv39, but we'd
like to start preparing
On 23.07.2019 17:25, Joel Fernandes wrote:
On Tue, Jul 23, 2019 at 04:59:07PM +0300, Konstantin Khlebnikov wrote:
On 23.07.2019 16:46, Joel Fernandes wrote:
On Tue, Jul 23, 2019 at 02:54:26PM +0300, Konstantin Khlebnikov wrote:
The page_idle tracking feature currently requires looking up
On Tue, Jul 23, 2019 at 04:59:07PM +0300, Konstantin Khlebnikov wrote:
>
>
> On 23.07.2019 16:46, Joel Fernandes wrote:
> > On Tue, Jul 23, 2019 at 02:54:26PM +0300, Konstantin Khlebnikov wrote:
> > > The page_idle tracking feature currently requires looking up the pagemap
> > > for a process
On 23.07.2019 16:46, Joel Fernandes wrote:
On Tue, Jul 23, 2019 at 02:54:26PM +0300, Konstantin Khlebnikov wrote:
The page_idle tracking feature currently requires looking up the pagemap
for a process followed by interacting with /sys/kernel/mm/page_idle.
This is quite cumbersome and can be
On Tue, Jul 23, 2019 at 02:54:26PM +0300, Konstantin Khlebnikov wrote:
> The page_idle tracking feature currently requires looking up the pagemap
> for a process followed by interacting with /sys/kernel/mm/page_idle.
> This is quite cumbersome and can be error-prone too. If between
> accessing the
The page_idle tracking feature currently requires looking up the pagemap
for a process followed by interacting with /sys/kernel/mm/page_idle.
This is quite cumbersome and can be error-prone too. If between
accessing the per-PID pagemap and the global page_idle bitmap, if
something changes with the
The Linux kernel for powerpc since 4.17 has a bug where unrelated processes may
be able to read/write to each other's virtual memory under certain conditions.
This bug only affects machines using 64-bit CPUs with the hash page table MMU,
see below for more detail on affected CPUs.
To trigger
TB | ... unused hole
ea00 | -22TB | eaff |1 TB | virtual memory
map (vmemmap_base)
- eb00 | -21TB | ebff |1 TB | ... unused hole
+ eb00 | -21TB | eb7f | 512 GB | ... unused hole
+ eb80
From: Eugeniy Paltsev
commit a8c715b4dd73c26a81a9cc8dc792aa715d8b4bb2 upstream.
As of today if userspace process tries to access a kernel virtual addres
(0x7000_ to 0x7_) such that a legit kernel mapping already
exists, that process hangs instead of being killed with SIGSEGV
Fix
As of today if userspace process tries to access address which belongs
to kernel virtual memory area and kernel have mapping for this address
that process hangs instead of receiving SIGSEGV and being killed.
Steps to reproduce:
Create userspace application which reads from the beginning of
kernel
From: Pankaj Suryawanshi
Sent: 29 March 2019 10:52
To: Matthew Wilcox
Cc: linux-kernel@vger.kernel.org; linux...@kvack.org
Subject: Re: [External] Re: Print map for total physical and virtual memory
From: Matthew
From: Matthew Wilcox
Sent: 26 March 2019 18:13
To: Pankaj Suryawanshi
Cc: linux-kernel@vger.kernel.org; linux...@kvack.org
Subject: Re: [External] Re: Print map for total physical and virtual memory
On Tue, Mar 26, 2019 at 12:35:25PM +, Pankaj
On 2019-03-28 5:49 a.m., Mike Rapoport wrote:
>> +
>> +The direct mapping covers as much of the physical memory space as
>> +possible so that it may cover some IO memory.
>
> Please move the text before the tables, so that meaning of Sv32 and Sv39
> would be clear.
>
Ok, thanks. I've queued
ode 100644
> index ..725dc85f2c65
> --- /dev/null
> +++ b/Documentation/riscv/mm.txt
> @@ -0,0 +1,24 @@
> +Sv32:
> +
> + - 7fff user space, different per mm (2G)
> +8000 - 81ff virtual memory map (32MB)
> +8200 - bfff vm
space, different per mm (2G)
+8000 - 81ff virtual memory map (32MB)
+8200 - bfff vmalloc/ioremap space (1GB - 32MB)
+c000 - direct mapping of lower phys. memory (1GB)
+
+Sv39:
+
+ - 003f user space, different per mm (256GB)
+hole caused
On Tue, Mar 26, 2019 at 12:35:25PM +, Pankaj Suryawanshi wrote:
> From: Matthew Wilcox
> Sent: 26 March 2019 17:06
> To: Pankaj Suryawanshi
> Cc: linux-kernel@vger.kernel.org; linux...@kvack.org
> Subject: [External] Re: Print map for total physical and virtual memory
>
>
From: Matthew Wilcox
Sent: 26 March 2019 17:06
To: Pankaj Suryawanshi
Cc: linux-kernel@vger.kernel.org; linux...@kvack.org
Subject: [External] Re: Print map for total physical and virtual memory
CAUTION: This email originated from outside
On Tue, Mar 26, 2019 at 08:34:20AM +, Pankaj Suryawanshi wrote:
> Hello,
>
> 1. Is there any way to print whole physical and virtual memory map in
> kernel/user space ?
>
> 2. Is there any way to print map of cma area reserved memory and movable
> pages of cma area.
Hello,
1. Is there any way to print whole physical and virtual memory map in
kernel/user space ?
2. Is there any way to print map of cma area reserved memory and movable pages
of cma area.
3. Is there any way to know who pinned the pages from cma reserved area ?
Regards,
Pankaj
From: Omer Shpigelman
This patch adds the Virtual Memory and MMU modules.
Goya has an internal MMU which provides process isolation on the internal
DDR. The internal MMU also performs translations for transactions that go
from Goya to the Host.
The driver is responsible for allocating
From: Omer Shpigelman
This patch adds the Virtual Memory and MMU modules.
Goya has an internal MMU which provides process isolation on the internal
DDR. The internal MMU also performs translations for transactions that go
from Goya to the Host.
The driver is responsible for allocating
On Mon, Feb 11, 2019 at 05:17:48PM +0200, Oded Gabbay wrote:
> From: Omer Shpigelman
>
> This patch adds the Virtual Memory and MMU modules.
>
> Goya has an internal MMU which provides process isolation on the internal
> DDR. The internal MMU also performs translations for tr
From: Omer Shpigelman
This patch adds the Virtual Memory and MMU modules.
Goya has an internal MMU which provides process isolation on the internal
DDR. The internal MMU also performs translations for transactions that go
from Goya to the Host.
The driver is responsible for allocating
On Wed, Feb 6, 2019 at 5:14 PM Mike Rapoport wrote:
>
> On Mon, Feb 04, 2019 at 10:32:51PM +0200, Oded Gabbay wrote:
> > From: Omer Shpigelman
> >
> > This patch adds the Virtual Memory and MMU modules.
> >
> > Goya has an internal MMU which provides proce
On Mon, Feb 04, 2019 at 10:32:51PM +0200, Oded Gabbay wrote:
> From: Omer Shpigelman
>
> This patch adds the Virtual Memory and MMU modules.
>
> Goya has an internal MMU which provides process isolation on the internal
> DDR. The internal MMU also performs translations for tr
From: Omer Shpigelman
This patch adds the Virtual Memory and MMU modules.
Goya has an internal MMU which provides process isolation on the internal
DDR. The internal MMU also performs translations for transactions that go
from Goya to the Host.
The driver is responsible for allocating
From: Omer Shpigelman
This patch adds the Virtual Memory and MMU modules.
Goya has an internal MMU which provides process isolation on the internal
DDR. The internal MMU also performs translations for transactions that go
from Goya to the Host.
The driver is responsible for allocating
On Sun, Jan 27, 2019 at 6:13 PM Mike Rapoport wrote:
>
> On Wed, Jan 23, 2019 at 02:00:54AM +0200, Oded Gabbay wrote:
> > From: Omer Shpigelman
> >
> > This patch adds the Virtual Memory and MMU modules.
> >
> > Goya has an internal MMU which provides proce
On Wed, Jan 23, 2019 at 02:00:54AM +0200, Oded Gabbay wrote:
> From: Omer Shpigelman
>
> This patch adds the Virtual Memory and MMU modules.
>
> Goya has an internal MMU which provides process isolation on the internal
> DDR. The internal MMU also performs translations for tr
From: Omer Shpigelman
This patch adds the Virtual Memory and MMU modules.
Goya has an internal MMU which provides process isolation on the internal
DDR. The internal MMU also performs translations for transactions that go
from Goya to the Host.
The driver is responsible for allocating
Since commit ad67b74d2469d9b8 ("printk: hash addresses printed with
%p"), the virtual memory layout printed during boot up contains "ptrval"
instead of actual addresses.
Instead of changing the printing to "%px", and leaking virtual memory
layout information a
The Linux kernel has a global address space that is the same for any
kernel code. This address space becomes a liability in a world with
processor information leak vulnerabilities, such as L1TF. With the right
cache load gadget, an attacker-controlled hyperthread pair can leak
arbitrary data via
The Linux kernel has a global address space that is the same for any
kernel code. This address space becomes a liability in a world with
processor information leak vulnerabilities, such as L1TF. With the right
cache load gadget, an attacker-controlled hyperthread pair can leak
arbitrary data via
-64 virtual memory layout descriptions
In Documentation/x86/x86_64/mm.txt, the description of the x86-64 virtual
memory layout has become a confusing hodgepodge of inconsistencies:
- there's a hard to read mixture of 'TB' and 'bits' notation
- the entries sometimes mention a size
-64 virtual memory layout descriptions
In Documentation/x86/x86_64/mm.txt, the description of the x86-64 virtual
memory layout has become a confusing hodgepodge of inconsistencies:
- there's a hard to read mixture of 'TB' and 'bits' notation
- the entries sometimes mention a size
On Tue, Aug 28, 2018 at 7:22 AM, Geert Uytterhoeven
wrote:
> Since commit ad67b74d2469d9b8 ("printk: hash addresses printed with
> %p"), the virtual memory layout printed during boot up contains "ptrval"
> instead of actual addresses:
>
> Memory: 501296K/5
On Tue, Aug 28, 2018 at 7:22 AM, Geert Uytterhoeven
wrote:
> Since commit ad67b74d2469d9b8 ("printk: hash addresses printed with
> %p"), the virtual memory layout printed during boot up contains "ptrval"
> instead of actual addresses:
>
> Memory: 501296K/5
On Tue, Aug 28, 2018 at 7:23 AM, Geert Uytterhoeven
wrote:
> Since commit ad67b74d2469d9b8 ("printk: hash addresses printed with
> %p"), the virtual memory layout printed during boot up contains "ptrval"
> instead of actual addresses.
>
> Instead of changing
On Tue, Aug 28, 2018 at 7:23 AM, Geert Uytterhoeven
wrote:
> Since commit ad67b74d2469d9b8 ("printk: hash addresses printed with
> %p"), the virtual memory layout printed during boot up contains "ptrval"
> instead of actual addresses.
>
> Instead of changing
Since commit ad67b74d2469d9b8 ("printk: hash addresses printed with
%p"), the virtual memory layout printed during boot up contains "ptrval"
instead of actual addresses.
Instead of changing the printing to "%px", and leaking virtual memory
layout information a
Since commit ad67b74d2469d9b8 ("printk: hash addresses printed with
%p"), the virtual memory layout printed during boot up contains "ptrval"
instead of actual addresses.
Instead of changing the printing to "%px", and leaking virtual memory
layout information a
1 - 100 of 569 matches
Mail list logo
