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
* 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
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/
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 mind to pick
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
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
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
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
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
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
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
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.
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:
>
>
> > * 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
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
* 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)
>
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
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 you
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
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 will
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
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: In function
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
* 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_base);
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 flushed (and they
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 a kernel 4MB mapping.
*/
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
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
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
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 __init
* 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_dir'
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!
> > > >>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
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
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
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 now.
So the
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 alias mapping
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 this... we need an identity map to
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?
Yes, I think so, I
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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 as well;
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
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,
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
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:
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
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
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
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
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
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
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
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 now.
For
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
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
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
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 the background to
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:
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
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()
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
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 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 from here?
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
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
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
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
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
* 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)
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
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
1 - 100 of 142 matches
Mail list logo
