* [RESEND PATCH v2 0/2] fixes for mem= option
@ 2012-10-19 10:16 wency
2012-10-19 10:16 ` [RESEND PATCH v2 1/2] update mem= option's spec according to its implementation wency
2012-10-19 10:16 ` [RESEND PATCH v2 2/2] x86: make 'mem=' option to work for efi platform wency
0 siblings, 2 replies; 6+ messages in thread
From: wency @ 2012-10-19 10:16 UTC (permalink / raw)
To: x86, linux-kernel
Cc: rob, tglx, mingo, bhelgaas, hpa, isimatu.yasuaki,
kosaki.motohiro, muneda.takahiro, Wen Congyang
From: Wen Congyang <wency@cn.fujitsu.com>
The documentation and implementation of 'mem=' option doesn't match, and the
option can't work for efi platform. This patchset updates the documentation
and make the option to work for efi platform.
I resend it again because HPA asked me to resend it some days after merge
window.
Changes from v1 to v2
Patch1: Just fix a typo error(ingoring -> ignoring).
Wen Congyang (2):
update mem= option's spec according to its implementation
x86: make 'mem=' option to work for efi platform
Documentation/kernel-parameters.txt | 7 ++++---
arch/x86/kernel/e820.c | 29 +++++++++++++++++++++++++----
2 files changed, 29 insertions(+), 7 deletions(-)
^ permalink raw reply [flat|nested] 6+ messages in thread
* [RESEND PATCH v2 1/2] update mem= option's spec according to its implementation
2012-10-19 10:16 [RESEND PATCH v2 0/2] fixes for mem= option wency
@ 2012-10-19 10:16 ` wency
2012-10-19 18:11 ` KOSAKI Motohiro
2012-10-19 10:16 ` [RESEND PATCH v2 2/2] x86: make 'mem=' option to work for efi platform wency
1 sibling, 1 reply; 6+ messages in thread
From: wency @ 2012-10-19 10:16 UTC (permalink / raw)
To: x86, linux-kernel
Cc: rob, tglx, mingo, bhelgaas, hpa, isimatu.yasuaki,
kosaki.motohiro, muneda.takahiro, Wen Congyang
From: Wen Congyang <wency@cn.fujitsu.com>
Current mem= implementation seems buggy because specification and
implementation doesn't match. Current mem= has been working
for many years and it's not buggy, it works as expected. So
we should update the specification.
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
Sort-of-tentatively-acked-by: Rob Landley <rob@landley.net>
---
Documentation/kernel-parameters.txt | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 9776f06..85b911a 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1481,9 +1481,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
mem=nn[KMG] [KNL,BOOT] Force usage of a specific amount of memory
Amount of memory to be used when the kernel is not able
to see the whole system memory or for test.
- [X86-32] Use together with memmap= to avoid physical
- address space collisions. Without memmap= PCI devices
- could be placed at addresses belonging to unused RAM.
+ [X86-32] Work as limiting max address. Use together
+ with memmap= to avoid physical address space collisions.
+ Without memmap= PCI devices could be placed at addresses
+ belonging to unused RAM.
mem=nopentium [BUGS=X86-32] Disable usage of 4MB pages for kernel
memory.
--
1.7.1
^ permalink raw reply [flat|nested] 6+ messages in thread
* [RESEND PATCH v2 2/2] x86: make 'mem=' option to work for efi platform
2012-10-19 10:16 [RESEND PATCH v2 0/2] fixes for mem= option wency
2012-10-19 10:16 ` [RESEND PATCH v2 1/2] update mem= option's spec according to its implementation wency
@ 2012-10-19 10:16 ` wency
1 sibling, 0 replies; 6+ messages in thread
From: wency @ 2012-10-19 10:16 UTC (permalink / raw)
To: x86, linux-kernel
Cc: rob, tglx, mingo, bhelgaas, hpa, isimatu.yasuaki,
kosaki.motohiro, muneda.takahiro, Wen Congyang
From: Wen Congyang <wency@cn.fujitsu.com>
Current mem boot option only can work for non efi environment. If the user
specifies add_efi_memmap, it cannot work for efi environment. In
the efi environment, we call e820_add_region() to add the memory map. So
we can modify __e820_add_region() and the mem boot option can work for
efi environment.
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
---
arch/x86/kernel/e820.c | 29 +++++++++++++++++++++++++----
1 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index ed858e9..e28982a 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -47,6 +47,7 @@ unsigned long pci_mem_start = 0xaeedbabe;
#ifdef CONFIG_PCI
EXPORT_SYMBOL(pci_mem_start);
#endif
+static u64 mem_limit = ~0ULL;
/*
* This function checks if any part of the range <start,end> is mapped
@@ -119,6 +120,20 @@ static void __init __e820_add_region(struct e820map *e820x, u64 start, u64 size,
return;
}
+ if (start >= mem_limit) {
+ printk(KERN_ERR "e820: ignoring [mem %#010llx-%#010llx]\n",
+ (unsigned long long)start,
+ (unsigned long long)(start + size - 1));
+ return;
+ }
+
+ if (mem_limit - start < size) {
+ printk(KERN_ERR "e820: ignoring [mem %#010llx-%#010llx]\n",
+ (unsigned long long)mem_limit,
+ (unsigned long long)(start + size - 1));
+ size = mem_limit - start;
+ }
+
e820x->map[x].addr = start;
e820x->map[x].size = size;
e820x->map[x].type = type;
@@ -809,7 +824,7 @@ static int userdef __initdata;
/* "mem=nopentium" disables the 4MB page tables. */
static int __init parse_memopt(char *p)
{
- u64 mem_size;
+ char *oldp;
if (!p)
return -EINVAL;
@@ -825,11 +840,11 @@ static int __init parse_memopt(char *p)
}
userdef = 1;
- mem_size = memparse(p, &p);
+ oldp = p;
+ mem_limit = memparse(p, &p);
/* don't remove all of memory when handling "mem={invalid}" param */
- if (mem_size == 0)
+ if (mem_limit == 0 || p == oldp)
return -EINVAL;
- e820_remove_range(mem_size, ULLONG_MAX - mem_size, E820_RAM, 1);
return 0;
}
@@ -881,6 +896,12 @@ early_param("memmap", parse_memmap_opt);
void __init finish_e820_parsing(void)
{
+ if (mem_limit != ~0ULL) {
+ userdef = 1;
+ e820_remove_range(mem_limit, ULLONG_MAX - mem_limit,
+ E820_RAM, 1);
+ }
+
if (userdef) {
u32 nr = e820.nr_map;
--
1.7.1
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RESEND PATCH v2 1/2] update mem= option's spec according to its implementation
2012-10-19 10:16 ` [RESEND PATCH v2 1/2] update mem= option's spec according to its implementation wency
@ 2012-10-19 18:11 ` KOSAKI Motohiro
2012-10-20 0:52 ` Wen Congyang
0 siblings, 1 reply; 6+ messages in thread
From: KOSAKI Motohiro @ 2012-10-19 18:11 UTC (permalink / raw)
To: wency
Cc: x86, linux-kernel, rob, tglx, mingo, bhelgaas, hpa,
isimatu.yasuaki, muneda.takahiro
On Fri, Oct 19, 2012 at 6:16 AM, <wency@cn.fujitsu.com> wrote:
> From: Wen Congyang <wency@cn.fujitsu.com>
>
> Current mem= implementation seems buggy because specification and
> implementation doesn't match. Current mem= has been working
> for many years and it's not buggy, it works as expected. So
> we should update the specification.
>
> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> Sort-of-tentatively-acked-by: Rob Landley <rob@landley.net>
> ---
> Documentation/kernel-parameters.txt | 7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index 9776f06..85b911a 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -1481,9 +1481,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
> mem=nn[KMG] [KNL,BOOT] Force usage of a specific amount of memory
> Amount of memory to be used when the kernel is not able
> to see the whole system memory or for test.
> - [X86-32] Use together with memmap= to avoid physical
> - address space collisions. Without memmap= PCI devices
> - could be placed at addresses belonging to unused RAM.
> + [X86-32] Work as limiting max address. Use together
> + with memmap= to avoid physical address space collisions.
> + Without memmap= PCI devices could be placed at addresses
> + belonging to unused RAM.
If my remember is correct, x86-64 also specify maximum address.
but my remember is not clear.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RESEND PATCH v2 1/2] update mem= option's spec according to its implementation
2012-10-19 18:11 ` KOSAKI Motohiro
@ 2012-10-20 0:52 ` Wen Congyang
2012-10-20 4:23 ` KOSAKI Motohiro
0 siblings, 1 reply; 6+ messages in thread
From: Wen Congyang @ 2012-10-20 0:52 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: x86, linux-kernel, rob, tglx, mingo, bhelgaas, hpa,
isimatu.yasuaki, muneda.takahiro
At 10/20/2012 02:11 AM, KOSAKI Motohiro Wrote:
> On Fri, Oct 19, 2012 at 6:16 AM, <wency@cn.fujitsu.com> wrote:
>> From: Wen Congyang <wency@cn.fujitsu.com>
>>
>> Current mem= implementation seems buggy because specification and
>> implementation doesn't match. Current mem= has been working
>> for many years and it's not buggy, it works as expected. So
>> we should update the specification.
>>
>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
>> Sort-of-tentatively-acked-by: Rob Landley <rob@landley.net>
>> ---
>> Documentation/kernel-parameters.txt | 7 ++++---
>> 1 files changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
>> index 9776f06..85b911a 100644
>> --- a/Documentation/kernel-parameters.txt
>> +++ b/Documentation/kernel-parameters.txt
>> @@ -1481,9 +1481,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
>> mem=nn[KMG] [KNL,BOOT] Force usage of a specific amount of memory
>> Amount of memory to be used when the kernel is not able
>> to see the whole system memory or for test.
>> - [X86-32] Use together with memmap= to avoid physical
>> - address space collisions. Without memmap= PCI devices
>> - could be placed at addresses belonging to unused RAM.
>> + [X86-32] Work as limiting max address. Use together
>> + with memmap= to avoid physical address space collisions.
>> + Without memmap= PCI devices could be placed at addresses
>> + belonging to unused RAM.
>
> If my remember is correct, x86-64 also specify maximum address.
> but my remember is not clear.
>
Do you mean max_addr option? It is only for ia64 box.
Thanks
Wen Congyang
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RESEND PATCH v2 1/2] update mem= option's spec according to its implementation
2012-10-20 0:52 ` Wen Congyang
@ 2012-10-20 4:23 ` KOSAKI Motohiro
0 siblings, 0 replies; 6+ messages in thread
From: KOSAKI Motohiro @ 2012-10-20 4:23 UTC (permalink / raw)
To: Wen Congyang
Cc: x86, linux-kernel, rob, tglx, mingo, bhelgaas, hpa,
isimatu.yasuaki, muneda.takahiro
On Fri, Oct 19, 2012 at 8:52 PM, Wen Congyang <wency@cn.fujitsu.com> wrote:
> At 10/20/2012 02:11 AM, KOSAKI Motohiro Wrote:
>> On Fri, Oct 19, 2012 at 6:16 AM, <wency@cn.fujitsu.com> wrote:
>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>>
>>> Current mem= implementation seems buggy because specification and
>>> implementation doesn't match. Current mem= has been working
>>> for many years and it's not buggy, it works as expected. So
>>> we should update the specification.
>>>
>>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
>>> Sort-of-tentatively-acked-by: Rob Landley <rob@landley.net>
>>> ---
>>> Documentation/kernel-parameters.txt | 7 ++++---
>>> 1 files changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
>>> index 9776f06..85b911a 100644
>>> --- a/Documentation/kernel-parameters.txt
>>> +++ b/Documentation/kernel-parameters.txt
>>> @@ -1481,9 +1481,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
>>> mem=nn[KMG] [KNL,BOOT] Force usage of a specific amount of memory
>>> Amount of memory to be used when the kernel is not able
>>> to see the whole system memory or for test.
>>> - [X86-32] Use together with memmap= to avoid physical
>>> - address space collisions. Without memmap= PCI devices
>>> - could be placed at addresses belonging to unused RAM.
>>> + [X86-32] Work as limiting max address. Use together
>>> + with memmap= to avoid physical address space collisions.
>>> + Without memmap= PCI devices could be placed at addresses
>>> + belonging to unused RAM.
>>
>> If my remember is correct, x86-64 also specify maximum address.
>> but my remember is not clear.
>
> Do you mean max_addr option? It is only for ia64 box.
No.
Your patch say x86-32 and x86-64 have different mem parameter
semantics. and I doubt it.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-10-20 4:24 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-19 10:16 [RESEND PATCH v2 0/2] fixes for mem= option wency
2012-10-19 10:16 ` [RESEND PATCH v2 1/2] update mem= option's spec according to its implementation wency
2012-10-19 18:11 ` KOSAKI Motohiro
2012-10-20 0:52 ` Wen Congyang
2012-10-20 4:23 ` KOSAKI Motohiro
2012-10-19 10:16 ` [RESEND PATCH v2 2/2] x86: make 'mem=' option to work for efi platform wency
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome