Build fails to upload image on Fedora

[nyh]

Of my newly-upgrade Fedora 32, "scripts/build" fails in upload_manifest:

+ /home/nyh/osv.tmp2/osv/scripts/upload_manifest.py -o usr.img -m usr.manifest -D libgcc_s_dir=/usr/lib64
KVM: injection failed, MSI lost (Operation not permitted)
...

The last message repeats indefinitely, until I kill it.

[wkozaczuk]

I noticed that as well. Please note that if you build ROFS image and run with ‘-k’ option (direct kernel) it all works. So I think loader.elf is fine. The issue most likely is with 32 bit lzloader.elf or 16 bit boot16.bin.

…

On Sat, May 23, 2020 at 08:18 nyh ***@***.***> wrote: Of my newly-upgrade Fedora 32, "scripts/build" fails in upload_manifest: + /home/nyh/osv.tmp2/osv/scripts/upload_manifest.py -o usr.img -m usr.manifest -D libgcc_s_dir=/usr/lib64 KVM: injection failed, MSI lost (Operation not permitted) ... The last message repeats indefinitely, until I kill it. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1084>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABINEIM3ARLYVHJIWJ3F733RS65KPANCNFSM4NINTCLA> .

[nyh]

gdb tells me we are stuck in address 0x000000000010100f. That's OSV_LZKERNEL_BASE + 0x1000 + 0xf.
I don't remember all the latest changes you did to the boot process, and what special significance this address has. I'll start investigating now, but may be have an idea?

[nyh]

According to arch/x64/lzloader.ld, OSV_LZKERNEL_BASE + 0x1000 is the beginning of the text segment of lzloader.elf.
objdump -d build/release.x64/lzloader.elf shows that 0x10100f is the middle of memset() which is how this elf starts. But this has not changed since Fedora 31, which also had memset() - with exactly the same assembly code - starting lzloader.elf, and uncompress_loader() only starts at 0x0010101c (and uncompress_loader() is marked as ENTRY in lzloader.ld).

[nyh]

I verified that the entry point in lzloader.elf (fastlz/lzloader.cc) is not a problem - the problem is the actual memset() function defined in lzloader.cc. I changed the order of the functions so that uncompress_loader() comes first and memset() comes second, and still gdb tells us we're hung in the memset() function.

[nyh]

Amazingly, a patch I wrote 3 years ago for #913 and didn't solve that issue, solves this one :-) I'll send a patch now.