On Fri, Jul 24, 2020 at 12:34 AM Benjamin Herrenschmidt
wrote:
> On Thu, 2020-07-23 at 01:21 -0400, Alex Ghiti wrote:
> > > works fine with huge pages, what is your problem there ? You rely on
> > > punching small-page size holes in there ?
> > >
> >
> > ARCH_HAS_STRICT_KERNEL_RWX prevents the
On Wed, Jul 22, 2020 at 11:06 PM Atish Patra wrote:
>
> On Wed, Jul 22, 2020 at 1:23 PM Arnd Bergmann wrote:
> >
> > I just noticed that rv32 allows 2GB of lowmem rather than just the usual
> > 768MB or 1GB, at the expense of addressable user memory. This seems
> > like an unusual choice, but I
On Thu, 2020-07-23 at 01:21 -0400, Alex Ghiti wrote:
> > works fine with huge pages, what is your problem there ? You rely on
> > punching small-page size holes in there ?
> >
>
> ARCH_HAS_STRICT_KERNEL_RWX prevents the use of a hugepage for the kernel
> mapping in the direct mapping as it sets
Le 7/21/20 à 7:36 PM, Palmer Dabbelt a écrit :
On Tue, 21 Jul 2020 16:11:02 PDT (-0700), b...@kernel.crashing.org wrote:
On Tue, 2020-07-21 at 14:36 -0400, Alex Ghiti wrote:
> > I guess I don't understand why this is necessary at all.
> > Specifically: why
> > can't we just relocate the
Hi Palmer,
Le 7/21/20 à 3:05 PM, Palmer Dabbelt a écrit :
On Tue, 21 Jul 2020 11:36:10 PDT (-0700), a...@ghiti.fr wrote:
Let's try to make progress here: I add linux-mm in CC to get feedback on
this patch as it blocks sv48 support too.
Sorry for being slow here. I haven't replied because I
Hi Benjamin,
Le 7/21/20 à 7:11 PM, Benjamin Herrenschmidt a écrit :
On Tue, 2020-07-21 at 14:36 -0400, Alex Ghiti wrote:
I guess I don't understand why this is necessary at all.
Specifically: why
can't we just relocate the kernel within the linear map? That would
let the
bootloader put the
On Wed, Jul 22, 2020 at 1:23 PM Arnd Bergmann wrote:
>
> On Wed, Jul 22, 2020 at 9:52 PM Palmer Dabbelt wrote:
> > On Wed, 22 Jul 2020 02:43:50 PDT (-0700), Arnd Bergmann wrote:
> > > On Tue, Jul 21, 2020 at 9:06 PM Palmer Dabbelt wrote:
> > > The eventual goal is to have a split of 3840MB for
On Wed, Jul 22, 2020 at 9:52 PM Palmer Dabbelt wrote:
> On Wed, 22 Jul 2020 02:43:50 PDT (-0700), Arnd Bergmann wrote:
> > On Tue, Jul 21, 2020 at 9:06 PM Palmer Dabbelt wrote:
> > The eventual goal is to have a split of 3840MB for either user or linear map
> > plus and 256MB for vmalloc,
On Wed, 22 Jul 2020 02:43:50 PDT (-0700), Arnd Bergmann wrote:
On Tue, Jul 21, 2020 at 9:06 PM Palmer Dabbelt wrote:
On Tue, 21 Jul 2020 11:36:10 PDT (-0700), a...@ghiti.fr wrote:
> Let's try to make progress here: I add linux-mm in CC to get feedback on
> this patch as it blocks sv48 support
On Tue, Jul 21, 2020 at 9:06 PM Palmer Dabbelt wrote:
>
> On Tue, 21 Jul 2020 11:36:10 PDT (-0700), a...@ghiti.fr wrote:
> > Let's try to make progress here: I add linux-mm in CC to get feedback on
> > this patch as it blocks sv48 support too.
>
> Sorry for being slow here. I haven't replied
On Tue, 21 Jul 2020 21:50:42 PDT (-0700), m...@ellerman.id.au wrote:
Benjamin Herrenschmidt writes:
On Tue, 2020-07-21 at 16:48 -0700, Palmer Dabbelt wrote:
> Why ? Branch distance limits ? You can't use trampolines ?
Nothing fundamental, it's just that we don't have a large code model in
Benjamin Herrenschmidt writes:
> On Tue, 2020-07-21 at 16:48 -0700, Palmer Dabbelt wrote:
>> > Why ? Branch distance limits ? You can't use trampolines ?
>>
>> Nothing fundamental, it's just that we don't have a large code model in the C
>> compiler. As a result all the global symbols are
On Tue, 2020-07-21 at 16:48 -0700, Palmer Dabbelt wrote:
> > Why ? Branch distance limits ? You can't use trampolines ?
>
> Nothing fundamental, it's just that we don't have a large code model in the C
> compiler. As a result all the global symbols are resolved as 32-bit
> PC-relative accesses.
On Tue, 21 Jul 2020 16:12:58 PDT (-0700), b...@kernel.crashing.org wrote:
On Tue, 2020-07-21 at 12:05 -0700, Palmer Dabbelt wrote:
* We waste vmalloc space on 32-bit systems, where there isn't a lot of it.
* On 64-bit systems the VA space around the kernel is precious because it's the
only
On Tue, 21 Jul 2020 16:11:02 PDT (-0700), b...@kernel.crashing.org wrote:
On Tue, 2020-07-21 at 14:36 -0400, Alex Ghiti wrote:
> > I guess I don't understand why this is necessary at all.
> > Specifically: why
> > can't we just relocate the kernel within the linear map? That would
> > let the
On Tue, 2020-07-21 at 12:05 -0700, Palmer Dabbelt wrote:
>
> * We waste vmalloc space on 32-bit systems, where there isn't a lot of it.
> * On 64-bit systems the VA space around the kernel is precious because it's
> the
> only place we can place text (modules, BPF, whatever).
Why ? Branch
On Tue, 2020-07-21 at 14:36 -0400, Alex Ghiti wrote:
> > > I guess I don't understand why this is necessary at all.
> > > Specifically: why
> > > can't we just relocate the kernel within the linear map? That would
> > > let the
> > > bootloader put the kernel wherever it wants, modulo the
On Tue, 21 Jul 2020 11:36:10 PDT (-0700), a...@ghiti.fr wrote:
Let's try to make progress here: I add linux-mm in CC to get feedback on
this patch as it blocks sv48 support too.
Sorry for being slow here. I haven't replied because I hadn't really fleshed
out the design yet, but just so
Let's try to make progress here: I add linux-mm in CC to get feedback on
this patch as it blocks sv48 support too.
Alex
Le 7/9/20 à 7:11 AM, Alex Ghiti a écrit :
Hi Palmer,
Le 7/9/20 à 1:05 AM, Palmer Dabbelt a écrit :
On Sun, 07 Jun 2020 00:59:46 PDT (-0700), a...@ghiti.fr wrote:
This is
Hi Palmer,
Le 7/9/20 à 1:05 AM, Palmer Dabbelt a écrit :
On Sun, 07 Jun 2020 00:59:46 PDT (-0700), a...@ghiti.fr wrote:
This is a preparatory patch for relocatable kernel.
The kernel used to be linked at PAGE_OFFSET address and used to be loaded
physically at the beginning of the main memory.
On Thu, Jul 9, 2020 at 1:05 PM Palmer Dabbelt wrote:
>
> On Sun, 07 Jun 2020 00:59:46 PDT (-0700), a...@ghiti.fr wrote:
> > This is a preparatory patch for relocatable kernel.
> >
> > The kernel used to be linked at PAGE_OFFSET address and used to be loaded
> > physically at the beginning of the
On Sun, 07 Jun 2020 00:59:46 PDT (-0700), a...@ghiti.fr wrote:
This is a preparatory patch for relocatable kernel.
The kernel used to be linked at PAGE_OFFSET address and used to be loaded
physically at the beginning of the main memory. Therefore, we could use
the linear mapping for the kernel
Hi Atish,
Le 6/11/20 à 5:34 PM, Atish Patra a écrit :
On Sun, Jun 7, 2020 at 1:01 AM Alexandre Ghiti wrote:
This is a preparatory patch for relocatable kernel.
The kernel used to be linked at PAGE_OFFSET address and used to be loaded
physically at the beginning of the main memory. Therefore,
On Sun, Jun 7, 2020 at 1:01 AM Alexandre Ghiti wrote:
>
> This is a preparatory patch for relocatable kernel.
>
> The kernel used to be linked at PAGE_OFFSET address and used to be loaded
> physically at the beginning of the main memory. Therefore, we could use
> the linear mapping for the kernel
This is a preparatory patch for relocatable kernel.
The kernel used to be linked at PAGE_OFFSET address and used to be loaded
physically at the beginning of the main memory. Therefore, we could use
the linear mapping for the kernel mapping.
But the relocated kernel base address will be different
25 matches
Mail list logo
