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
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
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"
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:
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
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
> +
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
+ accessing
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 bootloader and
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: either we make
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.
I see
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 memory
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 needs
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's
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 that 32-bit
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.
J
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 jumping to that
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
>
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
copying
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
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 on
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
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
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
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
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
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
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
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)
>
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)
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 segments with
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 think we
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
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 special
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 \x7fBZE or
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 belts
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
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
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.
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.
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 need some
44 matches
Mail list logo
