Rusty Russell wrote:
> Well there aren't that many instructions between startup_32 and
> lguest_init at the moment, but I guess if we end up going through
> bzImage decompression it makes more sense...
Yes, that's what I was thinking. If we boot compressed kernels in a
novel environment, there's
On Mon, 2007-04-30 at 22:37 -0700, Jeremy Fitzhardinge wrote:
> Eric W. Biederman wrote:
> > I'm not going to worry about going farther until the patches in flight
> > settle down a little bit, but this looks promising.
> >
>
> Is there any value in adding an "early-putchar" function pointer
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> I'm not going to worry about going farther until the patches in flight
>> settle down a little bit, but this looks promising.
>>
>
> Is there any value in adding an "early-putchar" function pointer into
> the
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Rusty Russell wrote:
>>
>> BTW, wrt. a new "platform type" field, should it go something like this?
>>
>> -0235/3 N/A pad2Unused
>> +0235/1 2.07+ platform_type Runtime platform (see below)
>> +0236/2 N/A pad2
H. Peter Anvin [EMAIL PROTECTED] writes:
Rusty Russell wrote:
BTW, wrt. a new platform type field, should it go something like this?
-0235/3 N/A pad2Unused
+0235/1 2.07+ platform_type Runtime platform (see below)
+0236/2 N/A pad2Unused
Jeremy Fitzhardinge [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
I'm not going to worry about going farther until the patches in flight
settle down a little bit, but this looks promising.
Is there any value in adding an early-putchar function pointer into
the structure somehow? I
On Mon, 2007-04-30 at 22:37 -0700, Jeremy Fitzhardinge wrote:
Eric W. Biederman wrote:
I'm not going to worry about going farther until the patches in flight
settle down a little bit, but this looks promising.
Is there any value in adding an early-putchar function pointer into
the
Rusty Russell wrote:
Well there aren't that many instructions between startup_32 and
lguest_init at the moment, but I guess if we end up going through
bzImage decompression it makes more sense...
Yes, that's what I was thinking. If we boot compressed kernels in a
novel environment, there's
Eric W. Biederman wrote:
> I'm not going to worry about going farther until the patches in flight
> settle down a little bit, but this looks promising.
>
Is there any value in adding an "early-putchar" function pointer into
the structure somehow? I could easily arrange for the domain builder
Rusty Russell wrote:
>
> BTW, wrt. a new "platform type" field, should it go something like this?
>
> -0235/3 N/A pad2Unused
> +0235/1 2.07+ platform_type Runtime platform (see below)
> +0236/2 N/A pad2Unused
> ...
> + platform_type:
> +
On Mon, 2007-04-30 at 21:00 -0700, H. Peter Anvin wrote:
> H. Peter Anvin wrote:
> > Rusty Russell wrote:
> >> It'd be nicer if there were a "struct boot_params" declaration, but we
> >> can't have everything.
> >
> > It's in my patchset-under-development.
> >
> > (Preview snapshot:
> >
H. Peter Anvin wrote:
> Rusty Russell wrote:
>> It'd be nicer if there were a "struct boot_params" declaration, but we
>> can't have everything.
>
> It's in my patchset-under-development.
>
> (Preview snapshot:
> http://userweb.kernel.org/~hpa/setup-snapshot-2007.04.30.patch)
Just pushed out a
On Mon, 2007-04-30 at 20:45 -0700, H. Peter Anvin wrote:
> Rusty Russell wrote:
> >
> > It'd be nicer if there were a "struct boot_params" declaration, but we
> > can't have everything.
>
> It's in my patchset-under-development.
Ah ha: excellent!
> > +typedef unsigned long long u64;
> >
Rusty Russell <[EMAIL PROTECTED]> writes:
> On Mon, 2007-04-30 at 09:34 -0600, Eric W. Biederman wrote:
>> Reading this it occurs to me what I object to wasn't that clear.
>>
>> I have no problem with the testing of %cs to see if we are not in ring0.
>> That part while a little odd is fine, and
Rusty Russell wrote:
>
> It'd be nicer if there were a "struct boot_params" declaration, but we
> can't have everything.
It's in my patchset-under-development.
(Preview snapshot:
http://userweb.kernel.org/~hpa/setup-snapshot-2007.04.30.patch)
> diff -r 9a673a220ad6
On Mon, 2007-04-30 at 09:34 -0600, Eric W. Biederman wrote:
> Reading this it occurs to me what I object to wasn't that clear.
>
> I have no problem with the testing of %cs to see if we are not in ring0.
> That part while a little odd is fine, and we will certainly need a test
> to skip the
Andi Kleen wrote:
>
> It's still unclear to me why exactly you want to rewrite it?
> Are there any particular bugs in the current code you want to fix?
>
It's more the sheer degree of unmaintainability which is grating on my
nerves. There is way too much hocus-pocus going on, and I dare to say
On Mon, Apr 30, 2007 at 04:16:10PM -0700, H. Peter Anvin wrote:
> Eric W. Biederman wrote:
> >
> > I'm tempted to just reload the segments in setup.S, but that might
> > break loadlin support or one of the other bootloaders that starts the
> > kernel in 32bit mode so we need to be careful.
> >
>
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>>
>> I'm tempted to just reload the segments in setup.S, but that might
>> break loadlin support or one of the other bootloaders that starts the
>> kernel in 32bit mode so we need to be careful.
>>
>
> We already load all
Eric W. Biederman wrote:
>
> I'm tempted to just reload the segments in setup.S, but that might
> break loadlin support or one of the other bootloaders that starts the
> kernel in 32bit mode so we need to be careful.
>
We already load all the segments in setup.S. I'm retaining this in my
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>>> I think I'd prefer to have the domain builder decompress/relocate the
>>> kernel from the bzImage and start it directly, rather than have it
>>> decompress/relocate itself, but I'm not really set on that.
>>>
>>
Jeremy Fitzhardinge wrote:
> I haven't checked if it already has this, but it would be nice if the
> bzImage had a memory range/list of memory ranges it needs mapped to get
> the kernel on its feet, so that the domain builder can just go and map
> those areas for it (either P==V mappings, or with
Eric W. Biederman wrote:
>> I think I'd prefer to have the domain builder decompress/relocate the
>> kernel from the bzImage and start it directly, rather than have it
>> decompress/relocate itself, but I'm not really set on that.
>>
>
> We can change a lot more implementation details
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> I have several ideas on how we can make this work but first I have to
>> ask what is it that you are trying to accomplish?
>>
>
> The requirements are:
>
>1. the domain builder needs to get various information
Eric W. Biederman wrote:
> I have several ideas on how we can make this work but first I have to
> ask what is it that you are trying to accomplish?
>
The requirements are:
1. the domain builder needs to get various information about the
guest kernel by inspecting its ELF notes
2.
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>>
>> Sure.
>>
>> Peter do we want to use the bootloader byte and assign lguest it's own
>> bootloader type or do we want to add another field specific to
>> paravirtualized environments?
>>
>
> The bootloader byte is
Eric W. Biederman wrote:
>
> Sure.
>
> Peter do we want to use the bootloader byte and assign lguest it's own
> bootloader type or do we want to add another field specific to
> paravirtualized environments?
>
The bootloader byte is already a bit too overused; I'm a little scared
that we're
Rusty Russell <[EMAIL PROTECTED]> writes:
> On Sun, 2007-04-29 at 21:38 -0700, H. Peter Anvin wrote:
>> Rusty Russell wrote:
>> >
>> > Dammit, Eric, you spend a lot of time using words like "insane" where
>> > you mean we didn't do everything all at once.
>> >
>> > It's *not* clear that using
Rusty Russell [EMAIL PROTECTED] writes:
On Sun, 2007-04-29 at 21:38 -0700, H. Peter Anvin wrote:
Rusty Russell wrote:
Dammit, Eric, you spend a lot of time using words like insane where
you mean we didn't do everything all at once.
It's *not* clear that using %esi is sane, but
Eric W. Biederman wrote:
Sure.
Peter do we want to use the bootloader byte and assign lguest it's own
bootloader type or do we want to add another field specific to
paravirtualized environments?
The bootloader byte is already a bit too overused; I'm a little scared
that we're going to
H. Peter Anvin [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Sure.
Peter do we want to use the bootloader byte and assign lguest it's own
bootloader type or do we want to add another field specific to
paravirtualized environments?
The bootloader byte is already a bit too
Eric W. Biederman wrote:
I have several ideas on how we can make this work but first I have to
ask what is it that you are trying to accomplish?
The requirements are:
1. the domain builder needs to get various information about the
guest kernel by inspecting its ELF notes
2. we
Jeremy Fitzhardinge [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
I have several ideas on how we can make this work but first I have to
ask what is it that you are trying to accomplish?
The requirements are:
1. the domain builder needs to get various information about the
Eric W. Biederman wrote:
I think I'd prefer to have the domain builder decompress/relocate the
kernel from the bzImage and start it directly, rather than have it
decompress/relocate itself, but I'm not really set on that.
We can change a lot more implementation details arbitrarily if
Jeremy Fitzhardinge wrote:
I haven't checked if it already has this, but it would be nice if the
bzImage had a memory range/list of memory ranges it needs mapped to get
the kernel on its feet, so that the domain builder can just go and map
those areas for it (either P==V mappings, or with a
Jeremy Fitzhardinge [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
I think I'd prefer to have the domain builder decompress/relocate the
kernel from the bzImage and start it directly, rather than have it
decompress/relocate itself, but I'm not really set on that.
We can change a
Eric W. Biederman wrote:
I'm tempted to just reload the segments in setup.S, but that might
break loadlin support or one of the other bootloaders that starts the
kernel in 32bit mode so we need to be careful.
We already load all the segments in setup.S. I'm retaining this in my
rewrite.
H. Peter Anvin [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
I'm tempted to just reload the segments in setup.S, but that might
break loadlin support or one of the other bootloaders that starts the
kernel in 32bit mode so we need to be careful.
We already load all the segments in
On Mon, Apr 30, 2007 at 04:16:10PM -0700, H. Peter Anvin wrote:
Eric W. Biederman wrote:
I'm tempted to just reload the segments in setup.S, but that might
break loadlin support or one of the other bootloaders that starts the
kernel in 32bit mode so we need to be careful.
We
Andi Kleen wrote:
It's still unclear to me why exactly you want to rewrite it?
Are there any particular bugs in the current code you want to fix?
It's more the sheer degree of unmaintainability which is grating on my
nerves. There is way too much hocus-pocus going on, and I dare to say
On Mon, 2007-04-30 at 09:34 -0600, Eric W. Biederman wrote:
Reading this it occurs to me what I object to wasn't that clear.
I have no problem with the testing of %cs to see if we are not in ring0.
That part while a little odd is fine, and we will certainly need a test
to skip the protected
Rusty Russell wrote:
It'd be nicer if there were a struct boot_params declaration, but we
can't have everything.
It's in my patchset-under-development.
(Preview snapshot:
http://userweb.kernel.org/~hpa/setup-snapshot-2007.04.30.patch)
diff -r 9a673a220ad6 Documentation/lguest/lguest.c
---
Rusty Russell [EMAIL PROTECTED] writes:
On Mon, 2007-04-30 at 09:34 -0600, Eric W. Biederman wrote:
Reading this it occurs to me what I object to wasn't that clear.
I have no problem with the testing of %cs to see if we are not in ring0.
That part while a little odd is fine, and we will
On Mon, 2007-04-30 at 20:45 -0700, H. Peter Anvin wrote:
Rusty Russell wrote:
It'd be nicer if there were a struct boot_params declaration, but we
can't have everything.
It's in my patchset-under-development.
Ah ha: excellent!
+typedef unsigned long long u64;
typedef uint32_t
H. Peter Anvin wrote:
Rusty Russell wrote:
It'd be nicer if there were a struct boot_params declaration, but we
can't have everything.
It's in my patchset-under-development.
(Preview snapshot:
http://userweb.kernel.org/~hpa/setup-snapshot-2007.04.30.patch)
Just pushed out a git tree:
On Mon, 2007-04-30 at 21:00 -0700, H. Peter Anvin wrote:
H. Peter Anvin wrote:
Rusty Russell wrote:
It'd be nicer if there were a struct boot_params declaration, but we
can't have everything.
It's in my patchset-under-development.
(Preview snapshot:
Rusty Russell wrote:
BTW, wrt. a new platform type field, should it go something like this?
-0235/3 N/A pad2Unused
+0235/1 2.07+ platform_type Runtime platform (see below)
+0236/2 N/A pad2Unused
...
+ platform_type:
+ For
Eric W. Biederman wrote:
I'm not going to worry about going farther until the patches in flight
settle down a little bit, but this looks promising.
Is there any value in adding an early-putchar function pointer into
the structure somehow? I could easily arrange for the domain builder to
Rusty Russell <[EMAIL PROTECTED]> writes:
> On Sun, 2007-04-29 at 21:38 -0700, H. Peter Anvin wrote:
>> Rusty Russell wrote:
>> >
>> > Dammit, Eric, you spend a lot of time using words like "insane" where
>> > you mean we didn't do everything all at once.
>> >
>> > It's *not* clear that using
On Sun, 2007-04-29 at 21:38 -0700, H. Peter Anvin wrote:
> Rusty Russell wrote:
> >
> > Dammit, Eric, you spend a lot of time using words like "insane" where
> > you mean we didn't do everything all at once.
> >
> > It's *not* clear that using %esi is sane, but nothing in the current
> > code
On Sun, 2007-04-29 at 00:24 -0700, Jeremy Fitzhardinge wrote:
> Is it possible to decompress and extract the kernel image from the
> bzImage without executing it? Ie, is there enough information to find
> the compressed data part of the bzImage by inspection?
>
> At some point we'll need to
Rusty Russell wrote:
>
> Dammit, Eric, you spend a lot of time using words like "insane" where
> you mean we didn't do everything all at once.
>
> It's *not* clear that using %esi is sane, but nothing in the current
> code prevents that.
>
Why not?
-hpa
-
To unsubscribe from this
On Sun, 2007-04-29 at 09:11 -0600, Eric W. Biederman wrote:
> Right now I'm a little frustrated that insanity below slipped into
> head.S right after the 32bit entry point after the review said
> use the normal linux parameters for parameter passing.
>
> > #ifdef CONFIG_PARAVIRT
> >
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Jeremy Fitzhardinge wrote:
>> Eric W. Biederman wrote:
>>> All it does is set a flag that tells a bootloader.
>>> "Hey. I can run when loaded a non-default address, and this is what
>>> you have to align me to."
>>>
>>> All relocation processing
Jeremy Fitzhardinge wrote:
> Eric W. Biederman wrote:
>> All it does is set a flag that tells a bootloader.
>> "Hey. I can run when loaded a non-default address, and this is what
>> you have to align me to."
>>
>> All relocation processing happens in the kernel itself.
>>
>
> Is it possible
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> All it does is set a flag that tells a bootloader.
>> "Hey. I can run when loaded a non-default address, and this is what
>> you have to align me to."
>>
>> All relocation processing happens in the kernel itself.
>>
Eric W. Biederman wrote:
> All it does is set a flag that tells a bootloader.
> "Hey. I can run when loaded a non-default address, and this is what
> you have to align me to."
>
> All relocation processing happens in the kernel itself.
>
Is it possible to decompress and extract the kernel
Eric W. Biederman wrote:
All it does is set a flag that tells a bootloader.
Hey. I can run when loaded a non-default address, and this is what
you have to align me to.
All relocation processing happens in the kernel itself.
Is it possible to decompress and extract the kernel image from
Jeremy Fitzhardinge [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
All it does is set a flag that tells a bootloader.
Hey. I can run when loaded a non-default address, and this is what
you have to align me to.
All relocation processing happens in the kernel itself.
Is it possible
Jeremy Fitzhardinge wrote:
Eric W. Biederman wrote:
All it does is set a flag that tells a bootloader.
Hey. I can run when loaded a non-default address, and this is what
you have to align me to.
All relocation processing happens in the kernel itself.
Is it possible to decompress and
H. Peter Anvin [EMAIL PROTECTED] writes:
Jeremy Fitzhardinge wrote:
Eric W. Biederman wrote:
All it does is set a flag that tells a bootloader.
Hey. I can run when loaded a non-default address, and this is what
you have to align me to.
All relocation processing happens in the kernel
On Sun, 2007-04-29 at 09:11 -0600, Eric W. Biederman wrote:
Right now I'm a little frustrated that insanity below slipped into
head.S right after the 32bit entry point after the review said
use the normal linux parameters for parameter passing.
#ifdef CONFIG_PARAVIRT
Rusty Russell wrote:
Dammit, Eric, you spend a lot of time using words like insane where
you mean we didn't do everything all at once.
It's *not* clear that using %esi is sane, but nothing in the current
code prevents that.
Why not?
-hpa
-
To unsubscribe from this list: send
On Sun, 2007-04-29 at 00:24 -0700, Jeremy Fitzhardinge wrote:
Is it possible to decompress and extract the kernel image from the
bzImage without executing it? Ie, is there enough information to find
the compressed data part of the bzImage by inspection?
At some point we'll need to change
On Sun, 2007-04-29 at 21:38 -0700, H. Peter Anvin wrote:
Rusty Russell wrote:
Dammit, Eric, you spend a lot of time using words like insane where
you mean we didn't do everything all at once.
It's *not* clear that using %esi is sane, but nothing in the current
code prevents that.
Rusty Russell [EMAIL PROTECTED] writes:
On Sun, 2007-04-29 at 21:38 -0700, H. Peter Anvin wrote:
Rusty Russell wrote:
Dammit, Eric, you spend a lot of time using words like insane where
you mean we didn't do everything all at once.
It's *not* clear that using %esi is sane, but
On Sat, Apr 28, 2007 at 02:46:18PM -0600, Eric W. Biederman wrote:
> "H. Peter Anvin" <[EMAIL PROTECTED]> writes:
>
> > Eric W. Biederman wrote:
> >>
> >> The boot protocol change is in 2.6.21 for arch/i386.
> >>
> >> HPA looked at it a while ago.
> >>
> >> All it does is set a flag that tells
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>>
>> The boot protocol change is in 2.6.21 for arch/i386.
>>
>> HPA looked at it a while ago.
>>
>> All it does is set a flag that tells a bootloader.
>> "Hey. I can run when loaded a non-default address, and this is what
No specific concern; the patch description did not say that bootloader
people had ACK'd the change, or describe the testing regimen.
Just reading the patch, the impact and preparation were unknowns.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Eric W. Biederman wrote:
>
> The boot protocol change is in 2.6.21 for arch/i386.
>
> HPA looked at it a while ago.
>
> All it does is set a flag that tells a bootloader.
> "Hey. I can run when loaded a non-default address, and this is what
> you have to align me to."
>
> All relocation
Jeff Garzik <[EMAIL PROTECTED]> writes:
> Andi Kleen wrote:
>> From: Vivek Goyal <[EMAIL PROTECTED]>
>>
>>
>> o Extend the bzImage protocol (same as i386) to allow bzImage loaders to
>> load the protected mode kernel at non-1MB address. Now protected mode
>> component is relocatable and can
Jeff Garzik [EMAIL PROTECTED] writes:
Andi Kleen wrote:
From: Vivek Goyal [EMAIL PROTECTED]
o Extend the bzImage protocol (same as i386) to allow bzImage loaders to
load the protected mode kernel at non-1MB address. Now protected mode
component is relocatable and can be loaded at
Eric W. Biederman wrote:
The boot protocol change is in 2.6.21 for arch/i386.
HPA looked at it a while ago.
All it does is set a flag that tells a bootloader.
Hey. I can run when loaded a non-default address, and this is what
you have to align me to.
All relocation processing
No specific concern; the patch description did not say that bootloader
people had ACK'd the change, or describe the testing regimen.
Just reading the patch, the impact and preparation were unknowns.
Jeff
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
H. Peter Anvin [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
The boot protocol change is in 2.6.21 for arch/i386.
HPA looked at it a while ago.
All it does is set a flag that tells a bootloader.
Hey. I can run when loaded a non-default address, and this is what
you have to align
On Sat, Apr 28, 2007 at 02:46:18PM -0600, Eric W. Biederman wrote:
H. Peter Anvin [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
The boot protocol change is in 2.6.21 for arch/i386.
HPA looked at it a while ago.
All it does is set a flag that tells a bootloader.
Hey. I
101 - 176 of 176 matches
Mail list logo
