"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>>
>> I have this vague memory of liking 0x3c because if we do happen to use
>> more room then we intended the consequences are pretty benign.
>>
>> But that is a pretty minor consequence.
>>
I meant to say it is a pretty
Eric W. Biederman wrote:
>
> I have this vague memory of liking 0x3c because if we do happen to use
> more room then we intended the consequences are pretty benign.
>
> But that is a pretty minor consequence.
>
That's a dangerous assumption (besides, it's likely wrong, since there
are only two
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>>
>> My notes show 0x5c reserved for additional apm_bios_info, although
>> of the top of my head I don't know how realistic that is.
>>
>> 0x1e4 does look available.
>>
>> It has been a long time since I made that choice,
Eric W. Biederman wrote:
>
> My notes show 0x5c reserved for additional apm_bios_info, although
> of the top of my head I don't know how realistic that is.
>
> 0x1e4 does look available.
>
> It has been a long time since I made that choice, and I do see that
> looking at struct screen_info I did
Eric W. Biederman wrote:
>
> My notes show 0x5c reserved for additional apm_bios_info, although
> of the top of my head I don't know how realistic that is.
>
> 0x1e4 does look available.
>
> It has been a long time since I made that choice, and I do see that
> looking at struct screen_info I did
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>>> Oh, right. And this runs with interrupts off, so you only need one
>>> dword. That's fine, of course, although the location is a bit awkward.
>>
>> Yep. That is what I found when surveyed the available locations.
>
> L
Eric W. Biederman wrote:
>> Oh, right. And this runs with interrupts off, so you only need one
>> dword. That's fine, of course, although the location is a bit awkward.
>
> Yep. That is what I found when surveyed the available locations.
Look at the structure definition I just posted; I think
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>>> I saw the 0x40(%esi) stack stuff, and I'm utterly puzzled by it. There
>>> is no reason one can't set up %esp to point to a hunk in ordinary memory
>>> and use it?
>>
>> That is what we are doing, remind me to make
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Jeremy Fitzhardinge wrote:
>>
>> Yes, that's more or less the same code, aside from using 0x40(%esi) as a
>> stack. Would that be OK here?
>>
>
> I saw the 0x40(%esi) stack stuff, and I'm utterly puzzled by it. There
> is no reason one can't set u
Eric W. Biederman wrote:
>>>
>> I saw the 0x40(%esi) stack stuff, and I'm utterly puzzled by it. There
>> is no reason one can't set up %esp to point to a hunk in ordinary memory
>> and use it?
>
> That is what we are doing, remind me to make certain we have this
> field of the boot protocol docu
Jeremy Fitzhardinge wrote:
>
> Yes, that's more or less the same code, aside from using 0x40(%esi) as a
> stack. Would that be OK here?
>
I saw the 0x40(%esi) stack stuff, and I'm utterly puzzled by it. There
is no reason one can't set up %esp to point to a hunk in ordinary memory
and use it?
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> Using 0x40 as a stack would be ok.
>>
>
> OK.
>
>> There are issues with CONFIG_RELOCATABLE and V!=P that I'm not
>> comfortable with yet, because we can't tell the difference.
>
> But it doesn't matter in this case,
Eric W. Biederman wrote:
> Using 0x40 as a stack would be ok.
>
OK.
> There are issues with CONFIG_RELOCATABLE and V!=P that I'm not
> comfortable with yet, because we can't tell the difference.
But it doesn't matter in this case, does it? It just needs to find the
current address, whether i
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
> BTW, I should have marked this as an RFC comment, rather than an actual
> submission. We don't need it for .22.
>
>> NAK.
>>
>> Skipping the segment register load is likely fine.
>> Supporting V!=P at startup_32 is not.
>>
>
> Why?
>
>> Assum
Eric W. Biederman wrote:
> Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
>
>
>> When the paravirt dispatcher gets run immediately on entry to
>> startup_32, the bss isn't cleared. This happens to work if the
>> hypervisor's domain builder loaded the complete kernel image and
>> cleared the bs
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
> When the paravirt dispatcher gets run immediately on entry to
> startup_32, the bss isn't cleared. This happens to work if the
> hypervisor's domain builder loaded the complete kernel image and
> cleared the bss for us, but this may not always be
When the paravirt dispatcher gets run immediately on entry to
startup_32, the bss isn't cleared. This happens to work if the
hypervisor's domain builder loaded the complete kernel image and
cleared the bss for us, but this may not always be true (for example,
if we're running out of a decompressed
17 matches
Mail list logo
