On Fri, Oct 5, 2012 at 7:58 AM, Yinghai Lu wrote:
> On Fri, Oct 5, 2012 at 4:27 AM, Stefano Stabellini
> wrote:
>> On Fri, 5 Oct 2012, Yinghai Lu wrote:
>>> On Thu, Oct 4, 2012 at 2:54 PM, H. Peter Anvin wrote:
>>> >
>>> > See my other post. This is bringing up the Kernel Summit algorithm
On Fri, Oct 5, 2012 at 7:58 AM, Yinghai Lu ying...@kernel.org wrote:
On Fri, Oct 5, 2012 at 4:27 AM, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
On Fri, 5 Oct 2012, Yinghai Lu wrote:
On Thu, Oct 4, 2012 at 2:54 PM, H. Peter Anvin h...@zytor.com wrote:
See my other post.
That disappeared 10 years ago...
ebied...@xmission.com wrote:
>"H. Peter Anvin" writes:
>
>> On 10/05/2012 02:41 PM, Eric W. Biederman wrote:
>>> Yinghai Lu writes:
>>>
with bzImage or vmlinux?
>>>
>>> bzImage I presume. Certainly the bzImage has lost it's 896M limit,
>>> which is where
"H. Peter Anvin" writes:
> On 10/05/2012 02:41 PM, Eric W. Biederman wrote:
>> Yinghai Lu writes:
>>
>>> with bzImage or vmlinux?
>>
>> bzImage I presume. Certainly the bzImage has lost it's 896M limit,
>> which is where ultimiately the 896M limite came from.
>>
>
> ~896M (actually comes from
On 10/05/2012 05:28 PM, Eric W. Biederman wrote:
Seriously, any case where we can't load anywhere in physical ram on x86-64 is a
bug. i386 is another matter.
As I recall there are data structures like the IDT that only have a
32bit base address.
Not true. The only one I know of is memory
"H. Peter Anvin" writes:
> On 10/05/2012 02:32 PM, Eric W. Biederman wrote:
>> Yinghai Lu writes:
>>
>>> On Fri, Oct 5, 2012 at 2:04 PM, Eric W. Biederman
>>> wrote:
>> Is there a git commit that explains what the 'big range' problem is?
At least on x86_64 this was recently
On 10/05/2012 02:41 PM, Eric W. Biederman wrote:
Yinghai Lu writes:
with bzImage or vmlinux?
bzImage I presume. Certainly the bzImage has lost it's 896M limit,
which is where ultimiately the 896M limite came from.
~896M (actually comes from i386, not from bzImage...
-hpa
--
On 10/05/2012 02:32 PM, Eric W. Biederman wrote:
Yinghai Lu writes:
On Fri, Oct 5, 2012 at 2:04 PM, Eric W. Biederman wrote:
Is there a git commit that explains what the 'big range' problem is?
At least on x86_64 this was recently tested and anywhere below 4G is
good, and there is a patch
I am going to see about merging these two threads.
Yinghai Lu writes:
> On Fri, Oct 5, 2012 at 2:41 PM, Eric W. Biederman
> wrote:
>> Yinghai Lu writes:
>>
>>> with bzImage or vmlinux?
>>
>> bzImage I presume. Certainly the bzImage has lost it's 896M limit,
>> which is where ultimiately
On Fri, Oct 5, 2012 at 2:41 PM, Eric W. Biederman wrote:
> Yinghai Lu writes:
>
>> with bzImage or vmlinux?
>
> bzImage I presume. Certainly the bzImage has lost it's 896M limit,
> which is where ultimiately the 896M limite came from.
they are using updated kexec-tools ?
last time when i
Yinghai Lu writes:
> with bzImage or vmlinux?
bzImage I presume. Certainly the bzImage has lost it's 896M limit,
which is where ultimiately the 896M limite came from.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Fri, Oct 5, 2012 at 2:32 PM, Eric W. Biederman wrote:
> Yinghai Lu writes:
>
>> On Fri, Oct 5, 2012 at 2:04 PM, Eric W. Biederman
>> wrote:
> Is there a git commit that explains what the 'big range' problem is?
>>>
>>> At least on x86_64 this was recently tested and anywhere below 4G is
Yinghai Lu writes:
> On Fri, Oct 5, 2012 at 2:04 PM, Eric W. Biederman
> wrote:
Is there a git commit that explains what the 'big range' problem is?
>>
>> At least on x86_64 this was recently tested and anywhere below 4G is
>> good, and there is a patch floating around somewhere to remove
On Fri, Oct 5, 2012 at 2:04 PM, Eric W. Biederman wrote:
>>> Is there a git commit that explains what the 'big range' problem is?
>
> At least on x86_64 this was recently tested and anywhere below 4G is
> good, and there is a patch floating around somewhere to remove this
> issue.
patch for
Yinghai Lu writes:
> On Thu, Oct 4, 2012 at 9:46 AM, Konrad Rzeszutek Wilk
> wrote:
>>> then kdump may have problem get big range again.
>>
>> Is there a git commit that explains what the 'big range' problem is?
At least on x86_64 this was recently tested and anywhere below 4G is
good, and
On Fri, Oct 5, 2012 at 4:27 AM, Stefano Stabellini
wrote:
> On Fri, 5 Oct 2012, Yinghai Lu wrote:
>> On Thu, Oct 4, 2012 at 2:54 PM, H. Peter Anvin wrote:
>> >
>> > See my other post. This is bringing up the Kernel Summit algorithm again.
>> >
>>
>> sure. please check if you are ok with
On Fri, 5 Oct 2012, Yinghai Lu wrote:
> On Thu, Oct 4, 2012 at 2:54 PM, H. Peter Anvin wrote:
> >
> > See my other post. This is bringing up the Kernel Summit algorithm again.
> >
>
> sure. please check if you are ok with attached one on top of x86/mm2
>
> Subject: [PATCH] x86: get early page
On Thu, 4 Oct 2012, Yinghai Lu wrote:
> On Mon, Oct 1, 2012 at 4:00 AM, Stefano Stabellini
> wrote:
> > On Sun, 30 Sep 2012, Yinghai Lu wrote:
> >> After
> >>
> >> | commit 8548c84da2f47e71bbbe300f55edb768492575f7
> >> | Author: Takashi Iwai
> >> | Date: Sun Oct 23 23:19:12 2011 +0200
> >> |
>
On Thu, Oct 4, 2012 at 2:54 PM, H. Peter Anvin wrote:
>
> See my other post. This is bringing up the Kernel Summit algorithm again.
>
sure. please check if you are ok with attached one on top of x86/mm2
Thanks
Yinghai
fix_max_pfn_xx_11.patch
Description: Binary data
On Thu, Oct 4, 2012 at 2:54 PM, H. Peter Anvin h...@zytor.com wrote:
See my other post. This is bringing up the Kernel Summit algorithm again.
sure. please check if you are ok with attached one on top of x86/mm2
Thanks
Yinghai
fix_max_pfn_xx_11.patch
Description: Binary data
On Thu, 4 Oct 2012, Yinghai Lu wrote:
On Mon, Oct 1, 2012 at 4:00 AM, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
On Sun, 30 Sep 2012, Yinghai Lu wrote:
After
| commit 8548c84da2f47e71bbbe300f55edb768492575f7
| Author: Takashi Iwai ti...@suse.de
| Date: Sun Oct 23
On Fri, 5 Oct 2012, Yinghai Lu wrote:
On Thu, Oct 4, 2012 at 2:54 PM, H. Peter Anvin h...@zytor.com wrote:
See my other post. This is bringing up the Kernel Summit algorithm again.
sure. please check if you are ok with attached one on top of x86/mm2
Subject: [PATCH] x86: get early
On Fri, Oct 5, 2012 at 4:27 AM, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
On Fri, 5 Oct 2012, Yinghai Lu wrote:
On Thu, Oct 4, 2012 at 2:54 PM, H. Peter Anvin h...@zytor.com wrote:
See my other post. This is bringing up the Kernel Summit algorithm again.
sure. please
Yinghai Lu ying...@kernel.org writes:
On Thu, Oct 4, 2012 at 9:46 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
then kdump may have problem get big range again.
Is there a git commit that explains what the 'big range' problem is?
At least on x86_64 this was recently tested and
On Fri, Oct 5, 2012 at 2:04 PM, Eric W. Biederman ebied...@xmission.com wrote:
Is there a git commit that explains what the 'big range' problem is?
At least on x86_64 this was recently tested and anywhere below 4G is
good, and there is a patch floating around somewhere to remove this
issue.
Yinghai Lu ying...@kernel.org writes:
On Fri, Oct 5, 2012 at 2:04 PM, Eric W. Biederman ebied...@xmission.com
wrote:
Is there a git commit that explains what the 'big range' problem is?
At least on x86_64 this was recently tested and anywhere below 4G is
good, and there is a patch floating
On Fri, Oct 5, 2012 at 2:32 PM, Eric W. Biederman ebied...@xmission.com wrote:
Yinghai Lu ying...@kernel.org writes:
On Fri, Oct 5, 2012 at 2:04 PM, Eric W. Biederman ebied...@xmission.com
wrote:
Is there a git commit that explains what the 'big range' problem is?
At least on x86_64 this
Yinghai Lu ying...@kernel.org writes:
with bzImage or vmlinux?
bzImage I presume. Certainly the bzImage has lost it's 896M limit,
which is where ultimiately the 896M limite came from.
Eric
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On Fri, Oct 5, 2012 at 2:41 PM, Eric W. Biederman ebied...@xmission.com wrote:
Yinghai Lu ying...@kernel.org writes:
with bzImage or vmlinux?
bzImage I presume. Certainly the bzImage has lost it's 896M limit,
which is where ultimiately the 896M limite came from.
they are using updated
I am going to see about merging these two threads.
Yinghai Lu ying...@kernel.org writes:
On Fri, Oct 5, 2012 at 2:41 PM, Eric W. Biederman ebied...@xmission.com
wrote:
Yinghai Lu ying...@kernel.org writes:
with bzImage or vmlinux?
bzImage I presume. Certainly the bzImage has lost it's
On 10/05/2012 02:32 PM, Eric W. Biederman wrote:
Yinghai Lu ying...@kernel.org writes:
On Fri, Oct 5, 2012 at 2:04 PM, Eric W. Biederman ebied...@xmission.com wrote:
Is there a git commit that explains what the 'big range' problem is?
At least on x86_64 this was recently tested and anywhere
On 10/05/2012 02:41 PM, Eric W. Biederman wrote:
Yinghai Lu ying...@kernel.org writes:
with bzImage or vmlinux?
bzImage I presume. Certainly the bzImage has lost it's 896M limit,
which is where ultimiately the 896M limite came from.
~896M (actually comes from i386, not from bzImage...
H. Peter Anvin h...@zytor.com writes:
On 10/05/2012 02:32 PM, Eric W. Biederman wrote:
Yinghai Lu ying...@kernel.org writes:
On Fri, Oct 5, 2012 at 2:04 PM, Eric W. Biederman ebied...@xmission.com
wrote:
Is there a git commit that explains what the 'big range' problem is?
At least on
On 10/05/2012 05:28 PM, Eric W. Biederman wrote:
Seriously, any case where we can't load anywhere in physical ram on x86-64 is a
bug. i386 is another matter.
As I recall there are data structures like the IDT that only have a
32bit base address.
Not true. The only one I know of is memory
H. Peter Anvin h...@zytor.com writes:
On 10/05/2012 02:41 PM, Eric W. Biederman wrote:
Yinghai Lu ying...@kernel.org writes:
with bzImage or vmlinux?
bzImage I presume. Certainly the bzImage has lost it's 896M limit,
which is where ultimiately the 896M limite came from.
~896M (actually
That disappeared 10 years ago...
ebied...@xmission.com wrote:
H. Peter Anvin h...@zytor.com writes:
On 10/05/2012 02:41 PM, Eric W. Biederman wrote:
Yinghai Lu ying...@kernel.org writes:
with bzImage or vmlinux?
bzImage I presume. Certainly the bzImage has lost it's 896M limit,
which is
On 10/04/2012 02:46 PM, Yinghai Lu wrote:
or let xen map that page table by itself at first?
See my other post. This is bringing up the Kernel Summit algorithm again.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
On 10/04/2012 06:56 AM, Konrad Rzeszutek Wilk wrote:
What Peter had in mind is a nice system where we get rid of
this linear allocation of page-tables (so pgt_buf_start -> pgt_buf
_end are linearly allocated). His thinking (and Peter if I mess
up please correct me), is that we can stick the
On Thu, Oct 4, 2012 at 2:41 PM, H. Peter Anvin wrote:
> On 10/04/2012 02:40 PM, Yinghai Lu wrote:
>> On Thu, Oct 4, 2012 at 2:21 PM, Yinghai Lu wrote:
>>> On Thu, Oct 4, 2012 at 9:45 AM, Konrad Rzeszutek Wilk
>>> wrote:
> So could use ram under 1M to map that page table at first.
On 10/04/2012 02:40 PM, Yinghai Lu wrote:
> On Thu, Oct 4, 2012 at 2:21 PM, Yinghai Lu wrote:
>> On Thu, Oct 4, 2012 at 9:45 AM, Konrad Rzeszutek Wilk
>> wrote:
So could use ram under 1M to map that page table at first.
>>>
>>> Could or does this patch do it? And why 1MB?
>>
>> can you or
On Thu, Oct 4, 2012 at 2:21 PM, Yinghai Lu wrote:
> On Thu, Oct 4, 2012 at 9:45 AM, Konrad Rzeszutek Wilk
> wrote:
>>> So could use ram under 1M to map that page table at first.
>>
>> Could or does this patch do it? And why 1MB?
>
> can you or stefano could test attached patch on xen ?
>
on top
On Thu, Oct 4, 2012 at 9:46 AM, Konrad Rzeszutek Wilk
wrote:
>> then kdump may have problem get big range again.
>
> Is there a git commit that explains what the 'big range' problem is?
commit 7f8595bfacef279f06c82ec98d420ef54f2537e0
Author: H. Peter Anvin
Date: Thu Dec 16 19:20:41 2010 -0800
On Thu, Oct 4, 2012 at 9:45 AM, Konrad Rzeszutek Wilk
wrote:
>> So could use ram under 1M to map that page table at first.
>
> Could or does this patch do it? And why 1MB?
can you or stefano could test attached patch on xen ?
that will map the page table buffer that will be used.
under 1M,
On Thu, Oct 04, 2012 at 09:19:08AM -0700, Yinghai Lu wrote:
> On Wed, Oct 3, 2012 at 9:51 AM, Jacob Shin wrote:
> > Any comments, thoughts? hpa? Yinghai?
> >
> > So it seems that during init_memory_mapping Xen needs to modify page table
> > bits and the memory where the page tables live needs to
On Thu, Oct 04, 2012 at 08:57:55AM -0700, Yinghai Lu wrote:
> On Mon, Oct 1, 2012 at 4:00 AM, Stefano Stabellini
> wrote:
> > On Sun, 30 Sep 2012, Yinghai Lu wrote:
> >> After
> >>
> >> | commit 8548c84da2f47e71bbbe300f55edb768492575f7
> >> | Author: Takashi Iwai
> >> | Date: Sun Oct 23
On Wed, Oct 3, 2012 at 9:51 AM, Jacob Shin wrote:
> Any comments, thoughts? hpa? Yinghai?
>
> So it seems that during init_memory_mapping Xen needs to modify page table
> bits and the memory where the page tables live needs to be direct mapped at
> that time.
>
> Since we now call
On Mon, Oct 1, 2012 at 4:00 AM, Stefano Stabellini
wrote:
> On Sun, 30 Sep 2012, Yinghai Lu wrote:
>> After
>>
>> | commit 8548c84da2f47e71bbbe300f55edb768492575f7
>> | Author: Takashi Iwai
>> | Date: Sun Oct 23 23:19:12 2011 +0200
>> |
>> |x86: Fix S4 regression
>> |
>> |Commit
On Wed, Oct 03, 2012 at 11:51:06AM -0500, Jacob Shin wrote:
> On Mon, Oct 01, 2012 at 12:00:26PM +0100, Stefano Stabellini wrote:
> > On Sun, 30 Sep 2012, Yinghai Lu wrote:
> > > After
> > >
> > > | commit 8548c84da2f47e71bbbe300f55edb768492575f7
> > > | Author: Takashi Iwai
> > > | Date: Sun
On Wed, Oct 03, 2012 at 11:51:06AM -0500, Jacob Shin wrote:
On Mon, Oct 01, 2012 at 12:00:26PM +0100, Stefano Stabellini wrote:
On Sun, 30 Sep 2012, Yinghai Lu wrote:
After
| commit 8548c84da2f47e71bbbe300f55edb768492575f7
| Author: Takashi Iwai ti...@suse.de
| Date: Sun Oct
On Mon, Oct 1, 2012 at 4:00 AM, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
On Sun, 30 Sep 2012, Yinghai Lu wrote:
After
| commit 8548c84da2f47e71bbbe300f55edb768492575f7
| Author: Takashi Iwai ti...@suse.de
| Date: Sun Oct 23 23:19:12 2011 +0200
|
|x86: Fix S4
On Wed, Oct 3, 2012 at 9:51 AM, Jacob Shin jacob.s...@amd.com wrote:
Any comments, thoughts? hpa? Yinghai?
So it seems that during init_memory_mapping Xen needs to modify page table
bits and the memory where the page tables live needs to be direct mapped at
that time.
Since we now call
On Thu, Oct 04, 2012 at 08:57:55AM -0700, Yinghai Lu wrote:
On Mon, Oct 1, 2012 at 4:00 AM, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
On Sun, 30 Sep 2012, Yinghai Lu wrote:
After
| commit 8548c84da2f47e71bbbe300f55edb768492575f7
| Author: Takashi Iwai ti...@suse.de
|
On Thu, Oct 04, 2012 at 09:19:08AM -0700, Yinghai Lu wrote:
On Wed, Oct 3, 2012 at 9:51 AM, Jacob Shin jacob.s...@amd.com wrote:
Any comments, thoughts? hpa? Yinghai?
So it seems that during init_memory_mapping Xen needs to modify page table
bits and the memory where the page tables live
On Thu, Oct 4, 2012 at 9:45 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
So could use ram under 1M to map that page table at first.
Could or does this patch do it? And why 1MB?
can you or stefano could test attached patch on xen ?
that will map the page table buffer that will be
On Thu, Oct 4, 2012 at 9:46 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
then kdump may have problem get big range again.
Is there a git commit that explains what the 'big range' problem is?
commit 7f8595bfacef279f06c82ec98d420ef54f2537e0
Author: H. Peter Anvin h...@linux.intel.com
On Thu, Oct 4, 2012 at 2:21 PM, Yinghai Lu ying...@kernel.org wrote:
On Thu, Oct 4, 2012 at 9:45 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
So could use ram under 1M to map that page table at first.
Could or does this patch do it? And why 1MB?
can you or stefano could test
On 10/04/2012 02:40 PM, Yinghai Lu wrote:
On Thu, Oct 4, 2012 at 2:21 PM, Yinghai Lu ying...@kernel.org wrote:
On Thu, Oct 4, 2012 at 9:45 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
So could use ram under 1M to map that page table at first.
Could or does this patch do it? And
On Thu, Oct 4, 2012 at 2:41 PM, H. Peter Anvin h...@zytor.com wrote:
On 10/04/2012 02:40 PM, Yinghai Lu wrote:
On Thu, Oct 4, 2012 at 2:21 PM, Yinghai Lu ying...@kernel.org wrote:
On Thu, Oct 4, 2012 at 9:45 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
So could use ram under 1M to
On 10/04/2012 06:56 AM, Konrad Rzeszutek Wilk wrote:
What Peter had in mind is a nice system where we get rid of
this linear allocation of page-tables (so pgt_buf_start - pgt_buf
_end are linearly allocated). His thinking (and Peter if I mess
up please correct me), is that we can stick the
On 10/04/2012 02:46 PM, Yinghai Lu wrote:
or let xen map that page table by itself at first?
See my other post. This is bringing up the Kernel Summit algorithm again.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
On 10/03/2012 09:51 AM, Jacob Shin wrote:
Any comments, thoughts? hpa? Yinghai?
So it seems that during init_memory_mapping Xen needs to modify page table
bits and the memory where the page tables live needs to be direct mapped at
that time.
Since we now call init_memory_mapping for every
On Mon, Oct 01, 2012 at 12:00:26PM +0100, Stefano Stabellini wrote:
> On Sun, 30 Sep 2012, Yinghai Lu wrote:
> > After
> >
> > | commit 8548c84da2f47e71bbbe300f55edb768492575f7
> > | Author: Takashi Iwai
> > | Date: Sun Oct 23 23:19:12 2011 +0200
> > |
> > |x86: Fix S4 regression
> > |
> >
On Mon, Oct 01, 2012 at 12:00:26PM +0100, Stefano Stabellini wrote:
On Sun, 30 Sep 2012, Yinghai Lu wrote:
After
| commit 8548c84da2f47e71bbbe300f55edb768492575f7
| Author: Takashi Iwai ti...@suse.de
| Date: Sun Oct 23 23:19:12 2011 +0200
|
|x86: Fix S4 regression
|
|
On 10/03/2012 09:51 AM, Jacob Shin wrote:
Any comments, thoughts? hpa? Yinghai?
So it seems that during init_memory_mapping Xen needs to modify page table
bits and the memory where the page tables live needs to be direct mapped at
that time.
Since we now call init_memory_mapping for every
On Sun, 30 Sep 2012, Yinghai Lu wrote:
> After
>
> | commit 8548c84da2f47e71bbbe300f55edb768492575f7
> | Author: Takashi Iwai
> | Date: Sun Oct 23 23:19:12 2011 +0200
> |
> |x86: Fix S4 regression
> |
> |Commit 4b239f458 ("x86-64, mm: Put early page table high") causes a S4
> |
On Sun, 30 Sep 2012, Yinghai Lu wrote:
After
| commit 8548c84da2f47e71bbbe300f55edb768492575f7
| Author: Takashi Iwai ti...@suse.de
| Date: Sun Oct 23 23:19:12 2011 +0200
|
|x86: Fix S4 regression
|
|Commit 4b239f458 (x86-64, mm: Put early page table high) causes a S4
|
After
| commit 8548c84da2f47e71bbbe300f55edb768492575f7
| Author: Takashi Iwai
| Date: Sun Oct 23 23:19:12 2011 +0200
|
|x86: Fix S4 regression
|
|Commit 4b239f458 ("x86-64, mm: Put early page table high") causes a S4
|regression since 2.6.39, namely the machine reboots
After
| commit 8548c84da2f47e71bbbe300f55edb768492575f7
| Author: Takashi Iwai ti...@suse.de
| Date: Sun Oct 23 23:19:12 2011 +0200
|
|x86: Fix S4 regression
|
|Commit 4b239f458 (x86-64, mm: Put early page table high) causes a S4
|regression since 2.6.39, namely the machine reboots
68 matches
Mail list logo
