On Tue, Apr 18, 2017 at 11:59:26AM +0300, Kirill A. Shutemov wrote: > On Mon, Apr 17, 2017 at 12:32:25PM +0200, Ingo Molnar wrote: > > > > * Kirill A. Shutemov <kir...@shutemov.name> wrote: > > > > > On Tue, Apr 11, 2017 at 07:09:07AM -0700, Andi Kleen wrote: > > > > > I'll look closer (building proccess it's rather complicated), but my > > > > > understanding is that VDSO is stand-alone binary and doesn't really > > > > > links > > > > > with the rest of the kernel, rather included as blob, no? > > > > > > > > > > Andy, may be you have an idea? > > > > > > > > There isn't any way I know of to directly link them together. The ELF > > > > format wasn't designed for that. You would need to merge blobs and then > > > > use > > > > manual jump vectors, like the 16bit startup code does. It would be > > > > likely > > > > complicated and ugly. > > > > > > Ingo, can we proceed without coverting this assembly to C? > > > > > > I'm committed to convert it to C later if we'll find reasonable solution > > > to the issue. > > > > So one way to do it would be to build it standalone as a .o, then add it > > not to > > the regular kernel objects link target (as you found out it's not possible > > to link > > 32-bit and 64-bit objects), but to link it in a manual fashion, as part of > > vmlinux.bin.all-y in arch/x86/boot/compressed/Makefile. > > > > But there would be other complications with this approach, such as we'd > > have to > > add a size field and there might be symbol linking problems ... > > > > Another, pretty hacky way would be to generate a .S from the .c, then > > post-process > > the .S and essentially generate today's 32-bit .S from it. > > > > Probably not worth the trouble. > > So, do I need to do anything else to get part 4 applied?
Doh! I've just realized we don't really need to enable 5-level paging in decompression code. Leaving 4-level paging there works perfectly fine. I'll drop changes to arch/x86/boot/compressed/head_64.S and resubmit the patchset. -- Kirill A. Shutemov
