Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1271909 > unrolled thread

Re: [PATCH 6/6] Documentation/x86: Update EFI memory region description

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 6/6] Documentation/x86: Update EFI memory region  description Ingo Molnar <mingo@kernel.org> - 2015-11-18 09:20 +0100
    Re: [PATCH 6/6] Documentation/x86: Update EFI memory region  description Matt Fleming <matt@codeblueprint.co.uk> - 2015-11-19 12:30 +0100

#1271909 — Re: [PATCH 6/6] Documentation/x86: Update EFI memory region description

* Matt Fleming <matt@codeblueprint.co.uk> wrote:

> On Fri, 13 Nov, at 10:22:10AM, Ingo Molnar wrote:
> > 
> > * Matt Fleming <matt@codeblueprint.co.uk> wrote:
> > 
> > > +We map EFI runtime services in the efi_pgd PGD in the virtual range of
> > > +64Gb (arbitrarily set, can be raised if needed). The mappings are not
> > > +part of any other kernel PGD and are only available during EFI runtime
> > > +calls.
> > 
> > Is that virtual address range 0-64Gb, i.e.:
> > 
> > 	0x00000000.00000000 - 0x00000010.00000000
> > 
> > or is it somewhere else?
> 
> You've snipped the patch hunk that gives the address range used,
> 
> diff --git a/Documentation/x86/x86_64/mm.txt
> b/Documentation/x86/x86_64/mm.txt
> index 05712ac83e38..a9885bb1ac22 100644
> --- a/Documentation/x86/x86_64/mm.txt
> +++ b/Documentation/x86/x86_64/mm.txt
> @@ -16,6 +16,8 @@ ffffec0000000000 - fffffc0000000000 (=44 bits) kasan
> shadow memory (16TB)
>  ... unused hole ...
>  ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks
>  ... unused hole ...
> +ffffffef00000000 - ffffffff00000000 (=64 GB) EFI region mapping space
> +... unused hole ...
>  ffffffff80000000 - ffffffffa0000000 (=512 MB)  kernel text mapping,
> from phys 0
>  ffffffffa0000000 - ffffffffff5fffff (=1525 MB) module mapping space
>  ffffffffff600000 - ffffffffffdfffff (=8 MB) vsyscalls

Ah yes - but then the text is misleading, what does 'in the virtual range of 64Gb' 
mean? A virtual memory range is a specific range of addresses - like in the table 
you extended.

A better phrasing would be something like:

 We map EFI runtime services in the 'efi_pgd' PGD in a 64Gb large virtual memory
 window (this size is arbitrary, it can be raised later if needed).

Agreed?

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1273045

On Wed, 18 Nov, at 09:18:59AM, Ingo Molnar wrote:
> 
> Ah yes - but then the text is misleading, what does 'in the virtual range of 64Gb' 
> mean? A virtual memory range is a specific range of addresses - like in the table 
> you extended.
> 
> A better phrasing would be something like:
> 
>  We map EFI runtime services in the 'efi_pgd' PGD in a 64Gb large virtual memory
>  window (this size is arbitrary, it can be raised later if needed).
> 
> Agreed?

Sounds OK to me.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web