Wrong location of the ramdisk in kexec about hyperkit HOT 18 CLOSED

have the information of any specification?

Please check Documentation/x86/boot.txt in the Linux kernel repository, this should IIRC provide guidance on load addresses.

from hyperkit.

@ijc25 Thanks advice. I had previously seen it, but try to read again.
Just in case, It means add some flag to Kernel boot command-line parameter(console options, e.g. loglevel=7)?

from hyperkit.

@zchee that document should include sufficient info to allow hyperkit to choose a better initramfs load address, to minimise the chance of overlap (IIRC it includes fields in the header which give the max allowable address, and loading the initramfs as high as possible ought to avoid these sorts of issues).

I'm not sure what you are asking wrt command-line parameters, there should be no need for such things to fix this issue.

from hyperkit.

@ijc25 Ah, I understand.
Yes, that doc has the detail of boot file header data. Including initramfs information too.

But, sorry, I'm not good at English... question again :(
I want to fix this problem based on x86/boot.txt documents.
Now, which one do you think the cause of Initramfs unpacking failed problem?

• kexec.c is fine, the way of make iso(or header data) is wrong.
• iso is fine, kexec.c is a little wrong. Should fix kexec.c to the better parse method.

I'd like to hear your opinion.

from hyperkit.

It seems more likely that kexec.c should be adjusted to make better choices WRT to the address it chooses to load the initramfs to. I was expecting that x86/boot.txt would provide enough guidance as to what a better mechanism for choosing the address would be.

To be a little more specific, but having not dug into this properly (so might be misguided) I think boot.txt describes some header fields around the maximum supported initramfs load address. So a good choice for kexec.c to make would be to load at min(amount of RAM given to VM, maximum address supported by the kernel image) - size of initrd) the answer would also need to be rounded down to a suitable alignment.

There is one slight complication since the guest RAM may not be completely contiguous. See xh_vm_setup_memory where it is split low and high memory (this is to ensure there is some MMIO space below 4GB). You'd want to avoid loading the initramfs into the hole for example. Once simple way to avoid that would be to load to the top of the lowmem region rather than total ram. e.g.
min(amount of RAM given to VM, maximum address supported by the kernel image, lowmem limit) - size of initrd)

from hyperkit.

@ijc25 Thanks for a polite reply. I totally understand you said meaning.

And understand you suggests mechanism too.
I know xh_vm_setup_memory behavior, so I also think min(amount of RAM given to VM, maximum address supported by the kernel image, lowmem limit) - size of initrd) is better.

I will more read that document and GNU/Linux kernel source.
Like the Docker for Mac, There is also a way to use uefi(bootrom) boot, but I will try to fix it.
Thanks again for good reference.

from hyperkit.

I haven't gotten to try this yet other than compiling, but might something like this work?
dlorenc/libhyperkit@249966a

My reading of boot.txt indicates that we can use this address to start the ramdisk:

Field name: initrd_addr_max
Type: read
Offset/size: 0x22c/4
Protocol: 2.03+

The maximum address that may be occupied by the initial
ramdisk/ramfs contents. For boot protocols 2.02 or earlier, this
field is not present, and the maximum address is 0x37FFFFFF. (This
address is defined as the address of the highest safe byte, so if
your ramdisk is exactly 131072 bytes long and this field is
0x37FFFFFF, you can start your ramdisk at 0x37FE0000.)

from hyperkit.

@dlorenc Oh, It seems to typo(lacking) i...?
I will try to test it.

@ijc25 What do you think about it?

from hyperkit.

Ah, it a wrong variable name for sure.
but that fix can't boot tiny core linux.
I'll more comment later.

from hyperkit.

@dlorenc I think your

ramdisk_start = ALIGNUP(zp->setup_header.initrd_addr_max - sz, 0x100ull);

Needs to be ALIGNDOWN (which may need to be added), otherwise the end of the initrd might go past the address limit. It might alternatively be sufficient to round up the size before subtracting it from the max address.

from hyperkit.

@ijc25 I tested with adding you suggests ALIGNDOWN(), but still fail boot depending on the size of the kernel. Their values seem too large.
I will more debug it.

from hyperkit.

This code from qemu looks relevant: https://github.com/qemu/openbios/blob/master/arch/sparc32/linux_load.c

from hyperkit.

I also reading qemu's standalone boot loader. and almost figured out.

I will backport some logic, and will create pull request.

from hyperkit.

@dlorenc that path says sparc32 in it, although the file itself refers to i386 a lot. Not sure what's going on there, maybe sparc Linux forked the x86 vmlinuz binary format waaay back -- I'd be wary of trusting it as a source of truth for an x86 fix too much though. (also, that code is from openbios, which is including in qemu but not actually qemu AFAICT).

@zchee awesome, thanks. Please pay attention to licensing if copying things from QEMU. Hyperkit is BSD licensed but QEMU is a mix of BSD and GPL (and possibly others). Please avoid introducing GPL code into Hyperkit (it might be that you feel it is appropriate to use such code as a reference to gather "facts" about the binary interface, but you'll need to rewrite from scratch and not literally copy).

from hyperkit.

@dlorenc that path says sparc32 in it, although the file itself refers to i386 a lot. Not sure what's going on there, maybe sparc Linux forked the x86 vmlinuz binary format waaay back -- I'd be wary of trusting it as a source of truth for an x86 fix too much though. (also, that code is from openbios, which is including in qemu but not actually qemu AFAICT).

Sorry, the same code is in the amd64 and x86 directories as well, I just grabbed the wrong link:
https://github.com/qemu/openbios/blob/master/arch/x86/linux_load.c

from hyperkit.

@ijc25 reply for license issue.
Yes, I don't like the introducing GPL code into Hyperkit.
I was gathering "facts" about the binary interface from qemu sources and copied one or two comments(note). but almost write scratch.

Is my PR have a problem?

from hyperkit.

I wrote the above comment about licensing before I'd seen that you had raised a PR and just wanted to head off one common pitfall. Having seen the PR now AFAICT it looks fine from a license perspective.

Closing this issue in favour of #66.

from hyperkit.

@ijc25 got it. Thanks :)

from hyperkit.