Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
> H. Peter Anvin wrote:
>> It would have to, because of the way code32_start is defined to work.
>> We don't get control again after its use as a hook.
>>
>
> Who uses that hook? The impression I get is that the execution
> environment for jumpin
H. Peter Anvin wrote:
> It would have to, because of the way code32_start is defined to work.
> We don't get control again after its use as a hook.
>
Who uses that hook? The impression I get is that the execution
environment for jumping to that pointer is not very well defined at present.
Jeremy Fitzhardinge wrote:
>
> Just to clarify:
>
> In my proposal is that we have bzImage structured something like (where
> "|" is concatenation, and "()" is a blob containing stuff):
>
> bzImage = 16-bit setup | ELF file (decompressor, compressed kernel)
>
>
> With the intention
H. Peter Anvin wrote:
> That's a method of defining the memory space.
>
> I think the current definition is suitable for entering at the 16-bit
> entry point.
I agree. I'm going to assume that if we're booting all the way up from
real mode, we're either on real hardware, or some environment that'
Jeremy Fitzhardinge wrote:
>
> Well, I think we can safely say that its something that's only
> meaningful in 32/64-bit mode, so we aren't constrained by the real-mode
> address space.
>
> One of my goals in this project is to make the boot image, in some way,
> completely define which memory it
H. Peter Anvin wrote:
> Well, if we define is as a movable object then it has to be treated as
> such. It's a protocol definition issue. If we define it opaque, though
> -- of for that matter, if we don't -- we should define what memory it
> can live in, though. Right now, the only "available" m
Jeremy Fitzhardinge wrote:
> H. Peter Anvin wrote:
>>> Do we care particularly? If 8 bytes is enough for the subarch, do we
>>> care whether its a pointer or literal? After all, this is just a private
>>> channel between the bootloader and some subarch-specific piece of code
>>> in the kernel.
>>>
H. Peter Anvin wrote:
>> Do we care particularly? If 8 bytes is enough for the subarch, do we
>> care whether its a pointer or literal? After all, this is just a private
>> channel between the bootloader and some subarch-specific piece of code
>> in the kernel.
>>
>>
>
> I see two options: eit
Jeremy Fitzhardinge wrote:
>
>> +Protocol: 2.07+
>> +
>> + A pointer to data that is specific to hardware subarch
>>
>
> Do we care particularly? If 8 bytes is enough for the subarch, do we
> care whether its a pointer or literal? After all, this is just a private
> channel between the boot
Eric W. Biederman wrote:
>
> +Field name: hardware_subarch
> +Type:write
> +Offset/size: 0x23c/4
> +Protocol:2.07+
> +
> + In a paravirtualized environment the hardware low level architectural
> + pieces such as interrupt handling, page table handling, and
> + accessin
On Wed, May 30, 2007 at 04:16:55PM -0700, Jeremy Fitzhardinge wrote:
> Eric W. Biederman wrote:
> > I think we should start there and be prepared to munge the ELF
> > magic number if there are problems. Placing ELF notes is going
> > to require a little work but mostly it should be a matter of
> >
Eric W. Biederman wrote:
> I think we should start there and be prepared to munge the ELF
> magic number if there are problems. Placing ELF notes is going
> to require a little work but mostly it should be a matter of
> copying the from vmlinux.
>
Do you have a semi-current ELF bzImage patch o
H. Peter Anvin wrote:
> Pardon me for saying it, but it's hardly a hardship to add support for a
> single additional constant in existing code. I'm starting to think this
> argument is approaching not just the silly, but downright ridiculous.
>
Well, if the existing code is a standard libelf/l
Rusty Russell wrote:
>
> hpa wrote:
>> Do we have *any* environment that enters the 32-bit code with interrupts
>> enabled? I would think that is unsafe no matter how you do it.
>
> Yeah, the cli there seems strange: maybe it's safe to simply delete it?
>
I suspect it was simply put there as a
Jeremy Fitzhardinge wrote:
>
> I'd really prefer to keep an intact embedded ELF file rather than have a
> semi-ELF file. That way it would be easier to simply load the image and
> point the normal ELF machinery at some offset into the file rather than
> having to have a special handler for "\x7fB
On Sun, 2007-05-27 at 00:47 +0100, Jeremy Fitzhardinge wrote:
> Rusty Russell wrote:
> > You also want to skip the cli: perhaps a separate flag for this is
> > appropriate though.
> >
>
> Not a problem for Xen; it will be trapped+emulated (ie, ignored).
Well, I could do that for lguest as a sp
Eric W. Biederman wrote:
>> What was the problem with ELF bzImage? Is it confirmed to be
>> problematic, or just suspected?
>>
>
> There was a problem, Andrews machine would not the kernel with the ELF
> header. It was not root caused. So we are not certain why.
>
The Vaio? Do you thin
Rusty Russell wrote:
> You also want to skip the cli: perhaps a separate flag for this is
> appropriate though.
>
Not a problem for Xen; it will be trapped+emulated (ie, ignored).
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Rusty Russell wrote:
>>
>> + Bit 6 (write): KEEP_SEGMENTS
>> +Protocol: 2.07+
>> +- if 0, reload the segment registers in the 32bit entry point.
>> +- if 1, do not reload the segment registers in the 32bit entry point.
>> +Assume that %cs %ds %ss %es are all set to flat seg
On Fri, 2007-05-25 at 10:46 -0600, Eric W. Biederman wrote:
> Most of that though is just packaging. The meat of the issue
> is how do we upgrade the bootloader data. Do the changes
> below sound like everything we need?
>
> Field name: loadflags
> Type:modify (obligatory)
>
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
> Well, it seems to be about time to have this conversation again.
>
> A rough overview of the previous thread and requirements is:
>
>1. bzImage would not be a bare ELF file, but it would contain an ELF
> header+file within it
>2. We n
Well, it seems to be about time to have this conversation again.
A rough overview of the previous thread and requirements is:
1. bzImage would not be a bare ELF file, but it would contain an ELF
header+file within it
2. We need some way to add extra ELF notes into that ELF file
3.
22 matches
Mail list logo
