[PATCH 11/12] ppc64: Move fwnmi vectors into trampoline area
Michael Ellerman
michael at ellerman.id.au
Tue Aug 30 17:28:34 EST 2005
On Tue, 30 Aug 2005 17:22, Milton Miller wrote:
> > Yeah it's reserved up to 0x3000 in the green book. My reasoning was
> > that when
> > a chip comes out that uses those addresses we'll know about it and we
> > can
> > move the fwmni vectors some where else, in the meantime it's just empty
> > space.
>
> By following the architecture, we have a chance of booting on CPUs that
> we don't know about yet. We also find out with a more deterministic
> crash when we are slow to add support for a new feature.
>
> Following the architecture will save us in the long run.
> [success story censored]
Ok, I'll fix it.
> > Do you mean the old and new vectors should be in the same place, or
> > different
> > places? If they're in the same place then perhaps we don't even need to
> > re-register them?
>
> I'm saying if rtas and the hypervisor accept the new address then
> we don't have to worry. If they don't accept an address, then we
> must reserve a fixed address in page 3 and only support dump of a
> base kernel of some minimum level.
Right.
> So let us test now if the address is accepted, and if so not worry
> about a "low" vector or trampoline for these entry points.
Anton said they had to be < 32 MB, so we'll still need a trampoline, although
perhaps not at a fixed address.
As an aside, if we do reuse the same address for the second kernel, is there
any chance we can be broken by fwmni vectors firing before the second kernel
is ready for them?
cheers
--
Michael Ellerman
IBM OzLabs
email: michael:ellerman.id.au
inmsg: mpe:jabber.org
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20050830/58bb064c/attachment.pgp
More information about the Linuxppc64-dev
mailing list