kexec: fix wrong calculation method of ramdisk_start

[zchee]

Fix ramdisk_start promlem in the kexec.c. This pull request is backported to https://github.com/docker/hyperkit/pull/66.

As in the https://github.com/mist64/xhyve/issues/116 and https://github.com/mist64/xhyve/issues/74,

ramdisk_start = ALIGNUP((kernel.base + kernel.size), 0x1000ull);

That logic is sometimes initrd will overlap with the kernel memory space. So, change calculation method using the initrd_addr_max variable from the kernel header data.

• Use the initrd_addr_max value from the kernel header if the kernel version is 2.03 or newer.
  • ref: https://github.com/zchee/linux-documentation/blob/master/x86/boot.md#initrd_addr_max
  • Use hardcoded(0x37ffffff) value if older.
• Compare the initrd_max and lowmem.size, and re-assign if initrd_max is larger.
• Add ALIGNDOWN macro for ramdisk_start, uses prevent to go past the address limit.
• Fix typo for initrd_addr_max.
• Rename memory to lowmem
  • backported to https://github.com/docker/hyperkit/pull/68

Based qemu/hw/i386/pc.c.

Close #116

[zchee]

/cc @mist64, @xez

[apparentorder]

I ran into Issue #74 today, trying to installing from the CentOS 7 Minimal ISO.

After applying @zchee's patches (thanks!), it immediately worked.

Would be great to see this merged.

[delfer]

@mist64 two years pass, we still can not boot 4.x kernels... Please, merge!

[delfer]

@zchee thank you very much! Finally I run Ubuntu 18.04 on xhyve! You've made my day!

brew install -s xhyve
cd $(brew --cache)
tar -xf xhyve--0.2.0.tar.gz
cd xhyve-0.2.0
wget https://patch-diff.githubusercontent.com/raw/mist64/xhyve/pull/119.patch
patch < 119.patch
cd ..
rm xhyve--0.2.0.tar.gz
tar -cjf xhyve--0.2.0.tar.gz xhyve-0.2.0
shasum -a 256 xhyve--0.2.0.tar.gz
brew edit xhyve
brew reinstall -s xhyve

Blog post in Russian: https://delfer.ru/2018/10/24/%d0%bf%d0%b0%d1%82%d1%87%d0%b8%d0%bc-%d0%bf%d0%b0%d0%ba%d0%b5%d1%82%d1%8b-brew-%d0%b4%d0%bb%d1%8f-macos/

[zchee]

@delfer np :) I learned a lot of resolves this problem. binary header, MMIO hole, etc .

FYI, it’s already merged on moby/hyperkit. So you can use almost the same implementations of the native hypervisor feature no need to apply the patch.

Enjoy Hypervisor.framework, also thanks for wrote blog post :) I’ll read it with the Google Translate because I’m Japanese lol

[delfer]

@zchee thank you very much for hyperkit recommendation! I've got another one bug with xhyve - RAM limited to 3Gb. But hyperkit is perfect:

• works with kernels up to 4.15 out of the box
• support > 3Gb RAM
• support qcow2 disk image format
• fully compatible with xhyve

I've just replaced xhyve to hyperkit in my bash scripts and now I have Ubuntu 18.04, Centos 7, Debian 9 on my mac, but still not Arch.

[jeremyhu]

By Based on qemu/hw/i386/pc.c, my assumption here is that this is a clean-room reimplementation of the spirit of some logic in qemu and that there was no source copied over or immediately referenced while implementing this change.

[zchee]

@jeremyhu Thanks for merge :)

/cc @c4milo

[zchee]

@jeremyhu And yes,

By Based on qemu/hw/i386/pc.c, my assumption here is that this is a clean-room reimplementation of the spirit of some logic in qemu and that there was no source copied over or immediately referenced while implementing this change.

I was just refer to qemu source, didn't copy. The moby/hyperkit also merged previously. I think license concern is no problem.

[dinamic]

It feels like we should have a new release tagged. 0.2.0 was tagged back in July 2015.

@jeremyhu thoughts on this?

[jeremyhu]

That's probably a good idea. There are a couple other PRs in the queue that we should look at and then maybe a 0.3.0 might be in order. =)