Add fake e820 memory map entries to zeropage

Add fake e820 memory map entries to zeropage

BUG=chromium-os:4521
TEST=manual

This patch set adds two e820 memory map entries to kernel's zeropage to
trick kernel into booting; otherwise kernel will choke on missing e820
memory map.

The added e820 memory map entries should let kernel boot and should not
make the memory map differ from that without the added entries.

Test Procedure:
1. Boot your test machine and save dmesg output, referred to as LOG1.
2. Apply the following one-line patch and then compile and install
   kernel.
3. Apply this patch set and re-build zeropage on kernel partition.
4. Boot the test machine and save dmesg output, referred to as LOG2.

LOG1 would contain the following messages (the exactly addresses of
memory map should differ slightly).
...
[    0.000000] BIOS-provided physical RAM map:
[    0.000000] bootconsole [earlyser0] enabled
...
[    0.000000] modified physical RAM map:
[    0.000000]  modified: 0000000000000000 - 0000000000002000 (usable)
[    0.000000]  modified: 0000000000002000 - 0000000000006000 (reserved)
[    0.000000]  modified: 0000000000006000 - 000000000008f000 (usable)
[    0.000000]  modified: 000000000008f000 - 0000000000090000 (ACPI NVS)
[    0.000000]  modified: 0000000000090000 - 00000000000a0000 (usable)
[    0.000000]  modified: 0000000000100000 - 0000000000f00000 (usable)
[    0.000000]  modified: 0000000001000000 - 000000003f33f000 (usable)
[    0.000000]  modified: 000000003f33f000 - 000000003f4bf000 (reserved)
[    0.000000]  modified: 000000003f4bf000 - 000000003f5bf000 (ACPI NVS)
[    0.000000]  modified: 000000003f5bf000 - 000000003f5f7000 (ACPI data)
[    0.000000]  modified: 000000003f5f7000 - 000000003f600000 (usable)
[    0.000000]  modified: 00000000fed1c000 - 00000000fed20000 (reserved)
[    0.000000]  modified: 00000000ffc00000 - 0000000100000000 (reserved)

LOG2 would contain the following messages (the exactly addresses of
memory map should differ slightly).
...
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 0000000000001000 (usable)
[    0.000000]  BIOS-e820: 00000000fffff000 - 0000000100000000 (reserved)
[    0.000000] bootconsole [earlyser0] enabled
...
[    0.000000] modified physical RAM map:
[    0.000000]  modified: 0000000000000000 - 0000000000002000 (usable)
[    0.000000]  modified: 0000000000002000 - 0000000000006000 (reserved)
[    0.000000]  modified: 0000000000006000 - 000000000008f000 (usable)
[    0.000000]  modified: 000000000008f000 - 0000000000090000 (ACPI NVS)
[    0.000000]  modified: 0000000000090000 - 00000000000a0000 (usable)
[    0.000000]  modified: 0000000000100000 - 0000000000f00000 (usable)
[    0.000000]  modified: 0000000001000000 - 000000003f33f000 (usable)
[    0.000000]  modified: 000000003f33f000 - 000000003f4bf000 (reserved)
[    0.000000]  modified: 000000003f4bf000 - 000000003f5bf000 (ACPI NVS)
[    0.000000]  modified: 000000003f5bf000 - 000000003f5f7000 (ACPI data)
[    0.000000]  modified: 000000003f5f7000 - 000000003f600000 (usable)
[    0.000000]  modified: 00000000fed1c000 - 00000000fed20000 (reserved)
[    0.000000]  modified: 00000000ffc00000 - 0000000100000000 (reserved)

Test result:
1. Compare the first paragraph of excerpts from LOG1 and LOG2:
   This shows that the fake e820 memory map entries are successfully
   added.
2. Compare the second paragraphs of excerpts from LOG1 and LOG2:
   This shows that the added entries do not modify the memory map.

diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 49706d0..c9075ee 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -425,7 +425,7 @@ static int __init append_e820_map(struct e820entry
*biosmap, int nr_map)
 {
        /* Only one memory region (or negative)? Ignore it */
        if (nr_map < 2)
-               return no_e820_map_return();
+               return -1;

        return __append_e820_map(biosmap, nr_map);
 }

[Bill Richardson, 2010-08-19 15:44:32]

Nice. Seems fine to me, but please wait for Olof to give it his approval, just
to be certain.

The TEST= instructions in the issue description say how to check this particular
patch, but we should really undo my kernel-source hackery (see
http://code.google.com/p/chromium-os/issues/detail?id=4521 for the changes) to
be certain that it works on an unmodified upstream kernel. And of course, once
this goes in, we should undo that hackery permanently.

[Olof Johansson, 2010-08-19 15:58:44]

Hi,

See individual comments below -- we cannot copy and paste code from the kernel
into vboot due to license differences. It needs to be rewritten from scratch
instead.

http://codereview.chromium.org/3176019/diff/1/2
File utility/include/kernel_blob.h (right):

http://codereview.chromium.org/3176019/diff/1/2#newcode31
utility/include/kernel_blob.h:31: // Copy from arch/x86/include/asm/e820.h in
the kernel source.
We can't just copy and paste code from the linux kernel sources, since they are
under a different license than the vboot code. This would taint vboot with GPL.

So this needs to be a clean implementation of the same interface.

http://codereview.chromium.org/3176019/diff/1/2#newcode44
utility/include/kernel_blob.h:44: } __attribute__((packed));
Same here, the above cannot be a copy and paste, it needs to be written from
scratch.

[clchiou, 2010-08-20 03:47:47]

Hi,

Thank Olof for reminding me.
I have rewritten the pieces of code in question from scratch.
But I am not sure how much rewritten have to be done.
Please indicate any insufficient rewriting work.
Thank you.

http://codereview.chromium.org/3176019/diff/1/2
File utility/include/kernel_blob.h (right):

http://codereview.chromium.org/3176019/diff/1/2#newcode31
utility/include/kernel_blob.h:31: // Copy from arch/x86/include/asm/e820.h in
the kernel source.
On 2010/08/19 15:58:44, Olof Johansson wrote:
> We can't just copy and paste code from the linux kernel sources, since they
are
> under a different license than the vboot code. This would taint vboot with
GPL.
> 
> So this needs to be a clean implementation of the same interface.
I rewrote the part of code.

http://codereview.chromium.org/3176019/diff/1/2#newcode44
utility/include/kernel_blob.h:44: } __attribute__((packed));
On 2010/08/19 15:58:44, Olof Johansson wrote:
> Same here, the above cannot be a copy and paste, it needs to be written from
> scratch.
I rewrote this part of code.

[Olof Johansson, 2010-08-20 21:21:20]

On 2010/08/20 03:47:47, clchiou wrote:
> Hi,
> 
> Thank Olof for reminding me.
> I have rewritten the pieces of code in question from scratch.
> But I am not sure how much rewritten have to be done.
> Please indicate any insufficient rewriting work.

No code can be cut and pasted from the kernel to vboot, all of it has to be
written from scratch (or come from a license-compatible project).

As far as I can tell, that has now been done, and the new implementation LGTM.