Commit-ID: ec400ddeff200b068ddc6c70f7321f49ecf32ed5
Gitweb: http://git.kernel.org/tip/ec400ddeff200b068ddc6c70f7321f49ecf32ed5
Author: Fenghua Yu
AuthorDate: Thu, 20 Dec 2012 23:44:28 -0800
Committer: H. Peter Anvin
CommitDate: Thu, 31 Jan 2013 13:19:18 -0800
Commit-ID: ec400ddeff200b068ddc6c70f7321f49ecf32ed5
Gitweb: http://git.kernel.org/tip/ec400ddeff200b068ddc6c70f7321f49ecf32ed5
Author: Fenghua Yu fenghua...@intel.com
AuthorDate: Thu, 20 Dec 2012 23:44:28 -0800
Committer: H. Peter Anvin h...@linux.intel.com
CommitDate: Thu, 31 Jan 2013
On 12/19/2012 08:16 PM, Jacob Shin wrote:
>
> Not exactly sure why the wierd boundaries, I'll have to ask the BIOS
> side folks to be sure. But if I were to guess ..
>
> Here is the NUMA spew out, physically there is 128 GB connected to
> each memory controller node. The PCI MMIO region starts
On Wed, Dec 19, 2012 at 06:37:45PM -0800, H. Peter Anvin wrote:
> On 12/19/2012 04:29 PM, Jacob Shin wrote:
> > On Wed, Dec 19, 2012 at 04:24:09PM -0800, H. Peter Anvin wrote:
> >> On 12/19/2012 04:07 PM, Jacob Shin wrote:
> >>>
> >>> From what I remember, accessing memory around the memory hole
On 12/19/2012 04:29 PM, Jacob Shin wrote:
> On Wed, Dec 19, 2012 at 04:24:09PM -0800, H. Peter Anvin wrote:
>> On 12/19/2012 04:07 PM, Jacob Shin wrote:
>>>
>>> From what I remember, accessing memory around the memory hole (not
>>> just the HT hole, but e03800 ~ 100 on our mentioned
On 12/19/2012 04:29 PM, Jacob Shin wrote:
> On Wed, Dec 19, 2012 at 04:24:09PM -0800, H. Peter Anvin wrote:
>> On 12/19/2012 04:07 PM, Jacob Shin wrote:
>>>
>>> From what I remember, accessing memory around the memory hole (not
>>> just the HT hole, but e03800 ~ 100 on our mentioned
On Wed, Dec 19, 2012 at 04:24:09PM -0800, H. Peter Anvin wrote:
> On 12/19/2012 04:07 PM, Jacob Shin wrote:
> >
> > From what I remember, accessing memory around the memory hole (not
> > just the HT hole, but e03800 ~ 100 on our mentioned system
> > ) generated prefetches because the
On 12/19/2012 04:07 PM, Jacob Shin wrote:
>
> From what I remember, accessing memory around the memory hole (not
> just the HT hole, but e03800 ~ 100 on our mentioned system
> ) generated prefetches because the memory hole was marked as WB in PAT.
>
> I'll take a look at the system
On 12/19/2012 04:10 PM, Borislav Petkov wrote:
On Wed, Dec 19, 2012 at 04:02:25PM -0800, H. Peter Anvin wrote:
The goal should be to have this into -tip and -next by the middle of
January in order to make the 3.9 merge window, I think.
...and an easy back-out strategy in case there are too
On Wed, Dec 19, 2012 at 04:02:25PM -0800, H. Peter Anvin wrote:
> The goal should be to have this into -tip and -next by the middle of
> January in order to make the 3.9 merge window, I think.
...and an easy back-out strategy in case there are too many issues while
testing. Maybe don't merge it
On Wed, Dec 19, 2012 at 03:50:14PM -0800, H. Peter Anvin wrote:
> On 12/19/2012 03:40 PM, Jacob Shin wrote:
> >>
> >>Just make the hole a bit bigger, so it starts at 0xfc, then you
> >>only need one MTRR. This is the correct BIOS-level fix, and it really
> >>needs to happen.
> >>
> >>Do
On 12/19/2012 03:40 PM, Borislav Petkov wrote:
This is done on the BSP, right? So we can measure it how long it takes
by taking TSC values of start and end.
Yes, and we can count the number of #PF traps cheaply enough. It would
be interesting to put a counter on the number of #PFs and the
On 12/19/2012 03:55 PM, Borislav Petkov wrote:
On Wed, Dec 19, 2012 at 03:50:14PM -0800, H. Peter Anvin wrote:
We are trying to discuss mitigation strategies with you, but you
haven't really given us any useful information, e.g. what happens near
the various boundaries of the hole, what could
On 12/19/2012 03:21 PM, Jacob Shin wrote:
On Thu, Dec 20, 2012 at 12:03:29AM +0100, Borislav Petkov wrote:
On Wed, Dec 19, 2012 at 04:59:41PM -0600, Jacob Shin wrote:
I can check but right, they might be used up. But even if we had slots
available, the memory range that needs to be covered is
On Wed, Dec 19, 2012 at 03:50:14PM -0800, H. Peter Anvin wrote:
> We are trying to discuss mitigation strategies with you, but you
> haven't really given us any useful information, e.g. what happens near
> the various boundaries of the hole, what could trigger prefeching into
> the range, and what
On 12/19/2012 03:40 PM, Jacob Shin wrote:
Just make the hole a bit bigger, so it starts at 0xfc, then you
only need one MTRR. This is the correct BIOS-level fix, and it really
needs to happen.
Do these systems actually exist in the field or are they engineering
prototypes? In the
On Wed, Dec 19, 2012 at 3:43 PM, H. Peter Anvin wrote:
> On 12/19/2012 03:40 PM, Yinghai Lu wrote:
>>
>> On Wed, Dec 19, 2012 at 3:22 PM, H. Peter Anvin wrote:
>>>
>>> The other bit is that building the real kernel page tables iteratively
>>> (ignoring the early page tables here) is safer, since
On Wed, Dec 19, 2012 at 3:40 PM, Jacob Shin wrote:
> On Wed, Dec 19, 2012 at 03:22:13PM -0800, H. Peter Anvin wrote:
>> The other bit is that building the real kernel page tables iteratively
>> (ignoring the early page tables here) is safer, since the real page
>> table builder is fully aware of
On 12/19/2012 03:40 PM, Yinghai Lu wrote:
On Wed, Dec 19, 2012 at 3:22 PM, H. Peter Anvin wrote:
The other bit is that building the real kernel page tables iteratively
(ignoring the early page tables here) is safer, since the real page
table builder is fully aware of the memory map. This
On Wed, Dec 19, 2012 at 03:22:13PM -0800, H. Peter Anvin wrote:
> On 12/19/2012 03:03 PM, Borislav Petkov wrote:
> > On Wed, Dec 19, 2012 at 04:59:41PM -0600, Jacob Shin wrote:
> >> I can check but right, they might be used up. But even if we had slots
> >> available, the memory range that needs
On Wed, Dec 19, 2012 at 3:22 PM, H. Peter Anvin wrote:
> The other bit is that building the real kernel page tables iteratively
> (ignoring the early page tables here) is safer, since the real page
> table builder is fully aware of the memory map. This means any
> "spillover" from the early page
On Wed, Dec 19, 2012 at 03:22:13PM -0800, H. Peter Anvin wrote:
[ … ]
> Now, calming down a little bit, we are definitely dealing with BIOS
> engineers and so f*ckups are going to happen, again and again.
Yeppers.
> The only truly "safe" option is to limit early mappings to 4K pages.
> This is
On 12/19/2012 03:30 PM, Borislav Petkov wrote:
On Wed, Dec 19, 2012 at 03:17:59PM -0800, H. Peter Anvin wrote:
I presume with "too big" he really means "oddly shaped".
Yeah, that's why it could be enlarged a little in order to adjust it to
the MTRR scheme. This is what the BKDG says about it:
On Wed, Dec 19, 2012 at 03:17:59PM -0800, H. Peter Anvin wrote:
> I presume with "too big" he really means "oddly shaped".
Yeah, that's why it could be enlarged a little in order to adjust it to
the MTRR scheme. This is what the BKDG says about it:
PhysMask and PhysBase are used together to
On 12/19/2012 02:55 PM, Jacob Shin wrote:
>
> Well, really the problem is with any memory hole above 4GB that is too
> big to be covered by variable range MTRRs as UC. Because the kernel
> use to just simply do init_memory_mapping for 4GB ~ top of memory,
> any memory hole above 4GB are marked as
On 12/19/2012 03:03 PM, Borislav Petkov wrote:
> On Wed, Dec 19, 2012 at 04:59:41PM -0600, Jacob Shin wrote:
>> I can check but right, they might be used up. But even if we had slots
>> available, the memory range that needs to be covered is in large
>> enough address and aligned in such a way
On Thu, Dec 20, 2012 at 12:03:29AM +0100, Borislav Petkov wrote:
> On Wed, Dec 19, 2012 at 04:59:41PM -0600, Jacob Shin wrote:
> > I can check but right, they might be used up. But even if we had slots
> > available, the memory range that needs to be covered is in large
> > enough address and
On 12/19/2012 03:00 PM, Borislav Petkov wrote:
> On Wed, Dec 19, 2012 at 04:55:06PM -0600, Jacob Shin wrote:
>> Well, really the problem is with any memory hole above 4GB that is too
>> big to be covered by variable range MTRRs as UC.
>
> Why, their PhysBase field is the 40 MSB bits of the
On Wed, Dec 19, 2012 at 04:59:41PM -0600, Jacob Shin wrote:
> I can check but right, they might be used up. But even if we had slots
> available, the memory range that needs to be covered is in large
> enough address and aligned in such a way that you cannot cover it with
> variable range MTRRs.
On Wed, Dec 19, 2012 at 04:55:06PM -0600, Jacob Shin wrote:
> Well, really the problem is with any memory hole above 4GB that is too
> big to be covered by variable range MTRRs as UC.
Why, their PhysBase field is the 40 MSB bits of the physical address.
That should be more than TB.
--
On Wed, Dec 19, 2012 at 11:51:55PM +0100, Borislav Petkov wrote:
> On Wed, Dec 19, 2012 at 02:25:44PM -0800, H. Peter Anvin wrote:
> > The real question is what we can do to mitigate the damage.
>
> Let's try the first thing that comes to mind: waste a variable MTRR on
> it:
>
> [0.00]
On 12/19/2012 02:47 PM, Yinghai Lu wrote:
>
> on demand to only map 2M will help ?
> or have to return to v6 version for-x86-boot ?
>
Why would 2M be inherently better than 1G? I realize it works for the
*one particular system* that you have a specimen for, but that is not a
sensible approach
On Wed, Dec 19, 2012 at 02:25:44PM -0800, H. Peter Anvin wrote:
> On 12/19/2012 02:05 PM, Jacob Shin wrote:
> >On Wed, Dec 19, 2012 at 01:48:33PM -0800, H. Peter Anvin wrote:
> >>There are a few very serious problems we need to figure out related to
> >>generalizing very early boot. If this
On Wed, Dec 19, 2012 at 02:25:44PM -0800, H. Peter Anvin wrote:
> The real question is what we can do to mitigate the damage.
Let's try the first thing that comes to mind: waste a variable MTRR on
it:
[0.00] MTRR variable ranges enabled:
[0.00] 0 base mask
On Wed, Dec 19, 2012 at 2:25 PM, H. Peter Anvin wrote:
>
> The problem is that before we have awareness of the memory map, we need to
> map things in order to access them. This is a big problem and right now
> there are ridiculous heuristics. I have been working on mapping on demand,
> but
On 12/19/2012 02:05 PM, Jacob Shin wrote:
On Wed, Dec 19, 2012 at 01:48:33PM -0800, H. Peter Anvin wrote:
There are a few very serious problems we need to figure out related to
generalizing very early boot. If this range gets mapped, will the CPU treat it
as WB? If so, with what
On Wed, Dec 19, 2012 at 01:48:33PM -0800, H. Peter Anvin wrote:
> There are a few very serious problems we need to figure out related to
> generalizing very early boot. If this range gets mapped, will the CPU treat
> it as WB? If so, with what consequences for either the HT region or the hole
There are a few very serious problems we need to figure out related to
generalizing very early boot. If this range gets mapped, will the CPU treat it
as WB? If so, with what consequences for either the HT region or the hole
below it?
Jacob Shin wrote:
>On Wed, Dec 19, 2012 at 09:37:51PM
On Wed, Dec 19, 2012 at 09:37:51PM +0100, Borislav Petkov wrote:
> On Sat, Dec 15, 2012 at 03:17:05PM -0800, H. Peter Anvin wrote:
> > On 12/15/2012 03:15 PM, Yinghai Lu wrote:
> > >>
> > >>That is for the kernel region itself (that code is actually unchanged from
> > >>the current code), and yes,
On Sat, Dec 15, 2012 at 03:17:05PM -0800, H. Peter Anvin wrote:
> On 12/15/2012 03:15 PM, Yinghai Lu wrote:
> >>
> >>That is for the kernel region itself (that code is actually unchanged from
> >>the current code), and yes, we could cap that one to _end if there are
> >>systems which have bugs in
On Sat, Dec 15, 2012 at 03:17:05PM -0800, H. Peter Anvin wrote:
On 12/15/2012 03:15 PM, Yinghai Lu wrote:
That is for the kernel region itself (that code is actually unchanged from
the current code), and yes, we could cap that one to _end if there are
systems which have bugs in that area.
On Wed, Dec 19, 2012 at 09:37:51PM +0100, Borislav Petkov wrote:
On Sat, Dec 15, 2012 at 03:17:05PM -0800, H. Peter Anvin wrote:
On 12/15/2012 03:15 PM, Yinghai Lu wrote:
That is for the kernel region itself (that code is actually unchanged from
the current code), and yes, we could cap
There are a few very serious problems we need to figure out related to
generalizing very early boot. If this range gets mapped, will the CPU treat it
as WB? If so, with what consequences for either the HT region or the hole
below it?
Jacob Shin jacob.s...@amd.com wrote:
On Wed, Dec 19, 2012
On Wed, Dec 19, 2012 at 01:48:33PM -0800, H. Peter Anvin wrote:
There are a few very serious problems we need to figure out related to
generalizing very early boot. If this range gets mapped, will the CPU treat
it as WB? If so, with what consequences for either the HT region or the hole
On 12/19/2012 02:05 PM, Jacob Shin wrote:
On Wed, Dec 19, 2012 at 01:48:33PM -0800, H. Peter Anvin wrote:
There are a few very serious problems we need to figure out related to
generalizing very early boot. If this range gets mapped, will the CPU treat it
as WB? If so, with what
On Wed, Dec 19, 2012 at 2:25 PM, H. Peter Anvin h...@zytor.com wrote:
The problem is that before we have awareness of the memory map, we need to
map things in order to access them. This is a big problem and right now
there are ridiculous heuristics. I have been working on mapping on demand,
On Wed, Dec 19, 2012 at 02:25:44PM -0800, H. Peter Anvin wrote:
The real question is what we can do to mitigate the damage.
Let's try the first thing that comes to mind: waste a variable MTRR on
it:
[0.00] MTRR variable ranges enabled:
[0.00] 0 base mask
On Wed, Dec 19, 2012 at 02:25:44PM -0800, H. Peter Anvin wrote:
On 12/19/2012 02:05 PM, Jacob Shin wrote:
On Wed, Dec 19, 2012 at 01:48:33PM -0800, H. Peter Anvin wrote:
There are a few very serious problems we need to figure out related to
generalizing very early boot. If this range gets
On 12/19/2012 02:47 PM, Yinghai Lu wrote:
on demand to only map 2M will help ?
or have to return to v6 version for-x86-boot ?
Why would 2M be inherently better than 1G? I realize it works for the
*one particular system* that you have a specimen for, but that is not a
sensible approach for
On Wed, Dec 19, 2012 at 11:51:55PM +0100, Borislav Petkov wrote:
On Wed, Dec 19, 2012 at 02:25:44PM -0800, H. Peter Anvin wrote:
The real question is what we can do to mitigate the damage.
Let's try the first thing that comes to mind: waste a variable MTRR on
it:
[0.00] MTRR
On Wed, Dec 19, 2012 at 04:55:06PM -0600, Jacob Shin wrote:
Well, really the problem is with any memory hole above 4GB that is too
big to be covered by variable range MTRRs as UC.
Why, their PhysBase field is the 40 MSB bits of the physical address.
That should be more than TB.
--
On Wed, Dec 19, 2012 at 04:59:41PM -0600, Jacob Shin wrote:
I can check but right, they might be used up. But even if we had slots
available, the memory range that needs to be covered is in large
enough address and aligned in such a way that you cannot cover it with
variable range MTRRs.
On 12/19/2012 03:00 PM, Borislav Petkov wrote:
On Wed, Dec 19, 2012 at 04:55:06PM -0600, Jacob Shin wrote:
Well, really the problem is with any memory hole above 4GB that is too
big to be covered by variable range MTRRs as UC.
Why, their PhysBase field is the 40 MSB bits of the physical
On Thu, Dec 20, 2012 at 12:03:29AM +0100, Borislav Petkov wrote:
On Wed, Dec 19, 2012 at 04:59:41PM -0600, Jacob Shin wrote:
I can check but right, they might be used up. But even if we had slots
available, the memory range that needs to be covered is in large
enough address and aligned in
On 12/19/2012 03:03 PM, Borislav Petkov wrote:
On Wed, Dec 19, 2012 at 04:59:41PM -0600, Jacob Shin wrote:
I can check but right, they might be used up. But even if we had slots
available, the memory range that needs to be covered is in large
enough address and aligned in such a way that you
On 12/19/2012 02:55 PM, Jacob Shin wrote:
Well, really the problem is with any memory hole above 4GB that is too
big to be covered by variable range MTRRs as UC. Because the kernel
use to just simply do init_memory_mapping for 4GB ~ top of memory,
any memory hole above 4GB are marked as WB
On Wed, Dec 19, 2012 at 03:17:59PM -0800, H. Peter Anvin wrote:
I presume with too big he really means oddly shaped.
Yeah, that's why it could be enlarged a little in order to adjust it to
the MTRR scheme. This is what the BKDG says about it:
PhysMask and PhysBase are used together to determine
On 12/19/2012 03:30 PM, Borislav Petkov wrote:
On Wed, Dec 19, 2012 at 03:17:59PM -0800, H. Peter Anvin wrote:
I presume with too big he really means oddly shaped.
Yeah, that's why it could be enlarged a little in order to adjust it to
the MTRR scheme. This is what the BKDG says about it:
On Wed, Dec 19, 2012 at 03:22:13PM -0800, H. Peter Anvin wrote:
[ … ]
Now, calming down a little bit, we are definitely dealing with BIOS
engineers and so f*ckups are going to happen, again and again.
Yeppers.
The only truly safe option is to limit early mappings to 4K pages.
This is
On Wed, Dec 19, 2012 at 3:22 PM, H. Peter Anvin h...@zytor.com wrote:
The other bit is that building the real kernel page tables iteratively
(ignoring the early page tables here) is safer, since the real page
table builder is fully aware of the memory map. This means any
spillover from the
On Wed, Dec 19, 2012 at 03:22:13PM -0800, H. Peter Anvin wrote:
On 12/19/2012 03:03 PM, Borislav Petkov wrote:
On Wed, Dec 19, 2012 at 04:59:41PM -0600, Jacob Shin wrote:
I can check but right, they might be used up. But even if we had slots
available, the memory range that needs to be
On 12/19/2012 03:40 PM, Yinghai Lu wrote:
On Wed, Dec 19, 2012 at 3:22 PM, H. Peter Anvin h...@zytor.com wrote:
The other bit is that building the real kernel page tables iteratively
(ignoring the early page tables here) is safer, since the real page
table builder is fully aware of the memory
On Wed, Dec 19, 2012 at 3:40 PM, Jacob Shin jacob.s...@amd.com wrote:
On Wed, Dec 19, 2012 at 03:22:13PM -0800, H. Peter Anvin wrote:
The other bit is that building the real kernel page tables iteratively
(ignoring the early page tables here) is safer, since the real page
table builder is
On Wed, Dec 19, 2012 at 3:43 PM, H. Peter Anvin h...@zytor.com wrote:
On 12/19/2012 03:40 PM, Yinghai Lu wrote:
On Wed, Dec 19, 2012 at 3:22 PM, H. Peter Anvin h...@zytor.com wrote:
The other bit is that building the real kernel page tables iteratively
(ignoring the early page tables here)
On 12/19/2012 03:40 PM, Jacob Shin wrote:
Just make the hole a bit bigger, so it starts at 0xfc, then you
only need one MTRR. This is the correct BIOS-level fix, and it really
needs to happen.
Do these systems actually exist in the field or are they engineering
prototypes? In the
On Wed, Dec 19, 2012 at 03:50:14PM -0800, H. Peter Anvin wrote:
We are trying to discuss mitigation strategies with you, but you
haven't really given us any useful information, e.g. what happens near
the various boundaries of the hole, what could trigger prefeching into
the range, and what it
On 12/19/2012 03:21 PM, Jacob Shin wrote:
On Thu, Dec 20, 2012 at 12:03:29AM +0100, Borislav Petkov wrote:
On Wed, Dec 19, 2012 at 04:59:41PM -0600, Jacob Shin wrote:
I can check but right, they might be used up. But even if we had slots
available, the memory range that needs to be covered is
On 12/19/2012 03:55 PM, Borislav Petkov wrote:
On Wed, Dec 19, 2012 at 03:50:14PM -0800, H. Peter Anvin wrote:
We are trying to discuss mitigation strategies with you, but you
haven't really given us any useful information, e.g. what happens near
the various boundaries of the hole, what could
On 12/19/2012 03:40 PM, Borislav Petkov wrote:
This is done on the BSP, right? So we can measure it how long it takes
by taking TSC values of start and end.
Yes, and we can count the number of #PF traps cheaply enough. It would
be interesting to put a counter on the number of #PFs and the
On Wed, Dec 19, 2012 at 03:50:14PM -0800, H. Peter Anvin wrote:
On 12/19/2012 03:40 PM, Jacob Shin wrote:
Just make the hole a bit bigger, so it starts at 0xfc, then you
only need one MTRR. This is the correct BIOS-level fix, and it really
needs to happen.
Do these systems
On Wed, Dec 19, 2012 at 04:02:25PM -0800, H. Peter Anvin wrote:
The goal should be to have this into -tip and -next by the middle of
January in order to make the 3.9 merge window, I think.
...and an easy back-out strategy in case there are too many issues while
testing. Maybe don't merge it
On 12/19/2012 04:10 PM, Borislav Petkov wrote:
On Wed, Dec 19, 2012 at 04:02:25PM -0800, H. Peter Anvin wrote:
The goal should be to have this into -tip and -next by the middle of
January in order to make the 3.9 merge window, I think.
...and an easy back-out strategy in case there are too
On 12/19/2012 04:07 PM, Jacob Shin wrote:
From what I remember, accessing memory around the memory hole (not
just the HT hole, but e03800 ~ 100 on our mentioned system
) generated prefetches because the memory hole was marked as WB in PAT.
I'll take a look at the system again,
On Wed, Dec 19, 2012 at 04:24:09PM -0800, H. Peter Anvin wrote:
On 12/19/2012 04:07 PM, Jacob Shin wrote:
From what I remember, accessing memory around the memory hole (not
just the HT hole, but e03800 ~ 100 on our mentioned system
) generated prefetches because the memory
On 12/19/2012 04:29 PM, Jacob Shin wrote:
On Wed, Dec 19, 2012 at 04:24:09PM -0800, H. Peter Anvin wrote:
On 12/19/2012 04:07 PM, Jacob Shin wrote:
From what I remember, accessing memory around the memory hole (not
just the HT hole, but e03800 ~ 100 on our mentioned system
)
On 12/19/2012 04:29 PM, Jacob Shin wrote:
On Wed, Dec 19, 2012 at 04:24:09PM -0800, H. Peter Anvin wrote:
On 12/19/2012 04:07 PM, Jacob Shin wrote:
From what I remember, accessing memory around the memory hole (not
just the HT hole, but e03800 ~ 100 on our mentioned system
)
On Wed, Dec 19, 2012 at 06:37:45PM -0800, H. Peter Anvin wrote:
On 12/19/2012 04:29 PM, Jacob Shin wrote:
On Wed, Dec 19, 2012 at 04:24:09PM -0800, H. Peter Anvin wrote:
On 12/19/2012 04:07 PM, Jacob Shin wrote:
From what I remember, accessing memory around the memory hole (not
just the
On 12/19/2012 08:16 PM, Jacob Shin wrote:
Not exactly sure why the wierd boundaries, I'll have to ask the BIOS
side folks to be sure. But if I were to guess ..
Here is the NUMA spew out, physically there is 128 GB connected to
each memory controller node. The PCI MMIO region starts at
Jan,
Can you check if attached patch is going to break KGDB?
Thanks
Yinghai
move_down_early_trap_init.patch
Description: Binary data
On Mon, Dec 17, 2012 at 5:11 PM, Yinghai Lu wrote:
> On Mon, Dec 17, 2012 at 3:26 PM, Yinghai Lu wrote:
>> On Mon, Dec 17, 2012 at 3:11 PM, H. Peter Anvin wrote:
>>> On 12/17/2012 02:47 PM, Yinghai Lu wrote:
Peter, can you check that branch again?
I moved the
On Mon, Dec 17, 2012 at 3:26 PM, Yinghai Lu wrote:
> On Mon, Dec 17, 2012 at 3:11 PM, H. Peter Anvin wrote:
>> On 12/17/2012 02:47 PM, Yinghai Lu wrote:
>>>
>>>
>>> Peter, can you check that branch again?
>>>
>>> I moved the early_trap_init after init_mem_mapping.
>>> so for 64bit native,
On Mon, Dec 17, 2012 at 3:11 PM, H. Peter Anvin wrote:
> On 12/17/2012 02:47 PM, Yinghai Lu wrote:
>>
>>
>> Peter, can you check that branch again?
>>
>> I moved the early_trap_init after init_mem_mapping.
>> so for 64bit native, init_mem_mapping will setup page table for ram from
>> blank.
>>
>
On 12/17/2012 02:47 PM, Yinghai Lu wrote:
Peter, can you check that branch again?
I moved the early_trap_init after init_mem_mapping.
so for 64bit native, init_mem_mapping will setup page table for ram from blank.
Looks better, at first glance at least. There are a couple of
unnecessary
On Sun, Dec 16, 2012 at 12:50 AM, Yinghai Lu wrote:
> On Sat, Dec 15, 2012 at 9:17 PM, Yinghai Lu wrote:
>> On Sat, Dec 15, 2012 at 6:09 PM, Yinghai Lu wrote:
>>> On Sat, Dec 15, 2012 at 1:40 PM, H. Peter Anvin wrote:
On 12/15/2012 12:55 PM, Yinghai Lu wrote:
>
> BTW, did you look
On Sun, Dec 16, 2012 at 12:50 AM, Yinghai Lu ying...@kernel.org wrote:
On Sat, Dec 15, 2012 at 9:17 PM, Yinghai Lu ying...@kernel.org wrote:
On Sat, Dec 15, 2012 at 6:09 PM, Yinghai Lu ying...@kernel.org wrote:
On Sat, Dec 15, 2012 at 1:40 PM, H. Peter Anvin h...@zytor.com wrote:
On 12/15/2012
On 12/17/2012 02:47 PM, Yinghai Lu wrote:
Peter, can you check that branch again?
I moved the early_trap_init after init_mem_mapping.
so for 64bit native, init_mem_mapping will setup page table for ram from blank.
Looks better, at first glance at least. There are a couple of
unnecessary
On Mon, Dec 17, 2012 at 3:11 PM, H. Peter Anvin h...@zytor.com wrote:
On 12/17/2012 02:47 PM, Yinghai Lu wrote:
Peter, can you check that branch again?
I moved the early_trap_init after init_mem_mapping.
so for 64bit native, init_mem_mapping will setup page table for ram from
blank.
On Mon, Dec 17, 2012 at 3:26 PM, Yinghai Lu ying...@kernel.org wrote:
On Mon, Dec 17, 2012 at 3:11 PM, H. Peter Anvin h...@zytor.com wrote:
On 12/17/2012 02:47 PM, Yinghai Lu wrote:
Peter, can you check that branch again?
I moved the early_trap_init after init_mem_mapping.
so for 64bit
On Mon, Dec 17, 2012 at 5:11 PM, Yinghai Lu ying...@kernel.org wrote:
On Mon, Dec 17, 2012 at 3:26 PM, Yinghai Lu ying...@kernel.org wrote:
On Mon, Dec 17, 2012 at 3:11 PM, H. Peter Anvin h...@zytor.com wrote:
On 12/17/2012 02:47 PM, Yinghai Lu wrote:
Peter, can you check that branch again?
Jan,
Can you check if attached patch is going to break KGDB?
Thanks
Yinghai
move_down_early_trap_init.patch
Description: Binary data
On Sat, Dec 15, 2012 at 9:17 PM, Yinghai Lu wrote:
> On Sat, Dec 15, 2012 at 6:09 PM, Yinghai Lu wrote:
>> On Sat, Dec 15, 2012 at 1:40 PM, H. Peter Anvin wrote:
>>> On 12/15/2012 12:55 PM, Yinghai Lu wrote:
BTW, did you look at smp boot problem with early_level4_pgt version?
>>>
>>>
On Sat, Dec 15, 2012 at 9:17 PM, Yinghai Lu ying...@kernel.org wrote:
On Sat, Dec 15, 2012 at 6:09 PM, Yinghai Lu ying...@kernel.org wrote:
On Sat, Dec 15, 2012 at 1:40 PM, H. Peter Anvin h...@zytor.com wrote:
On 12/15/2012 12:55 PM, Yinghai Lu wrote:
BTW, did you look at smp boot problem
On Sat, Dec 15, 2012 at 6:09 PM, Yinghai Lu wrote:
> On Sat, Dec 15, 2012 at 1:40 PM, H. Peter Anvin wrote:
>> On 12/15/2012 12:55 PM, Yinghai Lu wrote:
>>>
>>> BTW, did you look at smp boot problem with early_level4_pgt version?
>>
>>
>> No, I have been busy with non-Linux stuff today.
>>
>
>
On Sat, Dec 15, 2012 at 1:40 PM, H. Peter Anvin wrote:
> On 12/15/2012 12:55 PM, Yinghai Lu wrote:
>>
>> BTW, did you look at smp boot problem with early_level4_pgt version?
>
>
> No, I have been busy with non-Linux stuff today.
>
ok, i sorted it out. I will split it to small pieces and post
On 12/15/2012 03:15 PM, Yinghai Lu wrote:
That is for the kernel region itself (that code is actually unchanged from
the current code), and yes, we could cap that one to _end if there are
systems which have bugs in that area. The dynamic page tables map 1G
aligned at a time.
dynamic should
On Sat, Dec 15, 2012 at 2:17 PM, H. Peter Anvin wrote:
> On 12/15/2012 02:13 PM, Yinghai Lu wrote:
>>
>>
>> AMD system could have all mem between TOLM and TOHM all WB, and don
>> need to set them in MTRRs entries.
>>
>
> I include the TOM2 mechanism in the overall umbrella of MTRRs for this
>
On 12/15/2012 02:13 PM, Yinghai Lu wrote:
AMD system could have all mem between TOLM and TOHM all WB, and don
need to set them in MTRRs entries.
I include the TOM2 mechanism in the overall umbrella of MTRRs for this
purpose.
and also your switchover change that handle cross 1G, and 512g,
On Sat, Dec 15, 2012 at 1:40 PM, H. Peter Anvin wrote:
> On 12/15/2012 12:55 PM, Yinghai Lu wrote:
>> Also if we set map too large, could have chance to cover mem hole near
>> 1T for AMD HT system.
>
>
> Again, should not be cachable in the MTRRs, and even so, is 1G aligned
> already.
AMD system
On 12/15/2012 12:55 PM, Yinghai Lu wrote:
On Sat, Dec 15, 2012 at 11:30 AM, H. Peter Anvin wrote:
What is the point of only managing 2M at a time? Now you have to have
more conditionals and you don't get any more memory efficiency.
We don't need to, because real_data is less than 2M, and
The mem hole at 1T should not be marked cachable in the MTRRs.
Yinghai Lu wrote:
>On Sat, Dec 15, 2012 at 11:30 AM, H. Peter Anvin
>wrote:
>> What is the point of only managing 2M at a time? Now you have to
>have
>> more conditionals and you don't get any more memory efficiency.
>
>We don't
1 - 100 of 210 matches
Mail list logo
