Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

kexec: fix wrong calculation method of ramdisk_start #119

Merged
merged 3 commits into from Dec 3, 2018

Conversation

@zchee
Copy link
Contributor

@zchee zchee commented Oct 21, 2016

Fix ramdisk_start promlem in the kexec.c.
This pull request is backported to moby/hyperkit#66.

As in the #116 and #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.

Based qemu/hw/i386/pc.c.

Close #116

zchee added 3 commits Oct 21, 2016
Signed-off-by: Koichi Shiraishi <zchee.io@gmail.com>
Use the initrd_addr_max value from the kernel header if the kernel
version is 2.03 or newer. Use hardcoded(0x37ffffff) value if older.

Compare the initrd_max and memory.size, and re-assign if initrd_max
is larger.

Add ALIGNDOWN for ramdisk_start, uses prevent to go past the address
limit.

Based on qemu/hw/i386/pc.c

Signed-off-by: Koichi Shiraishi <zchee.io@gmail.com>
backport to moby/hyperkit#68

Original commit messages
  Various bits of code (e.g. kernel and initrd loading) rely on memory.base and
  memory.size referring to lowmem only, with highmem being handled separately, in
  order to avoid locating things into the MMIO region between the two.

  Rename the variable to make this more obvious and to forestall any ideas about
  "fixing" memory.size.

Signed-off-by: Koichi Shiraishi <zchee.io@gmail.com>
@zchee
Copy link
Contributor Author

@zchee zchee commented Oct 21, 2016

/cc @mist64, @xez

@apparentorder
Copy link

@apparentorder apparentorder commented Dec 17, 2017

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
Copy link

@delfer delfer commented Oct 24, 2018

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

@delfer
Copy link

@delfer delfer commented Oct 24, 2018

@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
Copy link
Contributor Author

@zchee zchee commented Oct 24, 2018

@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
Copy link

@delfer delfer commented Oct 25, 2018

@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
Copy link
Member

@jeremyhu jeremyhu commented Dec 3, 2018

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.

@jeremyhu jeremyhu merged commit e73e4f1 into machyve:master Dec 3, 2018
@zchee
Copy link
Contributor Author

@zchee zchee commented Jan 9, 2019

@jeremyhu Thanks for merge :)

/cc @c4milo

@zchee
Copy link
Contributor Author

@zchee zchee commented Jan 9, 2019

@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
Copy link

@dinamic dinamic commented Jan 21, 2019

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

@jeremyhu thoughts on this?

@jeremyhu
Copy link
Member

@jeremyhu jeremyhu commented Jan 24, 2019

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. =)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants