On Friday 01 February 2008 09:54, Ingo Molnar wrote:
>
> * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > > no strong preference here - pick the one you like best and send a
> > > patch please :-)
> >
> > Here you go, but I think it falls into the ACPI category.
>
> agreed - Len, would you
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > no strong preference here - pick the one you like best and send a
> > patch please :-)
>
> Here you go, but I think it falls into the ACPI category.
agreed - Len, would you mind to pick this patch up?
Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
On Friday, 1 of February 2008, Ingo Molnar wrote:
>
> * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > > arch/x86/kernel/built-in.o: In function `wakeup_start':
> > > : undefined reference to `swsusp_pg_dir'
> > >
> > > config attached.
> >
> > I see. CONFIG_HIBERNATION && CONFIG_ACPI ->
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > arch/x86/kernel/built-in.o: In function `wakeup_start':
> > : undefined reference to `swsusp_pg_dir'
> >
> > config attached.
>
> I see. CONFIG_HIBERNATION && CONFIG_ACPI -> CONFIG_ACPI_SLEEP and the
> Makefile in arch/x86/kernel/acpi/ want
On Monday, 28 of January 2008, H. Peter Anvin wrote:
> Rafael J. Wysocki wrote:
> > On Monday, 28 of January 2008, Jeremy Fitzhardinge wrote:
> >> Rafael J. Wysocki wrote:
> >>> Actually, no. We only do that with the kernel code mapping which should
> >>> be
> >>> safe as long as TLBs are not flu
Rafael J. Wysocki wrote:
On Monday, 28 of January 2008, Jeremy Fitzhardinge wrote:
Rafael J. Wysocki wrote:
Actually, no. We only do that with the kernel code mapping which should be
safe as long as TLBs are not flushed (and they aren't).
Er, what? Assuming the TLB will retain some mapping
On Monday, 28 of January 2008, H. Peter Anvin wrote:
> Rafael J. Wysocki wrote:
> > On Monday, 28 of January 2008, Pavel Machek wrote:
> >> Hi!
> >>
> > /*
> > * Swap suspend & friends need this for resume because things like the
> > intel-agp
> > * driver might have split up
On Monday, 28 of January 2008, Jeremy Fitzhardinge wrote:
> Rafael J. Wysocki wrote:
> > Actually, no. We only do that with the kernel code mapping which should be
> > safe as long as TLBs are not flushed (and they aren't).
> >
>
> Er, what? Assuming the TLB will retain some mappings while yo
Rafael J. Wysocki wrote:
Actually, no. We only do that with the kernel code mapping which should be
safe as long as TLBs are not flushed (and they aren't).
Er, what? Assuming the TLB will retain some mappings while you
overwrite the pagetable is a highly dubious prospect. Are you copying
Rafael J. Wysocki wrote:
On Monday, 28 of January 2008, Pavel Machek wrote:
Hi!
/*
* Swap suspend & friends need this for resume because things like the
intel-agp
* driver might have split up a kernel 4MB mapping.
*/
-char __nosavedata swsusp_pg_dir[PAGE_SIZE]
+char swsusp_pg_dir[PAGE_
On Monday, 28 of January 2008, H. Peter Anvin wrote:
> Jeremy Fitzhardinge wrote:
> > H. Peter Anvin wrote:
> >> and we already have to have code to synchronize the PGDs on !PAE and
> >> the PMDs on Xen (although that was supposedly getting fixed).
> >
> > No, I don't have any plans there. Xen
On Monday, 28 of January 2008, Pavel Machek wrote:
> Hi!
>
> > > > /*
> > > > * Swap suspend & friends need this for resume because things like the
> > > > intel-agp
> > > > * driver might have split up a kernel 4MB mapping.
> > > > */
> > > > -char __nosavedata swsusp_pg_dir[PAGE_SIZE]
>
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
and we already have to have code to synchronize the PGDs on !PAE and
the PMDs on Xen (although that was supposedly getting fixed).
No, I don't have any plans there. Xen will continue to require
non-shared kernel pmd, at least for a 32-bit hos
H. Peter Anvin wrote:
and we already have to have code to synchronize the PGDs on !PAE and
the PMDs on Xen (although that was supposedly getting fixed).
No, I don't have any plans there. Xen will continue to require
non-shared kernel pmd, at least for a 32-bit host. I think the point is
th
Pavel Machek wrote:
Hi!
/*
* Swap suspend & friends need this for resume because things like the
intel-agp
* driver might have split up a kernel 4MB mapping.
*/
-char __nosavedata swsusp_pg_dir[PAGE_SIZE]
+char swsusp_pg_dir[PAGE_SIZE]
thanks, applied.
Sorry, this is subtle and I've
Hi!
> > > /*
> > > * Swap suspend & friends need this for resume because things like the
> > > intel-agp
> > > * driver might have split up a kernel 4MB mapping.
> > > */
> > > -char __nosavedata swsusp_pg_dir[PAGE_SIZE]
> > > +char swsusp_pg_dir[PAGE_SIZE]
> >
> > thanks, applied.
Sorry
On Monday, 28 of January 2008, Ingo Molnar wrote:
>
> > > * driver might have split up a kernel 4MB mapping.
> > > */
> > > -char __nosavedata swsusp_pg_dir[PAGE_SIZE]
> > > +char swsusp_pg_dir[PAGE_SIZE]
>
> hm, random-qa found build breakage with this patch:
>
> arch/x86/kernel/built-in.o
> > * driver might have split up a kernel 4MB mapping.
> > */
> > -char __nosavedata swsusp_pg_dir[PAGE_SIZE]
> > +char swsusp_pg_dir[PAGE_SIZE]
hm, random-qa found build breakage with this patch:
arch/x86/kernel/built-in.o: In function `wakeup_start':
: undefined reference to `swsusp_pg_d
On Monday, 28 of January 2008, Ingo Molnar wrote:
>
> * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > Speaking of cleanups, the following one is applicable IMO.
>
> > --- linux-2.6.orig/arch/x86/mm/init_32.c
> > +++ linux-2.6/arch/x86/mm/init_32.c
> > @@ -444,23 +444,23 @@ static void __ini
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> Speaking of cleanups, the following one is applicable IMO.
> --- linux-2.6.orig/arch/x86/mm/init_32.c
> +++ linux-2.6/arch/x86/mm/init_32.c
> @@ -444,23 +444,23 @@ static void __init pagetable_init (void)
> paravirt_pagetable_setup_done(pgd_
Hi!
> > > >>I just looked at the ACPI suspend code, and it looks
> > > >>like it hacks its own identity map at runtime. Pavel,
> > > >>am I reading that code right?
> > > >
> > > >Yes, I think so, I believe we do it on both 32 and 64
> > > >bit now.
> > > >
> > >
> > > So the background to th
On Friday, 25 of January 2008, Pavel Machek wrote:
> On Thu 2008-01-24 16:27:58, H. Peter Anvin wrote:
> > Pavel Machek wrote:
> > >>>
> > >>I just looked at the ACPI suspend code, and it looks
> > >>like it hacks its own identity map at runtime. Pavel,
> > >>am I reading that code right?
> > >
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> Note. I don't believe we use either trampoline (cpu startup or acpi wakeup)
>> in the hypervisor case (esp Xen). So we should be able to completely ignore
>> Xen and do the memcpy of pgd entries.
>>
>
> Indeed. The al
On Thu 2008-01-24 16:27:58, H. Peter Anvin wrote:
> Pavel Machek wrote:
> >>>
> >>I just looked at the ACPI suspend code, and it looks
> >>like it hacks its own identity map at runtime. Pavel,
> >>am I reading that code right?
> >
> >Yes, I think so, I believe we do it on both 32 and 64
> >bit
Eric W. Biederman wrote:
Note. I don't believe we use either trampoline (cpu startup or acpi wakeup)
in the hypervisor case (esp Xen). So we should be able to completely ignore
Xen and do the memcpy of pgd entries.
Indeed. The alias mapping can be set up in
native_pagetable_setup_done()
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Jeremy Fitzhardinge wrote:
>> H. Peter Anvin wrote:
>>> No, if Xen wasn't an issue there wouldn't be anything to do for the PAE case
>>> at all (since the PGD is trivial.)
>>>
>>> Copying PMDs is more or less an analogous case of the !PAE case, once t
Eric W. Biederman wrote:
We already do this on the 64bit side. We reuse the kernel and the
identity parts from the core kernel page tables but it is actually
a distinct page table.
x86_64 has not had the identity mappings mapped in any of the
normal page tables since the relocatable kernel
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Pavel Machek wrote:
>>> I just looked at the ACPI suspend code, and it looks like it hacks its own
>>> identity map at runtime. Pavel, am I reading that code right?
>>
>> Yes, I think so, I believe we do it on both 32 and 64 bit now.
>>
>
> So t
Rafael J. Wysocki wrote:
On Friday, 25 of January 2008, H. Peter Anvin wrote:
Pavel Machek wrote:
I just looked at the ACPI suspend code, and it looks like it hacks its own
identity map at runtime. Pavel, am I reading that code right?
Yes, I think so, I believe we do it on both 32 and 64 bit
On Friday, 25 of January 2008, H. Peter Anvin wrote:
> Pavel Machek wrote:
> >>>
> >> I just looked at the ACPI suspend code, and it looks like it hacks its own
> >> identity map at runtime. Pavel, am I reading that code right?
> >
> > Yes, I think so, I believe we do it on both 32 and 64 bit no
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
No, if Xen wasn't an issue there wouldn't be anything to do for the
PAE case at all (since the PGD is trivial.)
Copying PMDs is more or less an analogous case of the !PAE case, once
the allocation is already done. The allocation should be triv
Pavel Machek wrote:
I just looked at the ACPI suspend code, and it looks like it hacks its own
identity map at runtime. Pavel, am I reading that code right?
Yes, I think so, I believe we do it on both 32 and 64 bit now.
So the background to this... we need an identity map to trampoline at
H. Peter Anvin wrote:
No, if Xen wasn't an issue there wouldn't be anything to do for the
PAE case at all (since the PGD is trivial.)
Copying PMDs is more or less an analogous case of the !PAE case, once
the allocation is already done. The allocation should be trivial
though, since this woul
On Thu 2008-01-24 15:51:24, H. Peter Anvin wrote:
> Jeremy Fitzhardinge wrote:
>> H. Peter Anvin wrote:
>>> While we're mucking around in this area, there is another thing which we
>>> should eventually get around to fixing:
>>>
>>> we need a set of page tables with an identity mapping as well as
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
Yeah, I'm aware of this particular piece of Xen braindamage, and
although I had some very unkind words to say about it, it mirrors what
we have to do for the !PAE case anyway, so it can be sort of glossed
over.
Sort of. If Xen weren't an issu
H. Peter Anvin wrote:
Yeah, I'm aware of this particular piece of Xen braindamage, and
although I had some very unkind words to say about it, it mirrors what
we have to do for the !PAE case anyway, so it can be sort of glossed
over.
Sort of. If Xen weren't an issue, then both cases are a mat
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
Yes. We'd use it during initialization and at other times when we
need trampolining, but give the swapper something which only has the
kernel map.
Hm, though Xen makes it all a bit more complex, as usual. In the PAE
case it wouldn't allow th
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
While we're mucking around in this area, there is another thing which
we should eventually get around to fixing:
we need a set of page tables with an identity mapping as well as the
kernel mapping, for trampolining (during startup, but also dur
H. Peter Anvin wrote:
Yes. We'd use it during initialization and at other times when we
need trampolining, but give the swapper something which only has the
kernel map.
Hm, though Xen makes it all a bit more complex, as usual. In the PAE
case it wouldn't allow the pmd to be shared, so you'd
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
While we're mucking around in this area, there is another thing which
we should eventually get around to fixing:
we need a set of page tables with an identity mapping as well as the
kernel mapping, for trampolining (during startup, but also dur
H. Peter Anvin wrote:
While we're mucking around in this area, there is another thing which
we should eventually get around to fixing:
we need a set of page tables with an identity mapping as well as the
kernel mapping, for trampolining (during startup, but also during
things like ACPI suspen
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
Yeah, and it's ugly for the kernel proper, so that bit is a
no-brainer. It's just a matter of hammering out the details.
It doesn't sound from the above that you have any opinion either way
about reusing the initial page tables or creating a n
H. Peter Anvin wrote:
Yeah, and it's ugly for the kernel proper, so that bit is a
no-brainer. It's just a matter of hammering out the details.
It doesn't sound from the above that you have any opinion either way
about reusing the initial page tables or creating a new set, as long
as they're
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
In other words, reusing the early page tables isn't all that
straightforward. It may easily be that it's better to build a new set
of page tables from scratch, however, it would *still* be beneficial
to have the early page tables be in the same
H. Peter Anvin wrote:
In other words, reusing the early page tables isn't all that
straightforward. It may easily be that it's better to build a new set
of page tables from scratch, however, it would *still* be beneficial
to have the early page tables be in the same format as the later one,
s
Ian Campbell wrote:
I'm not sure how PSE comes to be used ever though -- an EFI only thing?
Using the qemu monitor I could see a bunch of NX bits used when NX was
available.
This is part of the trickiness with re-using the early pagetables
instead of rebuilding them from scratch - if PSE is
On Wed, 2008-01-23 at 17:06 -0800, Jeremy Fitzhardinge wrote:
> Ian Campbell wrote:
> > FYI, CONFIG_DEBUG_PAGEALLOC+PAE is broken. I'll dig in but it might be
> > the weekend before I get a chance (there's a beer festival in town ;-)).
> >
>
> I'm poking around trying to get Xen working again
Ian Campbell wrote:
FYI, CONFIG_DEBUG_PAGEALLOC+PAE is broken. I'll dig in but it might be
the weekend before I get a chance (there's a beer festival in town ;-)).
I'm poking around trying to get Xen working again as well; I may end up
fixing it in passing.
At the moment I've got a proble
On Tue, 2008-01-22 at 21:36 +0100, Ingo Molnar wrote:
> * H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>
> >> Seems reasonable to me. I'll integrate your asm diff with the other
> >> changes and give it a whirl.
> >
> > This version boots into userspace on both PAE and !PAE. You want to
> > take
On Tue, 2008-01-22 at 13:00 -0800, H. Peter Anvin wrote:
> Ian Campbell wrote:
> > On Tue, 2008-01-22 at 21:36 +0100, Ingo Molnar wrote:
> >> * H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> >>
> Seems reasonable to me. I'll integrate your asm diff with the other
> changes and give it a wh
Ian Campbell wrote:
On Tue, 2008-01-22 at 21:36 +0100, Ingo Molnar wrote:
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Seems reasonable to me. I'll integrate your asm diff with the other
changes and give it a whirl.
This version boots into userspace on both PAE and !PAE. You want to
take it f
On Tue, 2008-01-22 at 21:36 +0100, Ingo Molnar wrote:
> * H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>
> >> Seems reasonable to me. I'll integrate your asm diff with the other
> >> changes and give it a whirl.
> >
> > This version boots into userspace on both PAE and !PAE. You want to
> > take
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>> ok, i'll wait for Ian to submit the final (tested) version then. A
>> few possible complications are: PSE-less boxes, 32-bit PAGEALLOC
>> bootups with tons of RAM, NX-less boxes and NX-able boxes :)
>
> PSE-less should be less of an issue than maki
Ingo Molnar wrote:
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Seems reasonable to me. I'll integrate your asm diff with the other
changes and give it a whirl.
This version boots into userspace on both PAE and !PAE. You want to
take it from here?
ok, i'll wait for Ian to submit the final (t
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>> Seems reasonable to me. I'll integrate your asm diff with the other
>> changes and give it a whirl.
>
> This version boots into userspace on both PAE and !PAE. You want to
> take it from here?
ok, i'll wait for Ian to submit the final (tested) ve
Ian Campbell wrote:
On Tue, 2008-01-22 at 10:23 -0800, H. Peter Anvin wrote:
Ian Campbell wrote:
Anyhow, I don't feel all that strongly about it so if the opinion of the
early start of day maintainer(s) is strongly in favour of ASM I'll defer
to that.
My opinion is that I want it done properly
On Tue, 2008-01-22 at 10:23 -0800, H. Peter Anvin wrote:
> Ian Campbell wrote:
> > Anyhow, I don't feel all that strongly about it so if the opinion of the
> > early start of day maintainer(s) is strongly in favour of ASM I'll defer
> > to that.
> >
>
> My opinion is that I want it done properly
Ian Campbell wrote:
On Mon, 2008-01-21 at 18:16 -0800, H. Peter Anvin wrote:
Ian Campbell wrote:
I'm just preparing to send out a version which uses the native_* way of
doing things, its not actually as clean as I would like so I'd be
interested to see the ASM variant.
This is the asm version
On Mon, 2008-01-21 at 18:16 -0800, H. Peter Anvin wrote:
> Ian Campbell wrote:
> >
> > I'm just preparing to send out a version which uses the native_* way of
> > doing things, its not actually as clean as I would like so I'd be
> > interested to see the ASM variant.
> >
>
> This is the asm ver
Ingo Molnar wrote:
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
I was thinking about this yesterday, and it seems to me that there are
two cleaner options here...
- either we should put in the full machinery to be able to run C code
compiled with -fPIC/-fPIE before paging is enabled. Unfortu
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> I was thinking about this yesterday, and it seems to me that there are
> two cleaner options here...
>
> - either we should put in the full machinery to be able to run C code
> compiled with -fPIC/-fPIE before paging is enabled. Unfortunately gcc
Ian Campbell wrote:
I'm just preparing to send out a version which uses the native_* way of
doing things, its not actually as clean as I would like so I'd be
interested to see the ASM variant.
This is the asm version I came up with. This is only the actual
assembly part; it doesn't require
On Mon, 2008-01-21 at 13:38 -0800, H. Peter Anvin wrote:
> Ian Campbell wrote:
> > On Sun, 2008-01-20 at 20:30 +0200, Mika Penttilä wrote:
> >>>
> >> You have dropped the requirement to map all of low memory (the boot
> >> allocator is used for instance to construct physical mem mapping).
> >
Ian Campbell wrote:
On Sun, 2008-01-20 at 20:30 +0200, Mika Penttilä wrote:
You have dropped the requirement to map all of low memory (the boot
allocator is used for instance to construct physical mem mapping).
Either you should fix your INIT_MAP_BEYOND_END or make a big comment
telling us
On Sun, 2008-01-20 at 20:30 +0200, Mika Penttilä wrote:
> > + * This is how much memory *in addition to the memory covered up to
> > + * and including _end* we need mapped initially. We need one bit for
> > + * each possible page, but only in low memory, which means
> > + * 2^32/4096/8 = 128K wor
Andi Kleen wrote:
There are various loaders (kexec, elilo, ...) that skip the 16bit code
and jump directly to 32bit head.S. So in theory those could hit it.
But still having the loop only is probably fine.
It's probably just as well, since we don't really know how to get a
message out in such a
> >There are various loaders (kexec, elilo, ...) that skip the 16bit code
> >and jump directly to 32bit head.S. So in theory those could hit it.
> >But still having the loop only is probably fine.
> >
>
> It's probably just as well, since we don't really know how to get a
> message out in such an
Andi Kleen wrote:
On Sun, Jan 20, 2008 at 04:44:50PM +, Ian Campbell wrote:
Indeed it does. I don't have any non-PAE to test it but I turned the
failure case into a simple jmp to hlt_loop since we ought never to get
here in any case.
There are various loaders (kexec, elilo, ...) that skip
+ * This is how much memory *in addition to the memory covered up to
+ * and including _end* we need mapped initially. We need one bit for
+ * each possible page, but only in low memory, which means
+ * 2^32/4096/8 = 128K worst case (4G/4G split.)
+ *
+ * Modulo rounding, each megabyte assigned
On Sun, Jan 20, 2008 at 04:44:50PM +, Ian Campbell wrote:
> Indeed it does. I don't have any non-PAE to test it but I turned the
> failure case into a simple jmp to hlt_loop since we ought never to get
> here in any case.
There are various loaders (kexec, elilo, ...) that skip the 16bit code
a
On Sun, 2008-01-20 at 00:07 +0100, Andi Kleen wrote:
> Ian Campbell <[EMAIL PROTECTED]> writes:
> > +#ifdef CONFIG_X86_PAE
> > +err_no_pae:
> > + /* It is probably too early but we might as well try... */
>
> Without a low identity mapping early_printk will not work and printk
> definitely not
Andi Kleen wrote:
That will break if the kernel is > 4GB won't it? Also same for pmd.
The kernel can't be > 4 GB; after all, we're running here with paging
disabled, so inherently we're < 4 GB...
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Ian Campbell <[EMAIL PROTECTED]> writes:
> +1:
> +#ifdef CONFIG_X86_PAE
> + btl $5, %eax
> + jnc err_no_pae
> +#endif
>
> xorl %ebx,%ebx /* This is the boot CPU (BSP) */
> jmp 3f
> +
> +#ifdef CONFIG_X86_PAE
> +err_no_pae:
> + /* It is probably too
Specifically the boot time page tables in a CONFIG_X86_PAE=y enabled
kernel are in PAE format.
early_ioremap is updated to use the standard page table accessors.
Derived from an earlier patch by Eric Biederman.
Signed-off-by: Ian Campbell <[EMAIL PROTECTED]>
Cc: Thomas Gleixner <[EMAIL PROTECTED
74 matches
Mail list logo
