* [PATCH] x86: consider modules when cutting off memory
@ 2013-11-18 8:37 Jan Beulich
2013-11-18 11:32 ` Keir Fraser
0 siblings, 1 reply; 4+ messages in thread
From: Jan Beulich @ 2013-11-18 8:37 UTC (permalink / raw)
To: xen-devel; +Cc: Keir Fraser
[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]
The code in question runs after module ranges got already removed from
the E820 table, so when determining the new maximum page/PDX we need to
explicitly take them into account.
Furthermore we need to round up the ending addresses here, in order to
fully cover eventual partial trailing pages.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1013,9 +1013,17 @@ void __init __start_xen(unsigned long mb
ASSERT(j);
}
map_e = boot_e820.map[j].addr + boot_e820.map[j].size;
- if ( (map_e >> PAGE_SHIFT) < max_page )
+ for ( j = 0; j < mbi->mods_count; ++j )
{
- max_page = map_e >> PAGE_SHIFT;
+ uint64_t end = pfn_to_paddr(mod[j].mod_start) +
+ mod[j].mod_end;
+
+ if ( map_e < end )
+ map_e = end;
+ }
+ if ( PFN_UP(map_e) < max_page )
+ {
+ max_page = PFN_UP(map_e);
max_pdx = pfn_to_pdx(max_page - 1) + 1;
}
printk(XENLOG_WARNING "Ignoring inaccessible memory range"
[-- Attachment #2: x86-memory-cutoff-modules.patch --]
[-- Type: text/plain, Size: 1342 bytes --]
x86: consider modules when cutting off memory
The code in question runs after module ranges got already removed from
the E820 table, so when determining the new maximum page/PDX we need to
explicitly take them into account.
Furthermore we need to round up the ending addresses here, in order to
fully cover eventual partial trailing pages.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1013,9 +1013,17 @@ void __init __start_xen(unsigned long mb
ASSERT(j);
}
map_e = boot_e820.map[j].addr + boot_e820.map[j].size;
- if ( (map_e >> PAGE_SHIFT) < max_page )
+ for ( j = 0; j < mbi->mods_count; ++j )
{
- max_page = map_e >> PAGE_SHIFT;
+ uint64_t end = pfn_to_paddr(mod[j].mod_start) +
+ mod[j].mod_end;
+
+ if ( map_e < end )
+ map_e = end;
+ }
+ if ( PFN_UP(map_e) < max_page )
+ {
+ max_page = PFN_UP(map_e);
max_pdx = pfn_to_pdx(max_page - 1) + 1;
}
printk(XENLOG_WARNING "Ignoring inaccessible memory range"
[-- Attachment #3: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] x86: consider modules when cutting off memory
2013-11-18 8:37 [PATCH] x86: consider modules when cutting off memory Jan Beulich
@ 2013-11-18 11:32 ` Keir Fraser
2013-11-18 12:11 ` Jan Beulich
0 siblings, 1 reply; 4+ messages in thread
From: Keir Fraser @ 2013-11-18 11:32 UTC (permalink / raw)
To: Jan Beulich, xen-devel
On 18/11/2013 00:37, "Jan Beulich" <JBeulich@suse.com> wrote:
> The code in question runs after module ranges got already removed from
> the E820 table, so when determining the new maximum page/PDX we need to
> explicitly take them into account.
>
> Furthermore we need to round up the ending addresses here, in order to
> fully cover eventual partial trailing pages.
Is rounding up the right thing to do? We round down in find_max_pfn()?
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1013,9 +1013,17 @@ void __init __start_xen(unsigned long mb
> ASSERT(j);
> }
> map_e = boot_e820.map[j].addr + boot_e820.map[j].size;
> - if ( (map_e >> PAGE_SHIFT) < max_page )
> + for ( j = 0; j < mbi->mods_count; ++j )
> {
> - max_page = map_e >> PAGE_SHIFT;
> + uint64_t end = pfn_to_paddr(mod[j].mod_start) +
> + mod[j].mod_end;
> +
> + if ( map_e < end )
> + map_e = end;
> + }
> + if ( PFN_UP(map_e) < max_page )
> + {
> + max_page = PFN_UP(map_e);
> max_pdx = pfn_to_pdx(max_page - 1) + 1;
> }
> printk(XENLOG_WARNING "Ignoring inaccessible memory range"
>
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] x86: consider modules when cutting off memory
2013-11-18 11:32 ` Keir Fraser
@ 2013-11-18 12:11 ` Jan Beulich
2013-11-18 12:26 ` Keir Fraser
0 siblings, 1 reply; 4+ messages in thread
From: Jan Beulich @ 2013-11-18 12:11 UTC (permalink / raw)
To: Keir Fraser; +Cc: xen-devel
>>> On 18.11.13 at 12:32, Keir Fraser <keir.xen@gmail.com> wrote:
> On 18/11/2013 00:37, "Jan Beulich" <JBeulich@suse.com> wrote:
>
>> The code in question runs after module ranges got already removed from
>> the E820 table, so when determining the new maximum page/PDX we need to
>> explicitly take them into account.
>>
>> Furthermore we need to round up the ending addresses here, in order to
>> fully cover eventual partial trailing pages.
>
> Is rounding up the right thing to do? We round down in find_max_pfn()?
Yes, it is - we're trying to determine a new max_page/max_pdx
here, so we should include the trailing part of a partial page. This
is particularly necessary for the modules, as otherwise the last
few bytes of a module may end up being in memory not satisfying
mfn_valid().
If anything, we'd need to round down after the E820 loop, and
round up after the modules one. But I don't think the two max_p*
being one too big here would matter much, so uniformly rounding
up seems sufficient.
Jan
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -1013,9 +1013,17 @@ void __init __start_xen(unsigned long mb
>> ASSERT(j);
>> }
>> map_e = boot_e820.map[j].addr + boot_e820.map[j].size;
>> - if ( (map_e >> PAGE_SHIFT) < max_page )
>> + for ( j = 0; j < mbi->mods_count; ++j )
>> {
>> - max_page = map_e >> PAGE_SHIFT;
>> + uint64_t end = pfn_to_paddr(mod[j].mod_start) +
>> + mod[j].mod_end;
>> +
>> + if ( map_e < end )
>> + map_e = end;
>> + }
>> + if ( PFN_UP(map_e) < max_page )
>> + {
>> + max_page = PFN_UP(map_e);
>> max_pdx = pfn_to_pdx(max_page - 1) + 1;
>> }
>> printk(XENLOG_WARNING "Ignoring inaccessible memory range"
>>
>>
>>
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] x86: consider modules when cutting off memory
2013-11-18 12:11 ` Jan Beulich
@ 2013-11-18 12:26 ` Keir Fraser
0 siblings, 0 replies; 4+ messages in thread
From: Keir Fraser @ 2013-11-18 12:26 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel
On 18/11/2013 04:11, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 18.11.13 at 12:32, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 18/11/2013 00:37, "Jan Beulich" <JBeulich@suse.com> wrote:
>>
>>> The code in question runs after module ranges got already removed from
>>> the E820 table, so when determining the new maximum page/PDX we need to
>>> explicitly take them into account.
>>>
>>> Furthermore we need to round up the ending addresses here, in order to
>>> fully cover eventual partial trailing pages.
>>
>> Is rounding up the right thing to do? We round down in find_max_pfn()?
>
> Yes, it is - we're trying to determine a new max_page/max_pdx
> here, so we should include the trailing part of a partial page. This
> is particularly necessary for the modules, as otherwise the last
> few bytes of a module may end up being in memory not satisfying
> mfn_valid().
>
> If anything, we'd need to round down after the E820 loop, and
> round up after the modules one. But I don't think the two max_p*
> being one too big here would matter much, so uniformly rounding
> up seems sufficient.
Okay makes sense.
Acked-by: Keir Fraser <keir@xen.org>
> Jan
>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>
>>> --- a/xen/arch/x86/setup.c
>>> +++ b/xen/arch/x86/setup.c
>>> @@ -1013,9 +1013,17 @@ void __init __start_xen(unsigned long mb
>>> ASSERT(j);
>>> }
>>> map_e = boot_e820.map[j].addr + boot_e820.map[j].size;
>>> - if ( (map_e >> PAGE_SHIFT) < max_page )
>>> + for ( j = 0; j < mbi->mods_count; ++j )
>>> {
>>> - max_page = map_e >> PAGE_SHIFT;
>>> + uint64_t end = pfn_to_paddr(mod[j].mod_start) +
>>> + mod[j].mod_end;
>>> +
>>> + if ( map_e < end )
>>> + map_e = end;
>>> + }
>>> + if ( PFN_UP(map_e) < max_page )
>>> + {
>>> + max_page = PFN_UP(map_e);
>>> max_pdx = pfn_to_pdx(max_page - 1) + 1;
>>> }
>>> printk(XENLOG_WARNING "Ignoring inaccessible memory range"
>>>
>>>
>>>
>
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-11-18 12:26 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-11-18 8:37 [PATCH] x86: consider modules when cutting off memory Jan Beulich
2013-11-18 11:32 ` Keir Fraser
2013-11-18 12:11 ` Jan Beulich
2013-11-18 12:26 ` Keir Fraser
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).