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
x86/microcode_intel_early.
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
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 (n
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 sys
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 sys
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 m
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 ag
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 man
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 in
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 th
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 n
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 tr
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 i
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 latt
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 t
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 means
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
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 deter
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 that
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 align
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 physica
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.
A
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.
--
Regards/Gr
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] MT
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 f
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
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 8
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 there
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 consequences
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 +01
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 t
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 early_trap_
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, init_me
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 ch
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 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 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.
>>
>
> ok
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 them
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 be
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
> purp
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 ram
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 ne
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 ramdisk is about 16M.
Also if we set map too
On 12/14/2012 11:57 PM, Yinghai Lu wrote:
>
> I tailored your patch and made use 2M page increase to replace patch
> ioremap function.
>
>[PATCH v6 12/27] x86: use io_remap to access real_mode_data
>
> and it will extend init_level4_pgt to map extra range. that will limit
> affect to even ot
On Fri, Dec 14, 2012 at 12:08 PM, Yinghai Lu wrote:
> On Fri, Dec 14, 2012 at 12:04 PM, Yinghai Lu wrote:
>> On Fri, Dec 14, 2012 at 11:46 AM, H. Peter Anvin wrote:
>>>
>>> I suspect we don't need init_level4_pgt at all and should just plan to
>>> get rid of it. Is there any reason we can't jus
On Fri, Dec 14, 2012 at 12:04 PM, Yinghai Lu wrote:
> On Fri, Dec 14, 2012 at 11:46 AM, H. Peter Anvin wrote:
>>
>> That patch doesn't apply on top of the merge of x86/mm2 and
>> linus/master. A trivial fixup is totally nonfunctional -- no
>> earlyprintk, just a null pointer death in setup_real_
On 12/14/2012 12:17 PM, Yinghai Lu wrote:
> On Fri, Dec 14, 2012 at 12:10 PM, H. Peter Anvin wrote:
>> What info are you referring to?
>
> pointer to init_level4_pgt page.
>
We point the trampoline at the proper page tables in swapper_pg_dir;
this means pushing realmode initialization (but not
On 12/14/2012 12:14 PM, Yinghai Lu wrote:
> On Fri, Dec 14, 2012 at 12:08 PM, Yinghai Lu wrote:
>> On Fri, Dec 14, 2012 at 12:04 PM, Yinghai Lu wrote:
>>> On Fri, Dec 14, 2012 at 11:46 AM, H. Peter Anvin wrote:
I suspect we don't need init_level4_pgt at all and should just plan to
On Fri, Dec 14, 2012 at 12:10 PM, H. Peter Anvin wrote:
> What info are you referring to?
pointer to init_level4_pgt page.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.or
What info are you referring to?
Yinghai Lu wrote:
>On Fri, Dec 14, 2012 at 11:46 AM, H. Peter Anvin wrote:
>>
>> That patch doesn't apply on top of the merge of x86/mm2 and
>> linus/master. A trivial fixup is totally nonfunctional -- no
>> earlyprintk, just a null pointer death in setup_real_m
On Fri, Dec 14, 2012 at 12:08 PM, Yinghai Lu wrote:
> On Fri, Dec 14, 2012 at 12:04 PM, Yinghai Lu wrote:
>> On Fri, Dec 14, 2012 at 11:46 AM, H. Peter Anvin wrote:
>>>
>>> I suspect we don't need init_level4_pgt at all and should just plan to
>>> get rid of it. Is there any reason we can't jus
On Fri, Dec 14, 2012 at 12:04 PM, Yinghai Lu wrote:
> On Fri, Dec 14, 2012 at 11:46 AM, H. Peter Anvin wrote:
>>
>> I suspect we don't need init_level4_pgt at all and should just plan to
>> get rid of it. Is there any reason we can't just build the proper
>> kernel page table set in pagetable_in
On Fri, Dec 14, 2012 at 11:46 AM, H. Peter Anvin wrote:
>
> That patch doesn't apply on top of the merge of x86/mm2 and
> linus/master. A trivial fixup is totally nonfunctional -- no
> earlyprintk, just a null pointer death in setup_real_mode().
just saw linus pulled efi fix that is touching rea
On 12/14/2012 01:11 AM, Yinghai Lu wrote:
> On Thu, Dec 13, 2012 at 1:36 PM, H. Peter Anvin wrote:
>>
>> : tazenda 111 ; qemu-kvm -smp 2 -m 2048 -hda ~/qemu/fc10/qemu-fc10-64.img
>> -serial stdio -kernel o.x86_64/arch/x86/boot/bzImage -append 'ro
>> root=/dev/sda1 console=ttyS0 earlyprintk=serial,
On 12/14/2012 01:11 AM, Yinghai Lu wrote:
>
> attached works on kvm local, but SMP does not work yet.
>
SMP should be easy... it is probably just a matter of getting through
the trampoline sequence properly. I will look at this shortly.
-hpa
--
To unsubscribe from this list: send the
On 12/13/2012 11:13 AM, Borislav Petkov wrote:
On Wed, Dec 12, 2012 at 09:26:47PM -0800, H. Peter Anvin wrote:
Well, minus a simple brainfart now it actually gets into the page
table setup.
If by this you mean that you can only see
"Decompressing Linux...
Parsing ELF.."
and then the VM rebo
On Wed, Dec 12, 2012 at 09:26:47PM -0800, H. Peter Anvin wrote:
> On 12/12/2012 09:12 PM, H. Peter Anvin wrote:
> >Here is a version that compiles. It doesn't *boot* yet, because the
> >switchover from dynamic mode to the real pagetables doesn't happen right
> >and so we end up on an uninitialized
On 12/12/2012 11:01 PM, Yinghai Lu wrote:
> On Wed, Dec 12, 2012 at 9:26 PM, H. Peter Anvin wrote:
>>>
>>> The new page table setup in tip:x86/mm2 should make that easier to
>>> achieve, however... I won't have time to test this out tonight, though.
>>>
>>> -hpa
>>
>>
>> Well, minus a simple
On Wed, Dec 12, 2012 at 9:26 PM, H. Peter Anvin wrote:
>>
>> The new page table setup in tip:x86/mm2 should make that easier to
>> achieve, however... I won't have time to test this out tonight, though.
>>
>> -hpa
>
>
> Well, minus a simple brainfart now it actually gets into the page table
>
On 12/12/2012 09:12 PM, H. Peter Anvin wrote:
Here is a version that compiles. It doesn't *boot* yet, because the
switchover from dynamic mode to the real pagetables doesn't happen right
and so we end up on an uninitialized set of page tables.
The new page table setup in tip:x86/mm2 should make
Here is a version that compiles. It doesn't *boot* yet, because the
switchover from dynamic mode to the real pagetables doesn't happen right
and so we end up on an uninitialized set of page tables.
The new page table setup in tip:x86/mm2 should make that easier to
achieve, however... I won't
> please check early_memremap version for microcode...
>
> 1. make find_cpio take map/unmap function pointer, and use that to set
> sliding window.
> 2. clean the end to size in some function to fix -1 offset
> 3. update_mc_saved to change back to __va for ap etc and after
> initrd_relocation.
>
>
On 12/12/2012 05:38 AM, Borislav Petkov wrote:
We completely lost level3_ident_pgt, causing:
arch/x86/built-in.o: In function `setup_real_mode':
/home/boris/kernel/linux-2.6/arch/x86/realmode/init.c:81: undefined reference
to `level3_ident_pgt'
make: *** [vmlinux] Error 1
You still need t
On Tue, Dec 11, 2012 at 10:57:03PM -0800, H. Peter Anvin wrote:
> @@ -372,46 +394,21 @@ ENTRY(name)
> i = i + 1 ; \
> .endr
>
> - .data
> - /*
> - * This default setting generates an ident mapping at address 0x10
> - * and a ma
On Tue, Dec 11, 2012 at 11:14 PM, Yinghai Lu wrote:
>
> please check draft version for early_memremap version for microcode...
>
> 1. make find_cpio take map/unmap function pointer, and use that to set
> sliding window.
> 2. clean the end to size in some function to fix -1 offset
> 3. update_mc_sa
On Tue, Dec 11, 2012 at 4:37 PM, H. Peter Anvin wrote:
> On 12/11/2012 04:27 PM, Yinghai Lu wrote:
>> On Tue, Dec 11, 2012 at 3:57 PM, H. Peter Anvin wrote:
>>> Well, we could invoke it on the bootloader page tables, but as you say
>>> it may not be a good idea... depending on how much memory we
On 12/11/2012 04:27 PM, Yinghai Lu wrote:
On Tue, Dec 11, 2012 at 3:57 PM, H. Peter Anvin wrote:
Well, we could invoke it on the bootloader page tables, but as you say
it may not be a good idea... depending on how much memory we may be
talking about. One solution -- which I have to admit is st
On 12/11/2012 04:27 PM, Yinghai Lu wrote:
> On Tue, Dec 11, 2012 at 3:57 PM, H. Peter Anvin wrote:
>> Well, we could invoke it on the bootloader page tables, but as you say
>> it may not be a good idea... depending on how much memory we may be
>> talking about. One solution -- which I have to adm
On Tue, Dec 11, 2012 at 3:57 PM, H. Peter Anvin wrote:
> Well, we could invoke it on the bootloader page tables, but as you say
> it may not be a good idea... depending on how much memory we may be
> talking about. One solution -- which I have to admit is starting to
> sound really good -- is to
On 12/11/2012 03:53 PM, Yinghai Lu wrote:
> On Tue, Dec 11, 2012 at 9:38 AM, H. Peter Anvin wrote:
>> On 12/11/2012 09:15 AM, Yinghai Lu wrote:
>>>
>>>
>>> No, that is not right place. initrd could be loaded anywhere like way
>>> high by bootloader.
>>>
>>
>> Only *after* your changes... the curre
On Tue, Dec 11, 2012 at 9:38 AM, H. Peter Anvin wrote:
> On 12/11/2012 09:15 AM, Yinghai Lu wrote:
>>
>>
>> No, that is not right place. initrd could be loaded anywhere like way
>> high by bootloader.
>>
>
> Only *after* your changes... the current protocol doesn't allow that.
before for-x86-boot
On 12/11/2012 11:18 AM, Yinghai Lu wrote:
>
> that will be bunch of asm code again, and need to parse the setup_header in
> that
> asm to get range value for those regions...
>
It's an index into an array, it's not "parsing".
>>
>>> but if the user memmap to exclude some page, we will still ne
On Tue, Dec 11, 2012 at 10:46 AM, H. Peter Anvin wrote:
> On 12/11/2012 10:42 AM, Yinghai Lu wrote:
>>
>> now in for-x86-boot:
>> http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=commit;h=8e4e093e6d140f1316953437fdde4e826f5cfd98
>>
>> it adds extra mapping from the whole kerne
On 12/11/2012 10:42 AM, Yinghai Lu wrote:
>
> now in for-x86-boot:
> http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=commit;h=8e4e093e6d140f1316953437fdde4e826f5cfd98
>
> it adds extra mapping from the whole kernel when kernel is loaded above 1G.
> from round_down(_text, 2M)
On Tue, Dec 11, 2012 at 10:20 AM, H. Peter Anvin wrote:
> On 12/11/2012 10:02 AM, H. Peter Anvin wrote:
>>
>>
>> The more I think about it, the more I think the right answer is the one
>> we have pretty stated all along: if using the 64-bit entry point it is
>> the responsibility of the boot loade
On 12/11/2012 10:02 AM, H. Peter Anvin wrote:
The more I think about it, the more I think the right answer is the one
we have pretty stated all along: if using the 64-bit entry point it is
the responsibility of the boot loader to make sure the kernel, the setup
data, and the initramfs are all ma
On 12/11/2012 09:15 AM, Yinghai Lu wrote:
On Tue, Dec 11, 2012 at 9:06 AM, Borislav Petkov wrote:
On Tue, Dec 11, 2012 at 09:00:55AM -0800, Yinghai Lu wrote:
ok, then next question is how early it should be.
before early_cpu_init/early_identify_cpu
or just before check_bugs/identify_cpu
Re
On 12/11/2012 09:15 AM, Yinghai Lu wrote:
No, that is not right place. initrd could be loaded anywhere like way
high by bootloader.
Only *after* your changes... the current protocol doesn't allow that.
Anyway, we need to deal with it, see below.
to make code simple, we should have followin
linutronix.de;
> h...@linux.intel.com; linux-tip-comm...@vger.kernel.org
> Subject: Re: [tip:x86/microcode] x86/microcode_intel_early.c: Early
> update ucode on Intel's CPU
>
> On Tue, Dec 11, 2012 at 9:06 AM, Borislav Petkov wrote:
> > On Tue, Dec 11, 2012 at 09:00:55AM
On Tue, Dec 11, 2012 at 9:06 AM, Borislav Petkov wrote:
> On Tue, Dec 11, 2012 at 09:00:55AM -0800, Yinghai Lu wrote:
>> ok, then next question is how early it should be.
>>
>> before early_cpu_init/early_identify_cpu
>>
>> or just before check_bugs/identify_cpu
>
> Read the code. It's in x86_64_s
On Tue, Dec 11, 2012 at 09:00:55AM -0800, Yinghai Lu wrote:
> ok, then next question is how early it should be.
>
> before early_cpu_init/early_identify_cpu
>
> or just before check_bugs/identify_cpu
Read the code. It's in x86_64_start_kernel on 64-bit.
--
Regards/Gruss,
Boris.
Sent from
On Tue, Dec 11, 2012 at 8:48 AM, H. Peter Anvin wrote:
>
> It's not about "not working"... it is about "if the microcode isn't
> loaded early we have to disable features."
ok, then next question is how early it should be.
before early_cpu_init/early_identify_cpu
or just before check_bugs/identi
On 12/11/2012 08:46 AM, Yinghai Lu wrote:
> On Tue, Dec 11, 2012 at 6:57 AM, Borislav Petkov wrote:
>> On Mon, Dec 10, 2012 at 11:07:38PM -0800, Yinghai Lu wrote:
>>> BTW, do we really need to update microcode so early?
>>
>> Yes we do. Normally ucode gets applied by the BIOS - this early approach
On Tue, Dec 11, 2012 at 6:57 AM, Borislav Petkov wrote:
> On Mon, Dec 10, 2012 at 11:07:38PM -0800, Yinghai Lu wrote:
>> BTW, do we really need to update microcode so early?
>
> Yes we do. Normally ucode gets applied by the BIOS - this early approach
> is for those cases where OEMs don't release n
On Mon, Dec 10, 2012 at 11:07:38PM -0800, Yinghai Lu wrote:
> BTW, do we really need to update microcode so early?
Yes we do. Normally ucode gets applied by the BIOS - this early approach
is for those cases where OEMs don't release new BIOS anymore but we
still need to apply a ucode patch as early
On Mon, Dec 10, 2012 at 10:34 PM, H. Peter Anvin wrote:
>
> That doesn't work if the microcode is replaced at runtime. However, vmalloc
> doesn't work either since 32 bits needs any one blob to be physically
> contiguous. I have suggested Fenghua replace it with a linked list of
> kmalloc areas,
On 12/10/2012 07:55 PM, Yinghai Lu wrote:
And my suggestion is: after scan and find the ucode, save it to BRK,
so don't need to adjust
pointer again, and don't need to copy the blob and update the pointer again.
That doesn't work if the microcode is replaced at runtime. However,
vmalloc doe
On Mon, Dec 10, 2012 at 7:41 PM, H. Peter Anvin wrote:
> On 12/10/2012 06:39 PM, Yinghai Lu wrote:
>>
>> No, you should not copy that several times.
>>
>> just pre-allocate some kbytes in BRK, and copy to there one time.
>>
>
> He doesn't copy it several times. He just saves an offset into the
>
1 - 100 of 105 matches
Mail list logo
