Re: [RFC PATCH 3/3] boot bzImages under paravirt

[Eric W. Biederman]

Jeremy Fitzhardinge <jeremy@xxxxxxxx> writes:

> Eric W. Biederman wrote:
>> Hmm. If we made that:
>> 	mov	%cs, %eax
>> 	add	$0x10, %eax
>> 	mov	%eax, %ds
>>
>> That is likely even backwards compatible.  If you don't mind having a fixed
>> offset between the code and the data segments.  As I recall code and data
>> are not interchangeable.
>>   
>
> Yes, that's just bogus thinko on my part.
>
>> I'm trying to remember the reason for the reloads.
>>
>> As I recall loadlin intercepts code32_start from head.S and so it
>> can do things just after we have switched to protected mode.  Because
>> historically we didn't load the segments before this jump loadlin had
>> to do it.  The code of loadlin appears to reload all of the segments
>> just like head.S does and then not touch them.
>>
>> My two bootloaders that enter the kernel at the 32bit entry point already
>> load the segments as well.
>>
>> Gujin looks like it loads just %es and %ds.
>>   
>
> We should be able to make do with that until we've got our own gdt.

Right after the segments loads we have:
	leal 0x40(%esi), %esp
	call 1f
1:	popl %ebp
	subl $1b, %ebp

That uses %ss and %ds.  Can we use a segment override on a call
instruction?

>> It is hard to tell with elilo what it sets up, it preserves the
>> descriptors from EFI, but sets up a linux boot protocol gdt.
>>   
>
> ? But the cached descriptors are still the EFI ones?

Yep.  Which means we can reload with our know good linux descriptors
but we can't reload the descriptors we are currently running with. 

>> At the same time we are doing this it would be good to drop our
>> boot protocol version into an ELF note so people booting vmlinux
>> can discover when we have relaxed various restrictions and which
>> fields in the real mode data we support.
>>   
>
> Do you mean the have the kernel expose its max supported version for
> bootloaders to inspect?

Yes.  Exactly like we do for real mode code, and with exactly the same
values.  Just in a little different format.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/