"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
16 matches
Mail list logo
